Re: Generalize start-process with keyword args

[Eli Zaretskii]

> From: Andy Moreton <address@hidden>
> Date: Tue, 17 Mar 2015 20:55:28 +0000
> 
> A simple example is using the cscope package from Cygwin. This installs
> a cscope executable, a cscope-indexer script and cscope.el that uses the
> cscope indexes for symbol lookup. cscope.el can also invoke the indexer
> script to regenerate the indexes (by invoking `cscope-indexing-script'
> with arguments via `start-process').
> 
> This script can easily be reused without modification, by advising
> `start-process to rework its arguments: cahnge PROGRAM to be "bash" and
> prepend "-c" to the PROGRAM-ARGS list. This allows cscope.el to invoke
> the original script from a Win32 emacs build without needing any changes
> to the original package.

So how you suggest this to work?  Should such scripts be treated as
executable only if the interpreter they require is on PATH, and
otherwise be treated as non-executable?  Or should we always treat
them as executables, and let them fail if the interpreter is not
available?  Or should we require that a script that says

  #! /usr/local/bin/perl

is run by "/usr/local/bin/perl", and nothing else?

What about scripts that say

  #! /usr/bin/env perl

should we run 'env' for them, too?

And what about MSYS mounting of Windows directories, whereby /bin/bash
resolves to something like C:\MSYS\1.0\bin\bash.exe (of which Emacs
has no idea)?

I see a lot of complications with the semantics of this, and no easy
solutions, since the necessary tools are not available on Windows,
could be installed in any directory, and come with a set of
assumptions that don't necessarily play well with a native Emacs.

> > But what shell would be able to interpret such scripts on Windows?
> > AFAIK, there are no good candidates for that role.
> 
> A shell from cygwin, msys2 or msys.

They are all subtly incompatible with a native Emacs, both in the
file-name syntax and in how they treat I/O.

> >> This allows integration of unix style commands inplemented as
> >> executable shell scripts with Win32 emacs.
> >
> > IMO, those shell scripts should be ported to Windows by converting
> > them to batch files that the stock Windows shell can interpret.
> 
> Far more work (and more error prone) than simply invoking the existing
> script via an appropriate (posix) shell. 

The same can be said about porting any program.  Porting shell scripts
is part of the job, IMO.