Re: How to suppress/avoid *Async Shell Command* buffer?

[Barry Margolin]

In article <mailman.41.1368897044.22516.help-gnu-emacs@gnu.org>,
 Andreas Röhler <andreas.roehler@easy-emacs.de> wrote:

> Am 18.05.2013 16:37, schrieb Marius Hofert:
> > Hi Andreas,
> >
> > what do you mean by 'caused'?
> >
> > The question mark is a place holder for the file (foo.pdf).
> 
> Okay, see dired-do-shell-command reads it
> 
> > What does this have to do with *Async Shell Command* being opened?
> >
> 
> Nothing. It's the ampersand following ? which matters.
> 
> > Note: The behavior of "!" on foo.pdf in dired mode is fine (in the sense
> > that Okular opens, the pdf is shown, everything asynchronously), I just want
> > to avoid the buffer *Async Shell Command* being opened.
> >
> 
> Which seems the buffer Emacs connects the process to.
> Deleting it should end the processes, probably not a good idea.
> 
> So the ampersand seems the culprit - not the question mark.
> What happens when calling your stuff without it?

This is essentially the same as using M-!, isn't it, except that it 
automatically fills in the filename argument? If you don't use the 
ampersand, Emacs waits for the command to finish, and then displays the 
output in *Shell Command Output*. If you use ampersand, it doesn't wait, 
and displays the output incrementally in *Async Shell Command*.

Either way, the output has to be put somewhere.

However, the synchronous mode has a feature: if the command produces 
little or no output, it doesn't switch to the *Shell Command Output* 
buffer, it just displays it in the minibuffer.  Here's a trick that I 
think should do what you want: Run the backgrounded command in a 
subshell (wrap it in parentheses):

! (command ? &>/dev/null &)

As far as Emacs is concerned, that's a synchronous command, because it 
doesn't end in "&". But it runs in the background within the subshell. 
Redirect the output so that Emacs immediately reads EOF, and has nothing 
to display in the minibuffer (it may display "(Shell command completed 
with no output)").

-- 
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***