Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-unknown-linux-gnu'
-DCONF_VENDOR='unknown' -DLOCALEDIR='/usr/local/share
On Mon, Sep 19, 2016 at 01:10:56PM -0700, L. A. Walsh wrote:
> Does readarray allow specifying the nulls as line-terminators?
Yes, as of bash 4.4.
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 read
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 fou
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 fourth choice: terminate the
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 reading a character.
Greg Wooledge wrote:
Bash has only three choices that I can think of: it can silently drop the
NUL bytes 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).
now who is being disingenuous? It was silent not just in 4.3, b
On 9/18/16 5:32 AM, xa...@t-online.de wrote:
> Bash Version: 4.4
> Patch Level: 0
> Release Status: rc2 / release
>
> Description:
> The tests below were performed with 4.4.0-rc2. However, the problem is
> still present in 4.4.0-release, only execution times are even higher
> fo
On Mon, Sep 19, 2016 at 11:30:56AM -0700, Linda Walsh wrote:
> How about, w/r/t the new warning -- I complain because the null bytes
> are missing after bash knowingly detected them and illegally modified
> the input. Putting out a warning about null bytes, doesn't mean it's
> "ok" to drop them.
Eric Blake wrote:
On 09/19/2016 11:58 AM, Greg Wooledge wrote:
wooledg@wooledg:~$ x=$(< /proc/$$/cmdline)
bash-4.4: warning: command substitution: ignored null byte in input
wooledg@wooledg:~$ x=$(< /proc/$$/cmdline 2>/dev/null)
wooledg@wooledg:~$
Or:
$ x=$(< /proc/$$/cmdline tr -d
On 09/19/2016 11:58 AM, Greg Wooledge wrote:
> On Mon, Sep 19, 2016 at 09:28:53AM -0700, L. A. Walsh wrote:
>>If users were relying on this behavior (I know I have scripts that read
>> things from proc -- a text interface that uses \0 to display values similar
>> to MS's multi-string Values in
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 byte in input
wooled
On Mon, Sep 19, 2016 at 09:28:53AM -0700, L. A. Walsh wrote:
>If users were relying on this behavior (I know I have scripts that read
> things from proc -- a text interface that uses \0 to display values similar
> to MS's multi-string Values in the Windows registry.
>Could you change it ba
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 p
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
resu
Chet Ramey wrote:
> On 9/18/16 11:20 PM, Felix Janda wrote:
>
> >>> Notice that the configure script disables job-control when a run-time
> >>> test (which could easily be a built-time test) fails. So by default,
> >>> a cross-compiled bash will have this bug.
> >>
> >> Which test?
> >
> > I am r
On 9/18/16 11:20 PM, Felix Janda wrote:
>>> Notice that the configure script disables job-control when a run-time
>>> test (which could easily be a built-time test) fails. So by default,
>>> a cross-compiled bash will have this bug.
>>
>> Which test?
>
> I am referring to BASH_SYS_JOB_CONTROL_MIS
> maybe I do not fully follow your example, but wouldn't you instead of:
>
> time D="${C//\[+([0-9])\]=}" # rm '[]='
>
> want:
>
> time D="${C//\[[0-9]*\]=}" # rm '[]='
this would also find [!asd]. And there are other possibilities.
but that was not
18 matches
Mail list logo
