bug in 4.4?

If I set bash to complain about uninitialized variables w/-u, I get inconsistent, and seemingly incorrect behavior: echo $BASH_VERSION 4.4.5(1)-release set -u echo ${undefvar} bash: undefvar: unbound variable echo ${undefvar[@]} # no message about

Re: What is correct syntax to check for empty array? behavior diffs between 4.3 and 4.4

Greg Wooledge wrote: On Thu, Jan 26, 2017 at 01:11:25PM -0800, L A Walsh wrote: Subject: Re: What is correct syntax to check for empty array? The number of elements is 0 if the array is empty. So you would test whether ${#array[@]} is 0. set -u # now

What is correct syntax to check for empty array? behavior diffs between 4.3 and 4.4

I noticed an error coming out of a script when I tried to check an array's size w/unbound var checking enabled (note my=declare, array='my -a') First w/bash-4.3.42: bash# try in subshell in case '-u' exits array gv_ops=() echo ${#gv_ops[@]} # existing var

Re: null pointer deref, segfault

Andreas Schwab wrote: On Jan 24 2017, "Brian 'geeknik' Carpenter" wrote: <<$(()())|>_[$($(<<0)) crashes bash on Debian, Red Hat, FreeBSD, etc. Worksforme with bash 4.4. --- I duplicated it under bash 4.3.42, but not under 4.4.5. -l

Re: suggestions: for bash shell: "shebam's and shebang's"

Greg Wooledge wrote: On Wed, Jan 11, 2017 at 01:30:02PM -0500, Bill William wrote: The problem with the shebang is that its not a file type its an executable...what is needed is the option to only specify a file type... examples: //Example Shebang: #!/usr/bin/perl //Example Shebam:

Re: possible in bash?: filter stderr of a prog & send filtered-output out on stderr leaving stdout untouched

Andreas Schwab wrote: { $prog 2>&1 >&3 | grep -v "$RE_filt" >&2; } 3>&1 Andreas. Closer to my last failed case: ( echo -n >&3 $($prog >&3 2>&1 | grep -Pv "$re" >&2 ) ) 3>&1 Had tried not putting $prog in $(), but bash didn't like the parens... At that point figured it was probably

Re: possible in bash?: filter stderr of a prog & send filtered-output out on stderr leaving stdout untouched

Dennis Williamson wrote: http://mywiki.wooledge.org/BashFAQ/047 (search for "stdout intact") Thanks!

possible in bash?: filter stderr of a prog & send filtered-output out on stderr leaving stdout untouched

Is there a way, in bash, to filter stderr and let the filtered result continue on stderr with the original stdout being output on stdout? with prog being the program to filter, and RE_filt being the filtering expression, conceptually, I wanted to do something like this: $prog >&3 2>&1 |grep -v

Re: Filename completion causes doubling of initial ':' character

Chet Ramey wrote: The short answer is that colon is special to readline: it breaks words for the readline completion code. If you want to complete filenames beginning with a colon, either quote the colon or remove colon from $COMP_WORDBREAKS. If you're using bash-completion, it may have its

Re: bashbug install mode

Michał Górny wrote: Hi, While scanning our systems for executables that are installed u-w, I've noticed this specific mode is used for bashbug explicitly. Is there a good reason for doing that? --- Doesn't it have execute permission? But it seems semi normal for a system-"executable"

correct error message?

I was checking to see if an associative array had a member: echo $BASH_VERSION 4.4.5(1)-release declare -A requires=([squid]="-d /var/cache/squid/run") This works as expected: if [[ ${requires[xxx]:-} ]]; then echo ok; else echo not; fi not But this

Re: ``read -N n -t timeout'' saves partial input only when EOF is seen?

isabella parakiss wrote: that's not true https://gist.github.com/fa4efd90376ff2714901e4429fdee734 read successfully reads the data, but then it's discarded by bash It's discarded by bash because the read doesn't read 10 characters within the time limit. If you use -N 5, you get

Re: specifying readline location & ignoring libdir...?

Chet Ramey wrote: On 11/16/16 2:26 PM, L A Walsh wrote: Because that's not what `libdir' is for. Look at the GNU coding standards: https://www.gnu.org/prep/standards/standards.html#Makefile-Conventions under the section "Variables for Installation Directories", where we fin

Re: specifying readline location & ignoring libdir...?

Chet Ramey wrote: On 11/16/16 12:48 PM, L A Walsh wrote: --- I suspected as much, which makes these settings all the more important ... these 2 things: 1) How is the location for readline-7.0 specified? Using the --with-installed-readline argument to `configure'. --- I

Re: specifying readline location & ignoring libdir...?

Chet Ramey wrote: It's likely that these have been problems for a long time; the code to warn about unknown variable names is new in readline-7.0. --- Ah... didn't know that. That's likely all or most of those. You can't link bash-4.4 against any readline version except 7.0; ---

Re: Curious... on readline history patch -- round up memory allocs?

Eduardo Bustamante wrote: I think this is unnecessary, malloc (either the bash malloc in lib/malloc/malloc.c or the libc provided malloc) should already take care of requesting memory in page sized chunks. At least that's what I see here (morecore function):

Curious... on readline history patch -- round up memory allocs?

Saw the bit about bash-4.4 changing things to reduce reallocs/copies, and wondered if you'd thought about rounding up the allocations to the nearest page size (at least on linux): Something along the lines of: Ishtar:tools/bash/readline-7.0> diff -u history.c.orig history.c --- history.c

probs making bash-4.4(+ patches)

Still having probs building bash-4.4 -- trying first, the builtin version of readline, and on running got: readline: ~/.inputrc: line 6: history-size=-1: unknown variable name readline: ~/.inputrc: line 35: completion-prefix-display-length=256: unknown variable name readline: ~/.inputrc: line

Re: The trap EXIT not allways executed

FYI: This works in 4.3.42 (echos "ATT: execute trap function" in both). Dr. Werner Fink wrote The trap EXIT not allways executed, see example script Repeat-By: Example script #!/bin/bash bash -c ' _rm () { echo ATT: Execute trap

Re: 4.4 change in behavior from 4.3: how to catch unset when using ${#length}

Chet Ramey wrote: Come on, don't be willfully obtuse. You know better than this. Posix mode doesn't mean "turning it off does everything the way Linda wants." No, but claiming posix as a backing for features running that are not running with posix-mode set, is equally obtuse. Bash is not

Re: 4.4 change in behavior from 4.3: how to catch unset when using ${#length}

Chet Ramey wrote: On 10/24/16 7:32 PM, L. A. Walsh wrote: I don't understand the ambiguity. If param= "#obj[@]", then it is clear to me that the user wants the length of an array named "obj". Stop there. In something like ${#obj[@]}, `param' is `obj

Re: Race in bash-4.3 'typeset'?

Stuart Shelton wrote: The cases appear, purely by inspection, to be: Not declared: trivially, `typeset -p` doesn’t include the value; Declared (even as local) but unassigned: `typeset -p` includes "declare -- varname"; Declared and assigned: `typeset -p` includes "declare -- varname=‘value’”

Re: Race in bash-4.3 'typeset'?

Stuart Shelton wrote: I have some code which evals a configuration file - but before doing so attempts to validate the content. It does this by taking each potential keyword from the file and then doing: if typeset -p | grep -q "^declare -. ${var}$”; then … to determine whether the

Re: 4.4 change in behavior from 4.3: how to catch unset when using ${#length}

Chet Ramey wrote: On 10/21/16 5:41 PM, L. A. Walsh wrote: [previously] one could have the illusion of this working w/o complaint -- and returning 0 when the array was 0-len or unset, or the array length, otherwise: echo ${#array[@]:-0} But I note it only seemed to work in arrays

Re: 4.4 change in behavior from 4.3: how to catch unset when using ${#length}

Eduardo Bustamante wrote: what's wrong with?: echo ${#array[@]} It will return: - With array=(1 2 3) -> 3 - With array=() -> 0 - With unset array -> 0 - With declare -a array -> 0 Seems to do what you're looking for. Not when "-u" is set, which I often have on to help catch

4.4 change in behavior from 4.3: how to catch unset when using ${#length}

On 4.3 and earlier, at least on arrays, one could have the illusion of this working w/o complaint -- and returning 0 when the array was 0-len or unset, or the array length, otherwise: echo ${#array[@]:-0} But I note it only seemed to work in arrays, and in 4.4 gets a syntax error: echo

Re: forked before bash subshell

Ya know, if you are looking for optimization opportunities, using a temporary file to communicate between processes rather than using an actual pipe, is definitely a performance hit -- ESPECIALLY on Cygwin, where you can't even do a "stat" call on a file without actually opening the file. I

Re: forked before bash subshell

Daniel Colascione wrote: On 10/15/2016 12:23 AM, L. A. Walsh wrote: Daniel Colascione wrote: One such case is Cygwin --- I'm not sure how "contrived" it is. Cygwin has an old-fashioned non-COW fork, and to add insult to injury, process creation generally is very slow (~100ms

Re: forked before bash subshell

XiaoBing Jiang wrote: Thank you for your explain! #!/bin/bash (cd /tmp && exec sleep 20) & echo "end" Then, instead of having: $ ./foo end $ ps f -t pts/5 PID TTY STAT TIME COMMAND 7287 pts/5Ss 0:00 bash 20165 pts/5R+ 0:00

Re: forked before bash subshell

Daniel Colascione wrote: One such case is Cygwin --- I'm not sure how "contrived" it is. Cygwin has an old-fashioned non-COW fork, and to add insult to injury, process creation generally is very slow (~100ms). It pays to eliminate subshells in that environment. Given what Cygwin has to work

Re: doc improvement for dotglob

Ian Kelling wrote: I'm not sure your reading it quite right. Chet gets it. Another way of explaining it is: dotglob does not affect the files "." and "..". --- After I saw Chet's response, I sorta got you were referring to the "exceptions". Thanks. -l

Re: doc improvement for dotglob

Ian Kelling wrote: The docs currently say: "When a pattern is used for filename expansion, the character '.' at the start of a filename or immediately following a slash must be matched explicitly, unless the shell option 'dotglob' is set. The last bit should be changed to say unless the

Re: Execution of a data string

Reuti wrote: Am 22.09.2016 um 15:23 schrieb Greg Wooledge : On Wed, Sep 21, 2016 at 11:15:45PM -0400, mobatu...@yahoo.ca wrote: declare -a "$string" # results in execution of $string declare -a a=($string)# does not result in execution of $string

Re: Command substitution with null bytes generates warning

The script is 5 years old. I don't remember any of the design decisions that went in to it -- so you wanna pick it apart, go ahead. I am already quite able to do so myself on stuff I wrote even 3 years ago, often, so 5 years, hey, go for it. I wasn't even using aliases to help my coding back

Re: Command substitution with null bytes generates warning

Chet Ramey wrote: Don't assume that every use of something like this has to do with /proc. Here's a representative report: "I was wondering what would happen if I'd do something like that: $ foo="$(cat file_containing_ascii_null_byte)" or faster $ foo="$(

Re: Is SIGWINCH fixed to re-enable it's pre-4.3 behavior? If not, why not?

Chet Ramey wrote: On 9/19/16 12:38 PM, L. A. Walsh wrote: It sounds like, from the release notes, that allowing real-time processing of signal handlers in read should no longer be an issue if pselect is used to before read to allow waiting for and processing of real-time events before

Re: Command substitution with null bytes generates warning

Chet Ramey wrote: On 9/19/16 2:41 PM, Greg Wooledge wrote: Bash has only three choices that I can think of: it can silently drop the NUL bytes (4.3 behavior), it can drop ALL of the bytes and return an error, or it can drop the NUL bytes with a warning (4.4 behavior). There is a

Re: Command substitution with null bytes generates warning

Greg Wooledge wrote: On Mon, Sep 19, 2016 at 09:28:53AM -0700, L. A. Walsh wrote: Could you change it back or provide a way to suppress "kiddy-scripter" seatbelts? wooledg@wooledg:~$ x=$(< /proc/$$/cmdline) bash-4.4: warning: command substitution: ignored null

Is SIGWINCH fixed to re-enable it's pre-4.3 behavior? If not, why not?

From the below, it sounds like you've fixed the problem disallowing signal handlers to process signals. SIGWINCH is specifically listed to use wait methods that allow it to be processed outside of 'read' -- which apparently caused problems such that signal handling was disabled in reads and not

Re: Command substitution with null bytes generates warning

Chet Ramey wrote: On 9/16/16 1:51 AM, Eric Pruitt wrote: Bash Version: 4.4 Patch Level: 0 Release Status: release Description: I have a script that execute `if [[ "$(<"/proc/$1/cmdline")" = tmux* ]];`. All /proc/*/cmdline include null bytes, and as of Bash 4.4, this

Re: Intriguing error with arithmetic evaluation

Chet Ramey wrote: Posix made an error in the 1992 version, in that the specification of set -e was subtly incompatible with historical... The relevant change was probably the change in the set of commands to which `set -e' applies. The (( command (among others) was added to that list in

is there a way to see if a var is declared so we can safely assign to it (and...)

This is a sample, of what I want: #!/bin/bash -u assign_var () { #if declared var; then var=assigned #else printf warn about global definition...; fi } lvl1 () { declare var assign_var printf "lvl1 var=%s\n" "$var" } lvl1 printf "main var after lvl1=%s\n" "${var:-undef}"

Re: Intriguing error with arithmetic evaluation

Greg Wooledge wrote: On Mon, Aug 15, 2016 at 03:15:13AM -0700, L. A. Walsh wrote: Calculations shouldn't ever trigger "-e" except for things like division by 0 (which doesn't trigger it, as the calculation dies before an return value can be calculated); it's counter-intuitive.

Re: Intriguing error with arithmetic evaluation

Chet Ramey wrote: On 8/15/16 6:15 AM, L. A. Walsh wrote: Chet Ramey wrote: The relevant change was probably the change in the set of commands to which `set -e' applies. The change was the result of Posix changing the semantics of the errexit option and expanding its scope from

Re: Unfamiliar; what does this do: "for file do"..."done"

Dennis Williamson wrote: There's an implied in "$@" for file in "$@" Hmmm...interesting, thanks, From a very narrow perspective, it doesn't seem very common. ;-) Re: Chet --- Yeah saw that... I think my brain blocked that instance out because it's the sorta the exact opposite of

Unfamiliar; what does this do: "for file do"..."done"

I was looking at how the 'ldd' command(bash script) on my system and came across the code usage: for file do ## about line 138 in my version ... case $file in */* : ;; *) file=./$file ;; esac ... done It doesn't appear to set the value of file in any of the code above the

Possible RFE? allowing array-initializer lists to be addressed like arrays

I was wanting to print, a true|false type text based on a boolean. What first came to mine was using an array holding the false & true values (in that order) and indexed by the ((value)) as 0=false, !0=true since arithmetic evals yield true or false depending on whether the expression

Re: IGNOREEOF and POSIXLY_CORRECT don't ignore invisible vars

Chet Ramey wrote: Think it through. A variable is not set until it has been assigned a value. Giving a variable an attribute (in this case, the `local' attribute) without assigning a value means that the variable is still unset. For example, Unless it was set in the global

Using new-bug based metrics to decide on release date (was Re: Before Bash 4.4 gets released)

On Thu, May 26, 2016 at 3:30 AM, Chet Ramey wrote: On 5/25/16 12:00 AM, konsolebox wrote: Bash seems to have gone through a lot of changes/bugs lately so it would be nice ...[to be]... sure it's stable forthat major version. There will be at least one, possibly

<    1   2   3   4