Andreas Tolfsen ❲:ato❳ Reporter
	Description • 10 years ago

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.

	Gregory Szorc [:gps]
	Comment 1 • 10 years ago

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).

	Andreas Tolfsen ❲:ato❳ Reporter
	Comment 2 • 10 years ago

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.

	Gregory Szorc [:gps]
	Comment 3 • 10 years ago

(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.