On Sun, Apr 9, 2017 at 6:23 PM, Cameron Simpson <[email protected]> wrote:
> On 09Apr2017 13:57, Samuel Sieb <[email protected]> wrote:
>>
>> On 04/09/2017 07:23 AM, bruce wrote:
>>>
>>> the following test works..
>>>
>>> ssh  [email protected] 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  [email protected] "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  [email protected] 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 <[email protected]>
>
> _______________________________________________
> users mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
_______________________________________________
users mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to