Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: darwin11.4.2
Compiler: /usr/bin/clang
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='darwin11.4.2' -DCONF_MACHTYPE='x86_64-apple-darwin11.4.2'
-DCONF_VENDOR='apple' -DLOCALEDIR='
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: darwin11.4.2
Compiler: /usr/bin/clang
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='darwin11.4.2' -DCONF_MACHTYPE='x86_64-apple-darwin11.4.2'
-DCONF_VENDOR='apple' -DLOCALEDIR='
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 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
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 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
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 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 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 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
uot;$BASH_VERSION"
4.4.12(3)-release
- Martijn
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
quot;$var"
Actual output:
[abc def ghi jkl / abc def ghi jkl /abc def ghi jkl]
Expected output:
[ abcdef ghi jkl / abcdef ghi jkl / abcdef ghi jkl ]
Thanks,
- Martijn
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 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
that status, whereas in fact all that
happens is that $? is set to the function's exit status.
- Martijn
003 177
001 002 003 177
001 002 003 177
Actual output (bash 4.4.12, bash-20171110 snapshot):
002 003
001 001 002 003 001 177
001 001 002 003 001 177
001 001 002 003 001 177
001 002 003 177
Actual output (bash 4.3.39, 4.2.53, 4.1.17, 3.2.57):
001 002 003 177
002 003
001 002 003 177
001 002 003 177
001 002 003 177
Actual output (bash 2.05b):
001 002 003
001 002 003
001 002 003
001 002 003
001 002 003
- 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
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 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
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
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 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
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
$ bash -c 'trap "echo WHOA" ERR; command false'
WHOA
WHOA
Expected output: just one WHOA (as on *ksh, zsh)
Thanks,
- M.
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
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
$ 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 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
e descriptor works as expected:
$ bash -c '{ exec 8open"'
Output: Bad file descriptor (as expected)
FYI:
* bash and dash have this bug;
* zsh, yash, AT&T ksh93, pdksh, mksh, posh, schily's bosh, Busybox ash,
FreeBSD sh, and NetBSD sh all do this correctly.
Thanks,
- Martijn
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,
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
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 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 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 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 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 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
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 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
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 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 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
ents (as opposed to assignment-arguments) and quoting expansions
should not be necessary. (This paragraph is included to pre-empt readers
who would reply "just quote everything". Yes, I know. It's still a bug.)
Thanks,
- Martijn
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
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
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
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'
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 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
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 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
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 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 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 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 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 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 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 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 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
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 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
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.
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
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_
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
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&
it to not be triggered.
To me, this smells like the use of some uninitialised value on various
Almquist shells. Tracing that is beyond my expertise though.
Whether this also represents a bug in bash or not, I can't say. But no
other shells trigger this that I've found, not even ksh9
nctioning inconsistently and incorrectly (instead of
not at all).
Failing reliably is something the shell is ATROCIOUSLY bad at, and it's
one of the first things modernish aims to fix.
- Martijn
--
modernish -- harness the shell
https://github.com/modernish/modernish
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-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 "
l ten commands.
The attached patch removes the error and limits the range to available
commands as specified.
- Martijn
--
|| modernish -- harness the shell
|| https://github.com/modernish/modernish
||
|| KornShell lives!
|| https://github.com/ksh93/ksh
diff --git a/builtins/fc.d
does one thing, your
patch does another, but neither one does that.
Then I suppose my patch was wrong. It seemed to work for me.
- Martijn
--
|| modernish -- harness the shell
|| https://github.com/modernish/modernish
||
|| KornShell lives!
|| https://github.com/ksh93/ksh
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 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
Adam Danischewski schreef op 16-01-16 om 20:28:
> Yet if we look for the null byte:
bash, like most UNIX shells, cannot store or handle null bytes. (zsh is
the only exception I know of.)
> $> while IFS= read -r -d'' a; do echo "got $a"; done < <(find . -type f
> -print0)
> *
In 'help typeset', the 'typeset' builtin is called obsolete and has been
so since at least bash 2.05b (2002) or possibly earlier. Perhaps it's
time to just call it a synonym, as indeed the texinfo documentation does.
diff -ur bash-4.4-beta.orig/builtins/declare.def
bash-4.4-beta/builtins/declare.d
ension of the positional parameters concept.
zsh and ksh93 can distinguish between empty and unset arrays.
Thanks,
- Martijn
Linda Walsh schreef op 16-02-16 om 04:59:
> w/the slow func being killed by a $() sub process, likely:
Yes, subshells are fatal for performance, particularly on bash.
> my fn2='() {my t="${2:?}[*]"
>my arRE="^($(IFS="|"; echo "${!t}"))$"
>[[ $1 =~ $arRE ]]
> }
> '
(What's "my"?
Dan Douglas schreef op 20-02-16 om 21:55:
> "typeset" vs. "declare" isn't always a straightforward decision
> depending on one's requirements. Bash's "typeset" has always
> been there for portability despite being a synonym for "declare",
> so I think just calling it a synonym would be counterprodu
The command
kill -l 0
outputs T. I would expect EXIT as T is not a valid signal or
pseudosignal name. Since T is the last letter of EXIT, I suspect a typo
somewhere.
AT&T ksh93 outputs EXIT. pdksh/mksh and zsh output 0 (presumably EXIT is
not a real signal). dash and yash give a "no such
Op 13-09-16 om 14:29 schreef Greg Wooledge:
> On Tue, Sep 13, 2016 at 05:11:05AM +0200, Martijn Dekker wrote:
>> The command
>>
>> kill -l 0
>>
>> outputs T. I would expect EXIT as T is not a valid signal or
>> pseudosignal name. Since T is th
doesn't compile on my
system so I was unable to test it. On bash-4.1 and bash-4.0 the bug is
not present. Testing was done on Mac OS X 10.11.6.
Thanks,
- Martijn
Op 22-09-16 om 00:06 schreef Martijn Dekker:
> On bash-4.4 with --enable-minimal-config:
> $ (false);echo $?
> 0
> $ (false);echo $?
> 0
> $ (false);echo $?
> 0
Another clue to the nature of the bug: it apparently happens before
exiting the subshell.
$ (false &&
The '!' operator in the legacy test/[ builtin does not invert the result
of the -o operator. Consequently the command
[ ! -o noclobber ]
amounts to a no-op, always returning exit status 0.
Proof:
$ set -o noclobber && [ -o noclobber ] && [ ! -o noclobber ] && echo bug
bug
Interestingly
Op 25-09-16 om 22:40 schreef isabella parakiss:
> On 9/25/16, Martijn Dekker wrote:
>> The '!' operator in the legacy test/[ builtin does not invert the result
>> of the -o operator. Consequently the command
>>
>> [ ! -o noclobber ]
>>
>> a
Op 25-09-16 om 22:57 schreef Martijn Dekker:
> And indeed your interpretation does not apply to something like
> "[ ! -e /tmp ]":
>
> $ [ -e /tmp ]; echo $?
> 0
> $ [ ! -e /tmp ]; echo $?
> 1
>
> However, the supposed synonym -a acts differently:
>
>
I detected an oddity (possible bug) in bash: the usual optimisation for
launching external processes in simple command substitutions is turned
off while executing a dot script.
Background: For reasons that would take too much space to explain here,
I need a cross-platform/POSIX way to get the proc
_SUBSHELL; exit' INT; echo $BASH_SUBSHELL;
kill -s INT $BASHPID)
Actual output: 1 1
Expected output: 1 1
Thanks,
- Martijn
Also, perhaps BASH_SUBSHELL should be a readonly like BASHPID is.
- M.
iable
[1]$ BASHPID=0
[1]$ ((UID=0))
bash: UID: readonly variable
[1]$ ((BASHPID=0))
[1]$
Thanks,
- Martijn
Op 19-10-16 om 15:18 schreef Chet Ramey:
> On 10/17/16 2:38 PM, Martijn Dekker wrote:
>> bash 4.4.0 (I did not investigate other versions) does not produce an
>> error message if you try to assign something to the BASHPID readonly
>> using either arithmetic or normal assignm
Op 20-10-16 om 14:22 schreef Greg Wooledge:
> On Wed, Oct 19, 2016 at 11:53:37PM +0200, Martijn Dekker wrote:
>> Assigning to BASHPID most certainly does have an effect. Since you
>> didn't quote that part, I think you might have missed my point that
>> attempting this wi
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
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 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 "
ave values separated by one of these, so it's a
perfectly legitimate use case to split something on these characters.
So, in addition to fixing pathname expansion for 4.4, I hope you would
consider releasing a patch fixing both aspects of this bug for earlier
versions, at least down to 3.2 (which will forever be the default
version on Mac OS X, since Apple won't touch the GPL3).
Thanks,
- Martijn
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
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
1 - 100 of 120 matches
Mail list logo
