On Sun, Apr 9, 2017 at 6:23 PM, Cameron Simpson <cs@xxxxxxxxxx> wrote: > On 09Apr2017 13:57, Samuel Sieb <samuel@xxxxxxxx> wrote: >> >> On 04/09/2017 07:23 AM, bruce wrote: >>> >>> the following test works.. >>> >>> ssh user_foo@1.2.3.4 pgrep -f 'master_app' | wc -l >>> >>> however, i realized that in some cases I was seeing a "ssh connection >>> timeout" so I looked into how to capture the complete STDERR from the >>> local side. >>> >>> ssh user_foo@1.2.3.4 "pgrep -f 'master_app' | wc -l " 1>&2 >>> >>> runs but not sure it will actually do what I want... >>> >> commands are very different from each other. The first one will run the >> "wc -l" on the local computer and the second one will run it on the remote >> computer. The "1>&2" will redirect the stdout to stderr, so all your output >> will be coming out in stderr. If you want to include stderr in stdout, use >> "2>&1". If you just want to save stderr somewhere, you can use >> "2>filename". > > > All very pertinent points. Just to add one: > > if you're doing the first command (ssh ... | wc ...) then your redirections > apply only to the "wc". You seem to want the stderr from the ssh. For that > you need to go: > > ssh .... 2>filename | wc -l > > One reason that you may think the two commands are the same is that > functionally they pretty much are because wc (as invoked) read from stdin > and writes to stdout, and so it doesn't matter whether it runs locally or > remote. > > As a matter of practive I tend to run as little as possibly remotely, so I > would use your first invocation (remote pgrep, local wc) if there wasn't a > special reason otherwise. > ----- hey guys.. my bad on the typos... the cmd -->> ssh user_foo@1.2.3.4 pgrep -f 'master_app' | wc -l works, as it runs the pgrep 'xxx' | wc -l all on the remote box.. i've checked this and it's giving thee correct expected value. however I realized that there might be "ssh command timeout" errs that I hadn't thought about, so I was wondering how to capture the ssh STDERR to be able to see the err. so the STDERR would the stderr for the local box running the ssh and not the remote from the "pgrep" action. hope that clarifies a bit. thanks > Cheers, > Cameron Simpson <cs@xxxxxxxxxx> > > _______________________________________________ > users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx _______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
