Re: Bug in [ -d ... ] ?

2017-11-03 Thread Greg Wooledge
On Fri, Nov 03, 2017 at 10:29:13AM +0700, Robert Elz wrote: > if [ -d "${FOOFOOFOO:=""}" ]; ... > > is not really portable. In bash, and several other shells, it does what > it looks like it should do, but in posix (as it stands today) and in some > other shells, including the original Bou

Re: New MILLISECONDS “special” variable?

2017-11-03 Thread Alan Dipert
Thanks all, EPOCHREALTIME sounds perfect. I’m also glad to have learned about loadable modules. Really cool. Alan On Thu, Nov 2, 2017 at 5:43 PM, Chet Ramey wrote: > On 11/2/17 4:09 PM, DJ Mills wrote: > > > > > > On Thu, Nov 2, 2017 at 3:35 PM, Chet Ramey > > wrote

Re: New MILLISECONDS “special” variable?

2017-11-03 Thread Chet Ramey
On 11/3/17 11:13 AM, Alan Dipert wrote: > Thanks all, EPOCHREALTIME sounds perfect. I’m also glad to have learned > about loadable modules. Really cool. Just to be clear: it's a special variable, not a builtin. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars

UID|EUID variables lose their ro properties

2017-11-03 Thread mike b
Hi! Below is some odd stuff I recently noticed, looks to me as a bug, though it's better if smarter people than me look at it as well to confirm that. :) Configuration Information: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' -DCONF_OS

Re: Bug in [ -d ... ] ?

2017-11-03 Thread Robert Elz
Date:Fri, 3 Nov 2017 08:21:41 -0400 From:Greg Wooledge Message-ID: <20171103122141.tvbmv5sfkcs7h...@eeg.ccf.org> | I am not seeing any evidence of this. As I said, for that particular usage, the effect is the same, either way. The way the shell gets there differs,

Re: UID|EUID variables lose their ro properties

2017-11-03 Thread Chet Ramey
On 11/3/17 12:09 PM, mike b wrote: > Bash Version: 4.4 > Patch Level: 12 > Release Status: release > > Description: > Whenever UID|EUID are exported to the env of newly exec Bash > instance said variables lose their ro properties. Here's example: Two reasons: you can't pass varia

Uncomplete multiline PS1 after 'display-shell-version'

2017-11-03 Thread Arnaud Gaillard
Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: cygwin Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash.exe' -DCONF_HOSTTYPE='x86_64' -DCONF_OSTYPE='cygwin' -DCONF_MACHTYPE='x86_64-unknown-cygwin' -DCONF_VENDOR='unknown' -DLOCALEDIR='/usr/share/locale' -DPA

Memory leak in subshell + read before bash 4.4

2017-11-03 Thread Adrien Mahieux
Hello, I think I've found a bug in the loop management. Maybe it's an expected behavior (didn't find any related topic on the manpages) but it's annoying in long-running scripts. The leak is triggered by this idiom (wether or not jobcontrol + lastpipe) : cmd | read var but not by this one : read

building: recutils bash builtins/readrec.so; ./configure --with-bash-headers=... # fails

2017-11-03 Thread bug-bash
No response today from bug-recutils: http://lists.gnu.org/archive/html/bug-recutils/2017-11/msg4.html For the ./configure, I untarred the latest bash source into a subdir, and set --with-bash-headers= to that pathname. Perhaps someone with an understanding of GNU configure/autoconf etc

Re: Uncomplete multiline PS1 after 'display-shell-version'

2017-11-03 Thread Chet Ramey
On 11/3/17 2:30 PM, Arnaud Gaillard wrote: > Bash Version: 4.4 > Patch Level: 12 > Release Status: release > > Description: > When using a multi-line PS1, pressing C-x C-v (invoking > *display-shell-version*) only redraws the last ("most bottom") line of the > PROMPT. > > > Repeat-By: >

Re: Memory leak in subshell + read before bash 4.4

2017-11-03 Thread Chet Ramey
On 11/3/17 6:01 PM, Adrien Mahieux wrote: > Hello, > > I think I've found a bug in the loop management. Maybe it's an > expected behavior (didn't find any related topic on the manpages) but > it's annoying in long-running scripts. > > The leak is triggered by this idiom (wether or not jobcontrol

Re: building: recutils bash builtins/readrec.so; ./configure --with-bash-headers=... # fails

2017-11-03 Thread Chet Ramey
On 11/3/17 6:28 PM, bug-b...@trodman.com wrote: > No response today from bug-recutils: > > http://lists.gnu.org/archive/html/bug-recutils/2017-11/msg4.html > > For the ./configure, I untarred the latest bash source into a subdir, and set > --with-bash-headers= > to that pathname. I don

Re: Memory leak in subshell + read before bash 4.4

2017-11-03 Thread Adrien Mahieux
On Sat, Nov 4, 2017 at 1:18 AM, Chet Ramey wrote: > On 11/3/17 6:01 PM, Adrien Mahieux wrote: >> Hello, >> >> I think I've found a bug in the loop management. Maybe it's an >> expected behavior (didn't find any related topic on the manpages) but >> it's annoying in long-running scripts. >> >> The

Re: Memory leak in subshell + read before bash 4.4

2017-11-03 Thread Chet Ramey
On 11/3/17 9:18 PM, Adrien Mahieux wrote: > On Sat, Nov 4, 2017 at 1:18 AM, Chet Ramey wrote: >> On 11/3/17 6:01 PM, Adrien Mahieux wrote: >>> Hello, >>> >>> I think I've found a bug in the loop management. Maybe it's an >>> expected behavior (didn't find any related topic on the manpages) but >>>

Re: Memory leak in subshell + read before bash 4.4

2017-11-03 Thread Adrien Mahieux
On Sat, Nov 4, 2017 at 2:21 AM, Chet Ramey wrote: > If it's that, it's not a leak. It's bash-4.3 keeping exit statuses for the > last CHILD_MAX processes. Bash-4.4 restricts that to the last CHILD_MAX > asynchronous background processes, with accompanying loss of functionality. Ok, seems indeed