List of background processes in a command group, in a pipeline, executed sequentially under certain conditions.

GE='bash' -DSHELL - DHAVE_CONFIG_H -I. -I. -I./include -I./lib - DDEFAULT_PATH_VALUE='/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin' -DSTANDARD_UTILS_PATH='/bin:/usr/bin:/sbin:/usr/sbin' - DSYS_BASHRC='/etc/bash/bashrc' -DSYS_BASH_LOGOUT

[bug] Command substitutions within C-style for loops. Semicolon causes error.

x error: `(( i = j = k = 1; i % 9 || (j *= -1, $( ((i%9)) || printf " " >&2; echo 0), k++ <= 10); i += j ))' Segmentation fault The segfault on the subshell there is a bit odd if it were merely a syntax error. GNU bash, version 4.2.10(1)-release (x86_64-pc-linux-gnu) -Dan Douglas

Re: lseek with bash

sic I/O isn't something I like to repeatedly fork little external processes to achieve. The zsh MULTIOS concept is interesting to that end but probably a bit over-the-top for Bash. Dan Douglas signature.asc Description: This is a digitally signed message part.

Re: Print non-readonly variables with declare +r -p

On Tuesday, December 13, 2011 12:14:41 PM lhun...@mbillemo.lin-k.net wrote: > Configuration Information [Automatically generated, do not change]: > Machine: i386 > OS: darwin11.2.0 > Compiler: /Developer/usr/bin/clang > Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i386' > -DCONF_OSTYPE='d

Re: Print non-readonly variables with declare +r -p

On Wednesday, December 14, 2011 10:57:21 AM Chet Ramey wrote: > On 12/13/11 3:13 PM, Dan Douglas wrote: > > I imagine this is ok because Bash's declare -p is intended to be human- > > readable only, whereas Ksh guarantees -p produces output in a format > > reusable as i

Re: Ill positioned 'until' keyword

On Wednesday, December 14, 2011 05:47:24 PM Peng Yu wrote: > Hi, > > I looks a little wired why 'until' is the way it is now. According to > the manual until is before the do-done block. > > until test-commands; do consequent-commands; done > > A common design of until in other language is that

segfault expanding certain arrays created via read -N directly to an array.

ll = invert = 0 ignore_return = 0 was_error_trap = my_undo_list = 0x0 exec_undo_list = 0x0 last_pid = save_line_number = #14 0x0046d7b3 in parse_and_execute (string=, from_file=, flags=) at evalstring.c:319 bitmap = 0x6f5920 code = 0 lreset = should_jump_to_top_level = 0 last_result = 0 command = 0x6f58f0 #15 0x0041d399 in run_one_command (command=) at shell.c:1315 code = 0 #16 0x0041c2c6 in main (argc=3, argv=0x7fffd448, env=0x7fffd468) at shell.c:688 i = code = old_errexit_flag = 0 saverst = 0 locally_skip_execution = 0 arg_index = 3 top_level_arg_index = 3 -- Dan Douglas signature.asc Description: This is a digitally signed message part.

[bug] Bash translates >&$var into &>$var for exported functions.

rt -f f + export -pf f () { echo 'hi' } &>${1} declare -fx f * PS4='* ' * BASH_XTRACEFD=4 + bash -xc 'f 3; cat' * f 3 * echo hi * cat + [[ -f 3 ]] + cat ./3 hi END OUTPUT Bash v. 4.2 w/ patchset 20 on Gentoo Linux amd64. -- Dan Douglas signature.asc Description: This is a digitally signed message part.

Re: bash blocking on exec assigning an output file descriptor to a fifo

O_NONBLOCK is up there in things I wouldn't mind using. Namely, having access to errno. I don't see any way of determining the "fullness" of a buffer even through /proc/self/fdinfo/ on Linux. -- Dan Douglas signature.asc Description: This is a digitally signed message part.

Re: excess braces ignored: bug or feature ?

On Friday, February 17, 2012 02:51:27 PM Mike Frysinger wrote: > can't tell if this is a bug or a feature. > > FOO= BAR=bar > > : ${FOO:=${BAR} > > echo $FOO > > i'd expect an error, or FOO to contain those excess braces. instead, FOO is > just "bar". >

Re: excess braces ignored: bug or feature ?

On Sunday, February 19, 2012 04:25:46 PM Chet Ramey wrote: > On 2/17/12 6:22 PM, Dan Douglas wrote: > > My favorite is probably the parser ignoring any valid redirection syntax > > with the special command substitutions. > > > > ~ $ { echo "$({xx

Re: excess braces ignored: bug or feature ?

2 ~ $ : | { { echo $BASH_SUBSHELL >&2; } } | : 1 -- Dan Douglas

Re: shopt can't set extglob in a sub-shell?

shopt -s extglob echo !(x) ) f fi f I was thinking there might be a general solution via the RETURN trap where you could just set "trace" on functions where you want it, but looks like even "redefinitions"

Re: Pathname expansion not performed in Here Documents

n. "If word is unquoted, all lines of the here-document are subjected to parameter expansion, command substitution, and arithmetic expansion." No pathname expansion. -- Dan Douglas

Re: Pathname expansion not performed in Here Documents

On Monday, February 27, 2012 02:07:25 PM Davide Baldini wrote: > FROM Davide Baldini > > On 02/27/12 04:11, Dan Douglas wrote: > > "If word is unquoted, all lines of the here-document are subjected to > > parameter expansion, command substitution, and arithmetic expans

Re: Inconsistent quote and escape handling in substitution part of parameter expansions.

t;> quote) when you want to not perform word splitting. I would consider > >> it > >> as a bug. > > > > imadev:~$ q=\' > > imadev:~$ input="foosomethingbar" > > imadev:~$ echo "${input//something/$q}" > > foo'bar > &g

Re: Inconsistent quote and escape handling in substitution part of parameter expansions.

On Tuesday, February 28, 2012 06:38:22 PM John Kearney wrote: > On 02/28/2012 06:31 PM, Dan Douglas wrote: > > On Tuesday, February 28, 2012 05:53:32 PM Roman Rakus wrote: > >> On 02/28/2012 05:49 PM, Greg Wooledge wrote: > >>> On Tue, Feb 28, 2012 at 05:36

Re: Inconsistent quote and escape handling in substitution part of parameter expansions.

On Tuesday, February 28, 2012 06:52:13 PM John Kearney wrote: > On 02/28/2012 06:43 PM, Dan Douglas wrote: > > On Tuesday, February 28, 2012 06:38:22 PM John Kearney wrote: > >> On 02/28/2012 06:31 PM, Dan Douglas wrote: > >>> On Tuesday, February 28, 2012 05:53:32 P

Brace expansion bug

b c' 'a b c' 'a b c' a b c a b c a b c I'm told similar glitches have been found before. Looks like this applies to anything that has this sort of replacement context that contains valid brace expansion syntax inside quotes. Bash 4.2.24 - Gentoo amd64 -- Dan Douglas signature.asc Description: This is a digitally signed message part.

Re: Brace expansion bug

On Monday, March 26, 2012 01:44:58 PM you wrote: > Dan Douglas writes: > > Hi, hopefully a self-explanatory one today: > > ~ $ ( set -x -- {a..c}; echo "${*-"{1..3}"}" ) > > + echo 'a b c' 'a b c' 'a b c' > >

Re: Brace expansion bug

On Monday, March 26, 2012 08:07:00 AM you wrote: > On 03/26/2012 07:56 AM, Dan Douglas wrote: > > Don't know how much I'm allowed to quote here, but a quick read of the > > POSIX parsing rules and parameter expansion sections suggest to me that > > the start of th

Re: Passing variables by reference conflicts with local

led explaination and example here: http://wiki.bash-hackers.org/commands/builtin/unset#scope Hopefully most of that is correct. -- Dan Douglas signature.asc Description: This is a digitally signed message part.

Segfault on compound assignment to a variable whose name is set in the environment of a declaration builtin.

old_errexit_flag = 0 saverst = 0 locally_skip_execution = 0 arg_index = 3 top_level_arg_index = 3 (gdb) q $ echo $BASH_VERSION 4.2.28(1)-release Thanks again. (not overly anxious for a fix.) -- Dan Douglas signature.asc Description: This is a digitally signed message part.

Re: quoted and concatenated positional parameters

<2> <3> <4> <5foo> <1 2 3 4 51> <1 2 3 4 5foo> dash: <1> <2> <3> <4> <51> <1> <2> <3> <4> <5foo> <1> <2> <3> <4> <51> <1> <2> <3> <4> <5foo> <123451> <12345foo> bash: <1 2 3 4 51> <1> <2> <3> <4> <5foo> <1> <2> <3> <4> <51> <1> <2> <3> <4> <5foo> <1 2 3 4 51> <1> <2> <3> <4> <5foo> zsh: <1> <2> <3> <4> <51> <1> <2> <3> <4> <5foo> <1> <2> <3> <4> <51> <1> <2> <3> <4> <5foo> <1> <2> <3> <4> <51> <1> <2> <3> <4> <5foo> -- Dan Douglas signature.asc Description: This is a digitally signed message part.

Re: quoted and concatenated positional parameters

Ugh, Sorry, I forgot to strip trailing whitespace. If that wasn't comprehensible for anyone, the heredoc in the preceeding the testcase was: args() { printf '<%s> ' "$@"; echo; } args "${@}${1}" args "${@}foo" args ${@}${1} args ${@}foo IFS= args ${@}${1} args ${@}foo EOF -- Dan Douglas

Re: handling of test == by BASH's POSIX mode

statically anyway. Any such lint tool is limited to lexical analysis which makes it not very useful for testing unless your script is perfectly free of side-efffects. And who writes side-effect free shell scripts? How would the shell check for the correctness of: "$(rm -rf somepath; echo '[')" x == x ] -- Dan Douglas signature.asc Description: This is a digitally signed message part.

Re: handling of test == by BASH's POSIX mode

h-0.5.7.1 Total files : 73 Total size : 1.14 MiB # equery s mksh * app-shells/mksh- Total files : 39 Total size : 1.61 MiB # equery s bash * app-shells/bash-4.2_p28 Total files : 464 Total size : 6.33 MiB -- Dan Douglas signature.asc Description: This is a digitally signed message part.

Re: Compare 2 arrays.

On Wed, May 30, 2012 at 4:57 PM, Greg Wooledge wrote: > > On Wed, May 30, 2012 at 10:14:42AM -0600, Bill Gradwohl wrote: > > What say you Chet? Bug or feature? There is no middle ground. > > That's unrealistic.  There are plenty of things that occupy that middle > ground -- unexpected program beha

Re: Indirect access to variables, including arrays (was Re: Compare 2 arrays.)

hink of whatever sucks the least. Granted, these are atypical issues. I care about this more than most due to Gentoo being stuck with Bash and eclasses being among the few valid reasons to care about large safe extensible libraries written for a shell. -- Dan Douglas

mapfile -n seeks ahead an extra line

From: Dan Douglas To: bug-bash@gnu.org Subject: mapfile -n seeks ahead an extra line Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: x86_64-pc-linux-gnu-gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64&

Re: Doc of "set -e" should mention non-locality

On Thursday, June 28, 2012 02:37:17 PM Rainer Blome wrote: > The implementation of "set -e" does not respect "lexical nesting". > This can be very surprising. None of the "set" options do, nor does the ERR trap. That would make this the exception. Here's a workaround (untested). sete() { [

Re: Doc of "set -e" should mention non-locality

On Wednesday, July 04, 2012 05:37:25 PM Rainer Blome wrote: > Original-Nachricht > > Datum: Fri, 29 Jun 2012 18:03:13 -0500 > > Von: Dan Douglas > > An: bug-bash@gnu.org > > CC: Rainer Blome > > Remember that my main suggestion is to clearly

Re: why must non-standard $IFS members be treated so differently ?

%s> ' "${v[@]}"; echo; }; f 1:2:3\:4 <1> <2> <3> <4> $ f() { IFS=: local -a 'v=( $@ )'; printf '<%s> ' "${v[@]}"; echo; }; f 1:2:3\\:4 <1> <2> <3\> <4> See also my answer to this recent question: http://superuser.com/a/454564/78905 -- Dan Douglas signature.asc Description: This is a digitally signed message part.

Re: why must non-standard $IFS members be treated so differently ?

#x27; and not `${#@}', and also that you did not set IFS=: for count_args? If you use exactly the function you sent with the default IFS then you should get 4 here. -- Dan Douglas signature.asc Description: This is a digitally signed message part.

Re: bash does filename expansion when assigning to array member in compound form

analagous behaviors for `+=' and the integer attribute. $ set -x; a=( [1]=* ) + a=([1]=*) -- Dan Douglas

Re: bash does filename expansion when assigning to array member in compound form

On Saturday, August 18, 2012 07:55:17 PM Stephane Chazelas wrote: > 2012-08-18 10:26:22 -0500, Dan Douglas: > > This is a feature that all shells with this style of compound assignment > > have > > in common. If no explicit subscripts are given, the text between the > &g

Re: bash does filename expansion when assigning to array member in compound form

Bleh I'm wrong, brace expansion remains too. I should know this... it's hard to remember all the quirks even when I write them down.

Re: bash does filename expansion when assigning to array member in compound form

icitly. I like that Bash can just implicitly start counting at any index. -- Dan Douglas

Re: bash does filename expansion when assigning to array member in compound form

ounds. The current behavior doesn't make sense. Still, a variable/function attribute for disabling pathname expansion in a controled manner would be useful given that having to manage the state of set -f mostly precludes its use. -- Dan Douglas

Re: bash does filename expansion when assigning to array member in compound form

nsion are ugly: $ declare -a 'a+=(['{0..3}']=foo)' b[{0..3}]=foo c=( [{0..3}]=foo ) $ declare -a "c=(${c[*]})" $ declare -p a b c declare -a a='([0]="foo" [1]="foo" [2]="foo" [3]="foo")' ... -- Dan Douglas

Some issues with short-circuiting arithmetic operators

# max depth == 1024 bash: n: expression recursion level exceeded (error token is "n") $ bash -c 'n=0 a="(a[n]=n++)<7&&a"; ((a)); echo "${a[@]:1}"' bash: (a[n]=n++)<7&&a: expression recursion level exceeded (error token is

Re: "break" inside a while-condition

ding the "do" keyword is considered part of the loop. The same applies to "continue". -- Dan Douglas

Re: Parsing error when "case" in "for" in $()

z,{,m}k}sh bb ) while IFS= read -r testCase; do printf '%s\nfails: ' "$testCase" for sh in "${shells[@]}"; do "$sh" -c "$testCase" 2>/dev/null || printf '%s ' "$sh" done echo $'\n' done <<"EOF" : $(case . in .) :; esac) : $(case . in (.) :; esac) : $({ case . in .) :; esac; }) : "$({ case . in .) :; esac; })" : $(for x in .; do case . in .) :; esac; done) : "$(for x in .; do case . in .) :; esac; done)" EOF -- Dan Douglas signature.asc Description: This is a digitally signed message part.

Re: a recursion bug

t; There's not actually anything you can do about that except use ulimit to > get as much stack space as you can. Well, poor-mans TCO f() if [ "$1" -ge 0 ]; then printf "$1 " exec dash -c "${2}f "'$(($1-1)) "$2"' -- "$@" fi ( f 100 "$(typeset -f f)"$'\n' ) Joking of course :o) FUNCNEST is usually good enough for me. No other shell I'm aware of even has that. -- Dan Douglas

Re: different exit codes in $? and ${PIPESTATUS[@]}

y allow things like: $ mksh -c ': | ! : | :; echo $? "( ${PIPESTATUS[@]} )"' 1 ( 0 1 ) $ mksh -c ': | ! { ! : | :; }; echo $? "( ${PIPESTATUS[@]} )"' 0 ( 0 0 ) I don't believe this is valid syntax, but also end up being pipelines of two elements. Bash, dash, zsh, etc don't accept this. -- Dan Douglas

bug-bash@gnu.org

t;-"EOF" >&2 Error: Braindamage detected. Protecting your system. EOF esac -- Dan Douglas signature.asc Description: This is a digitally signed message part.

Re: different exit codes in $? and ${PIPESTATUS[@]}

; though. Bash interestingly accepts "! !cmd" and "{ ! !; }; cmd", but not "! !; cmd". Also I may as well overload this mail by reporting that nearly every issue I've ever sent to this list over the last year or so (that turned out being "legitimate") appears to have been addressed in devel (at least, according to a few minutes of testing). Thanks! :) -- Dan Douglas

Re: [ast-users] [ksh93] Should ~$user be tilde expanded?

rated by the more common behavior. -- Dan Douglas

Re: wait unblocks before signals processed

l fire when any child exits including command/process substitutions or pipelines etc. If any are located within the main loop then monitor mode needs to be toggled off around them. -- Dan Douglas signature.asc Description: This is a digitally signed message part.

Re: wait unblocks before signals processed

ible for the count to become off. See: https://lists.gnu.org/archive/html/bug-bash/2012-05/msg00055.html I think you might be experiencing other known bugs. Chet pushed several wait/job related commits within the last few weeks. I haven't tested these yet. http://git.savannah.gnu.org/cgit/bas

Re: RFE: printf '%(fmt)T' prints current time by default

sh is equivalent to the date(1) default for the current locale. So, LC_TIME=C; [[ $(printf '%()T') == "$(date)" ]] is true. I imagine all the functionality ksh gets basically for free with libast tm.h functions is totally out of the question, if all there is to work from is libc strptime and friends. Having "date -d" essentially built in is handy. :/ -- Dan Douglas

Re: fd leak with {fd}>

On Monday, November 26, 2012 11:57:33 AM Chet Ramey wrote: > On 11/26/12 8:41 AM, Pierre Gaston wrote: > > On Mon, Nov 26, 2012 at 3:37 PM, Chet Ramey > > wrote: > > > > On 11/23/12 2:04 AM, Pierre Gaston wrote: > > > It seems rather counter intuitive that the fd is no

Re: "And" extended matching operator

ntax, which would be a huge undertaking. -- Dan Douglas

Re: Why can't I say "&>&3"? Bug or feature?

on't like &> to begin with. It makes the already cryptic redirection syntax that beginners struggle to understand even more confusing by adding a pointless shortcut with a non-obvious meaning instead of just being explicit. If you don't understand the copy descriptor and all of a sudden see yet another use for the & character to the left of a redirection operator, you're going to be even more confused. -- Dan Douglas

Requesting an alternate nameref feature

be passed through the positional parameters as in ksh. This feature would have similarities to "declare -g" in its ability to tunnel around overloaded variable names in outer scopes, except would allow both reading and writing to any scope from any deeper scope (provided the reference itself hasn't been covered up). This would be extremely useful for shell libraries. -- Dan Douglas

Re: shouldn't /+(??) capture 2 letter files only?

tiples of that length. $ ksh -c 'printf %R\\n \?' ^.$ $ ksh -c 'printf %R\\n "+(?)"' ^(.)+$ $ ksh -c 'printf %R\\n "+(??)"' ^(..)+$ -- Dan Douglas

Re: shouldn't /+(??) capture 2 letter files only?

On Thursday, December 13, 2012 09:25:02 PM DJ Mills wrote: > +(???) matches lengths that are multiples of 3, not all odd-length files. > ?+(??) would match odd-length files. My bad :) -- Dan Douglas

Re: Question about the return value of 'local'

ined types are self- documenting). Most shell manuals follow about the same overall format and obviously borrow from one another. Some paragraphs are word-for-word identical between Bash and multiple other manuals. Best bet is to learn to navigate it quickly. -- Dan Douglas

Re: RFE: printf '%(fmt)T' prints current time by default

extra c or s conversion specifiers shall be evaluated as if a null > string argument were supplied; other extra conversion specifications > shall be evaluated as if a zero argument were supplied. Ooh ok... hrm I didn't consider it's actually consistent with everything else this way. -- Dan Douglas

Some segfaults possible via mapfile callbacks

unset -v x; :" a' + typeset -n x=a + mapfile -tc1 -C 'unset -v x; :' a ++ unset -v x ++ : 0 a Segmentation fault There were others, mostly to do with modifying the variable being mapped. -- Dan Douglas signature.asc Description: This is a digitally signed message part.

Reverse redirection / assignment order

21 21 # bash posix mode bash: 21 21 21 # normal mode ksh : 21 21 12 # ksh93 is the other oddball shell dash: 12 12 12 # ... ...# Everything else same as dash I don't know why this order was chosen or what the advantages to one over the other might be. -- Dan Douglas signature.asc Description: This is a digitally signed message part.

Short list of issues with various expansions and IFS

_filename is false bypasses a huge chunk that I haven't looked at closely. diff --git a/redir.c b/redir.c index 921be8c..f248fd7 100644 --- a/redir.c +++ b/redir.c @@ -153,7 +153,7 @@ redirection_error (temp, error) } } #endif - else if (expandable_redirection_filename (temp)) + else if (0) { expandable_filename: if (posixly_correct && interactive_shell == 0) -- Dan Douglas signature.asc Description: This is a digitally signed message part.

Re: Segmentation fault in arithmetical expression when mixing array variables.

in an expression where the first refers to an array index. $ ( y=(1 2); (( _ = y, _ = 1 )) )# No error $ ( y=(1 2); (( _ = y[0], _ = 1 )) ) # crash Segmentation fault $ ( y=(1 2); (( _ = y[0] )) ) # No error lvalue doesn't matter. It's just any two assignments in which the first dereferences an array with an index given. -- Dan Douglas

Assignment errors with no additional words expanded in non-POSIX mode fails to abort

x27; 2>&1 pre bash: line 1: 8#9: value too great for base (error token is "8#9") post Only applies to non-POSIX mode. -- Dan Douglas signature.asc Description: This is a digitally signed message part.

typeset -p on an empty integer variable is an error. (plus -v test w/ array elements)

ks in ksh to test if an individual element is set, though it hasn't always. Maybe Bash should do the same? -v is tricky because it adds some extra nuances to what it means for something to be defined... -- Dan Douglas signature.asc Description: This is a digitally signed message part.

printf %q represents null argument as empty string.

', even mksh's ${var@Q} expansion. Zsh's ${(q)var} does. -- Dan Douglas signature.asc Description: This is a digitally signed message part.

Re: printf %q represents null argument as empty string.

On Friday, January 11, 2013 09:39:00 PM John Kearney wrote: > Am 11.01.2013 19:38, schrieb Dan Douglas: > > $ set --; printf %q\\n "$@" > > '' > > > > printf should perhaps only output '' when there is actually a corresponding >

Re: typeset -p on an empty integer variable is an error. (plus -v test w/ array elements)

On Friday, January 11, 2013 09:48:32 PM John Kearney wrote: > Am 11.01.2013 19:27, schrieb Dan Douglas: > > Bash treats the variable as essentially undefined until given at least an > > empty value. > > > > $ bash -c 'typeset -i x; [[ -v x ]]; echo "$

Re: printf %q represents null argument as empty string.

On Friday, January 11, 2013 04:37:56 PM Chet Ramey wrote: > On 1/11/13 4:05 PM, Dan Douglas wrote: > > > > > I don't understand what you mean. The issue I'm speaking of is that printf > > %q > > produces a quoted empty string both when given no args and

Re: printf %q represents null argument as empty string.

r zero argument if more formats than arguments are given. We already had pretty much this same discussion here: http://lists.gnu.org/archive/html/bug-bash/2012-12/msg00083.html It somehow slipped my mind. -- Dan Douglas

Re: typeset -p on an empty integer variable is an error. (plus -v test w/ array elements)

Yes some use -u / -e for debugging apparently. Actual logic relying upon those can be fragile of course. I prefer when things return nonzero instead of throwing errors usually so that they're handleable. -- Dan Douglas

Re: printf %q represents null argument as empty string.

On Friday, January 11, 2013 10:39:19 PM Dan Douglas wrote: > On Saturday, January 12, 2013 02:35:34 AM John Kearney wrote: > BTW, your wrappers won't work. A wrapper would need to implement format Hrmf I should have clarified that I only meant A complete printf wrapper would be d

Re: Reverse redirection / assignment order

On Sunday, January 13, 2013 04:54:59 PM Chet Ramey wrote: > On 1/9/13 2:00 PM, Dan Douglas wrote: > > When expanding simple commands, steps 3 and 4 are reversed unconditionally > > for > > all command types and number of words expanded, even in POSIX mode. > > http://pu

Re: "$(echo "x'" '{1, 2}')" performs brace expansion, even though it should not

d.h - W_NOBRACE: new word flag that means to inhibit brace expansion subst.c - brace_expand_word_list: suppress brace expansion for words with W_NOBRACE flag -- Dan Douglas

Re: about one feature in V4.2 against V4.1

mand :; echo survived' bash: a: readonly variable survived $ $ ( n=10 x= POSIXLY_CORRECT=; while printf "${x:-true} "; ((n--)); do x= ${x:-true ${x:=:}}; done ) true : true : true : true : true : true $ ( n=20 x=: POSIXLY_CORRECT=; while printf %s "${x:--) }"; ((n--)); do x= ${x:-true ${x:=:}}; done ) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) -- Dan Douglas

Re: about one feature in V4.2 against V4.1

Oops nevermind, I see the issue now. Couldn't reproduce here either. Neither with compat modes nor the real versions. -- Dan Douglas

Re: |& in bash?

bash 3.x, so I hadn't encountered it). Thanks. > > - John In scripts it breaks POSIX, conflicts with the coproc operator in kshes, and applies the redirections in an unintuitive order since the same operator redirects stdout first, then applies the stderr redirect after other redirections. It isn't very common to dump multiple streams into one pipe. I suggest avoiding |&. -- Dan Douglas

Re: |& in bash?

On Saturday, January 19, 2013 02:47:38 PM Chet Ramey wrote: > On 1/18/13 4:10 PM, Dan Douglas wrote: > > > In scripts it breaks POSIX, conflicts with the coproc operator in kshes, > > applies the redirections in an unintuitive order since the same operator > > redi

Re: Short list of issues with various expansions and IFS

t; Here-strings are of course an exception to the last sentence, and possibly an exception to parts of the previous sentence (here-strings are defined in terms of the here-document, which might make the issue not so straightforward). -- Dan Douglas

More fun with IFS

three four # bad var="${a[@]}" ... one:::two three:::four # good var=$@... one two three four # bad var="$@" ... one:::two three:::four # good Zsh and pdkshes produce: one:::two:three:::four For all of the above, which I think is wrong for the last 4. ksh93 produces: one:::two three:::four for the last 4, which I think is correct. -- Dan Douglas

Re: More fun with IFS

On Wednesday, January 30, 2013 02:00:26 AM Chris F.A. Johnson wrote: > On Wed, 30 Jan 2013, Dan Douglas wrote: > > > Hi everyone, and welcome to another edition of IBOTD (IFS-bug-of-the-day), > > featuring everyone's favorite Bourne shell kludge: word-splitting! >

Re: More fun with IFS

On Wednesday, January 30, 2013 11:35:55 AM Chet Ramey wrote: > On 1/30/13 2:47 AM, Dan Douglas wrote: > > > No, $* always expands to a single word. If multiple words result, those > > are > > the result of field-splitting, not an intrinsic multi-word expansion as

Re: builtin "read -d" behaves differently after "set -e#

to a nul byte. To be completely clear, the command: `read -rd '' x' is literally receiving the same arguments as the $'\0' case -- it's not only that `read' is treating them the same. Also, if it means anything, sadly ksh93 didn't perform that termination

Re: cd -e returns syntax error

On Sunday, February 24, 2013 02:43:03 PM Chris Down wrote: > Hi all, > > Unless I'm misunderstanding how it should work, `cd -P -e' does not work as > specified by the documentation. From `help cd': Yep, see: http://lists.gnu.org/archive/html/bug-bash/2013-01/msg00099.html -- Dan Douglas

Re: More fun with IFS

On Sunday, February 24, 2013 10:26:52 PM Thorsten Glaser wrote: > Dan Douglas dixit: > > >Zsh and pdkshes produce: > > > >one:::two:three:::four > > > >For all of the above, which I think is wrong for the last 4. ksh93 > >produces: > > Why is it i

Re: More fun with IFS

tions of their > own and then just use those. > I agree that's an excellent strategy. :) -- Dan Douglas

Re: More fun with IFS

On Friday, March 01, 2013 11:49:37 AM Thorsten Glaser wrote: > Dan Douglas dixit: > > >Well, ok then. I'm just nitpicking here. I think this makes sense because > >distinguishes between $@ and $* when assigning to a scalar, so that the end > >result of $@ is alwa

Re: More fun with IFS

the others can be kept as-is. > I think the root of the problem is trying to force unquoted $@ to be like $* instead of the other way around. That's how bash (if not for the bug) and ksh93 manage to do this while remaining consistent with the spec. -- Dan Douglas

Re: Bug/limitation in 'time'

( n )); do # end condition # cmds... cmd $((n--)) # Hope that there's a convienient spot for $(()) done } This construct at least extends the portability to pdksh and probably a few others. I usually draw the line at shells that lack typeset and inform people to upgrade to something modern. -- Dan Douglas

"typeset +x var" to a variable exported to a function doesn't remove it from the environment.

#x27;t have this issue. Dash doesn't actually export the variable to the environment in this case, but just "localizes" it, and requires a separate export.) -- Dan Douglas

Assignments preceding "declare" affect brace and pathname expansion.

ignment, though I can't think of any uses for it. Arguments in this case are treated neither as ordinary assignments nor ordinary expansions. -- Dan Douglas

A few possible process substitution issues

2>&1; wait $!; printf 2; } | cat; echo' 12 $ bash -c '{ { : <(sleep 1; printf 1 >&2); } 2>&1; wait $!; printf 2; } | cat; echo' bash: wait: pid 9027 is not a child of this shell 21 At least, this is a confusing error, because that actually is a direct child of the shell that runs the wait. Process substitutions do set $! in Bash, not in Zsh. -- Dan Douglas

Re: Assignments preceding "declare" affect brace and pathname expansion.

unexpected token `(' If it's true that an assignment prefix causes bash to not recognize declaration commands (which is unfortunate IMO), then you would expect the 2nd case above to be the same as the 3rd case. Instead, it's not wordsplitting and not failing due to the () metacharacters, and using sort of a hybrid of the two. -- Dan Douglas

Re: weird problem -- path interpretted/eval'd as numeric expression

Can you whittle this down to the smallest reproducer and post a stand-alone synthetic testcase with sample input data that fails? If the goal is simulating "exported arrays", there are other methods that would probably work out better. -- Dan Douglas

Re: [PATCH] Adding support for '--' in builtin echo's option parsing.

t(1) is an option for those that want --. AFAIK, it's consistent everywhere it's been implemented. There's a (barebones) example loadable, and it's quite easy to define a print shiv in shell if needed. Although, comparing the length: printf %s print -rn It's just as easy to type printf. -- Dan Douglas

Re: setvalue builtin command

primary advantages to set -A are: - It's the most portable way to assign multiple elements to an indexed array other than a separate assignment for each element. - The combination `set -sA' provides a means of sorting (lexicographically). Bash currently has no built-in way to sort an array or the positional parameters. -- Dan Douglas

Interpretation of escapes in expansions in pattern matching contexts

tored in the variable x 19:32:51 jilles: freebsd sh and kmk_ash say no, dash says yes 19:33:40 jilles: Bourne shell says no -- Dan Douglas

Re: Interpretation of escapes in expansions in pattern matching contexts

pically a symlink to busybox yes, which calls the shell. "jsh" is the default binary name produced by the heirloom build, though I've seen other names used. -- Dan Douglas

Re: Interpretation of escapes in expansions in pattern matching contexts

On Saturday, April 06, 2013 09:37:44 PM Chet Ramey wrote: > On 4/6/13 4:48 AM, Dan Douglas wrote: > > I couldn't find anything obvious in POSIX that implies which > > interpretation is > > correct. Assuming it's unspecified. > > > > Bash (4.2.45) uniquel

Re: Very slow pattern substitution in parameter expansion

I can't reproduce using the above code. $ bash ./testcases/substperf real0m0.000s user0m0.000s sys 0m0.000s real0m0.000s user 0m0.000s sys 0m0.000s As an aside, don't store commands in variables. http://mywiki.wooledge.org/BashFAQ/050 -- Dan Douglas

  1   2   3   >