Reproducer:
IFS=/
set a b c
cat
Op 22-05-2023 om 16:18 schreef Chet Ramey:
I'd call that a bug. It's not how mksh documents this type of command
substitution to work. ksh93 documents the parsing the same way.
So it does, yet ksh93 also accepts omitting the ;.
The only documentation of this is in the legacy changelog:
08-03
Op 02-02-22 om 20:59 schreef Chet Ramey:
[...] it makes no sense to join a process substitution to another word.
But it does. In arguments that look like assignments, and in GNU-style
long options, file names can be part of a larger word.
Assuming tar is GNU tar, something like
tar -c -
Op 01-02-22 om 15:23 schreef Chet Ramey:
Historically, bash (and ksh93) has favored the former. Just about all the
other shells claiming some sort of POSIX conformance favor the latter (all
the ash-based shells, yash, mksh).
What are your plans here?
I've no current plans. Any remotely plausib
Op 02-02-22 om 13:25 schreef L A Walsh:
I can't say for sure, but it would be interesting if anyone else
has this result in a bash with aliases on by default:
I.e. My bash is posix compliant by default w/r/t aliases:
env -i /bin/bash --noprofile --norc
bash-4.4$ shopt -p expand_aliases
Of c
On the latest code from the devel branch:
GNU bash, versie 5.2.0(35)-alpha (x86_64-apple-darwin18.7.0)
Reproducer script:
shopt -s expand_aliases
alias let='let --'
set -x
let '1 == 1'
: $(let '1 == 1')
Output:
+ let -- '1 == 1'
++ let -- -- '1 == 1'
foo: line 5: let: --: syntax error: operand
Op 20-11-21 om 23:54 schreef Robert Elz:
What the devel one does is unknown to me, I don't think I even have
the means to obtain it (I have nothing at all git related, and no interest
in changing that state of affairs).
Github allows downloading a gzipped tarball of any branch's current
state
Op 24-05-21 om 17:47 schreef Chet Ramey:
On 5/22/21 2:45 PM, Vincent Menegaux wrote:
Previously, these commands:
[[ ! 1 -eq 1 ]]; echo $?
[[ ! ! 1 -eq 1 ]]; echo $?
would both result in `1', since parsing `!' set CMD_INVERT_RETURN
instead of toggling it.
Interestingly, ksh93 produces t
Op 24-08-20 om 20:37 schreef Chet Ramey:
On 8/24/20 12:58 PM, Martijn Dekker wrote:
Op 24-08-20 om 15:57 schreef Chet Ramey:
I sometimes think I should have stuck with converting PROMPT_COMMAND to
an array. Either way, there's going to be a transition, and maybe that
would have bee
Op 24-08-20 om 15:57 schreef Chet Ramey:
I sometimes think I should have stuck with converting PROMPT_COMMAND to
an array. Either way, there's going to be a transition, and maybe that
would have been the easiest.
Is it too late? I think that would actually be cleaner than adding a
separate arr
Op 12-08-20 om 16:40 schreef Chet Ramey:
What's your opinion about what the `as appropriate' means? An out-of-range
`first' gets substituted with the first command in the history, and an out-
of-range `last' gets the last history entry?
Yes, that was my intention.
Bash does one thing, your
p
As I use/try/test many shells, I'm in the habit of using POSIX commands
such as 'fc -l 1' to list the complete history.
If there have been more than $HISTSIZE command, the list is trimmed at
the beginning without renumbering, and bash errors out:
$ fc -l 1
bash-5.0: fc: history specification
Op 07-05-20 om 14:20 schreef Chet Ramey:
On 5/6/20 2:08 PM, Martijn Dekker wrote:
On NetBSD, bash (all versions, including current git) dumps core when using
[[ to match against an ERE containing certain UTF-8 characters, for
example, É ($'\303\211').
| $ bin/bash-5.0-debug -c "
On NetBSD, bash (all versions, including current git) dumps core when
using [[ to match against an ERE containing certain UTF-8 characters,
for example, É ($'\303\211').
| $ bin/bash-5.0-debug -c "[[ c =~ $'\303\211' ]]"
|
| malloc: unknown:0: assertion botched
| malloc: 0x81ba08: allocated: la
Op 07-02-20 om 12:19 schreef Walter Harms:
IMHO is the bug on bash side. ash can assume to get an "healthy"
environment from the caller. You can simply not fix everything that
can possible go wrong.
That is a rather fallacious argument. Of course you cannot fix
*everything* that could possibly
This is probably the strangest bug (or maybe pair of bugs) I've run into
in nearly five years of breaking shells by developing modernish.
I've traced it to an interaction between bash >= 4.2 (i.e.: bash with
shopt -s lastpipe) and variants of the Almquist shell, at least: dash,
gwsh, Busybox a
Op 29-12-18 om 01:19 schreef Chet Ramey:
On 12/27/18 3:11 PM, Martijn Dekker wrote:
Consistency might be a better argument. If [[ -v foo ]] is equivalent to [[
-n ${foo+s} ]] for variables (with the advantage that you don't need 'eval'
to handle arbitrary values of 'foo&
Op 16-01-20 om 17:02 schreef Chet Ramey:
On 1/15/20 10:24 PM, Martijn Dekker wrote:
When alias expansion is enabled for a script in bash native mode,
prefixing POSIXLY_CORRECT=y to any command will turn alias expansion
globally off. This is a bug because the assignment should only have
effect
When alias expansion is enabled for a script in bash native mode,
prefixing POSIXLY_CORRECT=y to any command will turn alias expansion
globally off. This is a bug because the assignment should only have
effect on that command.
$ bash -c 'shopt -s expand_aliases; shopt|grep expand_a;
POSIXLY_
Setting the following trap makes an interactive bash (any version) exit
on issuing SIGINT:
trap 'trap "true" INT; kill -s INT $$; trap - INT; kill -s INT $$' INT
# ^^^ eat signal ^^ unset trap
After setting that trap, pressing Ctrl+C, or otherwise causing SIGINT to
The current git version of bash (at least on x86_64-apple-darwin18.7.0)
gives a spurious warning about a recursive trap invocation when running
the following more than once on an interactive shell. The trap unsets
itself before resending the signal, so there should be no recursive
invocation.
Op 08-12-19 om 10:29 schreef Oğuz:
I think otherwise. In POSIX mode Bash should at least print warnings
about features POSIX lets implementations provide but doesn't mandate,
like function, select, [[, etc.
That would be a far bigger change than just allowing process substitution.
Also, there
Process substitution is disabled in POSIX mode. A 'git blame' on parse.y
suggests that this has been the case since bash prehistory.
To me, this seems:
- Inconsistent. Other bash extensions are not disabled when POSIX mode
is active; as far as I can tell, this is the only one.
- Unnecessary.
Op 29-07-19 om 19:09 schreef Eli Schwartz:
The initial workaround discovered, was to use
$ function _[ () { echo hello; }; <() _[
hello
The use of <() somehow suppresses the glitch in the same way that
quoting it does. If it were just glob expansion, then why should that be so?
As others poin
Op 12-07-19 om 21:46 schreef Dennis Clarke:
Well the man page for XPG6 bc in Solaris 10 claims :
ENVIRONMENT VARIABLES
See environ(5) for descriptions of the following environment
variables that affect the execution of bc: LANG, LC_ALL,
LC_CTYPE, LC_MESSAGES, and NLSPATH.
Op 12-05-19 om 13:40 schreef Miro Kropáček:
On Sun, 12 May 2019 at 12:47, Martijn Dekker wrote:
I think you're probably hitting this bug:
https://lists.gnu.org/archive/html/bug-bash/2016-09/msg00083.html
Thanks, that indeed looks like it.
The exit status of subshells is broken in bas
Op 11-05-19 om 13:08 schreef Miro Kropáček:
It seems --enable-minimal-config isn't tested very often as both
4.3.48 and 4.2.x required a few #ifdef's to be added to make it
compile (Linux).
I think you're probably hitting this bug:
https://lists.gnu.org/archive/html/bug-bash/2016-09/msg00083.h
Op 27-01-19 om 22:59 schreef Chet Ramey:
> This is a consequence of a combination of two POSIX features. First, POSIX
> requires assignment statements preceding special builtins to create global
> variables (POSIX has no local variables) that persist in the shell context
> after the special builtin
Op 21-01-19 om 20:12 schreef Chet Ramey:
> On 1/20/19 9:04 PM, Rawiri Blundell wrote:
>> For what it's worth I did consider suggesting URANDOM, however I
>> figured some users may confuse it like this:
>>
>> RANDOM -> /dev/random
>> URANDOM -> /dev/urandom
>>
>> Couple that with an established base
Op 19-01-19 om 23:10 schreef Chet Ramey:
> On 1/19/19 2:45 PM, Martijn Dekker wrote:
>> Op 16-01-19 om 02:21 schreef Quentin:
>>> If you really need some quality CSPRNG values, I'd suggest adding a
>>> $SECURE_RANDOM variable that just reads from /dev/urandom.
>&
Op 16-01-19 om 02:21 schreef Quentin:
> If you really need some quality CSPRNG values, I'd suggest adding a
> $SECURE_RANDOM variable that just reads from /dev/urandom.
IMHO, this would clearly be the correct approach. I don't know of any
21st century Unix or Unix-like system that doesn't have /de
Op 10-01-19 om 22:52 schreef Jeremy:
> We are trying to determine if the current shell supports passing positional
> arguments to a script sourced by dot (.), and we are trying to do it in a
> way that will work under pretty much any shell. If you can show me how to
> do that with eval, then that
Op 01-01-19 om 23:47 schreef Vladimir Marek:
[...]
That said, I do use VirtualBox 5.1.22r115126 which is pretty old.
I recently upgraded to VirtualBox 6.0 on Mac OS X 10.11 and the results
are identical.
Putting 0.5s delay anywhere in the loop makes the problem disappear.
Yes, I'd noticed
You'd think that establishing a pipe between two processes is a very
basic UNIX feature that should work reliably on all UNIX variants.
But the following script seems to break consistently on Solaris and
variants (SunOS kernels) when executed by bash, ksh93, or dash. All it
does is make 100 FI
Op 28-12-18 om 01:39 schreef Peng Yu:
What I meant in my original email is that I want something for testing
if there is a command line argument (one or more, the exact number
does not matter). $# gives more than that info, because it tells not
only whether is any command line argument, but also
Op 27-12-18 om 19:22 schreef Chet Ramey:
On 12/26/18 10:49 PM, Peng Yu wrote:
Although [[ -z ${1+s} ]] and (($#)) works for testing if $1 is set,
neither of them are uniformly better performance wise. In this case,
should [[ -v 1 ]] be supported?
So you're saying that neither of the existing
Op 14-12-18 om 14:29 schreef Chet Ramey:
On 12/14/18 6:46 AM, Martijn Dekker wrote:
In current git, 'bash -o posix' no longer exits the shell on a syntax error
in the argument to the special builtin 'eval'. Bash 4.2-4.4 exit as POSIX
specifies.
Well, not quite. It'
In current git, 'bash -o posix' no longer exits the shell on a syntax
error in the argument to the special builtin 'eval'. Bash 4.2-4.4 exit
as POSIX specifies.
$ bash -o posix -c 'eval "(" || echo woops'
bash: eval: regel 1: syntaxfout: onverwacht bestandseinde
woops
On the other hand, note t
There is a minor inconsistency in grammatical parsing between 'for' and
'select' loops. Since 'select' is basically a glorified 'for', it seems
to me that they should parse the same way.
$ bash -c 'for x in; do :; done'
$ bash -c 'select x in; do :; done'
bash: -c: line 0: syntax error near une
I've noticed bash-5.0beta is quite a bit faster than bash-4.4 in running
a lot of pure shell code. Good news.
One optimisation that isn't done yet: if a subshell function like
f() (foo)
is used in a command substitution, it forks twice. I would like it if it
could be optimised to elim
That ^A / $'\1' character just keeps causing trouble...
This is a bug with IFS. Including a $'\1' character anywhere in IFS
causes expansions in shell assignments to discard that character.
$ bash -c "c=$'Y\1Y';
for IFS in $'\1' $'\2' $'x\1' $'x\2' $'\1x' $'\2x'; do
v=X\${c}X;
Op 11-03-18 om 17:31 schreef Ilkka Virta:
On 11.3. 17:17, Stephane Chazelas wrote:
$ bash -c 'umask 400; cat <<< test'
bash: cannot create temp file for here-document: Permission denied
Those shells use temporary files to store the content of the
here-documents as the Bourne shell initially d
Op 24-06-18 om 05:08 schreef Peter Passchier:
With memory being abundant and filesystem access expensive, I want to
put stdout and stderr of a command into variables (without needing to
write to a file):
output=$($command 2>>>errors)
This would not work even if the feature is implemented. The
Op 20-06-18 om 17:45 schreef Ilkka Virta:
$ for sh in dash 'busybox sh' bash ksh93 zsh ; do printf "%-10s: "
"$sh"; $sh -c 'while getopts abcd opt; do printf "$OPTIND "; done;
printf "$OPTIND "; shift $(($OPTIND - 1)); echo "$1" ' sh -a -bcd
hello; done
dash : 2 3 3 3 3 hello
busyb
Op 20-06-18 om 13:39 schreef Greg Wooledge:
I really don't understand what you're doing here, either. The only
use of OPTIND is after the final call to getopts, when there are no
more options to process. At that point, OPTIND tells you how many
times you have to "shift" to get rid of all the op
In bash-20180511 and bash-20180518 snapshots and in bash 5.0.0-alpha, in
POSIX mode, assignments preceding 'read' incorrectly persist past the
command. 'read' is a regular builtin so they should not persist.
$ ./bash -o posix -c 'v=ok; v=bug read x
Op 02-05-18 om 15:38 schreef Greg Wooledge:
*NOW* there's evidence of a local variable, because unset removes it
and exposes the global.
Right. That's what triggered my initial report, in which I confused that
phenomenon for a failure of the 'unset' command to unset the variable.
But it's
Op 02-05-18 om 02:20 schreef Chet Ramey:
You complained that `typeset +x' didn't `unexport' a variable. The reason > is
that the variable assignment preceding the special builtin caused a
variable to be created at the global scope, and the `typeset' resulted in
a local variable being created.
Op 01-05-18 om 19:36 schreef Chet Ramey:
OK, so which is it? Does an assignment statement preceding a special
builtin in a shell function create a local variable (as we discussed
just yesterday)
Huh? That was about 'typeset'/'declare'. How is that relevant here?
or does it create a global va
Op 01-05-18 om 18:45 schreef Martijn Dekker:
It appears that it must have one function calling another, and that
other function having an assignment preceding a special builtin, for
'unset' to fail silently for the variable so assigned.
Actually it can be simplified further: the
Op 26-04-18 om 04:51 schreef Martijn Dekker:
I've also succeeded in making 'unset -v' fail silently for a variable
that is so exported, but I've so far been unable to track down a
specific reproducer that is simple enough to post here.
Here is that reproducer. The followi
Op 30-04-18 om 21:12 schreef Chet Ramey:
2. The bug is: 'declare +x' a.k.a. 'typeset +x' then fails to unexport the
variable in the second version above. The variable remains exported past
'typeset +x foo', as proven by grepping the output of 'env'.
Now you've just created a local variable (type
Op 27-04-18 om 22:16 schreef Chet Ramey:
On 4/25/18 10:51 PM, Martijn Dekker wrote:
What I'm reporting here is a bug I discovered with unexporting a variable
that is so exported while bash is in POSIX mode. It cannot be unexported
using 'typeset +x' if you try to do that in a
POSIX allows assignments preceding special builtins such as ':', 'set',
etc. not only to persist but also to be persistently exported. I think
that exporting behaviour is inherently broken and it's unfortunate that
bash does this in POSIX mode, as it's merely allowed and not actually
mandated,
$ bash -c '{ exec 8Apparently, bash either fails to push the file descriptor onto the stack
at '} 8<&-', or fails to restore it.
Same bug with loops ending in "done 8<&-".
Confirmed in all bash versions down to 2.05b.
Also note that pushing an open file descriptor works as expected:
$ bash -
Op 14-04-18 om 03:49 schreef Chet Ramey:
On 4/10/18 5:56 AM, Martijn Dekker wrote:
It seems odd that the RETURN trap would be triggered while a RETURN trap
action is still being executed. Might it be better to temporarily
deactivate the effect of '-o functrace' while a RETURN trap
$ bash -o functrace -c 'fn() { eval "return"; }; trap "fn" RETURN; fn'
Result: segfault due to infinite recursion.
__
Even apart from this bug with 'eval return', the effect of '-o
functrace' is a bit strange:
$ bash -o functrace -c 'fn() { printf foo; fn2; };
fn2() { printf
Op 02-04-18 om 20:41 schreef Chet Ramey:
Thanks for the report. This clearly falls under this clause
"In every other respect, if command_name is not the name of a function, the
effect of command (with no options) shall be the same as omitting command."
in the Posix description of `command'. It
Op 02-04-18 om 16:47 schreef Nick Chambers:
You should still be providing this information :). How else would
you expect people to help you.
I'm not looking for help. I'm here to report the bugs in bash that I
find, and occasionally to help fix them. That's what this list is for.
> Ni
$ bash -c 'trap "echo WHOA" ERR; command false'
WHOA
WHOA
Expected output: just one WHOA (as on *ksh, zsh)
Thanks,
- M.
Op 14-03-18 om 16:49 schreef Martijn Dekker:
[...]
> {
>digits++;
>result = (result * 8) + (*string++ - '0');
> - if (result > 0777)
> + if (result > 0)
> return -1;
> }
>
> By the way, why does that fun
Op 14-03-18 om 16:49 schreef Martijn Dekker:
> While POSIX says the effect of specifying sticky/setuid/setgid bits is
> unspecified[*], the 'umask' builtin should still accept these bits, as
> it does in every other shell.
Forgot the footnote link. Here it is:
http://pubs.openg
This fixes two bugs:
1. The example 'mkdir' builtin, examples/loadables/mkdir.c, has a broken
'-m' option that doesn't accept sticky/setuid/setgid.
$ ./bash -c '(cd examples/loadables && make mkdir) &&
enable -f examples/loadables/mkdir mkdir &&
mkdir -m2775 foo'
['make' output sk
Op 05-03-18 om 13:57 schreef Greg Wooledge:
> On Sat, Mar 03, 2018 at 08:24:06PM +0900, Koichi Murase wrote:
>> - Note: ksh seems not support local variables. "typeset" in function
>> scopes defines a global variable, and "unset" removes the global
>> variable.
>
> "Real ksh" has two different kin
Op 14-02-18 om 14:29 schreef Greg Wooledge:
> On Wed, Feb 14, 2018 at 01:03:05PM +0100, Michael Felt wrote:
>> If after a successful build, I run "make distclean" - "./configure && make"
>> no longer works.
>
>> configure: WARNING: bison not available; needed to process parse.y
>> + /usr/bin/make
The latest development snapshot appears to have fixed this bug.
However, it introduced a new one: if the positional parameters are
empty, then
foo=$*
produces a segfault.
Thanks,
- Martijn
Op 16-12-17 om 17:06 schreef Chet Ramey:
> On 11/24/17 3:17 AM, Martijn Dekker wrote:
>> Here's another corner-case bug with assigning $* to a variable (i.e.:
>> foo=$*). If IFS is empty, the $* expansion removes any $'\001' (^A) and
>> $'\177' (DEL
Here's another corner-case bug with assigning $* to a variable (i.e.:
foo=$*). If IFS is empty, the $* expansion removes any $'\001' (^A) and
$'\177' (DEL) characters. If IFS contains a value, each ^A and DEL
character is prefixed by another $'\001'. If IFS is unset, the bug does
not show up at all
The bash manual and info pages state:
| If the search is unsuccessful, the shell searches for a
| defined shell function named 'command_not_found_handle'. If that
| function exists, it is invoked with the original command and the
| original command's arguments as its arguments, and the function's
Op 04-10-17 om 17:52 schreef Chet Ramey:
> It's interesting that other shells treat ${a:=b} as kind of like an
> assignment statement (word splitting) but not quite (tilde expansion).
Hmm...
v=~/bla
printf '%s\n' "$v"
outputs /Users/martijn/bla on all shells, so tilde expansion a
Op 27-09-17 om 14:44 schreef Greg Wooledge:
> I'm just going to chalk this up as yet another example of unquoted $*
> or $@ being Completely Wrong.
Nonsense. This is a bug in bash and it should be fixed, not excused.
Quoting expansions should never be necessary for assignments.
This strange behav
Op 20-06-17 om 02:13 schreef Kevin Brodsky:
> When IFS is unset, unquoted $* undergoes word splitting as if IFS=' ',
> and not the expected IFS=$' \t\n'.
Possibly related are the following two issues:
1. When IFS is unset, assignments of unquoted ${var-$*}, ${var+$*}, etc.
to a variable removes l
The bug test suite in my modernish shell library exposed a bug in the
current bash development snapshot. As far as I've been able to trace,
the following bug was introduced by bash-snap-20170620 (commit
d7d836dfc55b937f463f601ba5117d6442053089).
I've been able to distil the following test case:
s
The 'time' reserved word seems to be unable to time subshells that run
'exec'. Is this intentional? (ksh93, mksh and zsh all do manage this.)
$ time (sleep 1)
real0m1,003s
user0m0,001s
sys 0m0,002s
$ time (exec sleep 1)
$ time (echo hi; exec sleep 1)
hi
$ echo "$BASH_VERSION"
4.4.12(3
Op 31-08-17 om 16:43 schreef Nellis, Kenneth:
> At the keyboard, it is inconvenient to type (e.g.):
> shopt -s dotglob; mycmd; shopt -u dotglob
Try with a subshell. All it takes is a couple of parentheses.
(shopt -s dotglob; mycmd)
> But, I wonder if shopt might not itself accept a command to e
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.
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
$ 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 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
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 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
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 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
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 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
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
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
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
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
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 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
An interactive bash is killed by SIGINT after a command to unset any
trap for SIGINT.
$ cat >/tmp/dotscript <
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
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
My development with Modernish just exposed the following bug on bash
4.4.0(1)-maint, bash-20161028 snapshot, compiled with
--enable-minimal-config --enable-alias:
$ fn() { false && echo bug || echo ok; }
$ fn
ok
$ fn
ok
$ fn | cat
ok
$ fn | cat
bug
$ fn | cat
bug
$ (fn) | cat
ok
So apparently thi
Op 04-11-16 om 01:27 schreef Eduardo Bustamante:
> I agree with everything, except calling it severe. This is
> self-inflicted harm, and easy to work around
It is not self-inflicted. The behaviour is a bug in bash. The user did
nothing to cause that bug.
Even if you think it's somehow reasonable
Op 02-07-16 om 11:30 schreef Andreas Schwab:
> "Ibrahim M. Ghazal" writes:
>
>> After further investigation, the problem seems to be that when IFS is
>> set to '*', case *) doesn't get executed. Is this the intended
>> behavior?
>>
>> For example:
>>
>> IFS='*'; case "foo" in *) echo "got here";;
Op 28-10-16 om 15:00 schreef Chet Ramey:
> On 10/25/16 12:40 AM, Martijn Dekker wrote:
>> Try simply testing the exit status of 'typeset -p' or 'declare -p'. If
>> the variable is not declared, it exits unsuccessfully.
>>
>> if typeset -p "
Op 25-10-16 om 18:19 schreef Stuart Shelton:
> However, it doesn’t appear to be able to detect local variables (is this
> intentional or a bug?):
Strange. Works for me on bash 3.2.57 and bash 4.4.0 (Mac OS X) and bash
4.2.53 and 4.1.17 (Linux).
- M.
Op 25-10-16 om 00:42 schreef Stuart Shelton:
> Failing this, is there any alternative to ‘typeset’ to list a
> variable declared as local to a function but which has not yet been
> assigned a value?
Try simply testing the exit status of 'typeset -p' or 'declare -p'. If
the variable is not declared
1 - 100 of 118 matches
Mail list logo
