Community
Participate
Working Groups
New installation on virgin Windows 8 machine. Launched eclipse with default workspace location. User name has space in it e.g. "S HILLS" New Sync project with no local toolchain. Project name is "shallow" Build seems to work ok (local doesn't really matter I suppose) but gives the following annoying error: 11:58:00 **** Clean-only build of configuration Default for project shallow **** make clean /bin/bash: line 0: export: `HILLSworkspaceshallow"': not a valid identifier Unloading compiler-dependent module openmpi/1.4.3 Note: mpicc appears to invoke gcc rm -f shallow calc.o copy.o diag.o init.o main.o time.o tstep.o worker.o dump.o core > Shell Completed (exit code = 0) 11:58:04 Build Finished (took 4s.158ms) ===========and also: 12:15:21 **** Build of configuration Default for project shallow **** make all /bin/bash: line 0: export: `HILLSworkspaceshallow"': not a valid identifier Unloading compiler-dependent module openmpi/1.4.3 Note: mpicc appears to invoke gcc mpicc -g -c -o calc.o calc.c mpicc -g -c -o copy.o copy.c mpicc -g -c -o diag.o diag.c mpicc -g -c -o init.o init.c mpicc -g -c -o main.o main.c mpicc -g -c -o time.o time.c mpif90 -g -c -o tstep.o tstep.f90 mpicc -g -c -o worker.o worker.c mpicc -g -c -o dump.o dump.c mpicc -g -o shallow calc.o copy.o diag.o init.o main.o time.o tstep.o worker.o dump.o -lm -lgfortran > Shell Completed (exit code = 0) 12:15:27 Build Finished (took 5s.905ms)
I presume the user's home directory also has a space in it, which may be what is causing the problem. I'll see if I can find where it is getting used and escape the space. However, a space in a username is not posix compliant, so I can't guarantee that nothing else will break.
Now I'm not sure what this bug is about. What do you mean "workspace path"?
Yes exactly. The user home directory has a space in it. So Windows supports it. Can you tell I didn't set up this machine? I almost changed the default workspace path when I launched eclipse the first time, but decided it was worth testing..and it was.
So the remote host is Windows? This is not a supported configuration.
Sorry. Client is parallel package on windows 8. PTP 7.0.3 Kepler SR1 RC2. Remote host is Linux. trestles.sdsc.edu.
I'm still not getting it. Does the user's local home directory have a space in it? But when they build remotely, they're getting this error? Or are they building locally? Or does the remote home directory have a space in it?
This bug occurs because remote tools tries to set the PWD and CWD environment variables on the remote system to the local workspace path. While odd, this is harmless on Linux and Mac. On Windows, though, the backslashes in the path wreak havoc. Specifically, the path ends with a '\', which escapes the end quotes added by remote tools. To reproduce such problems on any platform, add an environment variable that ends with a '\' The solution is for remote tools to escape '\' in environment values. It is not enough to simply quote the string. The following stackoverflow discusses the problem in more detail: http://stackoverflow.com/questions/8632961/if-bash-doesnt-preserve-a-backslash-in-double-quotes-then-why-does-echo-e-n Note that quotes and maybe some other special characters in environment values should also be escaped. I have changed the title to reflect the more basic problem.
I think the fix for this bug is to remove the PWD and CWD environment variable for synchronized projects. They don't make any sense and break things on windows. Setting environment variables works on Linux and Mac, so I don't think the way they are escaped needs to change.
No, this is a bug on all platforms and is not specific to CWD and PWD. Note that there is a difference between environment variable values and environment variable names. Backslashes in either will produce errors on any platform. For environment variable names, though, it seems that more special characters cause errors, such as: - . " & (Note that there may be characters besides backslash that cause errors for values.) Names, however, are usually restricted. Bash does not allow the above characters, but in general they can be used. See the discussion at: http://stackoverflow.com/questions/2821043/allowed-characters-in-linux-environment-variable-names Setting CWD and PWD on the remote system is a separate problem.
I agree there are two separate issues here, but the PWD/CWD issues seems to be the most important to me.
The org.eclipse.remote component of the Eclipse Ecosystem has a new home. It is now part of the Eclipse CDT project[1]. This change means a new Git repo[2], P2 site[3] and Bugzilla component. The org.eclipse.remote will continue to be delivered as part of the quarterly Simultaneous Release of Eclipse as well. If this bug is no longer relevant, please feel free to comment or close the bug. If you can confirm if this issues still occurs in the latest release please do let me know in a comment. [1] https://wiki.eclipse.org/CDT/User/NewIn106 [2] https://git.eclipse.org/c/cdt/org.eclipse.cdt.git (in the remote directory) [3] first CDT release will be 10.6 - P2 site will be https://download.eclipse.org/tools/cdt/releases/10.6/ (This comment was added to all relevant org.eclipse.remote bugs along with changing the Product/component pair to CDT/remote.)
