Normal bash:
$ kill -l 141
PIPE
Bash compiled with --enable-minimal-config --enable-alias:
$ kill -l 141
SIGPIPE
That SIG prefix shouldn't be there. (Enabling POSIX mode makes no
difference to the output.)
A look at the source tells me that, for some reason, the POSIXly correct
output of 'kill
Op 04-11-16 om 21:41 schreef Martijn Dekker:
> $ fn() { false && echo bug || echo ok; }
> $ fn
> ok
> $ fn
> ok
> $ fn | cat
> ok
> $ fn | cat
> bug
> $ fn | cat
> bug
> $ (fn) | cat
> ok
Another datapoint: the result and output is exactly as above
An interactive bash is killed by SIGINT after a command to unset any
trap for SIGINT.
$ cat >/tmp/dotscript <
Op 06-11-16 om 09:08 schreef Martijn Dekker:
> An interactive bash is killed by SIGINT after a command to unset any
> trap for SIGINT.
...if executed in a dot script, that is (in case that wasn't clear from
the subject line and the code examples).
Another datapoint: the same phenomeno
Op 06-11-16 om 16:52 schreef Chet Ramey:
> On 11/6/16 4:08 AM, Martijn Dekker wrote:
>> An interactive bash is killed by SIGINT after a command to unset any
>> trap for SIGINT.
>>
>> $ cat >/tmp/dotscript <> trap
>> trap - INT
>> kill -s INT "$$
Op 08-11-16 om 14:38 schreef Chet Ramey:
> On 11/7/16 7:54 AM, Martijn Dekker wrote:
>
>> But it's really helped that bash turns out to have another unique
>> behaviour: apparently, bash refuses to ignore SIGINT on interactive
>> shells. So, for interactive bash, the
y; assignments to it are
>
> just ignored. Suggested by Martijn Dekker
>
I object to the impression given that I would suggest any such thing. In
fact I think ignoring assignments is very bad practice and I recall
arguing rat
When IFS is null, unquoted $* within an unquoted substitution (e.g.
${1+$*} or ${unset_var-$*}) joins the PPs together into one field, as if
either "$*" or the whole substitution were quoted.
POSIX says the unquoted substitution is supposed to generate one field
for each positional parameter, with
It is not clear to me why bash has two separate namespaces for
long-named shell options, handled by two separate commands.
It might make sense if 'set -o' is for POSIX options only and 'shopt'
for bash-specific options, but that doesn't apply. I can't figure out a
consistent basis for a distinctio
Op 27-02-17 om 15:32 schreef Chet Ramey:
> At the time, there were already some bash-specfic additions to
> `set -o' (braceexpand/histexpand/posix), but I wasn't interested in
> adding twenty more.
But why not? What's the advantage to users in creating a separate
category of options, seemingly bas
Op 24-02-17 om 21:20 schreef Grisha Levit:
> XRAT C.2.5 : Special Parameters [1] specifically addresses the case of
> ${unset_var-$*}. The following example is provided:
>
> set "abc" "def ghi" "jkl"
> IFS='' # null
> unset var
> printf '%s\n' ${var-$*}
>
> abcdef ghijkl
>
> ..which seems to co
Op 27-02-17 om 21:03 schreef Chet Ramey:
> If you think you have a winning argument, initiate a new discussion with
> the Austin Group. You might want to dig up the mail archives from
> October, 2014 and look at the discussion that preceded interpretation 888.
Thanks for the heads-up. I'm finding
Test script:
printf "$LINENO "
printf "$LINENO "
eval ' printf "$LINENO "
printf "$LINENO "
printf "$LINENO " '
printf "$LINENO\n"
Output on various shells:
bash: 1 2 5 6 7 6 (?!)
{m,l,pd}ksh: 1 2 0 0 0 6 (?)
AT&T ksh88: 1 2 3 3 3 6
AT&T ksh93: 1 2 1
Op 21-03-17 om 18:08 schreef Greg Wooledge:
> A builtin is always used by preference over an external command of the
> same name. You don't need to specify "builtin jobs" to be sure you're
> using the builtin. Just use "jobs".
>
> The only time you need to use the "builtin" command is when you'r
Op 21-03-17 om 16:38 schreef Stephane Chazelas:
> IOW, the work around I was mentioning earlier (of using "local"
> before "unset" to make sure "unset" unsets) doesn't work in that
> case. You'd need to use the same work around as for mksh/yash
> (call unset in a loop until the variable is really u
Op 18-03-17 om 14:40 schreef Martijn Dekker:
> Op 27-02-17 om 21:03 schreef Chet Ramey:
>> If you think you have a winning argument, initiate a new discussion with
>> the Austin Group. You might want to dig up the mail archives from
>> October, 2014 and look at the dis
$ x=$'\\a\\b\\c\\\001\\d\\e\\f'
$ case $'abc\001def' in $x) echo ok ;; *) echo oops; esac
oops
$ x=$'\\a\\b\\c\\\002\\d\\e\\f'
$ case $'abc\002def' in $x) echo ok ;; *) echo oops; esac
ok
'case' can't match an escaped $'\001' character passed from a variable.
Any other character from $'\002' up wo
Op 04-04-17 om 11:41 schreef nesro:
> # run an empty for cycle. we can see from the output that bash ran :, then
> # false and stopped to it. which is the right behavior
> for (( :; false; )); do :; done
This is a syntax error. 'for' takes arithmetic expressions, not shell
commands.
> # now run t
bash-snap-20170616
$ (eval '(');echo $?
bash: eval: line 2: syntax error: unexpected end of file
0
The exit status is 0, but should be 1.
As far as I can trace it, this bug seems to have been introduced in
bash-20170511 snapshot.
- M.
Reproducer:
IFS=/
set a b c
cat
101 - 120 of 120 matches
Mail list logo
