On Wed, Oct 05, 2016 at 09:20:58AM -0400, Chet Ramey wrote:
> Try the attached patch, which reduces the number of warnings to 1 per call
> to command substitution.
I don't agree with this approach -- I think you should be able to turn
off the warning completely, so I am not interested in testing t
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
> results in
>
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 th
On Tue, Sep 20, 2016 at 12:17:37PM -0700, L. A. Walsh wrote:
> /sys/class/net/br0> /tmp/showvals
> addr_assign_type: 1
> addr_len: 6
> address: 00:15:17:bf:be:b2
> /tmp/showvals: line 63: printf: `invalid format character
> brforward:
Ooops -- that script does try to run w/sudo.. forgot about that...
Like I said, fast & dirty
Greg Wooledge wrote:
I probably shouldn't even bother at this point, but morbid curiosity
compels me to foolish ends.
What are you DOING with these files that contain NUL bytes that makes
it permissible to simply drop the NUL bytes on the floor, with no
explicit step like tr -d \\0 to remove t
I probably shouldn't even bother at this point, but morbid curiosity
compels me to foolish ends.
What are you DOING with these files that contain NUL bytes that makes
it permissible to simply drop the NUL bytes on the floor, with no
explicit step like tr -d \\0 to remove them?
How is your script
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="$(http://www.gnu.org/software/bash/manual
On 9/19/16 12:28 PM, L. A. Walsh wrote:
>
>
> 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*
>>> ]];`.
>>>
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 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
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 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
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
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
> results in
>
On Thu, Sep 15, 2016 at 10:51:22PM -0700, Eric Pruitt wrote:
> Fix:
> Is this even an intentional change? I looked at some of the other
> internal_warning invocations, and they were commented out using "#if 0
> ...
> #endif."
In 4.4-beta2, I see them in subst.c and parse.y and y
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
22 matches
Mail list logo
