Re: Generalize start-process with keyword args

[Andy Moreton <andrewjmoreton@gmail.com>]

On Tue 17 Mar 2015, Eli Zaretskii wrote:

>> From: Andy Moreton <andrewjmoreton@gmail.com>
>> Date: Mon, 16 Mar 2015 22:27:44 +0000
>> 
>> On Mon 16 Mar 2015, Eli Zaretskii wrote:
>> 
>> >> From: Andy Moreton <andrewjmoreton@gmail.com>
>> >> Date: Mon, 16 Mar 2015 19:12:45 +0000
>> >> 
>> >> start-process assumes that the system is capable of handling shebang
>> >> lines in shell scripts and launching them by executing a shell.
>> >
>> > Can you point out where does this assumption live in the code?
>> 
>> In the callers of start-process
>
> Can you give me an example of such a caller?  (I'm not asking idle
> questions here; there are aspects of the problem you describe that
> aren't really clear to me, but I prefer finding out the answers by
> looking at the code than by asking too many questions.)

Sorry for not being clear.

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.

Similar issues arise with using other tools (e.g. git, hg) that use
shell scripts or symlinks for some executable tools.

>> By (optionally) invoking the command via a shell.
>
> 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.

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

    AndyM