On 04/10/2017 02:23 PM, Joe Zeff wrote:
ICBW, but I was under the impression that the OP wanted to capture any
error output from ssh itself and wasn't concerned with errors at the
other end.
It's difficult to separate the two. You'd have to ensure that stderr on
the remote end was either wri
On 04/10/2017 01:18 PM, Gordon Messmer wrote:
In that case, ssh and wc's stderr will be written to stderr.log, just
the same as the other two formats.
ICBW, but I was under the impression that the OP wanted to capture any
error output from ssh itself and wasn't concerned with errors at the
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
On 04/10/2017 01:42 PM, Jon LaBadie wrote:
> On Mon, Apr 10, 2017 at 01:29:59PM -0700, Rick Stevens wrote:
>> On 04/10/2017 12:46 PM, Gordon Messmer wrote:
> ...
>>
>> That's correct. In both examples, the commands inside the double quotes
>> and only what's inside the quotes are what's executed on
On Mon, Apr 10, 2017 at 01:29:59PM -0700, Rick Stevens wrote:
> On 04/10/2017 12:46 PM, Gordon Messmer wrote:
...
>
> That's correct. In both examples, the commands inside the double quotes
> and only what's inside the quotes are what's executed on the remote
> system. Everything else is executed
On 04/10/2017 12:46 PM, Gordon Messmer wrote:
> On 04/10/2017 11:30 AM, JD wrote:
>> On 04/10/2017 10:32 AM, Gordon Messmer wrote:
>>> On 04/09/2017 07:25 PM, JD wrote:
> ssh user_foo@1.2.3.4 "pgrep -f 'master_app' | wc -l" 2> stderr.log
Those stderr messages would be coming from wc and NO
On 04/10/2017 01:01 PM, Joe Zeff wrote:
On 04/10/2017 12:46 PM, Gordon Messmer wrote:
I did understand. It doesn't matter if 2>file appears before the ssh
arguments, or at the end. In both cases, ssh's stderr will be written
to a local file. It is incorrect to say that the former example wou
On 04/10/2017 12:46 PM, Gordon Messmer wrote:
I did understand. It doesn't matter if 2>file appears before the ssh
arguments, or at the end. In both cases, ssh's stderr will be written
to a local file. It is incorrect to say that the former example would
redirect wc's stderr, and not ssh.
T
On 04/10/2017 11:30 AM, JD wrote:
On 04/10/2017 10:32 AM, Gordon Messmer wrote:
On 04/09/2017 07:25 PM, JD wrote:
ssh user_foo@1.2.3.4 "pgrep -f 'master_app' | wc -l" 2> stderr.log
Those stderr messages would be coming from wc and NOT from ssh.
The OP's command should be
ssh user_foo@1.2.3.4 2
On 04/10/2017 10:32 AM, Gordon Messmer wrote:
On 04/09/2017 07:25 PM, JD wrote:
ssh user_foo@1.2.3.4 "pgrep -f 'master_app' | wc -l" 2> stderr.log
would write any errors to the file "stderr.log" on the local box.
Those stderr messages would be coming from wc and NOT from ssh.
The OP's comm
On 04/10/2017 05:56 AM, bruce wrote:
So if I get what you guys have said...
ssh crawl_user@1.2.3.4 2>&1 pgrep -f 'master_client' | wc -l
would work with the >> 2>&1 << writing the stderr to the stdout for the ssh
For curiosity's sake, let's look at how the shell parses and executes
that
On 04/09/2017 07:25 PM, JD wrote:
ssh user_foo@1.2.3.4 "pgrep -f 'master_app' | wc -l" 2> stderr.log
would write any errors to the file "stderr.log" on the local box.
Those stderr messages would be coming from wc and NOT from ssh.
The OP's command should be
ssh user_foo@1.2.3.4 2> stderr.log
On Sun, Apr 9, 2017 at 10:49 PM, Samuel Sieb wrote:
> On 04/09/2017 07:25 PM, JD wrote:
>>
>> On 04/09/2017 06:02 PM, Samuel Sieb wrote:
>>>
>>> ssh user_foo@1.2.3.4 "pgrep -f 'master_app' | wc -l" 2> stderr.log
>>>
>>> would write any errors to the file "stderr.log" on the local box.
>>
>> Those
On 04/09/2017 07:25 PM, JD wrote:
On 04/09/2017 06:02 PM, Samuel Sieb wrote:
ssh user_foo@1.2.3.4 "pgrep -f 'master_app' | wc -l" 2> stderr.log
would write any errors to the file "stderr.log" on the local box.
Those stderr messages would be coming from wc and NOT from ssh.
The OP's command sh
On 04/09/2017 06:02 PM, Samuel Sieb wrote:
On 04/09/2017 04:34 PM, bruce wrote:
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..
Actually, it doesn't. The "wc -l" will be run on the local box, but
hopeful
On 04/09/2017 04:34 PM, bruce wrote:
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..
Actually, it doesn't. The "wc -l" will be run on the local box, but
hopefully you're getting the same result either way.
On Sun, Apr 9, 2017 at 6:23 PM, Cameron Simpson wrote:
> On 09Apr2017 13:57, Samuel Sieb 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
On 09Apr2017 13:57, Samuel Sieb 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 t
On 04/09/2017 07:23 AM, bruce wrote:
hey...
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.
hey...
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 "
20 matches
Mail list logo
