On 10/12/11 4:07 PM, Greg Wooledge wrote:
> Personally I wish all the csh compatibility features would go away forever,
> but I appreciate that it's too late to remove them at this point. But
> I think the manual should be updated to indicate that the >&word form
> just plain fails for certain wo
On Thu, Oct 13, 2011 at 06:33:56AM +, Stephane CHAZELAS wrote:
> 2011-10-12, 14:39(-06), Eric Blake:
> > foo >&./1
>
> Or
>
> foo >&! 1
>
> or
>
> foo &> 1
>
> or
>
> foo > 1 2>&1
So put those in the manual! ;-)
2011-10-12, 14:39(-06), Eric Blake:
> On 10/12/2011 02:07 PM, Greg Wooledge wrote:
>> Even using a space is not sufficient to force a valid file descriptor number
>> to be treated as a filename:
>>
>> imadev:~$ foo>& 1
>> stdout
>> stderr
>> imadev:~$ ls -l 1
>> 1 not found
>
> If you want 'word'
On 10/12/2011 02:07 PM, Greg Wooledge wrote:
Even using a space is not sufficient to force a valid file descriptor number
to be treated as a filename:
imadev:~$ foo>& 1
stdout
stderr
imadev:~$ ls -l 1
1 not found
If you want 'word' treated as a filename, then express it as a filename.
It's
Greg Wooledge writes:
> Personally I wish all the csh compatibility features would go away forever,
> but I appreciate that it's too late to remove them at this point. But
> I think the manual should be updated to indicate that the >&word form
> just plain fails for certain words, even with a sp
The manual says:
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
