Re: nofork command substitution

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:

Process substitution as part of a word [was: Incorrect alias expansion ...]

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

Re: Incorrect alias expansion within command substitution

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

Re: Incorrect alias expansion within command substitution

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

Incorrect alias expansion within command substitution

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:

Re: Unclosed quotes on heredoc mode

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

Re: [patch #10070] toggle invert flag when reading `!'

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

Re: How to use PROMPT_COMMAND(S) without breaking other scripts

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 been

Re: How to use PROMPT_COMMAND(S) without breaking other scripts

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

Re: [PATCH] fc: trim range instead of erroring out

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

[PATCH] fc: trim range instead of erroring out

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

Re: '=~' crash on NetBSD

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 "[[ c =~ $

'=~' crash on NetBSD

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:

Re: AW: Bizarre interaction bug involving bash w/ lastpipe + Almquist 'wait'

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

[PATCH] efficient [[ -v 1 ]] [was: Should [[ -v 1 ]] be supported?]

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'), then perhaps it's

Re: temp setting POSIXLY_CORRECT turns alias expansion off

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

temp setting POSIXLY_CORRECT turns alias expansion off

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;

trap: interactive bash exits on resending SIGINT twice

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

Spurious recursive trap invocation warning

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.

Re: [PATCH] allow process substitution in POSIX mode

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

[PATCH] allow process substitution in POSIX mode

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. -

Re: x[

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

Re: built-in printf %f parameter format depend on LC_NUMERIC

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.

Re: Regression in --enable-minimal-config

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 bash-4.3

Re: Regression in --enable-minimal-config

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:

Re: bash-5.0: problem with variable scoping in posix-mode

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

Re: [bug-bash] $RANDOM not Cryptographically secure pseudorandom number generator

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

Re: [bug-bash] $RANDOM not Cryptographically secure pseudorandom number generator

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. >

Re: [bug-bash] $RANDOM not Cryptographically secure pseudorandom number generator

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

Re: Sourcing a script from a pipe is not reliable

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

Re: FIFO race condition on SunOS kernels

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

FIFO race condition on SunOS kernels

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

Re: Should [[ -v 1 ]] be supported?

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

Re: Should [[ -v 1 ]] be supported?

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

Re: 'eval' exit behaviour in posix mode

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's the specific case

[minor] for/select parsing inconsistency

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

Optimisation request

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

Another ^A bug

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;

Re: [minor] umask 400 causes here-{doc,string} failure

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

Re: Directing into a variable doesn't work

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

Re: $OPTIND varibale value is different from sh

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

Re: $OPTIND varibale value is different from sh

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

[BUG] assignments preceding 'read' persist past command in POSIX mode

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

Re: [BUG] 'unset' fails silently under specific conditions

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

Re: [BUG] 'unset' fails silently under specific conditions

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.

Re: [BUG] 'unset' fails silently under specific conditions

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

Re: [BUG] 'unset' fails silently under specific conditions

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 following

Re: [BUG] persistently assigned variable cannot be unexported in POSIX mode

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

Re: [BUG] persistently assigned variable cannot be unexported in POSIX mode

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 shell function

[BUG] persistently assigned variable cannot be unexported in POSIX mode

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,

[BUG] failure to push/restore closed file descriptor

$ 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

Re: [BUG] RETURN trap with -o functrace: infinite recursion on 'eval return'

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 action

[BUG] RETURN trap with -o functrace: infinite recursion on 'eval return'

$ 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

Re: [BUG] ERR trap triggered twice when using 'command'

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

Re: [BUG] ERR trap triggered twice when using 'command'

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. >

[BUG] ERR trap triggered twice when using 'command'

$ bash -c 'trap "echo WHOA" ERR; command false' WHOA WHOA Expected output: just one WHOA (as on *ksh, zsh) Thanks, - M.

Re: [PATCH] allow file modes up to 7777 instead of 777

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 function repe

Re: [PATCH] allow file modes up to 7777 instead of 777

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.opengroup.org/o

[PATCH] allow file modes up to 7777 instead of 777

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

[off-topic] ksh local vars [was: Unset array doesn't work]

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

Re: make distclean breaks "later "configure && makes"", i.e., removes a file in distro that a build needs (cannot process parse.y)

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 >> +

Re: foo=$*: ^A and DEL are prefixed or removed

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

Re: foo=$*: ^A and DEL are prefixed or removed

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) characters. If IFS c

foo=$*: ^A and DEL are prefixed or removed

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

command_not_found_handle documentation omission

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

Re: Spaces trimmed from $* when assigned while IFS is unset [was: Unexpected word splitting on $* ...]

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

Re: Spaces trimmed from $* when assigned while IFS is unset [was: Unexpected word splitting on $* ...]

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

Spaces trimmed from $* when assigned while IFS is unset [was: Unexpected word splitting on $* ...]

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

bash-snapshot: 'unset IFS' ignored under very specific circumstances

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:

'time' doesn't time subshells that exec

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"

Re: shopt suggestion

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

devel: 'eval' returns 0 upon syntax error

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.

Re: while loop with extdebug + debug trap always returning 1

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

another case from the case corner case casualty case files

$ 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

Re: [BUG] With null IFS, ${1+$*}, ${var-$*}, etc. don't generate fields

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

Re: "unset var" pops var off variable stack instead of unsetting it

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

Re: Bug: different behavior between "jobs -l" and "builtin jobs -l"

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

Odd LINENO behaviour in 'eval'

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 ksh88: 1 2 3 3 3 6 AT ksh93: 1 2 1 2

Re: [BUG] With null IFS, ${1+$*}, ${var-$*}, etc. don't generate fields

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

Re: [BUG] With null IFS, ${1+$*}, ${var-$*}, etc. don't generate fields

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

Re: Why two separate option namespaces?

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

Why two separate option namespaces?

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

[BUG] With null IFS, ${1+$*}, ${var-$*}, etc. don't generate fields

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,

Changelog credit objection

er readonly; assignments to it are > > just ignored. Suggested by Martijn Dekker <mart...@inlv.org> > 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 r

Re: SIGINT kills interactive shell from dot script

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 worka

Re: SIGINT kills interactive shell from dot script

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 "$$

Re: SIGINT kills interactive shell from dot script

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 phenomenon

SIGINT kills interactive shell from dot script

An interactive bash is killed by SIGINT after a command to unset any trap for SIGINT. $ cat >/tmp/dotscript <

Re: Bug with && in piped functions in minimal-config bash

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

'kill -l' outputs SIG prefix if job control not compiled in

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

Bug with && in piped functions in minimal-config bash

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

Re: Severe IFS glob bug needs patch [was: Setting IFS='*' causes bash to freeze on tab completion]

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

Severe IFS glob bug needs patch [was: Setting IFS='*' causes bash to freeze on tab completion]

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

Re: Race in bash-4.3 'typeset'?

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 "$var&

Re: Race in bash-4.3 'typeset'?

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.

Re: Race in bash-4.3 'typeset'?

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

Re: Assigning to BASHPID fails silently

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 will si

Re: Assigning to BASHPID fails silently

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

Assigning to BASHPID fails silently

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 assignment. Other readonlies produce a message on an assignment attempt. BASHPID seems to be an exception. Particularly

Re: BASH_SUBSHELL reset to 0 on EXIT trap in aubshell

Also, perhaps BASH_SUBSHELL should be a readonly like BASHPID is. - M.

  1   2   >