GNU bug report logs -
#63432
30.0.50; Handle current-prefix-arg in async-shell-command
Previous Next
Reported by: Gabriel <gabriel376 <at> hotmail.com>
Date: Wed, 10 May 2023 23:10:02 UTC
Severity: normal
Found in version 30.0.50
Done: Eli Zaretskii <eliz <at> gnu.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 63432 in the body.
You can then email your comments to 63432 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63432; Package
emacs.
(Wed, 10 May 2023 23:10:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Gabriel <gabriel376 <at> hotmail.com>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
Your message specified a Severity: in the pseudo-header, but
the severity value bug was not recognised.
The default severity normal is being used instead.
The recognised values are: critical, grave, serious, important, normal, minor, wishlist.
(Wed, 10 May 2023 23:10:02 GMT) Full text and rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Severity: bug
Steps:
1) emacs -Q from master branch (3adc1e7f379)
2) C-u M-& "ls"
Error: shell-command: Wrong type argument: stringp, (4)
Cause:
When called interactively, `async-shell-command' pass argument
OUTPUT-BUFFER as `current-prefix-arg' to `shell-command'. As per
docstring of `shell-command':
"If OUTPUT-BUFFER is not a buffer and not nil (which happens
interactively when the prefix argument is given), insert the output in
current buffer after point leaving mark after it. This cannot be done
asynchronously."
Patch:
[0001-Handle-current-prefix-arg-in-async-shell-command.patch (text/x-diff, attachment)]
[Message part 3 (text/plain, inline)]
---
Gabriel
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63432; Package
emacs.
(Sat, 13 May 2023 13:44:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 63432 <at> debbugs.gnu.org (full text, mbox):
> From: Gabriel <gabriel376 <at> hotmail.com>
> Date: Wed, 10 May 2023 20:04:24 -0300
>
> Steps:
> 1) emacs -Q from master branch (3adc1e7f379)
> 2) C-u M-& "ls"
> Error: shell-command: Wrong type argument: stringp, (4)
>
> Cause:
> When called interactively, `async-shell-command' pass argument
> OUTPUT-BUFFER as `current-prefix-arg' to `shell-command'. As per
> docstring of `shell-command':
>
> "If OUTPUT-BUFFER is not a buffer and not nil (which happens
> interactively when the prefix argument is given), insert the output in
> current buffer after point leaving mark after it. This cannot be done
> asynchronously."
Yes, this bug was there since the day async-shell-command was added to
Emacs.
> diff --git a/lisp/simple.el b/lisp/simple.el
> index 58517dd81f9..ba832581955 100644
> --- a/lisp/simple.el
> +++ b/lisp/simple.el
> @@ -4499,10 +4499,12 @@ async-shell-command
> ((eq major-mode 'dired-mode)
> (dired-get-filename nil t)))))
> (and filename (file-relative-name filename))))
> - current-prefix-arg
> + nil
> shell-command-default-error-buffer))
> (unless (string-match "&[ \t]*\\'" command)
> (setq command (concat command " &")))
> + (when (and output-buffer (numberp output-buffer))
> + (error "Invalid output buffer"))
> (shell-command command output-buffer error-buffer))
Thanks, but I don't understand why we need the error message. Isn't
it enough to pass nil as 2nd argument to shell-command?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63432; Package
emacs.
(Sat, 13 May 2023 23:42:02 GMT)
Full text and
rfc822 format available.
Message #11 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Eli Zaretskii <eliz <at> gnu.org> writes:
> Thanks, but I don't understand why we need the error message. Isn't
> it enough to pass nil as 2nd argument to shell-command?
The error message is just for noninteractive cases where a caller passes
a numeric argument as the second argument of `async-shell-command'. For
interactive cases, a nil value will be always passed to `shell-command'.
Example:
Before patch:
(async-shell-command "ls" 1) => error: (wrong-type-argument stringp 1)
After patch:
(async-shell-command "ls" 1) => error: (error "Invalid output buffer")
Here is a patch without the error message, in case it's preferable:
[0001-Ignore-current-prefix-arg-in-async-shell-command.patch (text/x-diff, attachment)]
[Message part 3 (text/plain, inline)]
---
Gabriel
Reply sent
to
Eli Zaretskii <eliz <at> gnu.org>:
You have taken responsibility.
(Sun, 14 May 2023 06:29:01 GMT)
Full text and
rfc822 format available.
Notification sent
to
Gabriel <gabriel376 <at> hotmail.com>:
bug acknowledged by developer.
(Sun, 14 May 2023 06:29:01 GMT)
Full text and
rfc822 format available.
Message #16 received at 63432-done <at> debbugs.gnu.org (full text, mbox):
> From: Gabriel <gabriel376 <at> hotmail.com>
> Date: Sat, 13 May 2023 20:35:51 -0300
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > Thanks, but I don't understand why we need the error message. Isn't
> > it enough to pass nil as 2nd argument to shell-command?
>
> The error message is just for noninteractive cases where a caller passes
> a numeric argument as the second argument of `async-shell-command'.
I think the error signaled by shell-command is sufficient in the
non-interactive case. We don't usually try detecting
wrong-type-argument errors in non-interactive use, we leave it to the
underlying primitives to detect and report.
> Example:
> Before patch:
> (async-shell-command "ls" 1) => error: (wrong-type-argument stringp 1)
> After patch:
> (async-shell-command "ls" 1) => error: (error "Invalid output buffer")
I see nothing wrong with the "before" version, it gives an accurate
description of the problem for that case.
> Here is a patch without the error message, in case it's preferable:
Thanks, installed on the emacs-29 branch, and closing the bug.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63432; Package
emacs.
(Sun, 14 May 2023 07:20:02 GMT)
Full text and
rfc822 format available.
Message #19 received at 63432 <at> debbugs.gnu.org (full text, mbox):
> Cc: 63432-done <at> debbugs.gnu.org
> Date: Sun, 14 May 2023 09:28:34 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
>
> Thanks, installed on the emacs-29 branch, and closing the bug.
Btw, I've noticed that the ERROR-BUFFER argument is ignored by
async-shell-command, and OUTPUT-BUFFER is not documented. So I've now
fixed the doc string to correct these deficiencies.
(I wonder why was ERROR-BUFFER at all provided in this function in the
first place, since the underlying shell-command cannot support it.
Maybe we should have an advertised-calling-convention there which
excludes it?)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63432; Package
emacs.
(Mon, 15 May 2023 17:19:02 GMT)
Full text and
rfc822 format available.
Message #22 received at 63432 <at> debbugs.gnu.org (full text, mbox):
> Btw, I've noticed that the ERROR-BUFFER argument is ignored by
> async-shell-command, and OUTPUT-BUFFER is not documented. So I've now
> fixed the doc string to correct these deficiencies.
>
> (I wonder why was ERROR-BUFFER at all provided in this function in the
> first place, since the underlying shell-command cannot support it.
> Maybe we should have an advertised-calling-convention there which
> excludes it?)
Keeping the same function signatures for shell-command and async-shell-command
would allow to implement the error-buffer support for the latter in future.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#63432; Package
emacs.
(Mon, 15 May 2023 18:24:02 GMT)
Full text and
rfc822 format available.
Message #25 received at 63432 <at> debbugs.gnu.org (full text, mbox):
> From: Juri Linkov <juri <at> linkov.net>
> Cc: gabriel376 <at> hotmail.com, Stefan Monnier <monnier <at> iro.umontreal.ca>,
> 63432 <at> debbugs.gnu.org
> Date: Mon, 15 May 2023 20:17:00 +0300
>
> > Btw, I've noticed that the ERROR-BUFFER argument is ignored by
> > async-shell-command, and OUTPUT-BUFFER is not documented. So I've now
> > fixed the doc string to correct these deficiencies.
> >
> > (I wonder why was ERROR-BUFFER at all provided in this function in the
> > first place, since the underlying shell-command cannot support it.
> > Maybe we should have an advertised-calling-convention there which
> > excludes it?)
>
> Keeping the same function signatures for shell-command and async-shell-command
> would allow to implement the error-buffer support for the latter in future.
That's fine, but then it would have been better to mention this in a
comment. Because otherwise it just looks like a copy-pasta error
(after one wastes some time to figure out that it is basically
unused).
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Tue, 13 Jun 2023 11:24:06 GMT)
Full text and
rfc822 format available.
This bug report was last modified 1 year and 333 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.