Falls on any module. I try random modules from AU. IDE completely
falls, no module installed, IDE restrats again and again. Must be
killed. It is at least NB 3.3.1 problem.

the problem is in the space character in "Programming Projects" not th
e dot.  This bug has been fixed for NB 3.4.  See issue 12183

*** This issue has been marked as a duplicate of 12183 ***

Do you know of a dot-related bug? There is definately a dot-related
problem with downloading modules from autoupdate into a directory with
a dot in the name. Or should I reopen this one?

This is not a space in path problem. It is a dot in path problem. I
has been verified for sure in the kjava module: bugtraq 4650798

And I think it is part of the OS X user problem quoted above as well.
The reason I think so is this snipped of output:
"Projects/NetBeans3/3/1"

(directory was named "Programming Projects/NetBeans3.3.1")

> And I think it is part of the OS X user problem quoted above as
> well. The reason I think so is this snipped of output: 
> "Projects/NetBeans3/3/1"

this is exactly the effect of bug #12183.  Jan, you must eliminate the
space from the pathnames, leave only the dots there and try again. 
Otherwise how can you be sure that this is a dot problem?

#12183 is fixed only for 3.4dev not for 3.3.1 nor Orion.
I just tried auto-update object browser module with
userdir=/tmp/3.4dev using latest 3.4dev build.  Worked perfectly

*** This issue has been marked as a duplicate of 12183 ***

I don't agree that this issue is duplicate of bug #12183. It is more
like a JDK problem. The problem reported for Mac is probably the same
as bug #12183. 

Steps to reproduce (on Windoze):
1) create c:\test.test\test.bat
2) use Runtime.exec("c:\test.test\test") to execute test.bat

Result is:
Exception in thread "main" java.io.IOException: CreateProcess:
c:\work\test.test
\test error=2
        at java.lang.Win32Process.create(Native Method)
        at java.lang.Win32Process.<init>(Win32Process.java:66)
        at java.lang.Runtime.execInternal(Native Method)
        at java.lang.Runtime.exec(Runtime.java:551)
        at java.lang.Runtime.exec(Runtime.java:418)
        at java.lang.Runtime.exec(Runtime.java:361)
        at java.lang.Runtime.exec(Runtime.java:325)
        at test.TestExecDot.main(TestExecDot.java:26)

(2 The system cannot find the file specified. ERROR_FILE_NOT_FOUND)

It seems that JDK is looking for the last dot in the pathname and
considers everything after the dot as an extension.

If Runtime.exec("c:\test.test\test.bat") is used, it works well. Also,
it can work on other OSs but I haven't tested it.

I can affect everyone who executes external commands. We, for
instance, rely on this mechanism because we execute the same
executable on different OSs (emulator on Unix, emulator.exe or
emulator.bat on windows) and we cannot change the implementation of
3rd party emulators.

The question is whether it can be workarounded in NbProcessDescriptor.

Martin, you contradict yourself.  Firstly you said

> I don't agree that this issue is duplicate of bug #12183.

but you went on and said that the original problem reported by the Mac
user is a duplicate.  You then you described a problem which is not in
the original bug report at all.

Please close this issue and report your problem as a separate bug
against core/execution

Trung, from my point of view, there are two descriptions of the
problem, originally reported by Jam Benway:
1) In the kjava module (ffj) having an emulator installed in such a
directory causes
the emulator to fail (on Windows 2000 and possibly other OS's).
NbProcessDescriptor is used for the execution and everyone who uses it
for the execution may have the same problem. I think this problem is
caused by JDK and I raised the question, whether it is possible to
workaround this problem in NbProcessDescriptor.

2) problem previously reported by someone on nbdev and added by Jan to
this issues because it seemed related.

I think that [1] is another problem than bug #12183 while [2] is
probably the same as bug #12183.
Do you see any contradiction? I not.

The reported problem is [1], [2] was used by Jan because she thougt it
was just another symptom of the same problem. I helped you to identify
the problem. I don't see any reason to create a new issue.

Martin, my point is that we should file a separate report for separate
problem.  Otherwise we would have only one issue "The IDE does not
work as expected" and keep fix/verify/reopen it again and again.

The execution problem should have a summary "dot in pathnames causes
external execution to fail" and would be filed against core/execution.  

But if you insist to have it in this report, fine.  I just tried to
make our life (core developers') a bit easier.  

Martin, I think you evaluated the problem very well. And I thank you
for doing that.

> Steps to reproduce (on Windoze):
> 1) create c:\test.test\test.bat
> 2) use Runtime.exec("c:\test.test\test") to execute test.bat
>
> Result is:
> Exception in thread "main" java.io.IOException: CreateProcess:
> c:\work\test.test
> \test error=2

I am very sorry but can you suggest how can we workaround this? Check
for OS type and write OS specific code to NbProcessDescriptor? I
cannot agree with this - we would eventually end up in code written
for all supported platforms. So, I am closing this as WONTFIX but I
have created an issue for the JDK team under number 4683032. Please
add your comments or change priority over there (I have added both of
you to the interest list over there).

The corresponding bug in JDK has been closed as invalid - you have to
pass different string to the command line interpreter to work
correctly. Please check
http://developer.java.sun.com/developer/bugParade/bugs/4661152.html

Resolved for 3.4.x or earlier, no new info since then -> verified.

Resolved for 3.4.x or earlier, no new info since then -> closing.