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.
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,
M
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 -p
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
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-state
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
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) __attr
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:
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 "27ac5e2f75
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
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
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 specif
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
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=a
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 reprod
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 l
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
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 /b
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.
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
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
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 o
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 pac
23 matches
Mail list logo
