Re: nameref to array[@] doesn't always expand to multiple words
On 1/19/21 5:38 AM, Oğuz wrote:
See:
$ a=(1 2 3)
$ b=a[@]
$ declare -n c=a[@]
$
$ printf '<%s>\n' "${!b}"
<1>
<2>
<3>
$ printf '<%s>\n' "$c"
<1 2 3>
Thanks for the report. This is an easy fix.
--
``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/
History -r breaks on FIFOs
The history command doesn't seem to work when given a FIFO instead of a file. I was trying to load history from FIFO using either 'history -r <(echo "$hist")' or 'echo "$hist" | history -r /dev/stdin', but neither of these seem to work, due to the command being unable to handle FIFOs. Cheers, Merijn signature.asc Description: Message signed with OpenPGP
obscure bug "extern void free (void *__ptr) __attribute__ ((__nothrow__ , __leaf__));"
From: l0rd
To: bug-bash@gnu.org
Subject: obscure bug "extern void free (void *__ptr) __attribute__
((__nothrow__ , __leaf__));"
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -march=x86-64 -mtune=generic -O2 -pipe -fno-plt
-DDEFAULT_PATH_VALUE='/usr/local/sbin:/usr/local/bin:/usr/bin'
-DSTANDARD_UTILS_PATH='/usr/bin' -DSYS_BASHRC='/etc/bash.bashrc'
-DSYS_BASH_LOGOUT='/etc/bash.bash_logout' -DNON_INTERACTIVE_LOGIN_SHELLS
uname output: Linux C1MPAQ 5.10.7-arch1-1 #1 SMP PREEMPT Wed, 13 Jan
2021 12:02:01 + x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu
Bash Version: 5.1 (Archlinux: core/bash 5.1.004-1)
Patch Level: 4
Release Status: release
Description:
An Autoconf configure script does fail, because some file it generated
does unexpectedly contain output from some command it called in an
if-statement that had output directed to >& /dev/null . Various
alterations to the script do produce strange outcomes. Sometimes it
avoids the bug, sometimes it will result in the line "extern void free
(void *__ptr) __attribute__ ((__nothrow__ , __leaf__));" to be inserted
into the file in addition to the behavior. This line is seemingly in
some cases also be generated by the command itself that generated the
misplaced output, which suggests that the bug is not in bash but some
API bash is written in.
Repeat-By:
git clone https://github.com/LibreELEC/LibreELEC.tv
cd LibreELEC.tv
ARCH=aarch64 PROJECT=Amlogic DEVICE=AMLGX ./scripts/build linux
-> the build fails after a minute in the Autoconfig step due to
wrongful insertion of silenced command output into file config.status at
line 533
In: build.LibreELEC-AMLGX.aarch64-9.80-devel/build/ccache-3.7.12/configure
Go to line 6532: if diff "$cache_file" confcache >/dev/null 2>&1; then
:; else
Hint: $cache_file is always /dev/null , hence the if-statement will
evaluate false
This diff command is the source of the insertion in
build.LibreELEC-AMLGX.aarch64-9.80-devel/build/ccache-3.7.12/config.status :
0a1,97:
> # This file is a shell script that caches the results of
configure
> # tests run on this system so they can be shared between
configure
...
Remove the line and the corresponding "fi" that closes the if-statement
-> script inserts "extern void free ..." instead into
./config.status at line 533
Replace line with: if diff "$cache_file" confcache >& /tmp/nothing; then
:; else
-> script inserts not only "extern void free ..." in config.status,
but also the following into /tmp/nothing at the top in addition to the
output:
1c1,97
< extern void free (void *__ptr) __attribute__ ((__nothrow__ ,
__leaf__));
---
> # This file is a shell script that caches the results of
configure
...
Replace line with if cat /tmp/nothing >& /dev/null; then :; else
-> script inserts content of /tmp/nothing into ./config.status at
line 533
Replace line with if false; then :; else # or other random commands
-> script works
Content of /tmp/nothing (all characters are exact part of the file):
1c1,97
< extern void free (void *__ptr) __attribute__ ((__nothrow__ , __leaf__));
---
> # This file is a shell script that caches the results of configure
> # tests run on this system so they can be shared between configure
> # scripts and configure runs, see configure's option --config-cache.
> # It is not useful on other systems. If it contains results you don't
> # want to keep, you may remove or edit it.
> #
> # config.status only pays attention to the cache file if you give it
> # the --recheck option to rerun configure.
> #
> # `ac_cv_env_foo' variables (set or unset) will be overridden when
> # loading this file, other *unset* `ac_cv_foo' will be assigned the
> # following values.
>
> ac_cv_build=${ac_cv_build=x86_64-pc-linux-gnu}
> ac_cv_c_bigendian=${ac_cv_c_bigendian=no}
> ac_cv_c_compiler_clang=${ac_cv_c_compiler_clang=no}
> ac_cv_c_compiler_gnu=${ac_cv_c_compiler_gnu=yes}
> ac_cv_c_extern_inline=${ac_cv_c_extern_inline=no}
> ac_cv_c_inline=${ac_cv_c_inline=inline}
> ac_cv_env_CC_set=set
> ac_cv_env_CC_value=/bin/gcc
> ac_cv_env_CFLAGS_set=set
> ac_cv_env_CFLAGS_value='-march=native -O2 -Wall -pipe
-I/home/l0rd/LibreELEC.tv/build.LibreELEC-AMLGX.aarch64-9.80-devel/toolchain/include
-Wno-format-security'
> ac_cv_env_CPPFLAGS_set=set
> ac_cv_env_CPPFLAGS_value=
> ac_cv_env_CPP_set=set
> ac_cv_env_CPP_value=cpp
> ac_cv_env_LDFLAGS_set=set
>
ac_cv_env_LDFLAGS_value='-Wl,-rpath,/home/l0rd/LibreELEC.tv/build.LibreELEC-AMLGX.aarch64-9.80-devel/toolchain/lib
-L/home/l0rd/LibreELEC.tv/build.LibreELEC-AMLGX.aarch64-9.80-devel/toolchain/lib'
> ac_cv_env_LIBS_set=
> ac_cv_env_LIBS_value=
> ac_cv_env_build_alias_set=set
> ac_cv_env_build_alias_value=x86_64-pc-linux-gnu
> ac_cv_env_host_alias_set=set
> ac_cv_env_host_alias_value=x86_64-pc-linux-gnu
> ac_cv_env_target_alias_set=
> ac_
Re: History -r breaks on FIFOs
On 21/01/2021 16:18, Merijn Verstraaten wrote:
The history command doesn't seem to work when given a FIFO instead of a file. I was trying to load
history from FIFO using either 'history -r <(echo "$hist")' or 'echo "$hist" |
history -r /dev/stdin', but neither of these seem to work, due to the command being unable to handle
FIFOs.
As the second command doesn't make for a valid test case, I'll add some
additional context.
# Succeeds
echo injected > commandlist; ( history -r commandlist && history 1 )
# Fails
echo injected | { history -r /dev/stdin && history 1; }
--
Kerin Millar
Re: obscure bug "extern void free (void *__ptr) __attribute__ ((__nothrow__ , __leaf__));"
On 1/21/21 1:11 PM, Mathias Steiger wrote: Bash Version: 5.1 (Archlinux: core/bash 5.1.004-1) Patch Level: 4 Release Status: release Description: An Autoconf configure script does fail, because some file it generated does unexpectedly contain output from some command it called in an if-statement that had output directed to >& /dev/null . Various alterations to the script do produce strange outcomes. Shouldn't you report this to bug-autoconf? -- ``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: History -r breaks on FIFOs
On 1/21/21 11:18 AM, Merijn Verstraaten wrote: The history command doesn't seem to work when given a FIFO instead of a file. I was trying to load history from FIFO using either 'history -r <(echo "$hist")' or 'echo "$hist" | history -r /dev/stdin', but neither of these seem to work, due to the command being unable to handle FIFOs. Correct. The history file reading code requires the history file be a regular file. This is because the technique it uses to read and process the file (mmap or read the file in one read into a large buffer, then move around in the buffer) doesn't work with non-regular files. -- ``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: obscure bug "extern void free (void *__ptr) __attribute__ ((__nothrow__ , __leaf__));"
No.
If you read the the rest of the bug report, it might become clearer to you.
Suppose I wrote a simple script:
{if echo "27ac5e2f757302" >& /dev/null; then echo "yes"; else echo
"no"; fi } > output
and then the file "output" would contain:
"extern void free (void *__ptr) __attribute__ ((__nothrow__ ,
__leaf__)); 27ac5e2f757302 yes"
This is more or less what is happening here.
Do you believe that could be an error in my script? If yes, how so?
How could the word "27ac5e2f757302" possibly end up in the file "output"?
Where does the mysterious line "extern void free (void *__ptr)
__attribute__ ((__nothrow__ , __leaf__));" come from? A line that is not
contained in the script or the rest of the code.
On 1/21/21 8:19 PM, Chet Ramey wrote:
On 1/21/21 1:11 PM, Mathias Steiger wrote:
Bash Version: 5.1 (Archlinux: core/bash 5.1.004-1)
Patch Level: 4
Release Status: release
Description:
An Autoconf configure script does fail, because some file it
generated does unexpectedly contain output from some command it
called in an if-statement that had output directed to >& /dev/null .
Various alterations to the script do produce strange outcomes.
Shouldn't you report this to bug-autoconf?
Re: obscure bug "extern void free (void *__ptr) __attribute__ ((__nothrow__ , __leaf__));"
On Thu, Jan 21, 2021 at 1:28 PM Mathias Steiger
wrote:
>
>
> No.
>
> If you read the the rest of the bug report, it might become clearer to you.
>
>
> Suppose I wrote a simple script:
>
> {if echo "27ac5e2f757302" >& /dev/null; then echo "yes"; else echo
> "no"; fi } > output
Did you mean:
echo "27ac5e2f757302" &> /dev/null;
Instead?
`>&` is not the same as `&>`
Re: obscure bug "extern void free (void *__ptr) __attribute__ ((__nothrow__ , __leaf__));"
On Thu, Jan 21, 2021 at 1:32 PM Eduardo Bustamante wrote:
>
> On Thu, Jan 21, 2021 at 1:28 PM Mathias Steiger
> wrote:
> >
> >
> > No.
> >
> > If you read the the rest of the bug report, it might become clearer to you.
> >
> >
> > Suppose I wrote a simple script:
> >
> > {if echo "27ac5e2f757302" >& /dev/null; then echo "yes"; else echo
> > "no"; fi } > output
>
> Did you mean:
> echo "27ac5e2f757302" &> /dev/null;
>
> Instead?
>
> `>&` is not the same as `&>`
Actually, don't mind me. I'm wrong. I should've checked the manual first.
Sorry about the noise.
Re: obscure bug "extern void free (void *__ptr) __attribute__ ((__nothrow__ , __leaf__));"
On Thu, Jan 21, 2021 at 10:27:54PM +0100, Mathias Steiger wrote:
> Suppose I wrote a simple script:
>
> {if echo "27ac5e2f757302" >& /dev/null; then echo "yes"; else echo "no";
> fi } > output
I count at least 3 bugs here, or 4 if you run this from something that
works around the exec format error by running sh rather than bash.
If this is supposed to be an actual script, then you need a shebang.
That's number one.
If you're going to use curly braces to turn the compound "if" command into
a command group, then you need a space after the first brace (that's two),
and you need a newline or semicolon or other command terminator before
the second brace (that's three). Of course, you could fix both of those
by simply removing the curly braces entirely.
Finally, if you're writing this as an sh script, you cannot use the >&
operator for redirection. That's a bashism. That's number four, if
the missing shebang is #!/bin/sh. If the missing shebang invokes bash,
then the >& operator is permitted, but I still wouldn't advise it.
When reporting a bug and showing an example script, it's best if the
example script actually *runs*, and ideally, produces the actual results
that you are reporting as a bug.
Just typing random malformed commands into an email as an "example"
does not help anyone.
Re: obscure bug "extern void free (void *__ptr) __attribute__ ((__nothrow__ , __leaf__));"
On 1/21/21 4:27 PM, Mathias Steiger wrote:
No.
If you read the the rest of the bug report, it might become clearer to you.
Suppose I wrote a simple script:
{if echo "27ac5e2f757302" >& /dev/null; then echo "yes"; else echo
"no"; fi } > output
Suppose you did.
I did, after correcting the syntax errors in yours, and couldn't reproduce
the problem. So if you can extract a script that exhibits the problem from
the rest of the autoconf framework, I'll be glad to see if it demonstrates
a bug in bash.
--
``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: obscure bug "extern void free (void *__ptr) __attribute__ ((__nothrow__ , __leaf__));"
As such bugs are likely related to buffer issues, maybe even in
underlying APIs, and since they only surface after very lengthy
mysterious sequences of commands - often just on single specific system
installations - I wouldn't know how you can reproduce this in a test.
Maybe you have specific testing frameworks for this, that would reduce
the whole script to more basic components and which schematically remove
or add complexity until the nature of the bug becomes more apparent?
This seems to call for a specialist who is able to follow the problem
into a far lower level of abstraction.
As it stands now, I don't see how there is no way how this kind of
execution can make any sense from a scripting POV.
Of course in a giant script, all sorts of random things might happen.
But this is not one of them.
On 1/21/21 10:38 PM, Chet Ramey wrote:
On 1/21/21 4:27 PM, Mathias Steiger wrote:
No.
If you read the the rest of the bug report, it might become clearer
to you.
Suppose I wrote a simple script:
{if echo "27ac5e2f757302" >& /dev/null; then echo "yes"; else
echo "no"; fi } > output
Suppose you did.
I did, after correcting the syntax errors in yours, and couldn't
reproduce
the problem. So if you can extract a script that exhibits the problem
from
the rest of the autoconf framework, I'll be glad to see if it
demonstrates
a bug in bash.
Re: obscure bug "extern void free (void *__ptr) __attribute__ ((__nothrow__ , __leaf__));"
On Thu, Jan 21, 2021 at 2:07 PM Mathias Steiger wrote: > > > As such bugs are likely related to buffer issues, maybe even in > underlying APIs, and since they only surface after very lengthy > mysterious sequences of commands - often just on single specific system > installations - I wouldn't know how you can reproduce this in a test. > > Maybe you have specific testing frameworks for this, that would reduce > the whole script to more basic components and which schematically remove > or add complexity until the nature of the bug becomes more apparent? > > This seems to call for a specialist who is able to follow the problem > into a far lower level of abstraction. > > As it stands now, I don't see how there is no way how this kind of > execution can make any sense from a scripting POV. > > Of course in a giant script, all sorts of random things might happen. > But this is not one of them. You could run the script through "strace" or a similar command to see what's writing that output and when. We could use that log output to confirm that it is indeed Bash that is writing this out-of-order and to a file descriptor that it shouldn't. Greg pointed out earlier that the construct you're trying to use doesn't work well when the shell is not Bash. Are you 100% confident that it is /bin/bash that is running the script and not /bin/sh (and thus maybe something like Dash?). And keep in mind that even Bash running as /bin/sh is not quite the same as Bash running as /bin/bash.
Re: obscure bug "extern void free (void *__ptr) __attribute__ ((__nothrow__ , __leaf__));"
You could improve this bug report. A few pointers: Mathias Steiger writes: > Repeat-By: > > git clone https://github.com/LibreELEC/LibreELEC.tv > cd LibreELEC.tv > ARCH=aarch64 PROJECT=Amlogic DEVICE=AMLGX ./scripts/build linux I attempted to follow this, but the output I got was: $ ARCH=aarch64 PROJECT=Amlogic DEVICE=AMLGX no_proxy ./scripts/build linux GET linux (archive) Usage: wget [OPTION]... [URL]... Try `wget --help' for more options. Usage: wget [OPTION]... [URL]... Try `wget --help' for more options. Usage: wget [OPTION]... [URL]... [a dozen or more times] Does your build process actually make external web fetches? You really need to warn people about that if you are presenting a recipe for duplicating a bug. > -> the build fails after a minute in the Autoconfig step due to > wrongful insertion of silenced command output into file config.status at > line 533 > In: build.LibreELEC-AMLGX.aarch64-9.80-devel/build/ccache-3.7.12/configure > Go to line 6532: if diff "$cache_file" confcache >/dev/null 2>&1; then > :; else > Hint: $cache_file is always /dev/null , hence the if-statement will > evaluate false I understand that a line appears in config.status that you believe is incorrect, but you don't quote what the line is (preferably with some context around it). You assert that it is "silenced command output", but you don't actually know that (without dissecting the script you're running), only that it *appears* to be silenced command output. If you've genuinely tracked down how it got there, you should explain your reasoning in detail. > This diff command is the source of the insertion in > build.LibreELEC-AMLGX.aarch64-9.80-devel/build/ccache-3.7.12/config.status : > 0a1,97: > > # This file is a shell script that caches the results of > configure > > # tests run on this system so they can be shared between > configure > ... > Remove the line and the corresponding "fi" that closes the if-statement > -> script inserts "extern void free ..." instead into > ./config.status at line 533 You say "remove the line" but it isn't clear what line you are referring to. Dale
Re: obscure bug "extern void free (void *__ptr) __attribute__ ((__nothrow__ , __leaf__));"
On 1/21/21 5:07 PM, Mathias Steiger wrote: As such bugs are likely related to buffer issues, maybe even in underlying APIs, and since they only surface after very lengthy mysterious sequences of commands - often just on single specific system installations - I wouldn't know how you can reproduce this in a test. And that's the problem. While the behavior you're seeing may be related to some `buffer issue', it's just as likely that there's some issue with how autoconf-generated scripts manipulate file descriptors or that your script interacts badly in some other way with what autoconf generates. But without a way to reproduce it independently, there's no way to tell whether it's a bug separate from autoconf. Maybe you have specific testing frameworks for this, that would reduce the whole script to more basic components and which schematically remove or add complexity until the nature of the bug becomes more apparent? This is why I advised you to report it to bug-autoconf. They're more familiar with the code generator and what problems might result from it. Of course in a giant script, all sorts of random things might happen. But this is not one of them. Maybe. Maybe not. You just don't have enough information to say. -- ``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: obscure bug "extern void free (void *__ptr) __attribute__ ((__nothrow__ , __leaf__));"
Thanks for your reply. My report maybe did contain a lot of too tightly
packed information. I try to clarify:
The git repository is the official one of Libreelec (a Linux
distribution). Naturally it has to download packages.
I did in fact quote an brief excerpt of the wrongfully inserted line two
times (with context where it is inserted). I made that clear by
indentation, a colon and also the context. When I was speaking of a
"diff" command inserting it's output somewhere else, you can see that I
did in fact quote "diff" formatted output afterwards as marked. It might
be confusing, because it might look a bit like I was using "diff" to
quote the inserted line instead.
When I was speaking of removing "the line", I was referring to the only
line I explicitly mentioned by line number and also the only line
mentioned that has a corresponding "if" statement. It is of course hard
to follow this, if you do not open and look at the mentioned file at the
same time.
By "silenced command output" I was simply referring to what is happening
in "the line", i.e. a command having its output directed at >& /dev/null.
I don't understand the rest of the paragraph you wrote.
In my mind, I have found an impossible execution: a "silenced command"
outputs to a file it shouldn't output into.
My knowledge of bash is not perfect, but I don't believe this should or
can ever happen. Unless of course you wrote another script to
specifically remove the redirection to /dev/null and then you executed
that altered script.
How would it only "appear to be silenced"? Can you somehow resurrect
output directed at /dev/null? I guess anything is possible if you made a
lot of effort to do it, but this doesn't seem likely to me in an
Autoconfig script. Especially considering the insertion is so random and
it doesn't happen with previous bash versions.
From what I can tell, there is no further need to dissect the rest of
the script to know that this is a bug in bash, because realistically
this can never make sense as it is.
In my limited knowledge, it looks to me like some pointer address
overflowed - due to the length and complexity of the script - and then
it just reads from some arbitrary old buffer.
On 1/21/21 10:27 PM, Mathias Steiger wrote:
{if echo "27ac5e2f757302" >& /dev/null; then echo "yes"; else echo
"no"; fi } > output
and then the file "output" would contain:
"extern void free (void *__ptr) __attribute__ ((__nothrow__ ,
__leaf__)); 27ac5e2f757302 yes"
This is more or less what is happening here.
Re: obscure bug "extern void free (void *__ptr) __attribute__ ((__nothrow__ , __leaf__));"
Here is the strace output. https://filebin.net/9auqyreezma08z12/bug_bash.tar.gz?t=3bjx4xpd It is very excessive due to the nature of Autoconf and I couldn't make a lot of sense of it. When I downgraded the package from bash-5.1.004-1 to bash-5.0.018-2 the bug disappeared. On 1/22/21 12:27 AM, Eduardo Bustamante wrote: On Thu, Jan 21, 2021 at 2:07 PM Mathias Steiger wrote: As such bugs are likely related to buffer issues, maybe even in underlying APIs, and since they only surface after very lengthy mysterious sequences of commands - often just on single specific system installations - I wouldn't know how you can reproduce this in a test. Maybe you have specific testing frameworks for this, that would reduce the whole script to more basic components and which schematically remove or add complexity until the nature of the bug becomes more apparent? This seems to call for a specialist who is able to follow the problem into a far lower level of abstraction. As it stands now, I don't see how there is no way how this kind of execution can make any sense from a scripting POV. Of course in a giant script, all sorts of random things might happen. But this is not one of them. You could run the script through "strace" or a similar command to see what's writing that output and when. We could use that log output to confirm that it is indeed Bash that is writing this out-of-order and to a file descriptor that it shouldn't. Greg pointed out earlier that the construct you're trying to use doesn't work well when the shell is not Bash. Are you 100% confident that it is /bin/bash that is running the script and not /bin/sh (and thus maybe something like Dash?). And keep in mind that even Bash running as /bin/sh is not quite the same as Bash running as /bin/bash.
Re: obscure bug "extern void free (void *__ptr) __attribute__ ((__nothrow__ , __leaf__));"
It is /bin/sh which is a symlink to bash on Archlinux. On 1/22/21 12:27 AM, Eduardo Bustamante wrote: Greg pointed out earlier that the construct you're trying to use doesn't work well when the shell is not Bash. Are you 100% confident that it is /bin/bash that is running the script and not /bin/sh (and thus maybe something like Dash?). And keep in mind that even Bash running as /bin/sh is not quite the same as Bash running as /bin/bash.
Re: obscure bug "extern void free (void *__ptr) __attribute__ ((__nothrow__ , __leaf__));"
I will write a report to automake. On 1/22/21 4:01 AM, Chet Ramey wrote: This is why I advised you to report it to bug-autoconf. They're more familiar with the code generator and what problems might result from it.
Feature Request: scanf-like parsing
Another feature request: To parse out simple thing like IP components, you can do something like IFS=. read a b c d <<< "11.22.33.44" But, if data are buried in a mess, then it's very labour-intensive to dig them out. It might be useful to have scanf()-like feature, where stdin or string are read and parsed according to the usual format string. I guess, it would actually be sscanf(), since 'read' builtin reads a line first. Since you're dealing with strings, only %s, %c, and %[] are sufficient. Where it would be used: - everywhere, really everywhere. Advantage: - You can concentrate on "business logic", and less time on bookkeeping. -- William Park
Re: History -r breaks on FIFOs
On 2021/01/21 11:43, Chet Ramey wrote: On 1/21/21 11:18 AM, Merijn Verstraaten wrote: The history command doesn't seem to work when given a FIFO instead of a file. I was trying to load history from FIFO using either 'history -r <(echo "$hist")' or 'echo "$hist" | history -r /dev/stdin', but neither of these seem to work, due to the command being unable to handle FIFOs. Correct. The history file reading code requires the history file be a regular file. This is because the technique it uses to read and process the file (mmap or read the file in one read into a large buffer, then move around in the buffer) doesn't work with non-regular files. There are two stages in readline -- being able to read previous history and then recording to a history file. Isn't it possible to load from one place (which would get copied to the 2nd as older history) and then bash move around to delete dups as needed in the new file?
Re: Feature Request: scanf-like parsing
On 2021/01/21 21:29, William Park wrote: Since you're dealing with strings, only %s, %c, and %[] are sufficient. You can't read numbers in sscanf? _Might_ be nice to be able to read a float as well even though it would need to be access/stored as a string. Would compliment ability to write out a floating point value using %f from a string. Why would you do that? To use the floating point round of printf to get float-vals to round up. Eh, would prolly want to scan it in with 2 integers now that I think about it (before + after decimal).
Re: obscure bug "extern void free (void *__ptr) __attribute__ ((__nothrow__ , __leaf__));"
On Fri, Jan 22, 2021 at 05:05:31AM +0100, Mathias Steiger wrote:
>
> Here is the strace output.
>
> https://filebin.net/9auqyreezma08z12/bug_bash.tar.gz?t=3bjx4xpd
>
> It is very excessive due to the nature of Autoconf and I couldn't make a lot
> of sense of it.
>
>
> When I downgraded the package from bash-5.1.004-1 to bash-5.0.018-2 the bug
> disappeared.
This trace file is quite interesting (redacted for brevity):
$ cat ./strace_if-statement_removed/strace_second.1243868
(...)
openat(AT_FDCWD, "./config.status", O_WRONLY|O_CREAT|O_APPEND, 0666) = 8
dup2(8, 1) = 1
close(8)= 0
openat(AT_FDCWD, "/dev/null", O_RDONLY) = 8
dup2(8, 0) = 0
close(8)= 0
execve("/bin/cat", ["cat"], [(...)]) = 0
(...)
fstat(1, {st_dev=makedev(0xfe, 0x3), st_ino=42548069, st_mode=S_IFREG|0775,
st_nlink=1, st_uid=1006, st_gid=0, st_blksize=4096, st_blocks=32,
st_size=16357, st_atime=1611282495 /* 2021-01-22T03:28:15.296486563+0100 */,
st_atime_nsec=296486563, st_mtime=1611282560 /*
2021-01-22T03:29:20.712747829+0100 */, st_mtime_nsec=712747829,
st_ctime=1611282560 /* 2021-01-22T03:29:20.712747829+0100 */,
st_ctime_nsec=712747829}) = 0
fstat(0, {st_dev=makedev(0, 0x5), st_ino=1728, st_mode=S_IFREG|0666,
st_nlink=1, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=8, st_size=73,
st_atime=1611282495 /* 2021-01-22T03:28:15.243153560+0100 */,
st_atime_nsec=243153560, st_mtime=1611282549 /*
2021-01-22T03:29:09.822815317+0100 */, st_mtime_nsec=822815317,
st_ctime=1611282549 /* 2021-01-22T03:29:09.822815317+0100 */,
st_ctime_nsec=822815317}) = 0
(...)
read(0, "extern void free (void *__ptr) __attribute__ ((__nothrow__ ,
__leaf__));\n", 131072) = 73
write(1, "extern void free (void *__ptr) __attribute__ ((__nothrow__ ,
__leaf__));\n", 73) = 73
read(0, "", 131072) = 0
(...)
This is in essence:
cat ./config.status
These are worth highlighting:
- Notice that the value returned by `fstat(0, ...)' indicates that /dev/null in
your system is a *regular* file (it should be `st_mode=S_IFCHR|0666', but
instead it is `st_mode=S_IFCHR|0666'). It also indicates that its size is 73
bytes (`st_size=73').
- Notice that `cat' reads from file descriptor 0 (i.e. /dev/null), and the
return value is a string of 73 bytes in length.
- `cat' then writes that string out to `./config.status'
73 happens to be the length of the string that has been causing issues for you:
$ echo "extern void free (void *__ptr) __attribute__ ((__nothrow__ ,
__leaf__));" | wc -c
73
Can you run:
stat /dev/null
And share with us what you get?
This is how it should look like:
$ stat /dev/null
File: /dev/null
Size: 0 Blocks: 0 IO Block: 4096 character special
file
Device: 5h/5d Inode: 4 Links: 1 Device type: 1,3
Access: (0666/crw-rw-rw-) Uid: (0/root) Gid: (0/root)
Access: 2021-01-09 15:28:48.589801534 -0800
Modify: 2021-01-09 15:28:48.589801534 -0800
Change: 2021-01-09 15:28:48.589801534 -0800
Birth: -
