Opened 12 years ago

Last modified 7 years ago

#456 reopened defect

Slave's ShellCommand and msys are broken

Reported by: even Owned by: even
Priority: major Milestone: 0.9.+
Version: 0.7.10 Keywords: windows
Cc: fqueze


While using buildbot in msys, new bugs appeared somewhere between 0.7.9 and 0.7.10p1.

Those are related to the changes in the ShellCommand? object even if, right now, I can't tell what exactly caused this. What I know is, when I call pwd using buildbot, it used to return a path in msys path format (full UNIX like, so it was looking alike /c/some/folder) when it returns a path in windows format now (c:path ofolder). Using some tricks with environment variables before launching buildbot I achieved to get UNIX compatible path using the windows format (like c:\path\to\folder) but it stills cause problems on some executables like make that completely fails.

Here is what the error looks like :

make -f build
 in dir c:uildbotxp-compilwin32uild (timeout 1200 secs)
 watching logfiles {}
 argv: ['make', '-f', '', 'build']
  ALLUSERSPROFILE=C:Documents and SettingsAll Users
  COMMONPROGRAMFILES=C:Program FilesFichiers communs
  DEVENVDIR=C:Program FilesMicrosoft Visual Studio 8Common7IDE
  FRAMEWORKSDKDIR=C:Program FilesMicrosoft Visual Studio 8SDKv2.0
  HOME=c:/Documents and Settings/buildbot
  INCLUDE=C:Program FilesMicrosoft SDKsWindowsv6.0\include;C:Program FilesMicrosoft SDKsWindowsv6.0\includeatl;C:Program FilesMicrosoft Visual Studio 8VCATLMFCINCLUDE;C:Program FilesMicrosoft Visual Studio 8VCINCLUDE;C:Program FilesMicrosoft Visual Studio 8VCPlatformSDKinclude;C:Program FilesMicrosoft Visual Studio 8SDKv2.0include;
  LIB=C:Program FilesMicrosoft SDKsWindowsv6.0\lib;C:Program FilesMicrosoft Visual Studio 8VCATLMFCLIB;C:Program FilesMicrosoft Visual Studio 8VCLIB;C:Program FilesMicrosoft Visual Studio 8VCPlatformSDKlib;C:Program FilesMicrosoft Visual Studio 8SDKv2.0lib;;C:mozilla-buildatlthunk_compat
  LIBPATH=C:WINDOWSMicrosoft.NETFrameworkv2.0.50727;C:Program FilesMicrosoft Visual Studio 8VCATLMFCLIB
  MAKEFLAGS= --unix
  MFLAGS=- --unix
  MSVC6KEY=HKLMSOFTWAREMicrosoftVisualStudio6.0SetupMicrosoft Visual C++
  OLD_PATH=C:Program FilesWindows Resource KitsTools;C:WINDOWSsystem32;C:WINDOWS;C:WINDOWSSystem32Wbem;c:Program FilesMicrosoft SQL Server90Toolsinn;C:mozilla-buildPython25;C:mozilla-buildPython25Scripts
sis-2.33u;c:mozilla-buildhg;c:mozilla-buildpython25Scripts;.;C:mozilla-buildmsyslocalin;C:mozilla-buildmsysmingwin;C:mozilla-buildmsysin;c:Program FilesMicrosoft SDKsWindowsv6.0in;c:Program FilesMicrosoft Visual Studio 8Common7IDE;c:Program FilesMicrosoft Visual Studio 8VCBIN;c:Program FilesMicrosoft Visual Studio 8Common7Tools;c:Program FilesMicrosoft Visual Studio 8Common7Toolsin;c:Program FilesMicrosoft Visual Studio 8VCPlatformSDKin;c:Program FilesMicrosoft Visual Studio 8SDKv2.0in;c:WINDOWSMicrosoft.NETFrameworkv2.0.50727;c:Program FilesMicrosoft Visual Studio 8VCVCPackages;c:WINDOWSSystem32;c:WINDOWS;c:WINDOWSSystem32Wbem;c:mozilla-buildmoztoolsin
  PROCESSOR_IDENTIFIER=x86 Family 6 Model 23 Stepping 7, GenuineIntel
  PROGRAMFILES=C:Program Files
33[32m]u@h [33[33mw33[0m]
  SDK6KEY=HKLMSOFTWAREMicrosoftMicrosoft SDKsWindowsv6.0WinSDKBuild
  SDKDIR=C:Program FilesMicrosoft SDKsWindowsv6.0
  USERPROFILE=C:Documents and Settingsuildbot
  VC8DIR=C:Program FilesMicrosoft Visual Studio 8VC
  VCINSTALLDIR=C:Program FilesMicrosoft Visual Studio 8VC
  VS80COMNTOOLS=C:Program FilesMicrosoft Visual Studio 8Common7Tools
  VSINSTALLDIR=C:Program FilesMicrosoft Visual Studio 8
 closing stdin
 using PTY: False
/bin/sh: c:buildbotxp-compilwin32build/ No such file or directory *** This source tree appears to have Windows-style line endings. To convert it to Unix-style line endings, run "python mozilla/build/win32/".  Stop.
program finished with exit code 2

While looking at the main differences with the previous version I used (0.7.8) that was working, the call to cmd.exe that previously preceded each calls disappeared. That might be the reason, but also it might be something else.

What I know for sure is that I noticed the version of ShellCommand? I can find on this trac is not mine and if I replace mine with it (just adding a usePTY argument to the constructor to get it working), everything works again.

I intend to look further on this bug but don't have time right now. If someone happens to find the exact reason of this and to produce a patch quickly (meaning before I find more time to look about that), I would really appreciate it.

Attachments (1)

msys.patch (546 bytes) - added by even 12 years ago.
Correct the bug.

Download all attachments as: .zip

Change History (15)

comment:1 Changed 12 years ago by fqueze

  • Cc fqueze added

comment:2 Changed 12 years ago by even

  • Keywords review added
  • Milestone changed from undecided to 0.7.11
  • Owner set to even
  • Status changed from new to assigned

I just added a patch correcting the bug on msys. It seems that changing the PWD variable is making everything bug on msys. It's better not to do it in these conditions.

If you ABSOLUTELY want to set PWD, I might try another patch that convert the path in msys format before setting it.

Since my patch does not affect other OS and seems to work, I add the review flag and set the milestone to next version.

Changed 12 years ago by even

Correct the bug.

comment:3 Changed 12 years ago by dustin

  • Keywords sprint added

comment:4 Changed 12 years ago by blackett

I had the same problem with buildslaves in Windows Server 2008 that use cygwin

It seems that once the PWD was set with a windows like path, cygwin maintained this form, whereas I had scripts that ran assuming the cygwin form, which is what had been defined up to that point.

My workaround was to unset PWD in the bat file that starts my cygwin processes for buildbot:


comment:5 Changed 12 years ago by dustin

  • Resolution set to fixed
  • Status changed from assigned to closed

comment:6 Changed 10 years ago by hushp1pt

  • Resolution fixed deleted
  • Status changed from closed to reopened

I had the same problem with Cygwin-1.7 on a Windows 2003 server.

However, I too had the same pwd problem (Windows path when cygwin-style path was expected). I also tried to unset PWD, but I never got that to change anything.

I eventually commented out the

self.environPWD? = os.path.abspath(self.workdir)

statement in, and everything was great.

Can you add a test for cygwin as well as msys to the patch that fixed this bug for msys?

comment:7 follow-up: Changed 10 years ago by dustin

  • Keywords review sprint removed

how can I identify a cygwin system in Python?

comment:8 in reply to: ↑ 7 Changed 10 years ago by hushp1pt

Replying to dustin:

how can I identify a cygwin system in Python?

I was wondering, in the earlier patch here, how did MACHTYPE know it was an MSYS system?

self.environ.get('MACHTYPE', None) == 'i686-pc-msys'

Do you need to start the buildslave from Msys for MACHTIME to say "msys"? If you started the buildslave from Cygwin, would MACHTYPE say "cygwin"?

In fact, I do not start our Windows buildslave from Cygwin. I used the run-buildbot-as-service contrib. But I still want the BuildCommand? commands to run under Cygwin.

If you don't have MACHTYPE that says Cygwin, there probably is no foolproof way to tell if a ShellCommand? buildstep wanted to run Cygwin. However, I bet if the first word of the first command in the build step was "bash", "bash.exe", or a full path to bash, and buildslave is Windows, then the odds would be pretty good that the command(s) were really meant for Cygwin bash- or for Msys bash. Either way, the patch would help.

Those who prefer to have their ShellCommand? start a BAT file to run Cygwin commands, I guess they can still set PWD= before they call bash or whatever.

comment:9 follow-up: Changed 10 years ago by dustin

  • Keywords windows added
  • Milestone changed from 0.7.11 to 0.8.3

I'm worried about playing whack-a-mole here, or getting too specific in analyzing the components of a buildstep. Could we add a ShellCommand? option that would be passed to the slave to enable this particular behavior?

comment:10 in reply to: ↑ 9 Changed 10 years ago by hushp1pt

Replying to dustin:

I'm worried about playing whack-a-mole here, or getting too specific in analyzing the components of a buildstep. Could we add a ShellCommand? option that would be passed to the slave to enable this particular behavior?

Thanks, I think that would be ideal. You could call the option with_cygwin_path. If value == None, no change- same as regular Windows process. If != None, skip the PWD reset in

For extra credit, if value looks like a Cygwin path string, then override the PATH that bash (or whatever) sees when it lands. In the example, I passed Cygwin's PATH through Shell Command's envPATH?. Implementing some kind of short cut for this override would be helpful, because envPATH? was the only value in env that had to be different between Windows and Linux builds and I had serious python and/or buildbot language troubles in my build factory, trying to define that env dictionary the right way at the right time. Your call. Thanks again.

comment:11 follow-up: Changed 10 years ago by ayust

  • Milestone changed from 0.8.3 to 0.8.+

comment:12 in reply to: ↑ 11 Changed 9 years ago by hushp1pt

Replying to above:

For extra credit, ...

Hi, please forget all about that "for extra credit" idea- my mistake.

Please reconsider the simple bug fix dustin proposed,

Could we add a ShellCommand option that would be passed to the slave to enable this particular behavior?

I suggest the new ShellCommand option be named with_cygwin_path. If with_cygwin_path == None, no change- same as regular Windows process. If != None, skip the PWD reset in


comment:13 Changed 9 years ago by tom.prince

I wonder if it actually makes sense to be setting PWD anywhere? If the command being run is a shell script, then the shell should be setting PWD. Otherwise, I'd guess that things should be using getcwd(3) to find the current directory, not a environment variable. Perhaps we should just unset it?

comment:14 Changed 7 years ago by dustin

  • Milestone changed from 0.8.+ to 0.9.+

Ticket retargeted after milestone closed

Note: See TracTickets for help on using tickets.