In article , Dan Douglas wrote:
> It isn't very common to dump multiple streams into one pipe.
echo "n't very" >/dev/null 2>&1
> I suggest avoiding |&.
Personally I wouldn't use it in scripts, since I try to stick as close
to plain vanilla Bourne shell as possible (though that's not as much of
In article , Chet Ramey wrote:
> On 1/17/13 1:01 PM, John Caruso wrote:
>> One feature of other shells (e.g. zsh and tcsh) I'd really love to have
>> in bash is "|&", which redirects both stdout and stderr--basically just
>> a shortcut for "2&g
One feature of other shells (e.g. zsh and tcsh) I'd really love to have
in bash is "|&", which redirects both stdout and stderr--basically just
a shortcut for "2>&1 |". Has this ever been considered for bash?
It may not seem like much of a difference, but it's saved me an enormous
numbers of keys
In article , Chet Ramey wrote:
> On 1/9/13 1:27 PM, John Caruso wrote:
>> In article , Chet Ramey wrote:
>>> Yes. Through 4.2.28, the dirspell option will cause the filename to be
>>> rewritten with spelling correction internally, but the corrected filename
>&
In article , Chet Ramey wrote:
> On 1/8/13 5:38 PM, John Caruso wrote:
>> So just to verify: there's no way in bash 4.2.0 through 4.2.28 to make
>> dirspell work correctly? The only fix is the direxpand option?
>
> Yes. Through 4.2.28, the dirspell option wil
In article , Chet Ramey wrote:
> On 1/8/13 5:18 PM, John Caruso wrote:
>> In bash 4.1, if you do "shopt +s dirspell" and type "ls /ect/passwd"
>> it's corrected to "ls /etc/passwd". In bash 4.2 with dirspell enabled,
>> the correction doe
In article , John
Caruso wrote:
> In bash 4.1, if you do "shopt +s dirspell" and type "ls /ect/passwd"
> it's corrected to "ls /etc/passwd". In bash 4.2 with dirspell enabled,
> the correction doesn't happen.
I forgot to mention that I've t
In bash 4.1, if you do "shopt +s dirspell" and type "ls /ect/passwd"
it's corrected to "ls /etc/passwd". In bash 4.2 with dirspell enabled,
the correction doesn't happen.
Some searching shows that the bash 4.1 behavior can apparently be enabled
again in bash 4.2 with a patch that adds a new "dire
