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.