emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Generalize start-process with keyword args


From: Andy Moreton
Subject: Re: Generalize start-process with keyword args
Date: Tue, 17 Mar 2015 22:04:26 +0000
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (windows-nt)

On Wed 18 Mar 2015, Eli Zaretskii wrote:

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

I agree that this is awkward. What I envisaged was an (optional) alist
of (REGEXP . (INTERPRETER INTERPRETER-ARGS)) pairs such that if
start-process is onvoked for a PROGRAM that matches REGEXP, then use
INTERPRETER as the PROGRAM argument to start-process, and prepend
INTERPRETER-ARGS to the PROGRAM-ARGS list.

E.g. (start-process name buffer "/path/to/script" "foo" "bar" "baz")

and assuming something like:
(setq start-process-interpreter-alist
      '(("/path/to/script" . ("/path/to/shell" "-c")))

would result in behaviour equivalent to:
  (start-process name buffer "/path/to/shell" "-c" "/path/to/script"
                 "foo" "bar" "baz")

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

Agreed. The filenames can be massaged (e.g. cygwin-mount.el), and other
issues can be ameliorated by using a different shell (or arguments) for
different tools.

    AndyM




reply via email to

[Prev in Thread] Current Thread [Next in Thread]