The environment variable SHELL is read in python/mach/mach/mixin/process.py and assigned to _current_shell. This is used to determine whether a switch to a Unix-like shell is necessary on Windows when you're not in msys. Because the shell emulators in Emacs are not standalone programs per se, this causes an exception to be raised about SHELL not being set: -*- mode: compilation; default-directory: "~/dev/gecko/src/" -*- Compilation started at Tue Mar 18 11:46:08 ./mach build Traceback (most recent call last): File "./mach", line 55, in <module> main(sys.argv) File "./mach", line 47, in main mach = load_mach(dir_path) File "./mach", line 21, in load_mach return mach_bootstrap.bootstrap(topsrcdir) File "/home/ato/Code/gecko/src/build/mach_bootstrap.py", line 190, in bootstrap mach.load_commands_from_file(os.path.join(mozilla_dir, path)) File "/home/ato/Code/gecko/src/python/mach/mach/main.py", line 235, in load_commands_from_file imp.load_source(module_name, path) File "/home/ato/Code/gecko/src/addon-sdk/mach_commands.py", line 10, in <module> from mozbuild.base import ( File "/home/ato/Code/gecko/src/python/mozbuild/mozbuild/base.py", line 17, in <module> from mach.mixin.process import ProcessExecutionMixin File "/home/ato/Code/gecko/src/python/mach/mach/mixin/process.py", line 29, in <module> raise Exception('Could not detect environment shell!') Exception: Could not detect environment shell! Compilation exited abnormally with code 1 at Tue Mar 18 11:46:08 Setting SHELL to anything bypasses the problem, but seems like a hack. Is there a possibility for us relaxing the enforcement of SHELL being set, considering it's only a Windows-only check? It also seems strange to require SHELL to be set when there are shell emulators like this, so my suggestion would be to simply remove the raise altogether.

The comment above the exception point implies this can be changed without ill-effect. However, we still need to know what shell to invoke for commands that require a shell environment. We would have to guess a shell from the environment (looking for well-known shells, etc).

As far as I can tell there isn't anything apart from switching into a Unix-compatible shell on Windows that reads _current_shell? Would it have any negative consequences to fall back to /bin/sh when SHELL can't be deduced? We could check if it exists, and then throw if it doesn't.

(In reply to Andreas Tolfsen (:ato) from comment #2) > As far as I can tell there isn't anything apart from switching into a > Unix-compatible shell on Windows that reads _current_shell? > > Would it have any negative consequences to fall back to /bin/sh when SHELL > can't be deduced? We could check if it exists, and then throw if it doesn't. I think falling back to /bin/sh[.exe] is sensible. We might want to change the variable name to indicate that it's a unix_shell (as opposed to the Windows shell). Looking at this code, I think things will fall apart if we attempt to run things from cmd.exe.