shell-command

shell-command

[Matthias Pfeifer]

Hi There,

I have following issue and wonder if sombody can help out:

I am calling shell-command interactively without prefix argument. The help
text says

(shell-command COMMAND &optional OUTPUT-BUFFER ERROR-BUFFER)

Execute string COMMAND in inferior shell; display output, if any.
With prefix argument, insert the COMMAND’s output at point.

The command that I call copies a couple of files (around 20-30 files) via
scp. A sample line from the output of the command when I call it in a xterm
terminal window looks like this:

file    100%    123kb      123KB/s     00:00

However emacs keeps telling me "Shell command succeeded with no output."
and the *Shell Command Output* buffer is in fact empty. I wonder where the
output goes?

Matthias

Re: shell-command

[tomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, Jan 10, 2017 at 12:17:49PM +0100, Matthias Pfeifer wrote:
> Hi There,
> 
> I have following issue and wonder if sombody can help out:
> 
> I am calling shell-command interactively without prefix argument. The help
> text says
> 
> (shell-command COMMAND &optional OUTPUT-BUFFER ERROR-BUFFER)
> 
> Execute string COMMAND in inferior shell; display output, if any.
> With prefix argument, insert the COMMAND’s output at point.
> 
> The command that I call copies a couple of files (around 20-30 files) via
> scp. A sample line from the output of the command when I call it in a xterm
> terminal window looks like this:
> 
> file    100%    123kb      123KB/s     00:00
> 
> However emacs keeps telling me "Shell command succeeded with no output."
> and the *Shell Command Output* buffer is in fact empty. I wonder where the
> output goes?

To stderr.

Try this:

  scp -rv foo@bar:~/some-dir /tmp > one 2>two

and look at files "one" and "two".

So either you wrap your scp in some kind of redirection or you look
into the ERROR-BUFFER.

Regards
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlh0zVgACgkQBcgs9XrR2kaR6ACfRhXNfz5ctWvEYyv/5XfnI2FX
JR4An0UeZ8PYTMlWOz/wWlZsL3p/qZIk
=fZFY
-----END PGP SIGNATURE-----

Re: shell-command

[Matthias Pfeifer]

2017-01-10 13:02 GMT+01:00 <tomas@tuxteam.de>:

> > However emacs keeps telling me "Shell command succeeded with no output."
> > and the *Shell Command Output* buffer is in fact empty. I wonder where
> the
> > output goes?
>
> To stderr.
>
> Try this:
>
>   scp -rv foo@bar:~/some-dir /tmp > one 2>two
>
> and look at files "one" and "two".
>
> So either you wrap your scp in some kind of redirection or you look
> into the ERROR-BUFFER.
>


That was just what I was thinking. And I fear that I must have some very
basic misunderstanding here, but i was testing this before wrinting and did:

$ scp somefile somehost:/tmp 2> /dev/null

I see the same output as usual...

$ scp somefile somehost:/tmp > /dev/null

I ses nothing...

Where am i mistaking?

Re: shell-command

[tomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, Jan 11, 2017 at 09:45:55AM +0100, Matthias Pfeifer wrote:
> 2017-01-10 13:02 GMT+01:00 <tomas@tuxteam.de>:
> 
> > > However emacs keeps telling me "Shell command succeeded with no output."
> > > and the *Shell Command Output* buffer is in fact empty. I wonder where
> > the
> > > output goes?
> >
> > To stderr.
> >
> > Try this:
> >
> >   scp -rv foo@bar:~/some-dir /tmp > one 2>two
> >
> > and look at files "one" and "two".
> >
> > So either you wrap your scp in some kind of redirection or you look
> > into the ERROR-BUFFER.
> >
> 
> 
> That was just what I was thinking. And I fear that I must have some very
> basic misunderstanding here, but i was testing this before wrinting and did:
> 
> $ scp somefile somehost:/tmp 2> /dev/null
> 
> I see the same output as usual...
> 
> $ scp somefile somehost:/tmp > /dev/null
> 
> I ses nothing...
> 
> Where am i mistaking?

I can't say for sure (and am a bit pressed to check now), but most probably
scp checks whether it's "talking" to a tty on its stdout or not and adapts
its behaviour. Sounds grotty, but many potentially interactive programs
do that (and users are generally better off for it, except in cases like
this :-)

regards
- -- t
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlh1/TYACgkQBcgs9XrR2kYw6ACaA/0k3pzbjY/3/uCd3kMQ9OZR
i3QAn3G2sqZc/roRv+gNrs54n/PHnYAq
=YpnH
-----END PGP SIGNATURE-----

Re: shell-command

[Kaushal Modi]

On Wed, Jan 11, 2017 at 3:46 AM Matthias Pfeifer <mpfeifer77@gmail.com>
wrote:

> That was just what I was thinking. And I fear that I must have some very
> basic misunderstanding here, but i was testing this before wrinting and
> did:
>
> $ scp somefile somehost:/tmp 2> /dev/null
>
> I see the same output as usual...
>

Correct, because that redirects only errors to /dev/null. The standard
output is still sent to your default output device (terminal).


> $ scp somefile somehost:/tmp > /dev/null
>
> I ses nothing...
>

That is expected here again because ">" redirects standard output to
/dev/null. So the terminal gets nothing.


>
> Where am i mistaking?
>

You can simply try

ls > /dev/null

and see that you get no output on the terminal, because all output is
redirected to /dev/null

Here's one of the references that came up at top when I googled "unix
redirection": http://sc.tamu.edu/help/general/unix/redirection.html
-- 

Kaushal Modi

Re: shell-command

[tomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, Jan 11, 2017 at 03:11:51PM +0000, Kaushal Modi wrote:
> On Wed, Jan 11, 2017 at 3:46 AM Matthias Pfeifer <mpfeifer77@gmail.com>
> wrote:
> 
> > That was just what I was thinking. And I fear that I must have some very
> > basic misunderstanding here, but i was testing this before wrinting and
> > did:
> >
> > $ scp somefile somehost:/tmp 2> /dev/null
> >
> > I see the same output as usual...
> >
> 
> Correct, because that redirects only errors to /dev/null. The standard
> output is still sent to your default output device (terminal).

No. "ls" and "scp" behave differently:

# This is ls:

  tomas@rasputin:~$ ls > foo.stdout 2>foo.stderr
  tomas@rasputin:~$ ls -l foo.*
  -rw-r--r-- 1 tomas tomas    0 Jan 11 16:20 foo.stderr
  -rw-r--r-- 1 tomas tomas 1629 Jan 11 16:20 foo.stdout

# regular output goes to stdout; only error output goes to
# stderr (in this case, nothing)

# and this is scp:

  tomas@rasputin:~$ scp /etc/init.d tomas@localhost:/tmp > bar.stdout 2>bar.stderr
  Enter passphrase for key '/home/tomas/.ssh/id_rsa': 
  tomas@rasputin:~$ ls -l bar*
  -rw-r--r-- 1 tomas tomas 32 Jan 11 16:21 bar.stderr
  -rw-r--r-- 1 tomas tomas  0 Jan 11 16:21 bar.stdout

# "regular" output goes to stderr, nothing to stdout

But note that scp most probably changes behavior whether it's "seeing"
a tty as its stdout and/or stderr. Beware!

What at first looks strange makes some sense if you think that scp's
"output" somehow is not the same as ls's output. The first one is
meant for human consumption whereas the latter is for both: human
and for piping into other programs. More or less.

(still have to check with sources, so take the above with a grain
of salt).

regards
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlh2TzkACgkQBcgs9XrR2kYvRQCbBj1mI7ROj0IwWzzcmMvfZevL
HPsAn2F1GlFN113/bXnb5+1/xFd1I5cY
=Qr/o
-----END PGP SIGNATURE-----

shell-command

[John J Foerch]

Hello,

  When running an asynchronous command with `shell-command', special
sequences in the output are not processed, so for example, the
progress-meter of wget gets output repeatedly "end-to-end" instead of
printing over itself for the effect of animation.  If comint were used
instead of call-process for asynchronous processes, such commands'
output would be displayed "correctly".  Is there anything blocking such
a change?  I would find it very convenient, as I often want to run an
mplayer or wget process with M-!.

Thank you,

John Foerch