On 04/10/2017 01:56 PM, Rick Stevens wrote:
Might as well be complete:
2>stderr.log sshuser_foo@1.2.3.4 "pgrep -f 'master_app' | wc -l"
is also equivalent
Uhm, dunno about that one as you'd be redirecting stderr of the shell
itself--not the stderr of the ssh command ONLY. I also don't know if
that'd be treated like a non-exported environment variable (that only
lasts for the subshell's lifetime) or if it'd be sticky and you'd need
to restart your shell to get stderr for the shell back.
Nope. This works *exactly* the same way as all of the other examples
given. Again, it is trivial to test this if the documentation is in any
way unclear, or if you don't understand it:
$ 2> stderr ssh testhost ./write-to-stderr
$ cat stderr
test stderr
$ echo test >&2
test
It's uncommon, in my experience, to see redirection in any location
other than the end of a command. And in my opinion, it's really
misleading to do so (as evidenced by the fact that at least one person
in this thread thinks that the effect is different if the redirection is
moved).
The bash man page states, "redirection operators may precede or appear
anywhere within a simple command or may follow a command."
It *is* possible to redirect the shell's own stderr, to which you
alluded, but you'd use "exec 2> ./stderr" (or another path) to do so.
_______________________________________________
users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx