Bug 68373 - Unable to launch project from project directory with spaces in file name
Unable to launch project from project directory with spaces in file name
Status: RESOLVED FIXED
Product: platform
Classification: Unclassified
Component: -- Other --
5.x
PC Linux
: P3 (vote)
: 5.x
Assigned To: Jesse Glick
issues@platform
: SPACE_IN_PATH
Depends on:
Blocks: 61551
  Show dependency treegraph
 
Reported: 2005-11-09 12:45 UTC by ahe
Modified: 2008-12-22 23:21 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
:


Attachments
space suppport patch (2.81 KB, text/plain)
2005-11-09 22:35 UTC, Martin Krauskopf
Details
space suppport patch (a) (2.81 KB, patch)
2005-11-09 23:05 UTC, Martin Krauskopf
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description ahe 2005-11-09 12:45:47 UTC
Product Version       = NetBeans IDE Dev (Build 200510311820)
  Operating System      = Linux version 2.6.10-1.771_FC2 running on i386
  Java; VM; Vendor      = 1.6.0-ea; Java HotSpot(TM) Client VM 1.6.0-ea-b57; Sun
Microsystems Inc.

I created a NetBeans project using the new wizards.  I placed the project
in "/home/ahe/ws/Annotation Processing Module".  When I try to run the project,
I get this error:

Deploying test module /home/ahe/ws/Annotation...
java.io.FileNotFoundException: /home/ahe/ws/Annotation (No such file or directory)
        at java.io.FileInputStream.open(Native Method)
        at java.io.FileInputStream.<init>(FileInputStream.java:106)
        at org.netbeans.Util.makeTempJar(Util.java:47)
        at org.netbeans.StandardModule.ensurePhysicalJar(StandardModule.java:227)
        at org.netbeans.StandardModule.loadManifest(StandardModule.java:253)
        at org.netbeans.StandardModule.<init>(StandardModule.java:104)
        at org.netbeans.ModuleFactory.create(ModuleFactory.java:37)
        at org.netbeans.ModuleManager.create(ModuleManager.java:474)
        at
org.netbeans.core.startup.ModuleSystem.deployTestModule(ModuleSystem.java:306)
        at
org.netbeans.core.startup.TestModuleDeployer.deployTestModule(TestModuleDeployer.java:40)
        at
org.netbeans.core.startup.CLITestModuleReload.cli(CLITestModuleReload.java:47)
        at org.netbeans.CLIHandler.notifyHandlers(CLIHandler.java:173)
        at org.netbeans.CLIHandler.access$000(CLIHandler.java:42)
        at org.netbeans.CLIHandler$1.exec(CLIHandler.java:493)
        at org.netbeans.CLIHandler.finishInitialization(CLIHandler.java:342)
        at org.netbeans.Main.finishInitialization(Main.java:184)
        at org.netbeans.core.NonGui.run(NonGui.java:136)
        at org.netbeans.core.startup.Main.start(Main.java:386)
        at org.netbeans.core.startup.TopThreadGroup.run(TopThreadGroup.java:90)
        at java.lang.Thread.run(Thread.java:620)
Post-initialization command-line options could not be run.
Comment 1 Miloslav Metelka 2005-11-09 13:36:46 UTC
Reassigning to core/modules for evaluation
Comment 2 Jesse Glick 2005-11-09 19:03:03 UTC
apisupport is fine, as is core/launcher/unix/nbexec (AFAICT). But
ide/launcher/unix/netbeans cannot handle spaces in non-userdir params. And I
have no idea how to fix it to do so - spent some time trying during the fix of
issue #61551 before giving up. If the launcher were written in Perl it would be
trivial, but in the Bourne shell this is very hard. The meat of the problem is
that although you can pass "$@" along to a child script unchanged, there is no
apparent way to examine and replace individual elements of this list without
discarding information about the location of argument breaks. Maybe there is
some trick with sed or something, but I have no idea how to verify that every
Unixish platform we deploy to would have a version installed which is compatible
with whatever args it is given.
Comment 3 Martin Krauskopf 2005-11-09 22:34:24 UTC
Wrapper-quoting all parameters in ide/launcher/unix/netbeans could help. But
also need to hack a little core/launcher/unix/nbexec to strip redundant quotes
when it is appropriate to make it work with the case command. I'm not able to
explain :) Better to see the attached patch which seems to work somehow. Using
very simple sed - so shouldn't be the problem on other platforms. Not sure how
much 'remembering' is supported. Could be workarounded by double call to sed
eventually.
Comment 4 Martin Krauskopf 2005-11-09 22:35:08 UTC
Created attachment 26805 [details]
space suppport patch
Comment 5 Martin Krauskopf 2005-11-09 23:05:03 UTC
There is a little bug. Attaching fixed version....
Comment 6 Martin Krauskopf 2005-11-09 23:05:53 UTC
Created attachment 26806 [details]
space suppport patch (a)
Comment 7 ahe 2005-11-09 23:28:26 UTC
The proposed fix is at best brittle.  It would be better if you didn't try to
filter out the --userdir option in /cvs/ide/launcher/unix/netbeans,v.  In that
case, setting userdir can be written like this:

userdir="${netbeans_default_userdir}"
founduserdir=""
for opt in  "$@" ; do
    if [ "${founduserdir}" ] ; then
        userdir="$opt"
        break
    elif [ "$opt" == "--userdir" ] ; then
        founduserdir="yes"
    esac
done

Then later launch nbexec like this:


launchNbexec() {
    if [ "${founduserdir}" ] ; then
        exec "$nbexec" \
            "$@"
    else
        sh "$nbexec" \
            --userdir "${userdir}" \
            "$@"
    fi
}

launchNbexec \
            --jdkhome "$netbeans_jdkhome" \
            --branding nb \
            --clusters "$netbeans_clusters" \
            --userdir "${userdir}" \
            -J-Dnetbeans.importclass=org.netbeans.upgrade.AutoUpgrade \
            -J-Dnetbeans.accept_license_class=org.netbeans.license.AcceptLicense \
            ${netbeans_default_options} \
            "$@"
Comment 8 ahe 2005-11-09 23:30:18 UTC
I forgot to remove --userdir from the argument list to launchNbexec:

launchNbexec \
            --jdkhome "$netbeans_jdkhome" \
            --branding nb \
            --clusters "$netbeans_clusters" \
            -J-Dnetbeans.importclass=org.netbeans.upgrade.AutoUpgrade \
            -J-Dnetbeans.accept_license_class=org.netbeans.license.AcceptLicense \
            ${netbeans_default_options} \
            "$@"
Comment 9 Jan Chalupa 2005-11-09 23:31:29 UTC
'ide' -> 'core'
Comment 10 Jesse Glick 2005-11-10 01:11:52 UTC
I much prefer Peter's approach. Should also be applied to
apisupport/harness/release/launchers/app.sh. Unfortunately we cannot use it in
nbexec, which still hacks around spaces by inserting and then later stripping "
chars, since nbexec needs to remove some args (like --cp or -J*) before passing
on to the Java launcher. However it could help with the bug reported here.
Someone would also need to retest all the scenarios in #61551 with such a change
to make sure nothing regressed. Will do for 5.0 if I can find the time, but in
the meantime users are well advised to avoid spaces in directory names generally.
Comment 11 Martin Krauskopf 2005-11-10 02:49:01 UTC
Ummm. Still not sure in which scenario the second patch wouldn't work - other
thing is that it is not as elegant ;) (wrapping all parameters). I would have to
try it. The main culprit is nbexec anyway which must count with both, non-quote
and quote parameters, since it could be called from another scripts or command
line in more ways.
Otherwise org.netbeans.Main could complain somehow (don't remember how exactly)
because some parameter will not be noticed (effectivelly ignored) in nbexec case
command. There are surely more ways.
Very sensitive part. Something should be intergratet soon or better for post-5.0
probably.
Comment 12 Jesse Glick 2005-11-10 03:13:56 UTC
"nbexec [...] must count with both, non-quote and quote parameters, since it
could be called from another scripts or command line in more ways" - I don't
think so. The convention for Unix executables (unlike Windows) is that char
**argv should be exactly what it seems (only 0x00 is really forbidden); if the
caller is a shell script then it is the caller's responsibility to quote any
args containing spaces... and *not* to include quote characters themselves in
args unless you really wanted them:

nbexec --reload "/tmp/Jesse's module"
^^^^^^ ^^^^^^^^  ^^^^^^^^^^^^^^^^^^^
[0]    [1]       [2]
Comment 13 ahe 2005-11-10 04:01:00 UTC
Perhaps you should consider using a small C launcher.
Comment 14 Jesse Glick 2005-11-10 04:36:08 UTC
We would rather not have to maintain binaries for every Unixish platform: Linux
x86, Solaris SPARC, Mac OS X, Solaris x86, Linux x86_64, HPUX, Irix, AIX, ....
Every minor launcher source change would require recompilation for every
possible platform, which would be a huge headache for us. It's bad enough to
have to recompile the Windows launcher, but at least there are plenty of people
around who run Windows and can check in a new .exe to CVS occasionally.

As I mentioned, Perl would make an ideal launcher language - low overhead,
(pseudo-)interpreted, thorough OS integration, etc. - but I think we cannot rely
on all of our users having Perl installed. Almost certainly every Linux user
will, but I do not know about other Unixish systems.
Comment 15 Martin Krauskopf 2005-11-10 06:43:01 UTC
> re quotes vs. non-quotes.

Yes, right. Note that the sed regexp strips only beginning *and* ending quote.
Shouldn't hurt in allmost all cases. Happy bashing :)
Comment 16 Jesse Glick 2005-12-06 02:35:30 UTC
Applying a minor variant of Peter's fix.

committed     Up-To-Date  1.28        ide/launcher/unix/netbeans


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo