Re: Bash 5.2.0: Memory leak with $(
> On Mon, Jan 8, 2024, 12:26 wrote: > >> Do any of the other six patches in that report also apply to Bash 5.2? >> > > Yes, all but the one for the `kv' builtin which did not exist yet. See > attached. > >> >> Would you please consider releasing these as an official patch?
Re: document that read built-in can't return zero-length string in the middle of input
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 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 was there and it simply
> >> assigns the next non-NUL character to the variable.
> >>
> >> 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.
> >
> > While doing read -N 16 from a file bigger than 16 bytes and ending up
> > with less than that (e.g. only 10 bytes because the other 6 turned out
> > to be NULs) would be surprising, the assumption of the OP that when
> > using -N1 a NUL byte would become an empty string doesn't seem far-
> > fetched.
>
> The -N option doesn't make `read' immune from the other rules it follows.
> If you run
>
> printf '\\sa\n' | { read -N 1 var ; echo "$var"; }
> or
> printf '\\\n\sa\n' | { read -N 1 var ; echo "$var"; }
>
> you'll get `s'.
>
> >> What would you like to see documented? That NUL characters don't
> >> count towards the number of characters read to satisfy -N? Doesn't
> >> that follow from the above?
> >
> > Not eccessarily. The phrase "reading exactly nchars characters" depends
> > on (a) what you consider to be reading, as you are read(2)ing more
> > bytes than stated with -N; and (b) what you consider to be a character.
>
> `read' reads multibyte characters; should -N 1 read the first byte or
> the entire character? Anyway, the description of `read -N' doesn't say
> `bytes', it says `characters'. Maybe there should be something in there
> that says -N n stops after consuming enough data to store n characters
> in the named variable.
>
maybe locale based ..
> I would tend to add a line below saying e.g. "NUL characters
> > cannot be stored in bash variables and are always ignored by read".
>
> That's reasonable, except you have to mention the -d '' case. It might
> also be worthwhile to add something to the description of shell variables
> that says they can't store NUL bytes.
>
> Chet
> --
> ``The lyf so short, the craft so long to lerne.'' - Chaucer
> ``Ars longa, vita brevis'' - Hippocrates
> Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
>
>
Re: document that read built-in can't return zero-length string in the middle of input
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 would assign an empty string, however
there's no indication that a NUL character was there and it simply
assigns the next non-NUL character to the variable.
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.
While doing read -N 16 from a file bigger than 16 bytes and ending up
with less than that (e.g. only 10 bytes because the other 6 turned out
to be NULs) would be surprising, the assumption of the OP that when
using -N1 a NUL byte would become an empty string doesn't seem far-
fetched.
The -N option doesn't make `read' immune from the other rules it follows.
If you run
printf '\\sa\n' | { read -N 1 var ; echo "$var"; }
or
printf '\\\n\sa\n' | { read -N 1 var ; echo "$var"; }
you'll get `s'.
What would you like to see documented? That NUL characters don't
count towards the number of characters read to satisfy -N? Doesn't
that follow from the above?
Not eccessarily. The phrase "reading exactly nchars characters" depends
on (a) what you consider to be reading, as you are read(2)ing more
bytes than stated with -N; and (b) what you consider to be a character.
`read' reads multibyte characters; should -N 1 read the first byte or
the entire character? Anyway, the description of `read -N' doesn't say
`bytes', it says `characters'. Maybe there should be something in there
that says -N n stops after consuming enough data to store n characters
in the named variable.
I would tend to add a line below saying e.g. "NUL characters
cannot be stored in bash variables and are always ignored by read".
That's reasonable, except you have to mention the -d '' case. It might
also be worthwhile to add something to the description of shell variables
that says they can't store NUL bytes.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
OpenPGP_signature.asc
Description: OpenPGP digital signature
Re: Bash 5.2.21 segfaults when I feed it garbage
On 1/14/24 7:24 PM, Grisha Levit wrote:
See also (even after the fix pushed today):
bash -c '(( X=([))])'
heap-use-after-free parse.y:2712:60 in shell_getc
bash -c '(( X=([))]) ))'
heap-use-after-free parse.y:2077:11 in parser_expanding_alias
Thanks. This is a different issue. In this case, the parser needs to treat
a string pushed by a failed attempt to parse `((' as an arithmetic command
(in which case we fall back and try to parse the text as a nested subshell)
the same as an alias and fix up the pushed string list.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
OpenPGP_signature.asc
Description: OpenPGP digital signature
Re: bash aborts line-editing on tab-expansion with find pattern
2024年1月15日(月) 23:02 :
> Description:
> Found while editing history line with a find pattern.
> Apparently bash doesn't like + characters very much.
>
> Repeat-By:
> find . -type f -ctime +30 ! -ctime +40 -exec ls -la --full-time {} +
> Move cursor to any point after find and before -exec, press TAB, and
> bash will print
> -bash: COMP_POINT: substring expression < 0
That is an issue of the "bash-completion" project, which provides the
configurations for the Bash programmable completion, but is not Bash's
issue. This is actually reported at [1], which was already fixed in
[2]. The fix is not yet in the release version of bash-completion, so
you need to use the master branch of bash-completion on GitHub if you
want a copy of bash-completion free from this issue.
[1] https://github.com/scop/bash-completion/issues/1080
[2] https://github.com/scop/bash-completion/pull/860
--
Koichi
bash aborts line-editing on tab-expansion with find pattern
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -g -O2 -fstack-protector-strong -Wformat
-Werror=format-security -Wall
uname output: Linux sourcetronic.com 5.10.0-19-amd64 #1 SMP Debian 5.10.149-2
(2022-10-21) x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu
Bash Version: 5.1
Patch Level: 4
Release Status: release
Description:
Found while editing history line with a find pattern.
Apparently bash doesn't like + characters very much.
Repeat-By:
find . -type f -ctime +30 ! -ctime +40 -exec ls -la --full-time {} +
Move cursor to any point after find and before -exec, press TAB, and
bash will print
-bash: COMP_POINT: substring expression < 0
(before the +3)
or
-bash: index: substring expression < 0
(after the +3)
at the cursor position and abort editing the line.
MfG MOW []-)
