> On Dec 12, 2020, at 5:51 PM, Léa Gris wrote:
>
> It raises multiple observations:
>
> - I thought the placeholder variable _ was a sinkhole like /dev/null.
It is not. I expect you've been deceived by countless examples like:
read var1 var2 _ var3 _ var4
Your three non-dash shells explic
Date:Sat, 12 Dec 2020 23:51:19 +0100
From:=?UTF-8?B?TMOpYSBHcmlz?=
Message-ID:
| - I thought the placeholder variable _
It isn't really a placeholder variable, it is a magic piece of sh*t
invented by ksh (initially) to fill the role that !$ had in csh
(bash has !$
# GNU bash, version 5.0.17(1)-release (x86_64-pc-linux-gnu)
bash -c 'unset _;_=42;echo $_;unset _;: $((_=666));echo "$_"'
666
# ksh version sh (AT&T Research) 93u+ 2012-08-01
ksh -c 'unset _;_=42;echo $_;unset _;: $((_=666));echo "$_"'
42
-3,02546243348e-123
# zsh 5.8 (x86_64-ubuntu-linux
Emanuel Haupt wrote:
> On 12/7/20 1:44 PM, Fazal Majid wrote:
> >> On Dec 7, 2020, at 15:37, Chet Ramey wrote:
> >>
> >> Thanks for the report. I've never actually encountered this error.
> >> Just lucky, I guess.
> >
> > It’s a race condition. The machine I run it on has 6 cores and HT,
> > so I
On 12/12/20 5:54 AM, Oğuz wrote:
In Bash 5.1, Ctrl-C doesn't interrupt the command below. The only way out I
guess is to stop it Ctrl-Z and run `kill %%`, but that's really too much
work.
cat <
It's not a signal blocking problem. It's a combination of an interactive
shell and the shell for
In Bash 5.1, Ctrl-C doesn't interrupt the command below. The only way out I
guess is to stop it Ctrl-Z and run `kill %%`, but that's really too much
work.
cat <
