On Mon, Jan 15, 2024, 19:03 Chet Ramey wrote:
> On 1/11/24 7:29 PM, Ángel wrote:
> > On 2024-01-11 at 09:29 -0500, Chet Ramey wrote:
> >> On 1/11/24 2:37 AM, ilya Basin wrote:
> >>> Dear.
> >>> I needed to read 16 bytes from a binary file and tried to replace a
> >> hexdump call with read
On 1/11/24 7:29 PM, Ángel wrote:
On 2024-01-11 at 09:29 -0500, Chet Ramey wrote:
On 1/11/24 2:37 AM, ilya Basin wrote:
Dear.
I needed to read 16 bytes from a binary file and tried to replace a
hexdump call with read built-in. I expected that with "-N1" if a NUL
character is encountered bash
Random irreversible behaviour change strikes again.
This changed in Bash 4.3.0, and to make matters worse, shopt -s compat42
does not restore the previous behaviour.
Up to Bash 4.2, read -N1 would indeed set the receiving variable to empty
while returning a zero status, having read only one
On Sat, Jan 13, 2024 at 02:06:08AM +0700, Robert Elz wrote:
> Date:Fri, 12 Jan 2024 07:15:35 -0500
> From:Greg Wooledge
> Message-ID:
>
> | This was one of the things I tested:
>
> Perhaps intended to, but didn't, or not in this example:
>
> | { read -N1; read
On Fri, Jan 12, 2024, at 2:06 PM, Robert Elz wrote:
> ps: the use of process substitution there is just silly, it would work
> just as well, and be easier to understand if written:
>
> printf '\\\nabc' | { read -N1; read -r b c; }; declare -p REPLY b c
Presumably Greg was just preventing
Date:Fri, 12 Jan 2024 07:15:35 -0500
From:Greg Wooledge
Message-ID:
| This was one of the things I tested:
Perhaps intended to, but didn't, or not in this example:
| { read -N1; read -r b c; } < <(printf \\nabc); declare -p REPLY a b c
Rewrite that, correctly
On Fri, Jan 12, 2024 at 03:26:31PM +0700, Robert Elz wrote:
> Date:Thu, 11 Jan 2024 20:02:04 -0500
> From:Greg Wooledge
> Message-ID:
>
> | What actually counts is how many
> | characters are *stored* in the variable, not how many characters are
> | *read*
Date:Thu, 11 Jan 2024 20:02:04 -0500
From:Greg Wooledge
Message-ID:
| What actually counts is how many
| characters are *stored* in the variable, not how many characters are
| *read* from the input.
I suspect that is the root of the issue here, you're
On Thu, Jan 11, 2024 at 08:02:04PM -0500, Greg Wooledge wrote:
> And this for the help text:
>
> -N nchars return only after storing exactly NCHARS characters, unless
>EOF is encountered or read times out, ignoring any NUL or
>delimiter characters
Actually,
On Fri, Jan 12, 2024 at 01:29:19AM +0100, Ángel wrote:
> One might say "reading exactly nchars characters into the name",
I would still find that confusing. What actually counts is how many
characters are *stored* in the variable, not how many characters are
*read* from the input.
> but
> given
On 2024-01-11 at 09:29 -0500, Chet Ramey wrote:
> On 1/11/24 2:37 AM, ilya Basin wrote:
> > Dear.
> > I needed to read 16 bytes from a binary file and tried to replace a
> hexdump call with read built-in. I expected that with "-N1" if a NUL
> character is encountered bash would assign an empty
On Thu, Jan 11, 2024, 15:29 Chet Ramey wrote:
> On 1/11/24 2:37 AM, ilya Basin wrote:
> > Dear.
> > I needed to read 16 bytes from a binary file and tried to replace a
> hexdump call with read built-in. I expected that with "-N1" if a NUL
> character is encountered bash would assign an empty
On Thu, Jan 11, 2024 at 09:29:03AM -0500, Chet Ramey wrote:
> The read builtin skips over NUL characters because you can't store them
> as part of the value of a shell variable. That seems obvious.
I would argue that it's not obvious at all when using -N. The help
text for -N says "return only
On 1/11/24 2:37 AM, ilya Basin wrote:
Dear.
I needed to read 16 bytes from a binary file and tried to replace a hexdump call with
read built-in. I expected that with "-N1" if a NUL character is encountered
bash would assign an empty string, however there's no indication that a NUL character
14 matches
Mail list logo
