Re: open-process and related functions for MinGW Guile

[Eli Zaretskii]

> Date: Tue, 12 Aug 2014 22:44:03 +0300
> From: Eli Zaretskii <address@hidden>
> Cc: address@hidden, address@hidden
> 
> > > +  /* If they ask for the Unix system shell, try to find it on PATH.  */
> > > +  if (c_strcasecmp (program, "/bin/sh") == 0)
> > > +    {
> > > +      bin_sh_requested = 1;
> > > +      program = "sh.exe";
> > > +    }
> > 
> > Hmm.  I'm not so comfortable with such cleverness at this low level.
> 
> You mean, that we look for 'sh' not in '/bin', but along PATH?  What
> else is reasonable? there's no standard '/bin' directory on Windows
> systems, certainly not on every drive.  Without something like that,
> we will never be able to support portably shell commands that require
> a Unixy shell, because on Unix you _must_ use "/bin/sh" verbatim.
> 
> This is very important for running the test suite, since there are
> quite a few commands there that explicitly invoke /bin/sh and require
> Bourne shell functionality.
> 
> > I'd prefer to have it higher in the stack, perhaps in the Scheme code in
> > (ice-9 popen) or maybe even in the application code.
> 
> I don't think this is practical: too many places to change.  And you
> will have to keep an eye on it from now to eternity.  It's a losing
> battle.
> [...]
> > > +  /* If they asked for /bin/sh and we didn't find it, fall back on the
> > > +     default Windows shell.  */
> > > +  if (abs_namelen <= 0 && bin_sh_requested)
> > > +    {
> > > +      const char *shell = getenv ("ComSpec");
> > > +
> > > +      if (!shell)
> > > + shell = "C:\\Windows\\system32\\cmd.exe";
> > > +
> > > +      *bin_sh_replaced = 1;
> > > +      strcpy (abs_name, shell);
> > > +      abs_namelen = strlen (abs_name);
> > > +    }
> > 
> > Again, I'd prefer to put this at a higher level in the stack.
> 
> And I again think that this is impractical to place that burden on
> higher levels.
> 
> > If the user specifically asks to run "/bin/sh", we should not
> > silently substitute a different incompatible shell.
> 
> If the command is incompatible with cmd, it will fail anyway.  But if
> it is a simple command, it is likely to work with cmd as well, so this
> is better than always failing.  People who work on Unix will use
> /bin/sh without much thought (what else can they do when they need a
> shell?), so if we see it, it doesn't necessarily mean they must have a
> Bourne shell.

If the above still doesn't convince you, I can think of the following
alternative (but will need help in implementing it):

 . We define 2 new variables, %shell-file-name and
   %shell-command-switch.  (The names were stolen from Emacs, which
   has these facilities.)  %shell-file-name will default to "/bin/sh"
   on Posix platforms, and to the absolute file name of cmd.exe on
   Windows, determined at startup.  %shell-command-switch will default
   to "-c" and "/c" respectively.

 . We publicly ban the use of literal "/bin/sh -c" in Guile sources
   (and in the test suite, except where Bourne shell semantics is
   required), and require the use of the above 2 variables instead.

 . The test suite, when it runs on Windows, will look for sh.exe along
   PATH, and, if found, will set %shell-file-name to its absolute file
   name and %shell-command-switch to "-c".

Note that the 2nd item above will require thorough review of the
existing sources that invoke "/bin/sh" directly and indirectly, and
changing them so that they'd work with the Windows shell as well.
Some obvious gotcha's include quoting with ".." rather than '..'.
Some less obvious gotcha's include things like this one (from
autofrisk.scm):

  (define (unglob pattern)
    (let ((p (open-input-pipe (format #f "echo '(' ~A ')'" pattern))))
      (map symbol->string (read p))))

This assumes that 'echo' globs its argument, but the cmd.exe built-in
by the same name does not.

This alternative gives you what you want (AFAIU), but it's not without
a price: it is not 100% reliable, and it will require some maintenance
burden, both initially and in the future (to make sure no hidden
dependencies on /bin/sh creep in).  It also places an additional
burden on users and on Scheme programmers.  TANSTAAFL.