Community
Participate
Working Groups
When I try to build a remote project I get the error "Word too long.". The reason is that the command line is longer than the shell accepts. The reason is that the command-line is 4326 characters long which is longer than the tcsh allows for a word. The command line is: /bin/sh -c 'echo "PID=$$ PIID=45" > /dev/pts/3; export "LANG=en_US.UTF-8"; {many more enviroment variables} ; cd /u/ac/schulzr/r1; make all; ' Everything after the -c (thus everything between the ' ') is considered a word by tcsh. I see two problems: 1) the call to ManagedBuildManager.getEnvironmentVariableProvider().getVariables(configuration, true) in ManagedBuildManager adds all the local environment variables. Those should not be added to the remote build 2) RemoteTools in org.eclipse.ptp.remotetools.internal.ssh.KillableExecution.setCommandLine(String) should make sure that the command line doesn't become too long for the shell to handle. Fixing either one would fix this problem (this is why I filed it as one bug). This is with the latest PTP HEAD, CDT HEAD and using RemoteTools. Host is abe at Nsca.
I just tested it with Eclipse running under Windows and Linux Server. In this case I get: /bin/sh: -c: line 0: syntax error near unexpected token `(' trying to build. Added this to the same bug because it also seems to be caused by the local environment variables passed to the RemoteTools environment. Bumping this up to critical because I can't build any projects under Windows.
*** Bug 347020 has been marked as a duplicate of this bug. ***
There has been some change in CDT/RDT so that it now tries to send local environment variables. I'm seeing this also on a remote makefile project: /bin/sh: line 0: export: `com.apple.java.jvmMode=client': not a valid identifier /bin/sh: line 0: export: `com.apple.java.jvmTask=JNI.java': not a valid identifier /bin/sh: line 0: cd: /Users/greg/testing/test: No such file or directory make: *** No rule to make target `all'. Stop. It's a recent change because this worked fine not so long ago. Anyone have any idea what the change was?
(In reply to comment #3) > There has been some change in CDT/RDT so that it now tries to send local > environment variables. I'm seeing this also on a remote makefile project: > /bin/sh: line 0: export: `com.apple.java.jvmMode=client': not a valid > identifier > /bin/sh: line 0: export: `com.apple.java.jvmTask=JNI.java': not a valid > identifier > /bin/sh: line 0: cd: /Users/greg/testing/test: No such file or directory > make: *** No rule to make target `all'. Stop. > It's a recent change because this worked fine not so long ago. Anyone have any > idea what the change was? From what I can see so far, for some reason the build system environment variable supplier is no longer returned by the managed build info, and that is screwing things up. Need to email the cdt-dev list and find out what's going on.
Tracked it to the following code in /org.eclipse.ptp.rdt.ui/src/org/eclipse/ptp/rdt/ui/wizards/RemoteMakefileWizardHandler.java //turn off append local environment variables for remote projects StorableEnvironment vars = EnvironmentVariableManager.fUserSupplier.getWorkspaceEnvironmentCopy(); vars.setAppendContributedEnvironment(false); vars.setAppendEnvironment(false); // EnvironmentVariableManager.fUserSupplier.setWorkspaceEnvironment(vars); That last line should not be commented out. Looks like Greg commented it out by accident on 4/29. Putting the line back in fixes the probem for me. Changes checked into HEAD. Note that any project you created while the bug was in effect will still have problems until you recreate it from scratch. The bug causes the project settings to be incorrect and they will stay that way after the changes.
Created attachment 196987 [details] build console result
I got this large chuck of result after I build the project created by Remote Tool on Linux with properly environment set up. Please have a look at the attachment.
(In reply to comment #7) > I got this large chuck of result after I build the project created by Remote > Tool on Linux with properly environment set up. Please have a look at the > attachment. You don't have the fix then. Those are Windows environment variables.
Mine here is build 5.0.0.201105301002, should be the fixed one ,right?
(In reply to comment #9) > Mine here is build 5.0.0.201105301002, should be the fixed one ,right? That build should be ok I would think. Did you create a new project or test it on an old one?
(In reply to comment #10) > (In reply to comment #9) > > Mine here is build 5.0.0.201105301002, should be the fixed one ,right? > That build should be ok I would think. > Did you create a new project or test it on an old one? I just realized that when I tested John's fix to Bug 338595, I didn't do it with a fresh workspace. His fix seems to have broken this fix.
I've temporarily backed out the offending fix. Leaving this open until we get a proper soluton that fixes both bugs.
It looks like managed build projects are suffering from this as well. BTW I'm not sure what happened but it looks like my changes didn't make it in to the repository, I had to check them in again this morning. Probably something screwy during the Eclipse.org outage.
It should be resolved by 338595 new fix.
