Quote file name args to start-process-shell-command?

Quote file name args to start-process-shell-command?

[Lennart Borgman]

Should arguments to 
start-process-shell-command/call-process-shell-command that are file 
names be quoted with shell-quote-arguments? Could that perhaps be done 
inside those functions? (I mean could 'identity be replaced by 
'shell-quote-argument in those functions.)

Re: Quote file name args to start-process-shell-command?

[Eli Zaretskii]

> Date: Wed, 11 Oct 2006 22:32:24 +0200
> From: Lennart Borgman <lennart.borgman.073@student.lu.se>
> 
> Should arguments to 
> start-process-shell-command/call-process-shell-command that are file 
> names be quoted with shell-quote-arguments?

Can you show examples of situations when this is an issue?

Re: Quote file name args to start-process-shell-command?

[Lennart Borgman]

Eli Zaretskii wrote:
>> Date: Wed, 11 Oct 2006 22:32:24 +0200
>> From: Lennart Borgman <lennart.borgman.073@student.lu.se>
>>
>> Should arguments to 
>> start-process-shell-command/call-process-shell-command that are file 
>> names be quoted with shell-quote-arguments?
>>     
>
> Can you show examples of situations when this is an issue?
>   

Something like this:

    (call-process-shell-command "ls" nil t nil "c:/program files/emacs")

Re: Quote file name args to start-process-shell-command?

[Eli Zaretskii]

> Date: Thu, 12 Oct 2006 08:08:08 +0200
> From: Lennart Borgman <lennart.borgman.073@student.lu.se>
> CC:  emacs-devel@gnu.org
> 
> Eli Zaretskii wrote:
> >> Date: Wed, 11 Oct 2006 22:32:24 +0200
> >> From: Lennart Borgman <lennart.borgman.073@student.lu.se>
> >>
> >> Should arguments to 
> >> start-process-shell-command/call-process-shell-command that are file 
> >> names be quoted with shell-quote-arguments?
> >>     
> >
> > Can you show examples of situations when this is an issue?
> >   
> 
> Something like this:
> 
>     (call-process-shell-command "ls" nil t nil "c:/program files/emacs")

I believe it's wrong for call-process-shell-command to quote
arguments, because it has no idea of their semantics.  The doc string
of call-process-shell-command says:

  Remaining arguments are strings passed as additional arguments for COMMAND.

There's no requirement here that each one of the "&rest ARGS" be a
separate command-line argument, is there?  For example, I just tried
this:

  (call-process-shell-command "ls" nil t nil "foo* bar*")

and got a listing of all files that match the two wildcards `foo*' and
`bar*'.

So I think that any quoting should be done by the caller of
call-process-shell-command, since only the caller knows what each
argument means.

Re: Quote file name args to start-process-shell-command?

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Thu, 12 Oct 2006 08:08:08 +0200
>> From: Lennart Borgman <lennart.borgman.073@student.lu.se>
>> CC:  emacs-devel@gnu.org
>> 
>> Eli Zaretskii wrote:
>> >> Date: Wed, 11 Oct 2006 22:32:24 +0200
>> >> From: Lennart Borgman <lennart.borgman.073@student.lu.se>
>> >>
>> >> Should arguments to 
>> >> start-process-shell-command/call-process-shell-command that are file 
>> >> names be quoted with shell-quote-arguments?
>> >>     
>> >
>> > Can you show examples of situations when this is an issue?
>> >   
>> 
>> Something like this:
>> 
>>     (call-process-shell-command "ls" nil t nil "c:/program files/emacs")
>
> I believe it's wrong for call-process-shell-command to quote
> arguments, because it has no idea of their semantics.  The doc string
> of call-process-shell-command says:
>
>   Remaining arguments are strings passed as additional arguments for COMMAND.
>
> There's no requirement here that each one of the "&rest ARGS" be a
> separate command-line argument, is there?

Then it would be completely pointless to allow several ARGS.

> For example, I just tried this:
>
>   (call-process-shell-command "ls" nil t nil "foo* bar*")
>
> and got a listing of all files that match the two wildcards `foo*' and
> `bar*'.

I think that would be abuse of the command.

> So I think that any quoting should be done by the caller of
> call-process-shell-command, since only the caller knows what each
> argument means.

The caller knows that different arguments mean different arguments,
presumably.

One would have to look at the actual use cases to see whether any
caller assumes differently, but from the description, I'd agree with
Lennart's idea.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Quote file name args to start-process-shell-command?

[Kim F. Storm]

David Kastrup <dak@gnu.org> writes:

> One would have to look at the actual use cases to see whether any
> caller assumes differently, but from the description, I'd agree with
> Lennart's idea.

But it would break any uses where the caller already has used
shell-quote-argument.

Let's leave the API alone -- but it would be ok to mention the use of
shell-quote-argument in the doc string.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Quote file name args to start-process-shell-command?

[David Kastrup]

storm@cua.dk (Kim F. Storm) writes:

> David Kastrup <dak@gnu.org> writes:
>
>> One would have to look at the actual use cases to see whether any
>> caller assumes differently, but from the description, I'd agree
>> with Lennart's idea.
>
> But it would break any uses where the caller already has used
> shell-quote-argument.
>
> Let's leave the API alone

It appears broken to me, but fixing it in a backwards-compatible way
does not seem possible without further messing the API up.

The question is how much actual code might be affected by a non
backwards-compatible change of the API.  I never heard of the function
until now.

> -- but it would be ok to mention the use of shell-quote-argument in
> the doc string.

I'd prefer fixing the function instead.  A command API should take
either a single string, or a list of individual arguments.  A list of
individual arguments which get concatened into a single string that is
later split into individual arguments in a different way: that simply
is not a useful concept to wrap into calling conventions.

The current API suggests a usage that does not actually work.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Quote file name args to start-process-shell-command?

[Andreas Schwab]

David Kastrup <dak@gnu.org> writes:

> storm@cua.dk (Kim F. Storm) writes:
>
>> David Kastrup <dak@gnu.org> writes:
>>
>>> One would have to look at the actual use cases to see whether any
>>> caller assumes differently, but from the description, I'd agree
>>> with Lennart's idea.
>>
>> But it would break any uses where the caller already has used
>> shell-quote-argument.
>>
>> Let's leave the API alone
>
> It appears broken to me, but fixing it in a backwards-compatible way
> does not seem possible without further messing the API up.

There is nothing broken.  The function is explicitly designed that way.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Quote file name args to start-process-shell-command?

[Andreas Schwab]

David Kastrup <dak@gnu.org> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>> For example, I just tried this:
>>
>>   (call-process-shell-command "ls" nil t nil "foo* bar*")
>>
>> and got a listing of all files that match the two wildcards `foo*' and
>> `bar*'.
>
> I think that would be abuse of the command.

No, it isn't.  The doc string says:

"Wildcards and redirection are handled as usual in the shell."

That implies that there shall be no quoting applied.  You need to go lower
level to avoid metacharacter handling.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Quote file name args to start-process-shell-command?

[David Kastrup]

Andreas Schwab <schwab@suse.de> writes:

> David Kastrup <dak@gnu.org> writes:
>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>>> For example, I just tried this:
>>>
>>>   (call-process-shell-command "ls" nil t nil "foo* bar*")
>>>
>>> and got a listing of all files that match the two wildcards `foo*' and
>>> `bar*'.
>>
>> I think that would be abuse of the command.
>
> No, it isn't.  The doc string says:
>
> "Wildcards and redirection are handled as usual in the shell."

Spaces are neither a wildcard nor a redirection.

> That implies that there shall be no quoting applied.

`shell-quote-argument' and `shell-quote-wildcard-pattern' are two
different functions.

> You need to go lower level to avoid metacharacter handling.

Straw man.  This never was about "metacharacter handling" but rather
about argument processing.

However, I agree that `shell-quote-argument' would be inappropriate to
apply on the arguments of `call-process-shell-command'.  Only those
characters responsible for splitting arguments into words should get
quoted.  That would pretty much be the subset that
`shell-quote-wildcard-pattern' uses.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Quote file name args to start-process-shell-command?

[Andreas Schwab]

David Kastrup <dak@gnu.org> writes:

> Spaces are neither a wildcard nor a redirection.

The function executes a shell command.  Shell commands can include many
kinds of meta characters, including wildcards and redirections.

> Straw man.  This never was about "metacharacter handling" but rather
> about argument processing.

The function is about shell commands.  That includes any kind of meta
characters.  This works as documented.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Quote file name args to start-process-shell-command?

[David Kastrup]

Andreas Schwab <schwab@suse.de> writes:

> David Kastrup <dak@gnu.org> writes:
>
>> Spaces are neither a wildcard nor a redirection.
>
> The function executes a shell command.  Shell commands can include
> many kinds of meta characters, including wildcards and redirections.

Spaces are neither a wildcard nor a redirection.

>> Straw man.  This never was about "metacharacter handling" but
>> rather about argument processing.
>
> The function is about shell commands.  That includes any kind of
> meta characters.  This works as documented.

I disagree.  If I call something like

(start-process-shell-command "ls" "*scratch*" "ls"
 "\"Program" "Files\"")

then "\"Program" and "Files\"" are not become separate arguments to
the shell.  Rather there is one argument "Program Files".

The command should either make some attempt to actually pass separate
arguments (and that means quoting of word separating entities), or
just accept a single string as an argument.

Everything else is inconsistent.

Again: this does not at all have anything to do with wildcards and
redirections, so I fail to see why you bring them up time and again.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Quote file name args to start-process-shell-command?

[Andreas Schwab]

David Kastrup <dak@gnu.org> writes:

> I disagree.  If I call something like
>
> (start-process-shell-command "ls" "*scratch*" "ls"
>  "\"Program" "Files\"")
>
> then "\"Program" and "Files\"" are not become separate arguments to
> the shell.

Read the documentation.  You are changing the semantics of the function.

> Again: this does not at all have anything to do with wildcards and
> redirections, so I fail to see why you bring them up time and again.

Read the documentation again.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Quote file name args to start-process-shell-command?

[David Kastrup]

Andreas Schwab <schwab@suse.de> writes:

> David Kastrup <dak@gnu.org> writes:
>
>> I disagree.  If I call something like
>>
>> (start-process-shell-command "ls" "*scratch*" "ls"
>>  "\"Program" "Files\"")
>>
>> then "\"Program" and "Files\"" are not become separate arguments to
>> the shell.
>
> Read the documentation.  You are changing the semantics of the
> function.

I can't change semantics of a function by using it.  The function
already _has_ those semantics, and the question was whether that is a
good idea.

>> Again: this does not at all have anything to do with wildcards and
>> redirections, so I fail to see why you bring them up time and again.
>
> Read the documentation again.

The only thing the documentation says in that respect is

    Remaining arguments are the arguments for the command.
    Wildcards and redirection are handled as usual in the shell.

Since I am apparently too stupid to understand your meaning by
rereading those two sentences, would you care to explain it in words
fit for a simple-minded person like myself?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Quote file name args to start-process-shell-command?

[Andreas Schwab]

David Kastrup <dak@gnu.org> writes:

> The only thing the documentation says in that respect is

     It follows that if
     you include an arbitrary user-specified arguments in the command,
     you should quote it with `shell-quote-argument' first, so that any
     special shell characters do _not_ have their special shell
     meanings.

*Any* special characters.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Quote file name args to start-process-shell-command?

[David Kastrup]

Andreas Schwab <schwab@suse.de> writes:

> David Kastrup <dak@gnu.org> writes:
>
>> The only thing the documentation says in that respect is
>
>      It follows that if
>      you include an arbitrary user-specified arguments in the command,
>      you should quote it with `shell-quote-argument' first, so that any
>      special shell characters do _not_ have their special shell
>      meanings.

Please don't do creative misquoting by combining things I actually
wrote with stuff of your own.  I did not quote the above, it is not
present in `start-process-shell-command's doc string, and you don't
give a source for the quote you attribute to me in a very misleading
manner.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Quote file name args to start-process-shell-command?

[Stephen Leake]

David Kastrup <dak@gnu.org> writes:

> Andreas Schwab <schwab@suse.de> writes:
>
>> David Kastrup <dak@gnu.org> writes:
>>
>>> Spaces are neither a wildcard nor a redirection.
>>
>> The function executes a shell command.  Shell commands can include
>> many kinds of meta characters, including wildcards and redirections.
>
> Spaces are neither a wildcard nor a redirection.
>
>>> Straw man.  This never was about "metacharacter handling" but
>>> rather about argument processing.
>>
>> The function is about shell commands.  That includes any kind of
>> meta characters.  This works as documented.
>
> I disagree.  If I call something like
>
> (start-process-shell-command "ls" "*scratch*" "ls"
>  "\"Program" "Files\"")
>
> then "\"Program" and "Files\"" are not become separate arguments to
> the shell.  Rather there is one argument "Program Files".

That is what I would expect, and what I believe the documentation
says:

(start-process-shell-command NAME BUFFER &rest ARGS)
...
    Remaining arguments are the arguments for the command.

Each lisp object in ARGS is one command shell argument.

Not "remaining arguments are split on spaces", which is what you seem
to be expecting.

> The command should either make some attempt to actually pass separate
> arguments 

That is what it does.

> (and that means quoting of word separating entities)

This it does not do. Perhaps it should; I think that is the point of
this discussion.

This matters to me as the maintainer of ada-mode; it builds compiler
commands, that may contain arguments that need to be quoted.

My inclination is that any "automagic" quoting that I don't have
direct control over will be wrong at some point. So I'd prefer to
leave start-process-shell-command as is, but mention that
shell-quote-argument might be useful.

> , or just accept a single string as an argument.

It is often convenient to build the arguments in separate groups; a
single string would be awkward.

I don't have any exact examples handy.

-- 
-- Stephe

Re: Quote file name args to start-process-shell-command?

[Stefan Monnier]

> It is often convenient to build the arguments in separate groups; a
> single string would be awkward.

Is (mapconcat 'identity foo " ") really awkward?


        Stefan

Re: Quote file name args to start-process-shell-command?

[Eli Zaretskii]

> Cc: David Kastrup <dak@gnu.org>,  Andreas Schwab <schwab@suse.de>,
> 	  Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org,
> 	  Lennart Borgman <lennart.borgman.073@student.lu.se>
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Thu, 12 Oct 2006 15:47:28 -0400
> 
> > It is often convenient to build the arguments in separate groups; a
> > single string would be awkward.
> 
> Is (mapconcat 'identity foo " ") really awkward?

It's more awkward than just calling a function with a list.

Re: Quote file name args to start-process-shell-command?

[Stefan Monnier]

>> > It is often convenient to build the arguments in separate groups; a
>> > single string would be awkward.
>> Is (mapconcat 'identity foo " ") really awkward?
> It's more awkward than just calling a function with a list.

The question wasn't whether it more or less awkward, just whether it is
awkward.  And I really don't think it is.  And it has the invaluable
advantage of making it crystal clear what's happening.


        Stefan

Re: Quote file name args to start-process-shell-command?

[Eli Zaretskii]

> Cc: stephen_leake@member.fsf.org,  dak@gnu.org,  schwab@suse.de,
> 	  emacs-devel@gnu.org,  lennart.borgman.073@student.lu.se
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Fri, 13 Oct 2006 14:16:11 -0400
> 
> >> > It is often convenient to build the arguments in separate groups; a
> >> > single string would be awkward.
> >> Is (mapconcat 'identity foo " ") really awkward?
> > It's more awkward than just calling a function with a list.
> 
> The question wasn't whether it more or less awkward, just whether it is
> awkward.  And I really don't think it is.  And it has the invaluable
> advantage of making it crystal clear what's happening.

It's quite clear I cannot convince you no matter what I say, so let's
just agree to disagree.

Re: Quote file name args to start-process-shell-command?

[Stefan Monnier]

>> The question wasn't whether it more or less awkward, just whether it is
>> awkward.  And I really don't think it is.  And it has the invaluable
>> advantage of making it crystal clear what's happening.

> It's quite clear I cannot convince you no matter what I say, so let's
> just agree to disagree.

I guess I could be convinced by example code where the use of the "multiple
arg feature" makes the code simpler (without introducing extra bugs).


        Stefan

Re: Quote file name args to start-process-shell-command?

[Eli Zaretskii]

> Cc: stephen_leake@member.fsf.org,  dak@gnu.org,  schwab@suse.de,
> 	  emacs-devel@gnu.org,  lennart.borgman.073@student.lu.se
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Fri, 13 Oct 2006 16:18:18 -0400
> 
> >> The question wasn't whether it more or less awkward, just whether it is
> >> awkward.  And I really don't think it is.  And it has the invaluable
> >> advantage of making it crystal clear what's happening.
> 
> > It's quite clear I cannot convince you no matter what I say, so let's
> > just agree to disagree.
> 
> I guess I could be convinced by example code where the use of the "multiple
> arg feature" makes the code simpler (without introducing extra bugs).

Define ``make the code simpler'', and I will try to think if there is
an example of that.

Re: Quote file name args to start-process-shell-command?

[Stefan Monnier]

>> >> The question wasn't whether it more or less awkward, just whether it is
>> >> awkward.  And I really don't think it is.  And it has the invaluable
>> >> advantage of making it crystal clear what's happening.
>> 
>> > It's quite clear I cannot convince you no matter what I say, so let's
>> > just agree to disagree.
>> 
>> I guess I could be convinced by example code where the use of the "multiple
>> arg feature" makes the code simpler (without introducing extra bugs).

> Define ``make the code simpler'', and I will try to think if there is
> an example of that.

The notion of what is simpler is clearly objective and we may never agree,
but I may be satisfied by a concrete example which you consider
as simpler.

I just honestly can't think of any case where the "multiple args feature"
can be used without either introducing bugs, or just pushing the arguably
strange behavior (of having a list of strings which will be concatenated
by Emacs and re-split later differently by the shell) to the user of
that code.


        Stefan

Re: Quote file name args to start-process-shell-command?

[Eli Zaretskii]

> Cc: stephen_leake@member.fsf.org,  dak@gnu.org,  schwab@suse.de,
> 	  emacs-devel@gnu.org,  lennart.borgman.073@student.lu.se
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Sat, 14 Oct 2006 12:57:50 -0400
> >> 
> >> I guess I could be convinced by example code where the use of the "multiple
> >> arg feature" makes the code simpler (without introducing extra bugs).
> 
> > Define ``make the code simpler'', and I will try to think if there is
> > an example of that.
> 
> The notion of what is simpler is clearly objective and we may never agree,

That is exactly why I asked for _your_ notion of ``simpler''.

> I just honestly can't think of any case where the "multiple args feature"
> can be used without either introducing bugs, or just pushing the arguably
> strange behavior (of having a list of strings which will be concatenated
> by Emacs and re-split later differently by the shell) to the user of
> that code.

Well, the function exists in this form for many years (at least 12).
I'm guessing that the &rest args form was to make it similar to
start-process or something, but that's just a guess.

Re: Quote file name args to start-process-shell-command?

[Stefan Monnier]

>> The notion of what is simpler is clearly objective and we may never agree,
> That is exactly why I asked for _your_ notion of ``simpler''.

>> but I may be satisfied by a concrete example which you consider
>> as simpler.
>[silence]

The absence of answer here seems to indicate that you don't have a concrete
example which *you* consider as simpler.  So the potential disagreement
about what is simpler is really not the stumbling block.

> Well, the function exists in this form for many years (at least 12).
> I'm guessing that the &rest args form was to make it similar to
> start-process or something, but that's just a guess.

Yes, that's my guess as well.  Doesn't mean that it was a good decision,
since it is misleading to think that it works like start-process.
Anyway, that's post-22 stuff.


        Stefan

Re: Quote file name args to start-process-shell-command?

[Eli Zaretskii]

> Cc: stephen_leake@member.fsf.org,  dak@gnu.org,  schwab@suse.de,
> 	  emacs-devel@gnu.org,  lennart.borgman.073@student.lu.se
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Sun, 15 Oct 2006 20:14:39 -0400
> 
> >> The notion of what is simpler is clearly objective and we may never agree,
> > That is exactly why I asked for _your_ notion of ``simpler''.
> 
> >> but I may be satisfied by a concrete example which you consider
> >> as simpler.
> >[silence]
> 
> The absence of answer here seems to indicate that you don't have a concrete
> example which *you* consider as simpler.

And what does _your_ silence mean to my request of telling what is
your notion of simpler?

I don't want to waste my time to come up with examples only to hear
you say ``that's not simpler''.

Re: Quote file name args to start-process-shell-command?

[Stefan Monnier]

>> >> The notion of what is simpler is clearly objective and we may never agree,
>> > That is exactly why I asked for _your_ notion of ``simpler''.
>> 
>> >> but I may be satisfied by a concrete example which you consider
>> >> as simpler.
>> >[silence]
>> 
>> The absence of answer here seems to indicate that you don't have a concrete
>> example which *you* consider as simpler.

> And what does _your_ silence mean to my request of telling what is
> your notion of simpler?

It means that I don't know how to define it.

> I don't want to waste my time to come up with examples only to hear
> you say ``that's not simpler''.

As I said: I may be satisfied by a concrete example which you consider
as simpler.

Basically, I see no evidence that we'll strongly disagree on what is simpler.

To get the thing rolling, he is my rewrite of pgg-pgp.el to avoid the use of
a list of args.  It fixes a few missing shell-quote-arguments and replaces
a few (concat "\"" foo "\"") with calls to shell-quote-arguments.

The only other place I could find where the `args' feature of
start-process-shell-command is used is in pgg-pgp5.el which is basically
a copy of pgg-pgp.el so the patch can trivially be adapted, although I'd
rather not do that since I think pgg-pgp5.el has no business being in Emacs,
owing to the fact that pgp5 is not Free Software.

Do you find my new code less simple?


        Stefan


PS: It also fixes a bug in the handling of pgg-pgp-extra-args: the
defcustom says it should be a string, but the previous code assumed it was
a list of strings instead.


--- pgg-pgp.el	03 jui 2006 14:46:24 -0400	1.4
+++ pgg-pgp.el	16 oct 2006 01:36:27 -0400	
@@ -63,9 +63,9 @@
 (defun pgg-pgp-process-region (start end passphrase program args)
   (let* ((errors-file-name (pgg-make-temp-file "pgg-errors"))
 	 (args
-	  (append args
+	  (concat args
 		  pgg-pgp-extra-args
-		  (list (concat "2>" errors-file-name))))
+                  " 2>" (shell-quote-argument errors-file-name)))
 	 (shell-file-name pgg-pgp-shell-file-name)
 	 (shell-command-switch pgg-pgp-shell-command-switch)
 	 (process-environment process-environment)
@@ -83,9 +83,8 @@
 	  (let ((coding-system-for-read 'binary)
 		(coding-system-for-write 'binary))
 	    (setq process
-		  (apply #'funcall
-			 #'start-process-shell-command "*PGP*" output-buffer
-			 program args)))
+		  (start-process-shell-command "*PGP*" output-buffer
+                                               (concat program " " args))))
 	  (set-process-sentinel process #'ignore)
 	  (when passphrase
 	    (process-send-string process (concat passphrase "\n")))
@@ -142,15 +141,14 @@
 				    pgg-pgp-user-id)
 			    pgg-pgp-user-id))))
 	 (args
-	  (append
-	   `("+encrypttoself=off +verbose=1" "+batchmode"
-	     "+language=us" "-fate"
-	     ,@(if recipients
-		   (mapcar (lambda (rcpt) (concat "\"" rcpt "\""))
+	  (concat
+	   "+encrypttoself=off +verbose=1 +batchmode +language=us -fate"
+           (if recipients
+               (mapconcat 'shell-quote-argument
 			   (append recipients
 				   (if pgg-encrypt-for-me
-				       (list pgg-pgp-user-id))))))
-	   (if sign '("-s" "-u" pgg-pgp-user-id)))))
+                                      (list pgg-pgp-user-id)))))
+           (if sign (concat " -s -u " (shell-quote-argument pgg-pgp-user-id))))))
     (pgg-pgp-process-region start end nil pgg-pgp-program args)
     (pgg-process-when-success nil)))
 
@@ -166,7 +164,7 @@
 	      (pgg-read-passphrase
 	       (format "PGP passphrase for %s: " pgg-pgp-user-id) key)))
 	 (args
-	  '("+verbose=1" "+batchmode" "+language=us" "-f")))
+	  "+verbose=1 +batchmode +language=us -f"))
     (pgg-pgp-process-region start end passphrase pgg-pgp-program args)
     (pgg-process-when-success
       (if pgg-cache-passphrase
@@ -184,9 +182,9 @@
 	       (format "PGP passphrase for %s: " pgg-pgp-user-id)
 	       (pgg-pgp-lookup-key pgg-pgp-user-id 'sign))))
 	 (args
-	  (list (if clearsign "-fast" "-fbast")
-		"+verbose=1" "+language=us" "+batchmode"
-		"-u" pgg-pgp-user-id)))
+	  (concat (if clearsign "-fast" "-fbast")
+		" +verbose=1 +language=us +batchmode"
+		" -u " (shell-quote-argument pgg-pgp-user-id))))
     (pgg-pgp-process-region start end passphrase pgg-pgp-program args)
     (pgg-process-when-success
       (goto-char (point-min))
@@ -204,7 +202,7 @@
 (defun pgg-pgp-verify-region (start end &optional signature)
   "Verify region between START and END as the detached signature SIGNATURE."
   (let* ((orig-file (pgg-make-temp-file "pgg"))
-	 (args '("+verbose=1" "+batchmode" "+language=us"))
+	 (args "+verbose=1 +batchmode +language=us"))
 	 (orig-mode (default-file-modes)))
     (unwind-protect
 	(progn
@@ -216,8 +214,8 @@
     (if (stringp signature)
 	(progn
 	  (copy-file signature (setq signature (concat orig-file ".asc")))
-	  (setq args (append args (list signature orig-file))))
-      (setq args (append args (list orig-file))))
+	  (setq args (concat args " " (shell-quote-argument signature)))))
+    (setq args (concat args " " (shell-quote-argument orig-file)))
     (pgg-pgp-process-region (point)(point) nil pgg-pgp-program args)
     (delete-file orig-file)
     (if signature (delete-file signature))
@@ -237,8 +235,8 @@
   "Insert public key at point."
   (let* ((pgg-pgp-user-id (or pgg-pgp-user-id pgg-default-user-id))
 	 (args
-	  (list "+verbose=1" "+batchmode" "+language=us" "-kxaf"
-		(concat "\"" pgg-pgp-user-id "\""))))
+	  (concat "+verbose=1 +batchmode +language=us -kxaf "
+                  (shell-quote-argument pgg-pgp-user-id))))
     (pgg-pgp-process-region (point)(point) nil pgg-pgp-program args)
     (insert-buffer-substring pgg-output-buffer)))
 
@@ -247,8 +245,8 @@
   (let* ((pgg-pgp-user-id (or pgg-pgp-user-id pgg-default-user-id))
 	 (key-file (pgg-make-temp-file "pgg"))
 	 (args
-	  (list "+verbose=1" "+batchmode" "+language=us" "-kaf"
-		key-file)))
+	  (concat "+verbose=1 +batchmode +language=us -kaf "
+                  (shell-quote-argument key-file))))
     (let ((coding-system-for-write 'raw-text-dos))
       (write-region start end key-file))
     (pgg-pgp-process-region start end nil pgg-pgp-program args)
@@ -257,5 +255,5 @@
 
 (provide 'pgg-pgp)
 
-;;; arch-tag: 076b7801-37b2-49a6-97c3-218fdecde33c
+;; arch-tag: 076b7801-37b2-49a6-97c3-218fdecde33c
 ;;; pgg-pgp.el ends here

Re: Quote file name args to start-process-shell-command?

[Andreas Schwab]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Do you find my new code less simple?

It shows how easy it is to get it wrong.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Quote file name args to start-process-shell-command?

[Richard Stallman]

    And what does _your_ silence mean to my request of telling what is
    your notion of simpler?

    I don't want to waste my time to come up with examples only to hear
    you say ``that's not simpler''.

Could we please drop this argument?  This is an issue without practical
consequence, and it is sapping your time.

Re: Quote file name args to start-process-shell-command?

[Richard Stallman]

For simple practical reasons, I'm not considering a change in the
specs of this function, so could we drop the discussion?

Re: Quote file name args to start-process-shell-command?

[Eli Zaretskii]

> Cc: Eli Zaretskii <eliz@gnu.org>,
> 	  Lennart Borgman <lennart.borgman.073@student.lu.se>,
> 	  emacs-devel@gnu.org
> From: David Kastrup <dak@gnu.org>
> Date: Thu, 12 Oct 2006 11:27:58 +0200
> 
> However, I agree that `shell-quote-argument' would be inappropriate to
> apply on the arguments of `call-process-shell-command'.  Only those
> characters responsible for splitting arguments into words should get
> quoted.

What about < and | and ` and ' and ~ and ! etc.?  Some, if not all of
them also split arguments into words, and have other effects.  We
should leave this to the shell.

Let's put it another way: an interface to invoking a shell eventually
boils down to calling `system' or its equivalent.  A call to `system'
accepts a single string that is the command line to pass to the shell.
So any API wrapped around `system' eventually concatenates all the
portions of the command-line args into a single string, and that is
how applications should use such an API.

If one needs to pass several strings as separate arguments to a
subprogram (including a shell), one should use an appropriate API,
such as call-process.

Re: Quote file name args to start-process-shell-command?

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> Cc: Eli Zaretskii <eliz@gnu.org>,
>> 	  Lennart Borgman <lennart.borgman.073@student.lu.se>,
>> 	  emacs-devel@gnu.org
>> From: David Kastrup <dak@gnu.org>
>> Date: Thu, 12 Oct 2006 11:27:58 +0200
>> 
>> However, I agree that `shell-quote-argument' would be inappropriate to
>> apply on the arguments of `call-process-shell-command'.  Only those
>> characters responsible for splitting arguments into words should get
>> quoted.
>
> What about < and | and ` and ' and ~ and ! etc.?  Some, if not all of
> them also split arguments into words, and have other effects.  We
> should leave this to the shell.
>
> Let's put it another way: an interface to invoking a shell eventually
> boils down to calling `system' or its equivalent.  A call to `system'
> accepts a single string that is the command line to pass to the shell.
> So any API wrapped around `system' eventually concatenates all the
> portions of the command-line args into a single string, and that is
> how applications should use such an API.
>
> If one needs to pass several strings as separate arguments to a
> subprogram (including a shell), one should use an appropriate API,
> such as call-process.

But the current documentation string and the availability of multiple
arguments that are _documented_ as multiple arguments is quite
misleading.  If we decide that those arguments are not intended to be
multiple arguments but rather something that is merely spliced
together with spaces into one single string, then the documentation
should reflect this.

And it would seem like this function has a different behavior under
VMS, too.

The current situation is an incoherent mess.  The implementation under
VMS, the implementation under other systems, and the documentation are
not consistent.

If the documentation documents something which we can't reasonably
provide, the solution is to change the documentation, not to stick
one's head into the sand.  And then the behavior should be consistent
between operating systems.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Quote file name args to start-process-shell-command?

[Eli Zaretskii]

> Cc: schwab@suse.de,  lennart.borgman.073@student.lu.se,  emacs-devel@gnu.org
> From: David Kastrup <dak@gnu.org>
> Date: Thu, 12 Oct 2006 13:01:29 +0200
> 
> But the current documentation string and the availability of multiple
> arguments that are _documented_ as multiple arguments is quite
> misleading.  If we decide that those arguments are not intended to be
> multiple arguments but rather something that is merely spliced
> together with spaces into one single string, then the documentation
> should reflect this.

I agree that the fact they are concatenated should be documented.

> And it would seem like this function has a different behavior under
> VMS, too.

I don't know enough about VMS to comment on that; perhaps on VMS it's
impossible to do what we do on other systems.  Or maybe the VMS code
of this function should be rewritten.

Re: Quote file name args to start-process-shell-command?

[Richard Stallman]

    But the current documentation string and the availability of multiple
    arguments that are _documented_ as multiple arguments is quite
    misleading.  If we decide that those arguments are not intended to be
    multiple arguments but rather something that is merely spliced
    together with spaces into one single string, then the documentation
    should reflect this.

The function does what it is supposed to do.
I agree that we should change the documentation in this way.

Re: Quote file name args to start-process-shell-command?

[Stefan Monnier]

>     But the current documentation string and the availability of multiple
>     arguments that are _documented_ as multiple arguments is quite
>     misleading.  If we decide that those arguments are not intended to be
>     multiple arguments but rather something that is merely spliced
>     together with spaces into one single string, then the documentation
>     should reflect this.

> The function does what it is supposed to do.
> I agree that we should change the documentation in this way.

I still think that saying

   (start-process-shell-command NAME BUFFER COMMAND &rest COMMAND-ARGS)

is misleading and the "flexibility" it provides is very minor.  So it'd be
better to only have

   (start-process-shell-command NAME BUFFER COMMAND)

because it makes the behavior of the function much more obvious.  Makes for
a simpler docstring as well, which in turn will save us trouble and the
users as well.

And the callers can easily do the (mapconcat 'identity <args> " ")
themselves when they need it.


        Stefan

Re: Quote file name args to start-process-shell-command?

[Lennart Borgman]

Stefan Monnier wrote:
>>     But the current documentation string and the availability of multiple
>>     arguments that are _documented_ as multiple arguments is quite
>>     misleading.  If we decide that those arguments are not intended to be
>>     multiple arguments but rather something that is merely spliced
>>     together with spaces into one single string, then the documentation
>>     should reflect this.
>>     
>
>   
>> The function does what it is supposed to do.
>> I agree that we should change the documentation in this way.
>>     
>
> I still think that saying
>
>    (start-process-shell-command NAME BUFFER COMMAND &rest COMMAND-ARGS)
>
> is misleading and the "flexibility" it provides is very minor.  So it'd be
> better to only have
>
>    (start-process-shell-command NAME BUFFER COMMAND)
>
> because it makes the behavior of the function much more obvious.  Makes for
> a simpler docstring as well, which in turn will save us trouble and the
> users as well.
>
> And the callers can easily do the (mapconcat 'identity <args> " ")
> themselves when they need it.
>   

After reading this long discussion I agree to this.

Re: Quote file name args to start-process-shell-command?

[Kim F. Storm]

Lennart Borgman <lennart.borgman.073@student.lu.se> writes:

> After reading this long discussion I agree to this.

The start-process-shell-command command has existed in its current form
since 1994 -- I see no need to change it _right now_.

Pls. leave further discussions on the subject until ATR (after the release).

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Quote file name args to start-process-shell-command?

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> CC: eliz@gnu.org, schwab@suse.de, emacs-devel@gnu.org,
> 	lennart.borgman.073@student.lu.se
> Date: Thu, 12 Oct 2006 18:38:26 -0400
> 
> The function does what it is supposed to do.
> I agree that we should change the documentation in this way.

Done.

Re: Quote file name args to start-process-shell-command?

[Eli Zaretskii]

> Cc: Lennart Borgman <lennart.borgman.073@student.lu.se>,  emacs-devel@gnu.org
> From: David Kastrup <dak@gnu.org>
> Date: Thu, 12 Oct 2006 09:44:14 +0200
> 
> >   Remaining arguments are strings passed as additional arguments for COMMAND.
> >
> > There's no requirement here that each one of the "&rest ARGS" be a
> > separate command-line argument, is there?
> 
> Then it would be completely pointless to allow several ARGS.

It's not pointless, it can be useful if the command line is generated
piecewise.  start-process-shell-command is not system(3).

Re: Quote file name args to start-process-shell-command?

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> Cc: Lennart Borgman <lennart.borgman.073@student.lu.se>,  emacs-devel@gnu.org
>> From: David Kastrup <dak@gnu.org>
>> Date: Thu, 12 Oct 2006 09:44:14 +0200
>> 
>> >   Remaining arguments are strings passed as additional arguments
>> >   for COMMAND.
>> >
>> > There's no requirement here that each one of the "&rest ARGS" be a
>> > separate command-line argument, is there?
>> 
>> Then it would be completely pointless to allow several ARGS.
>
> It's not pointless, it can be useful if the command line is
> generated piecewise.  start-process-shell-command is not system(3).

Then the question is why it should behave like it.

The code says:

(defun start-process-shell-command (name buffer &rest args)
  "Start a program in a subprocess.  Return the process object for it.

[...]

Remaining arguments are the arguments for the command.
Wildcards and redirection are handled as usual in the shell.

[...]"

  (cond
   ((eq system-type 'vax-vms)
    (apply 'start-process name buffer args))
   ;; We used to use `exec' to replace the shell with the command,
   ;; but that failed to handle (...) and semicolon, etc.
   (t
    (start-process name buffer shell-file-name shell-command-switch
		   (mapconcat 'identity args " ")))))

Clearly, ARGS is (except on VMS) _not_ a list of separate arguments,
but rather strings pasted together with spaces.

So I don't understand how to apply your remark
"start-process-shell-command is not system(3).".
`start-process-shell-command' certainly is coded in a manner that
_strongly_ suggests it to be quite close to system(3) which is
documented as

SYNOPSIS
	#include <stdlib.h>

	int system(const char *command);

DESCRIPTION
	system() executes a command  specified in command by calling
	/bin/sh -c  command, and returns after the  command has been
	completed.  During execution of the command, SIGCHLD will be
	blocked, and SIGINT and SIGQUIT will be ignored.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Quote file name args to start-process-shell-command?

[Eli Zaretskii]

> Cc: lennart.borgman.073@student.lu.se,  emacs-devel@gnu.org
> From: David Kastrup <dak@gnu.org>
> Date: Thu, 12 Oct 2006 12:45:43 +0200
> 
> Clearly, ARGS is (except on VMS) _not_ a list of separate arguments,
> but rather strings pasted together with spaces.

Yes, as any API to `system' should do.

> So I don't understand how to apply your remark
> "start-process-shell-command is not system(3).".

That remark should be understood as follows:
start-process-shell-command is a wrapper around `system', but it isn't
`system' itself.  So it doesn't need to accept only one string, but
eventually it will concatenate them all.

Apologies for being unclear.

Re: Quote file name args to start-process-shell-command?

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> Cc: lennart.borgman.073@student.lu.se,  emacs-devel@gnu.org
>> From: David Kastrup <dak@gnu.org>
>> Date: Thu, 12 Oct 2006 12:45:43 +0200
>> 
>> Clearly, ARGS is (except on VMS) _not_ a list of separate arguments,
>> but rather strings pasted together with spaces.
>
> Yes, as any API to `system' should do.

start-process-shell-command is neither documented as an API to
`system', nor implemented by using `system'.

>> So I don't understand how to apply your remark
>> "start-process-shell-command is not system(3).".
>
> That remark should be understood as follows:
> start-process-shell-command is a wrapper around `system',

No, it isn't.  It does something similar, but the similarity to what
`system' does is not documented, and `system' is not used in its
implementation.

> but it isn't `system' itself.  So it doesn't need to accept only one
> string, but eventually it will concatenate them all.

Even if did use `system' (which it doesn't), any behavior that arises
as a consequence of undocumentated implementation details of
`start-process-shell-command' would need to get documented.

> Apologies for being unclear.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Quote file name args to start-process-shell-command?

[Eli Zaretskii]

> Cc: lennart.borgman.073@student.lu.se,  emacs-devel@gnu.org
> From: David Kastrup <dak@gnu.org>
> Date: Thu, 12 Oct 2006 13:25:00 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Clearly, ARGS is (except on VMS) _not_ a list of separate arguments,
> >> but rather strings pasted together with spaces.
> >
> > Yes, as any API to `system' should do.
> 
> start-process-shell-command is neither documented as an API to
> `system', nor implemented by using `system'.

It clearly produces the same effect; the details don't matter.  And I
think that any reasonable API to invoke a shell command would work in
the same way.

> > That remark should be understood as follows:
> > start-process-shell-command is a wrapper around `system',
> 
> No, it isn't.  It does something similar

You are nitpicking.

> but the similarity to what `system' does is not documented

There's no need to document that; we don't refer to C functions for
other primitives, at least not as a matter of principle.

Re: Quote file name args to start-process-shell-command?

[Andreas Schwab]

David Kastrup <dak@gnu.org> writes:

> Then the question is why it should behave like it.

It was definitely designed that way.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Quote file name args to start-process-shell-command?

[David Kastrup]

Andreas Schwab <schwab@suse.de> writes:

> David Kastrup <dak@gnu.org> writes:
>
>> Then the question is why it should behave like it.
>
> It was definitely designed that way.

By that argument, every misbehavior can be justified.  Whenever an
implementation disagrees with expectation and doc string, one can
_always_ claim "it was definitely designed that way", since any
implementation will exhibit just the behavior that the code actually
happens to have.

It does not make sense to document desirable behavior that the
implementation does not provide.  If the implementation can't
reasonably be expected to have the documented behavior, the
documentation needs to get changed.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Quote file name args to start-process-shell-command?

[Andreas Schwab]

David Kastrup <dak@gnu.org> writes:

> Andreas Schwab <schwab@suse.de> writes:
>
>> David Kastrup <dak@gnu.org> writes:
>>
>>> Then the question is why it should behave like it.
>>
>> It was definitely designed that way.
>
> By that argument, every misbehavior can be justified.

There is no misbehaviour.  It works like this on purpose, and since it is
documented that way we should not change it, or we break the users of
these functions.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Quote file name args to start-process-shell-command?

[Stefan Monnier]

I think the current situation is misleading: the "&rest ARGS" gives the
impression that these are separate args to the command, whereas they're just
arbitrary strings concatenated to COMMAND (which really can itself be
anything rather than a file name).

Just as obviously, this can't be fixed by quoting the arguments, because it
would defeat the purpose: you may as well use `start-process' and avoid the
whole shell problem.

I suggest the patch below to fix this problem: let the caller do the
concatenation/quoting, so she gets what she expects.  It's really not that
big a deal.


        Stefan


* auto-adding monnier@iro.umontreal.ca--first/emacs--monnier--0--patch-405 to greedy revision library /home/monnier/tmp/arch-lib
* found immediate ancestor revision in library (monnier@iro.umontreal.ca--first/emacs--monnier--0--patch-404)
* patching for this revision (monnier@iro.umontreal.ca--first/emacs--monnier--0--patch-405)
--- orig/lisp/subr.el
+++ mod/lisp/subr.el
@@ -2304,11 +2304,9 @@
  an output stream or filter function to handle the output.
  BUFFER may be also nil, meaning that this process is not associated
  with any buffer
-COMMAND is the name of a shell command.
-Remaining arguments are the arguments for the command.
-Wildcards and redirection are handled as usual in the shell.
+COMMAND is the shell command to run.
 
-\(fn NAME BUFFER COMMAND &rest COMMAND-ARGS)"
+\(fn NAME BUFFER COMMAND)"
   (cond
    ((eq system-type 'vax-vms)
     (apply 'start-process name buffer args))

Re: Quote file name args to start-process-shell-command?

[David Kastrup]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> I think the current situation is misleading: the "&rest ARGS" gives
> the impression that these are separate args to the command, whereas
> they're just arbitrary strings concatenated to COMMAND (which really
> can itself be anything rather than a file name).
>
> Just as obviously, this can't be fixed by quoting the arguments,
> because it would defeat the purpose: you may as well use
> `start-process' and avoid the whole shell problem.
>
> I suggest the patch below to fix this problem: let the caller do the
> concatenation/quoting, so she gets what she expects.  It's really
> not that big a deal.

> * auto-adding monnier@iro.umontreal.ca--first/emacs--monnier--0--patch-405 to greedy revision library /home/monnier/tmp/arch-lib
> * found immediate ancestor revision in library (monnier@iro.umontreal.ca--first/emacs--monnier--0--patch-404)
> * patching for this revision (monnier@iro.umontreal.ca--first/emacs--monnier--0--patch-405)
> --- orig/lisp/subr.el
> +++ mod/lisp/subr.el
> @@ -2304,11 +2304,9 @@
>   an output stream or filter function to handle the output.
>   BUFFER may be also nil, meaning that this process is not associated
>   with any buffer
> -COMMAND is the name of a shell command.
> -Remaining arguments are the arguments for the command.
> -Wildcards and redirection are handled as usual in the shell.
> +COMMAND is the shell command to run.
>  
> -\(fn NAME BUFFER COMMAND &rest COMMAND-ARGS)"
> +\(fn NAME BUFFER COMMAND)"
>    (cond
>     ((eq system-type 'vax-vms)
>      (apply 'start-process name buffer args))

I agree with the gist of your patch which removes the confusion about
the args.

But it does this only in the doc string, not the code itself.  This
gives the function "hidden" backwards compatibility.

I don't think that is really a good idea: I think the code should
follow suit.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Quote file name args to start-process-shell-command?

[Stefan Monnier]

> I agree with the gist of your patch which removes the confusion about
> the args.

> But it does this only in the doc string, not the code itself.  This
> gives the function "hidden" backwards compatibility.

> I don't think that is really a good idea: I think the code should
> follow suit.

Well, I guess the docstring should do like the `sit-for' does, and mention
the old calling convention and mention that it's deprecated.


        Stefan

Re: Quote file name args to start-process-shell-command?

[Stuart D. Herring]

>> I agree with the gist of your patch which removes the confusion about
>> the args.
>
>> But it does this only in the doc string, not the code itself.  This
>> gives the function "hidden" backwards compatibility.
>
>> I don't think that is really a good idea: I think the code should
>> follow suit.
>
> Well, I guess the docstring should do like the `sit-for' does, and mention
> the old calling convention and mention that it's deprecated.

Unless it makes sense on VMS (about which I know nothing) to do something
like (start-process "foo" "*bar*" "ls -l") (since
`start-process-shell-command' redirects to an identical `start-process'
call on VMS), which would be the preferred mode of operation for this
function, the function is broken already.

I tend to agree with David that, as written, this function is
fundamentally confused (and confusing): if the client (a Lisp program)
really has separate arguments for a process (a "command line"), it should
be calling `start-process' anyway.  If a client has a true command line,
it should (be required to) do any dynamic construction required for the
command itself if only to make it obvious to the reader what construction
is occurring.

To me, the only question is whether the whole-command-as-string case works
on VMS: if it does, we can just change the argument list, avoid calling
`apply', and hope that the compatibility impact isn't too great (I see
that all 2 calls to s-p-s-c in 21 use just one string, and that in 22 only
pgg-pgp5.el, pgg-pgp.el, and grep.el have calls to s-p-s-c or c-p-s-c that
would need changing).  If my earlier example doesn't work on VMS, though,
we still need to change the argument list just because the function will
have to do some magic to make the command work (possibly involving
emulating the shell to some extent) and it would be far too confusing to
layer that transformation on top of the implied argument concatenation.

For what it's worth, the implementation-equivalent
`call-process-shell-command' didn't exist in 21, so there's no
compatibility consideration there.  If we decide to actually make the
change, I'll be glad to write the change and fix those three files to be
compatible.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: Quote file name args to start-process-shell-command?

[Stefan Monnier]

> Unless it makes sense on VMS (about which I know nothing) to do something
> like (start-process "foo" "*bar*" "ls -l") (since
> `start-process-shell-command' redirects to an identical `start-process'
> call on VMS), which would be the preferred mode of operation for this
> function, the function is broken already.

I don't think the decision on this should depend on VMS.


        Stefan

Re: Quote file name args to start-process-shell-command?

[Stuart D. Herring]

> I don't think the decision on this should depend on VMS.

My point was merely that this function's current definition may very well
be buggy (as well as, IMHO, misguided), and that incompatible change would
be required to remove such a bug, so that (in that case) backward
compatibility would not be so great a concern.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: Quote file name args to start-process-shell-command?

[Richard Stallman]

The function does what it was supposed to do.
I don't want to change it.

Could we please turn from this subject to something useful?

Re: Quote file name args to start-process-shell-command?

[Richard Stallman]

call-process-shell-command can't quote its arguments
because there would be no way to specify wildcards
and redirections.