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 <e...@gnu.org>
> Cc: l...@gnu.org, guile-devel@gnu.org
>
> > Date: Tue, 12 Aug 2014 22:44:03 +0300
> > From: Eli Zaretskii <e...@gnu.org>
> > Cc: l...@gnu.org, guile-devel@gnu.org
> >
> > > > + /* 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.
>
>
