Re: open-process and related functions for MinGW Guile

[Eli Zaretskii]

Ping!

It's been a month since the last exchange, and more than a year since
I started working on this.  Can we please pick up where this was left
off, and resolve whatever issues remain?  Please?

> Date: Fri, 15 Aug 2014 10:07:50 +0300
> From: Eli Zaretskii <address@hidden>
> Cc: address@hidden, address@hidden
> 
> > 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.
> 
>