Redirect both stdout and stderr

[Cecil Westerhof]

I like to do the following:
exec ping -q -c 1 -W 1 ${pingDomain} &>/dev/null

But that gives:
ping: &>/dev/null: Temporary failure in name resolution
while evaluating {exec ping -q -c 1 -W 1 ${pingDomain} &>/dev/null}

I can do:
$ exec ping -q -c 1 -W 1 ${pingDomain} >/dev/null 2>/dev/null

But was wondering if there is a better way.

--
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof

[Rich]

Cecil Westerhof <Ce...@decebal.nl> wrote:
> I like to do the following:
> exec ping -q -c 1 -W 1 ${pingDomain} &>/dev/null
>
> But that gives:
> ping: &>/dev/null: Temporary failure in name resolution
> while evaluating {exec ping -q -c 1 -W 1 ${pingDomain} &>/dev/null}
>
> I can do:
> $ exec ping -q -c 1 -W 1 ${pingDomain} >/dev/null 2>/dev/null
>
> But was wondering if there is a better way.

Yes, but it involves being /very careful/ when reading the man page.

The redirect both "sigil" is >&

You used &> above

Those two are not the same. :)

[Cecil Westerhof]

Oops, I have seen it done like this so often in Bash, that I not even
wondered if it could be wrong. For one reason or another this works in
Bash.

Thanks for the correction. This works.

[Rich]

Cecil Westerhof <Ce...@decebal.nl> wrote:
> Rich <ri...@example.invalid> writes:
>
>> Cecil Westerhof <Ce...@decebal.nl> wrote:
>>> I like to do the following:
>>> exec ping -q -c 1 -W 1 ${pingDomain} &>/dev/null
>>>
>>> But that gives:
>>> ping: &>/dev/null: Temporary failure in name resolution
>>> while evaluating {exec ping -q -c 1 -W 1 ${pingDomain} &>/dev/null}
>>>
>>> I can do:
>>> $ exec ping -q -c 1 -W 1 ${pingDomain} >/dev/null 2>/dev/null
>>>
>>> But was wondering if there is a better way.
>>
>> Yes, but it involves being /very careful/ when reading the man page.
>>
>> The redirect both "sigil" is >&
>>
>> You used &> above
>>
>> Those two are not the same. :)
>
> Oops, I have seen it done like this so often in Bash, that I not even
> wondered if it could be wrong. For one reason or another this works in
> Bash.

Really? I'm going to have to try that later. Bash is only documented
for >& as well. It will be interesting to see.

[Cecil Westerhof]

Nope, &> is even the preferred way, from the man page:
Redirecting Standard Output and Standard Error
This construct allows both the standard output (file descriptor 1) and the standard error output (file descriptor 2) to be redirected
to the file whose name is the expansion of word.

There are two formats for redirecting standard output and standard error:

&>word
and
>&word

Of the two forms, the first is preferred. This is semantically equivalent to

>word 2>&1

When using the second form, word may not expand to a number or -. If it does, other redirection operators apply (see Duplicating File
Descriptors below) for compatibility reasons.


Now I am a little less mad on myself. ;-)

[Rich]

Ah, I see. And that is in my Bash man page as well. I've always used
the >& form myself, likely due to using the 2>&1 form to convince
stderr and stdout to go over a pipe to less for viewing. When I looked
quickly last night, I did not find this part of the manpage.

> Now I am a little less mad on myself. ;-)

Yep. Your Bash habits were hiding the reversed variant from your
sight.

[Brad Lanam]

On Friday, March 16, 2018 at 12:28:05 AM UTC-7, Cecil Westerhof wrote:
> Nope, &> is even the preferred way, from the man page:
> Redirecting Standard Output and Standard Error
> This construct allows both the standard output (file descriptor 1) and the standard error output (file descriptor 2) to be redirected
> to the file whose name is the expansion of word.
>
> There are two formats for redirecting standard output and standard error:
>
> &>word
> and
> >&word
>
> Of the two forms, the first is preferred. This is semantically equivalent to
>
> >word 2>&1
>
> When using the second form, word may not expand to a number or -. If it does, other redirection operators apply (see Duplicating File
> Descriptors below) for compatibility reasons.
>
>
> Now I am a little less mad on myself. ;-)

So the &> or >& syntax redirects both stdout and stderr.
Be aware that both &> and >& are bash-isms, and is not portable across shells.
They've added &>> also.
Don't know how long ago they added this stuff.
zsh may support this syntax also.