GNU bug report logs - #68732
29.1; shell-command-default-error-buffer is not interactive

Previous Next

Full log

Message #16 received at 68732 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Krzysztof Żelechowski <giecrilj <at> stegny.2a.pl>
Cc: 68732 <at> debbugs.gnu.org
Subject: Re: bug#68732: 29.1; shell-command-default-error-buffer is not
 interactive
Date: Fri, 26 Jan 2024 16:41:32 +0200

> Date: Fri, 26 Jan 2024 15:23:13 +0100
> From: Krzysztof Żelechowski <giecrilj <at> stegny.2a.pl>
> Cc: 68732 <at> debbugs.gnu.org
> 
> Suppose I am not a software developer but a system administrator.  I prefer not to use the scratch
> buffer or M-:.  

Then you should consider asking the software developer to write a
command for you which modifies the variable and then invokes
shell-command.

>    If the variable shell-command-default-error-buffer is not interactive by design, how am I supposed to
> get a clean output from M-! grub-mkconfig RET, for example?

By writing a new command which does that and is otherwise a thin
wrapper around shell-command, for example.

> The design looks inconsistent in that the variable affects only interactive behaviour while being
> non-interactive itself.  What is the use case for it?  Who is supposed to modify its value?

Variables that are not user options are supposed to be modified by
Lisp programs.

(But I also fail to see a problem with using setq by users.  It isn't
like that is forbidden or "not kosher" in some way.  We even show
examples of that in the user manual.  So why is this such a big
problem?)

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.