Re: bug attached
On Thu, Aug 31, 2023 at 10:38:55PM +0300, queency3 jones wrote:
> i don't think that main is significant when it declared in "Bash" but even
> though,
> if you change the function main , to function ain the $aa should be local
> , but it ain't !!
Function names being "main" or "ain" is irrelevant (the shell does
not give significance to their name). The scope of the variable "aa"
is global in all functions in your example. If you want a variable
to be local to a function, you need to declare it as such. Note that
declaring a variable as local in your "main" function will give it a
scope that stretches into the called "sub" function. If you want the
changes that "sub" makes to the variable be local to that function, then
you need to declare it as local in "sub", like I showed.
Quoting the manual:
Variables local to the function may be declared with the local
builtin command (local variables). Ordinarily, variables and
their values are shared between the function and its caller.
If a variable is declared local, the variable's visible scope
is restricted to that function and its children (including the
functions it calls).
>
>
> On Wed, Aug 30, 2023 at 5:59 PM Andreas Kusalananda Kähäri <
> andreas.kah...@abc.se> wrote:
>
> > On Wed, Aug 30, 2023 at 03:40:21PM +0300, queency3 jones wrote:
> > >
> >
> > > From: queen...@gmail.com
> > > To: bug-bash@gnu.org
> > > Subject: 2 same var name in different function causing mix
> > >
> > > Configuration Information [Automatically generated, do not change]:
> > > Machine: x86_64
> > > OS: linux-gnu
> > > Compiler: gcc
> > > Compilation CFLAGS: -g -O2
> > -fdebug-prefix-map=/build/bash-2bxm7h/bash-5.0=. -fstack-protector-strong
> > -Wformat -Werror=format-security -Wall -Wno-parentheses -Wno-format-security
> > > uname output: Linux debian 4.19.0-25-amd64 #1 SMP Debian 4.19.289-2
> > (2023-08-08) x86_64 GNU/Linux
> > > Machine Type: x86_64-pc-linux-gnu
> > >
> > > Bash Version: 5.0
> > > Patch Level: 3
> > > Release Status: release
> > >
> > > Description:
> > >
> > > function sub { aa=8;return_value=$aa; }
> > > function sub { aa=8; }
> > >
> > > function main { aa=3;sub;aa=$(($aa+1));printf "$aa\n"; }
> > >
> > >
> > > calling main will print 9 instead of 4
> > >
> > >
> >
> > Not a bug.
> >
> > The code outputs "9" because the scope of the variable "aa" is global
> > (once it has been created in "main"). The second function "sub" will
> > therefore modify the value of the variable "aa" in the global scope.
> > The change in the variabel's value will be visible in "main" after the
> > call to "sub".
> >
> > To make the variable local to the "sub" function, use the "local"
> > keyword:
> >
> > function sub { local aa=8; }
> >
> > This will create a local variable "aa" in the function "sub" that will
> > not be visible outside of the function. In particular, it will not
> > overwrite the global variable "aa" in "main" and the value of "aa" in
> > "main" will remain unchanged (until you increment it from "3" to "4").
> >
> > On an unrelated note, you sohuld be printing the value using a static
> > formatting string, like so:
> >
> > printf '%s\n' "$aa"
> >
> > This avoids interpreting the value of the variable as a printf formatting
> > string.
> >
> > --
> > Andreas (Kusalananda) Kähäri
> > SciLifeLab, NBIS, ICM
> > Uppsala University, Sweden
> >
> > .
> >
--
Andreas (Kusalananda) Kähäri
SciLifeLab, NBIS, ICM
Uppsala University, Sweden
.
Re: bug attached
On Wed, Aug 30, 2023 at 03:40:21PM +0300, queency3 jones wrote:
>
> From: queen...@gmail.com
> To: bug-bash@gnu.org
> Subject: 2 same var name in different function causing mix
>
> Configuration Information [Automatically generated, do not change]:
> Machine: x86_64
> OS: linux-gnu
> Compiler: gcc
> Compilation CFLAGS: -g -O2 -fdebug-prefix-map=/build/bash-2bxm7h/bash-5.0=.
> -fstack-protector-strong -Wformat -Werror=format-security -Wall
> -Wno-parentheses -Wno-format-security
> uname output: Linux debian 4.19.0-25-amd64 #1 SMP Debian 4.19.289-2
> (2023-08-08) x86_64 GNU/Linux
> Machine Type: x86_64-pc-linux-gnu
>
> Bash Version: 5.0
> Patch Level: 3
> Release Status: release
>
> Description:
>
> function sub { aa=8;return_value=$aa; }
> function sub { aa=8; }
>
> function main { aa=3;sub;aa=$(($aa+1));printf "$aa\n"; }
>
>
> calling main will print 9 instead of 4
>
>
Not a bug.
The code outputs "9" because the scope of the variable "aa" is global
(once it has been created in "main"). The second function "sub" will
therefore modify the value of the variable "aa" in the global scope.
The change in the variabel's value will be visible in "main" after the
call to "sub".
To make the variable local to the "sub" function, use the "local"
keyword:
function sub { local aa=8; }
This will create a local variable "aa" in the function "sub" that will
not be visible outside of the function. In particular, it will not
overwrite the global variable "aa" in "main" and the value of "aa" in
"main" will remain unchanged (until you increment it from "3" to "4").
On an unrelated note, you sohuld be printing the value using a static
formatting string, like so:
printf '%s\n' "$aa"
This avoids interpreting the value of the variable as a printf formatting
string.
--
Andreas (Kusalananda) Kähäri
SciLifeLab, NBIS, ICM
Uppsala University, Sweden
.
Re: IFS field splitting doesn't conform with POSIX
On Thu, Mar 30, 2023 at 10:51:58AM -0600, Felipe Contreras wrote: > On Thu, Mar 30, 2023 at 10:10 AM Oğuz İsmail Uysal > wrote: > > > > On 3/30/23 2:12 PM, Felipe Contreras wrote: > > > IFS=, > > > str='foo,bar,,roo,' > > > printf '"%s"\n' $str > > zsh is the only shell that generates an empty last field, no other shell > > exhibits this behavior. > > So? This is argumentum ad populum. The fact that most shells do X > doesn't imply that POSIX says X. > > It could very well mean that all shells are implementing POSIX wrong. > Except zsh. Without getting into this *specific* issue: That's not how POSIX works. POSIX standardises existing practices. Cheers, A > Or it could mean POSIX doesn't specify which behavior is correct. > > > Besides your link says: > > >The shell shall treat each character of the IFS as a delimiter and use > > the delimiters as *field >terminators* to split the results of parameter > > expansion, command substitution, and arithmetic >expansion into fields. > > > > So the delimiters terminate fields, not separate them. > > Yes. 'foo,bar,' has two terminators, and therefore two fields. > 'foo,bar,roo' has two terminators and therefore two fields, plus > garbage. > > You want to interpret 'foo' as a field, even though it does not have > an an explicit terminator. But that's not specified anywhere in POSIX. > > POSIX doesn't say what should be done with the text after the last > terminator. You could throw it away and still be conforming to POSIX. > > -- > Felipe Contreras -- Andreas (Kusalananda) Kähäri SciLifeLab, NBIS, ICM Uppsala University, Sweden .
Re: "trap" output from "if" statement redirected wrongly
On Wed, Apr 13, 2022 at 02:58:30PM +0200, Frank Heckenbach wrote: > 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 mars 5.10.0-12-amd64 #1 SMP Debian 5.10.103-1 > (2022-03-07) x86_64 GNU/Linux > Machine Type: x86_64-pc-linux-gnu > > Bash Version: 5.1 > Patch Level: 16 > Release Status: release > > Description: > > This script writes "foo" to bar rather than stdout as I'd expect. > > It's triggered by the "if" statement (which doesn't even cause > running in a subshell, so it's not that). > > #!/bin/bash > set -e > trap 'echo foo' 0 > #false > bar # "foo" written to stdout correctly > if true; then false; else false; fi > bar # "foo" written to bar The POSIX standard says to execute the EXIT trap in the same environment as the last command executed in the script (that first "false"). I believe that the current state of the standard streams is part of what is included in "the environment". The environment in which the shell executes a trap on EXIT shall be identical to the environment immediately after the last command executed before the trap on EXIT was taken. (from https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#trap) A trap on 0 is identical to a trap on EXIT. -- Andreas (Kusalananda) Kähäri SciLifeLab, NBIS, ICM Uppsala University, Sweden .
Re: "~~" and "~" case-toggling modification undocumented
On Tue, Apr 05, 2022 at 10:58:33AM -0400, Chet Ramey wrote:
> On 4/5/22 10:49 AM, Andreas Kusalananda Kähäri wrote:
> > When the ",", ",,", "^", and "^^" case-modifying operators were
> > introduced with Bash 4.0 some 13 years ago, the operators "~" and "~~"
> > were also introduced. These toggle the case of the first character that
> > match the pattern ("~") or the all characters that match the pattern
> > ("~~") in a similar manner as up-casing and down-casing is done with "^"
> > and ",".
> >
> > However, as far as I can see, the case-toggling operators remain
> > undocumented.
>
> https://lists.gnu.org/archive/html/bug-bash/2019-08/msg1.html
>
> --
> ``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/
Much thanks.
--
Andreas (Kusalananda) Kähäri
SciLifeLab, NBIS, ICM
Uppsala University, Sweden
.
"~~" and "~" case-toggling modification undocumented
When the ",", ",,", "^", and "^^" case-modifying operators were
introduced with Bash 4.0 some 13 years ago, the operators "~" and "~~"
were also introduced. These toggle the case of the first character that
match the pattern ("~") or the all characters that match the pattern
("~~") in a similar manner as up-casing and down-casing is done with "^"
and ",".
However, as far as I can see, the case-toggling operators remain
undocumented.
I wonder if this is on purpose due to some instability or other
deficiency in the code, or whether it's an oversight (hence this bug
report).
--
Andreas (Kusalananda) Kähäri
SciLifeLab, NBIS, ICM
Uppsala University, Sweden
.
Re: command line not saved after "event not found" error
On Sun, Feb 20, 2022 at 05:38:06PM +0100, Andrea Monaco wrote: > > Hello, > > > on my bash 5.0.3, when I input > > $ foo!\ > > I get "bash: !\: event not found", which I think is appropriate, but the > line doesn't get saved in history. The same doesn't happen for other > errors, for example "command not found". > > Is this behavior intended? > > > > Let me know, > > Andrea Monaco It's not that it's the error that prevents the command from being saved in the shell's history, it's the fact that it is a history expansion (albeit a failed one). History expansions are not saved in the history. If history expansions, like !! to execute the most recent command in history, was saved to the shell's command history, then what would the shell execute if you entered !! for the secand time in a row? -- Andreas (Kusalananda) Kähäri SciLifeLab, NBIS, ICM Uppsala University, Sweden .
Re: Bash not escaping escape sequences in directory names
On Wed, Jan 26, 2022 at 12:26:05AM -0800, L A Walsh wrote: > On 2022/01/22 12:48, Andreas Kusalananda Kähäri wrote: > > The shell even keeps the PS1 variable's value from its inherited > > environment > > without sanitizing it. > > > > This is a requirement of the unix/posix model that has 'fork' > > create a new process that is a new unfiltered, unsanitized copy of the > original. > > All memory, not just environment vars are exact copies of the > parent. > > If a child process did not contain an exact copy of its parent after > a fork, it would be a serious problem. > > What you are insinuating as a problem "the shell even keeps the PS1 > variable's value from its inherited environment without sanitizing it", > is a requirement not just for PS1, but all memory. > > If you don't like that feature, you move to an entirely different > OS -- like 'NT' (at base of windows), where new processes are created > by a special OS-function that has no automatic importation of anything > from the previous process. Everything is created 'anew' with nothing > in the new process being automatically inherited from the previous process. > > If a shell or any process didn't inherit it's parent's memory, it would be > a serious error. > > > You seem to misunderstand my comment, and I'm not entirely sure whether you choose to do that on purpose to try to make it sound like I don't know how environment variables work, or if I was genuinely unclear. Just like IFS is reset to a predefined value for a new shell session (required to be so by POSIX), so could PS1 be. In fact, POSIX explicitly says that "$ " shall be the default value of PS1, but does not say that it needs to be reset to this value for new shells. As you may read in other parts of this thread, I'm no longer pursuing this though. But for you, I could be convinced to discuss the nature of environment variables, and the fact that the shell *could* reset the value of PS1 if it was present in the inherited environment. -- Andreas (Kusalananda) Kähäri SciLifeLab, NBIS, ICM Uppsala University, Sweden .
Re: Bash not escaping escape sequences in directory names
On Tue, Jan 25, 2022 at 02:24:26AM +0700, Robert Elz wrote: > Date:Mon, 24 Jan 2022 19:53:03 +0100 > From:Andreas Kusalananda =?utf-8?B?S8OkaMOkcmk=?= > > Message-ID: > > | Why would people want it to do that (i.e. export PS1)? > > It isn't exporting PS1 that's the issue, it is importing it. And that > I rely on quite frequently. (Of course, it has to be exported by something > to be imported elsewhere - which gives the reason why one would want to > export PS1). > > Eg: I am often working with several variants of the same basic shell > (various bug fixes, or attempts at them, or new features being developed) > and I want to get some hint of which variant I have running in some particular > window, so when I run test code, and it works, or doesn't, I know which > variant did what). > > To do that, given that they are 99.9% identical shells (including all startup > scripts etc) I just do > > PS1='bugfix1 $ ' /path/to/shell1 > PS1='newfeat $ ' /path/to/shell2 > PS1='standard$ ' /bin/sh > > (in different windows, one for each, of course), then however I move > the windows around, or whatever else I do (aside from changing PS1 > obviously) I always know which variant is running. > > If a shell refused to import PS1, this wouldn't work. > > kre > > This, together with Chet's and Greg's mail; All around good and reasonable things said by people I trust to say sensible things about the shell. Thanks. I'll stand down from my "you need to do something right now" position. Take care, -- Andreas (Kusalananda) Kähäri SciLifeLab, NBIS, ICM Uppsala University, Sweden .
Re: Bash not escaping escape sequences in directory names
On Mon, Jan 24, 2022 at 10:41:32AM -0500, Chet Ramey wrote: > On 1/22/22 3:48 PM, Andreas Kusalananda Kähäri wrote: > > On Sat, Jan 22, 2022 at 01:28:50PM -0500, Chet Ramey wrote: > > > On 1/22/22 5:52 AM, Andreas Kusalananda Kähäri wrote: > > > > On Fri, Jan 21, 2022 at 06:33:02PM -0500, Chet Ramey wrote: > > > > > On 1/21/22 6:13 PM, Mike Jonkmans wrote: > > > > > > On Fri, Jan 21, 2022 at 03:29:47PM -0500, Chet Ramey wrote: > > > > > > > On 1/21/22 1:43 AM, Lawrence Velázquez wrote: > > > > > > > > > > > > > > > Personally, I would be > > > > > > > > less than pleased if my whole terminal turned red just because I > > > > > > > > changed into a directory that happened to have a weird name. > > > > > > > > > > > > > > A mild annoyance at best, don't you think? > > > > > > > > > > > > Mostly an annoyance, but it has potential to be a security issue. > > > > > > > > > > Highly unlikely. It would require an implausible scenario. > > > > > > > > Mind if I use that quote? :-) > > > > > > > > Example of interesting values to test in PS1, with discussions: > > > > > > > > https://security.stackexchange.com/q/56307 > > > > > > They're all about security issues in terminal emulators, or cat, not bash. > > > They don't require bash at all. > > > > I totally agree that this is not a vulnerability in bash (or cat), but > > bash, as opposed to cat, has no requirement to faithfully pass every > > conceivable escape sequence on to the terminal from $PS1. > > I'd say there's a user expectation for that. That's why the \[ and \] > escapes exist. Fair comment. > > The shell > > even keeps the PS1 variable's value from its inherited environment > > without sanitizing it. > > Why would people want bash to second-guess them like that? I was honestly a bit surprised to see bash picking up PS1 from the environment. Why would people want it to do that (i.e. export PS1)? > > > I will look at doing something here to improve the situation, but I'll > > > push > > > back on the notion that this is a security issue with bash. > > > > Sure. Bash is just the vector, a carrier of potentially problematic > > data. Data that is part of the prompt. > > > > Displaying the prompt should not be dangerous. > > And by the same token, `pwd' and `cd' should not be dangerous, right? As > I said in my previous message, there is a legitimate reason to make the > output of the \w and \W escapes visible: not doing so throws off readline's > redisplay. But let's not take this into the ridiculous. The cd and pwd utilities are expected to provide particular output. A system administrator often sets the bash shell's prompt, and having the shell output unwanted escape sequences to the terminal through the prompt may be somewhat of a surprise to users who do not know or care about modifying PS1 in their startup scripts. I would personally be happy if the output of the special built-in formatting codes you mentioned were modified as you suggested. To make the prompt safe would include forcing the user to use a pre-defined set of allowed escapes (e.g., color, as already provided by shells like yash and zsh). I understand if this would be a too big change, as it would undoubtedly break existing setups. -- Andreas (Kusalananda) Kähäri SciLifeLab, NBIS, ICM Uppsala University, Sweden .
Re: Bash not escaping escape sequences in directory names
On Sat, Jan 22, 2022 at 01:28:50PM -0500, Chet Ramey wrote: > On 1/22/22 5:52 AM, Andreas Kusalananda Kähäri wrote: > > On Fri, Jan 21, 2022 at 06:33:02PM -0500, Chet Ramey wrote: > > > On 1/21/22 6:13 PM, Mike Jonkmans wrote: > > > > On Fri, Jan 21, 2022 at 03:29:47PM -0500, Chet Ramey wrote: > > > > > On 1/21/22 1:43 AM, Lawrence Velázquez wrote: > > > > > > > > > > > Personally, I would be > > > > > > less than pleased if my whole terminal turned red just because I > > > > > > changed into a directory that happened to have a weird name. > > > > > > > > > > A mild annoyance at best, don't you think? > > > > > > > > Mostly an annoyance, but it has potential to be a security issue. > > > > > > Highly unlikely. It would require an implausible scenario. > > > > Mind if I use that quote? :-) > > > > Example of interesting values to test in PS1, with discussions: > > > > https://security.stackexchange.com/q/56307 > > They're all about security issues in terminal emulators, or cat, not bash. > They don't require bash at all. I totally agree that this is not a vulnerability in bash (or cat), but bash, as opposed to cat, has no requirement to faithfully pass every conceivable escape sequence on to the terminal from $PS1. The shell even keeps the PS1 variable's value from its inherited environment without sanitizing it. > I will look at doing something here to improve the situation, but I'll push > back on the notion that this is a security issue with bash. Sure. Bash is just the vector, a carrier of potentially problematic data. Data that is part of the prompt. Displaying the prompt should not be dangerous. It's another thing entirely to accidentally mistype a globbing pattern with rm, or purposefully write and/or run a destructive bash script, which must be allowed. -- Andreas (Kusalananda) Kähäri SciLifeLab, NBIS, ICM Uppsala University, Sweden .
Re: Bash not escaping escape sequences in directory names
On Fri, Jan 21, 2022 at 06:33:02PM -0500, Chet Ramey wrote: > On 1/21/22 6:13 PM, Mike Jonkmans wrote: > > On Fri, Jan 21, 2022 at 03:29:47PM -0500, Chet Ramey wrote: > > > On 1/21/22 1:43 AM, Lawrence Velázquez wrote: > > > > > > > Personally, I would be > > > > less than pleased if my whole terminal turned red just because I > > > > changed into a directory that happened to have a weird name. > > > > > > A mild annoyance at best, don't you think? > > > > Mostly an annoyance, but it has potential to be a security issue. > > Highly unlikely. It would require an implausible scenario. Mind if I use that quote? :-) Example of interesting values to test in PS1, with discussions: https://security.stackexchange.com/q/56307 -- Andreas (Kusalananda) Kähäri SciLifeLab, NBIS, ICM Uppsala University, Sweden .
Re: A bug when using bash shell variable
On Thu, Jan 13, 2022 at 11:55:45AM +0100, Kusalananda Kähäri wrote:
>
> When you want to store several separate arguments, do not combine them
> into a single string.
>
> Compare this
>
> args="-a 'hello world' -b '1 * 3'"
> printf '"%s"\n' $args
>
> and
>
> args=( -a 'hello world' -b '1 * 3' )
> printf '"%s"\n' "${args[@]}"
Portably, to shells without arrays:
set -- -a 'hello world' -b '1 * 3'
printf '"%s"\n' "$@"
> Using an unquoted variable causes the shell to split the variable's
> value on spaces, tabs, and newlines (by default, the values in the IFS
> variable). The words generated from this also undergoes filename
> globbing. This is not what you want to do.
>
> Instead, use an array to store the quoted arguments, and then make sure
> that you properly quote the expansion of the array's elements when you
> use it on the command line.
>
> The bug is in your code, not in bash.
>
> See also:
>
> https://unix.stackexchange.com/questions/68694/when-is-double-quoting-necessary
> https://unix.stackexchange.com/questions/444946/how-can-we-run-a-command-stored-in-a-variable
>
> (and others)
>
>
> On Thu, Jan 13, 2022 at 10:13:05AM +, ju nan wrote:
[cut]
--
Andreas (Kusalananda) Kähäri
SciLifeLab, NBIS, ICM
Uppsala University, Sweden
.
Re: A bug when using bash shell variable
When you want to store several separate arguments, do not combine them
into a single string.
Compare this
args="-a 'hello world' -b '1 * 3'"
printf '"%s"\n' $args
and
args=( -a 'hello world' -b '1 * 3' )
printf '"%s"\n' "${args[@]}"
Using an unquoted variable causes the shell to split the variable's
value on spaces, tabs, and newlines (by default, the values in the IFS
variable). The words generated from this also undergoes filename
globbing. This is not what you want to do.
Instead, use an array to store the quoted arguments, and then make sure
that you properly quote the expansion of the array's elements when you
use it on the command line.
The bug is in your code, not in bash.
See also:
https://unix.stackexchange.com/questions/68694/when-is-double-quoting-necessary
https://unix.stackexchange.com/questions/444946/how-can-we-run-a-command-stored-in-a-variable
(and others)
On Thu, Jan 13, 2022 at 10:13:05AM +, ju nan wrote:
> I hava run into some troubles when I use bash shell to execute qemu, here is
> the log.
>
>
>
> 1. Run qemu with arguments directly in bash shell, I use strace to track
> execve syscall, everything goes well
>
> junan@u0:~/Documents/coding/run-riscv-qemu-linux$ strace qemu-system-riscv64
> -nographic -machine virt -kernel ../linux-5.11/arch/riscv/boot/Image -append
> "root=/dev/vda ro console=ttyS0" -drive file=root.ext4,format=raw,id=hd0
> -device virtio-blk-device,drive=hd0
> execve("/usr/bin/qemu-system-riscv64", ["qemu-system-riscv64", "-nographic",
> "-machine", "virt", "-kernel", "../linux-5.11/arch/riscv/boot/Im"...,
> "-append", "root=/dev/vda ro console=ttyS0", "-drive",
> "file=root.ext4,format=raw,id=hd0", "-device",
> "virtio-blk-device,drive=hd0"], 0x7ffc39cda858 /* 58 vars */) = 0
> brk(NULL) = 0x55bb77e2
> arch_prctl(0x3001 /* ARCH_??? */, 0x7ffd61474450) = -1 EINVAL (Invalid
> argument)
> access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or
> directory)
> openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
>
>
> 1. But when I use bash variables to do it again, something wired happend,
> as you can see, the argument "root=/dev/vda ro console=ttyS0" is splited into
> different parts, so qemu did not start successfully 😋
>
>
> junan@u0:~/Documents/coding/run-riscv-qemu-linux$ echo $QEMU
> qemu-system-riscv64
> junan@u0:~/Documents/coding/run-riscv-qemu-linux$ echo $QOPTIONS
> -nographic -machine virt -kernel ../linux-5.11/arch/riscv/boot/Image -append
> "root=/dev/vda ro console=ttyS0" -drive file=root.ext4,format=raw,id=hd0
> -device virtio-blk-device,drive=hd0
>
> junan@u0:~/Documents/coding/run-riscv-qemu-linux$ strace $QEMU $QOPTIONS
> execve("/usr/bin/qemu-system-riscv64", ["qemu-system-riscv64", "-nographic",
> "-machine", "virt", "-kernel", "../linux-5.11/arch/riscv/boot/Im"...,
> "-append", "\"root=/dev/vda", "ro", "console=ttyS0\"", "-drive",
> "file=root.ext4,format=raw,id=hd0", "-device",
> "virtio-blk-device,drive=hd0"], 0x7ffe1e71a928 /* 58 vars */) = 0
> brk(NULL) = 0x5613dfdc4000
>
>
> Thank you all for making so many excellent softwares, and I wish this will
> help to improve the bash shell 😊.
--
Andreas (Kusalananda) Kähäri
SciLifeLab, NBIS, ICM
Uppsala University, Sweden
.
Re: can't unset hash item with specific key
On Sun, Dec 12, 2021 at 08:47:21PM +0100, l.bash...@scarydevilmonastery.net
wrote:
> 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 h2 5.15.0-2-amd64 #1 SMP Debian 5.15.5-1 (2021-11-26)
> x86_64 GNU/Linux
> Machine Type: x86_64-pc-linux-gnu
>
> Bash Version: 5.1
> Patch Level: 12
> Release Status: release
>
> Description:
> making left square bracket char ([) part of the key into a hash causes
> unset to silently fail when trying to unset that specific hash item.
> The position of left square bracket char in the string used as key
> doesn't
> matter. unset also fails when the key is a single [ character.
> Please refer to the following script which attempts to demonstrate this
> quirk.
>
> Repeat-By:
>
> # diagnostic shows remains of hash after attempts to unset single item.
> show() { echo "$1, ${#a[@]} items in a: a['${!a[@]}']=${a['[foo]']}"; }
>
>
> # prepare test scenario
>
> declare -A a # make "a" a hash
> a['[foo]']="bar" # assign "bar" to item keyed [foo]
> show "good" # correctly output item, show correct
> item count
>
>
> # intention is to get rid of the item again, by unsetting the single item,
> not the whole array.
> # several ways of quoting are attempted here
>
> unset "a['[foo]']"# try to remove item
> show "wrong" # can still output item, item still
> counts
>
> unset 'a["[foo]"]'# try to remove item
> show "wrong" # can still output item, item still
> counts
>
> unset 'a[[foo]]' # try to remove item
> show "wrong" # can still output item, item still
> counts
>
> unset "a[[foo]]" # try to remove item
> show "wrong" # can still output item, item still
> counts
>
> unset "a[\[foo]]" # try to remove item
> show "wrong" # can still output item, item still
> counts
>
> unset "a["\[foo]"]" # try to remove item
> show "wrong" # can still output item, item still
> counts
>
> unset "a['['foo]]"# try to remove item
> show "wrong" # can still output item, item still
> counts
>
> a["[foo]"]="" # Best I can currently do
> show "set empty, item still counted" # item still there though contents are
> empty string.
Just to say this unsets the element correctly:
k='[foo]'
unset -v 'a["$k"]'
--
Andreas (Kusalananda) Kähäri
SciLifeLab, NBIS, ICM
Uppsala University, Sweden
.
Re: some unknown bug, says : command not found
On Tue, Nov 02, 2021 at 03:23:15AM +0700, Robert Elz wrote:
> Date:Mon, 1 Nov 2021 12:03:48 -0400
> From:Greg Wooledge
> Message-ID:
>
> | > bash: : command not found
> | > bash: : command not found
> |
> | Because this is you, I can't be sure whether you are correctly pasting
> | the output from your terminal into email,
>
> Actually, because it is him, it is more likely that he has "cat" aliased
> to ' ' somehow, since he loves aliases so much.
>
> kre
>
Looking at their trace output, the thing that causes the error is
'' /dev/fd/63
The /dev/fd/63 bit is probably from a process substitution.
What causes the '' is anyone's guess, and mine is that it's simply a
variable that happens to be unset or empty (possibly due to a mistyping
in its name?)
$ "$my_thnig" <( [[ -s "$pathname" ]] && cat -- "$pathname" )
bash: : command not found
--
Andreas (Kusalananda) Kähäri
SciLifeLab, NBIS, ICM
Uppsala University, Sweden
.
Re: Request change to output of declare -f funcname
On Sat, Oct 02, 2021 at 09:09:39AM -0400, Greg Wooledge wrote:
> On Sat, Oct 02, 2021 at 01:41:35PM +0200, Léa Gris wrote:
> > $ declare -f hello
> >
> > hello ()
> > {
> > echo 'hello';
> > echo 'world'
> > }
> >
> > The issue is that in some circumstances, newline characters may be handled
> > as space, making the function declaration invalid.
>
> Can you show an example where the output of declare -f is invalid?
I don't think their issue is that the output from declare -f is ever
invalid as such, but that their usage of the resulting text involves
replacing newlines with spaces, which turns it into invalid shell code.
--
Andreas (Kusalananda) Kähäri
SciLifeLab, NBIS, ICM
Uppsala University, Sweden
.
Re: Why tail coreutil cannot work as its input is from tee
On Mon, Sep 06, 2021 at 07:38:03AM +, Budi wrote: > How come tail coreutil cannot work as its input is from tee > > $ echo -e '9\n4\n3\n2\n8\n7\n3\n1' |tail -1 > 1 > > But : > > $ echo -e '9\n4\n3\n2\n8\n7\n3\n1' |tee >(head -1) |tail -1 > 9 > > Please help explain I don't see how this is a bug report against the bash shell. Note that the output from your pipeline is non-deterministic: $ echo -e '9\n4\n3\n2\n8\n7\n3\n1' |tee >(head -1) | tail -1 1 $ echo -e '9\n4\n3\n2\n8\n7\n3\n1' |tee >(head -1) | tail -1 9 This is on an OpenBSD system. This depends on whether tee has a chance of outputting the complete data from echo to its standard output first, before the head outputs its data. With GNU tools, I can't get the pipeline to output 1, but I know there's a chance it may eventually output 1 rather than 9. -- Andreas (Kusalananda) Kähäri SciLifeLab, NBIS, ICM Uppsala University, Sweden .
Re: NL character removed after \\ in command substitution
On Tue, Aug 17, 2021 at 08:32:35AM +0200, Kusalananda Kähäri wrote: > On Tue, Aug 17, 2021 at 10:28:16AM +0800, Haojun Bao wrote: > > Configuration Information [Automatically generated, do not change]: > > Machine: x86_64 > > OS: linux-gnu > > Compiler: gcc > > Compilation CFLAGS: -g -O2 > > -fdebug-prefix-map=/build/bash-2bxm7h/bash-5.0=. > > -fstack-protector-strong -Wformat -Werror=format-security -Wall > > -Wno-parentheses -Wno-format-security > > uname output: Linux bhj-pc1 5.10.0-0.bpo.5-amd64 #1 SMP Debian > > 5.10.24-1~bpo10+1 (2021-03-29) x86_64 GNU/Linux > > Machine Type: x86_64-pc-linux-gnu > > > > Bash Version: 5.0 > > Patch Level: 3 > > Release Status: release > > > > Description: > > > > A bug found in parse.y, that will treat reading of COMMAND and > > $(COMMAND) differently, despite the info manual saying that: > > > > > When the old-style backquote form of substitution is used, backslash > > > retains its literal meaning except when followed by '$', '`', or '\'. > > > The first backquote not preceded by a backslash terminates the command > > > substitution. When using the '$(COMMAND)' form, all characters between > > > the parentheses make up the command; none are treated specially. > > > > It seems the NL after \\ will be removed when run as $(COMMAND) in parse.y? > > > > Repeat-By: > > > > This command will output $'hello \\\nworld\n': > > > > cat < > hello \\ > > world > > EOF > > > > This command will output $'hello \\world\n' (missing the \n after \\): > > echo "$( > > cat < > hello \\ > > world > > EOF > > )" > > > Consider quoting the here-document: > > cat <<'EOF' > hello \\ > world > EOF > )" > The initial line saying echo "$( was obviously missing there (copy+paste error), sorry. -- Andreas (Kusalananda) Kähäri SciLifeLab, NBIS, ICM Uppsala University, Sweden .
Re: NL character removed after \\ in command substitution
On Tue, Aug 17, 2021 at 10:28:16AM +0800, Haojun Bao wrote: > Configuration Information [Automatically generated, do not change]: > Machine: x86_64 > OS: linux-gnu > Compiler: gcc > Compilation CFLAGS: -g -O2 > -fdebug-prefix-map=/build/bash-2bxm7h/bash-5.0=. > -fstack-protector-strong -Wformat -Werror=format-security -Wall > -Wno-parentheses -Wno-format-security > uname output: Linux bhj-pc1 5.10.0-0.bpo.5-amd64 #1 SMP Debian > 5.10.24-1~bpo10+1 (2021-03-29) x86_64 GNU/Linux > Machine Type: x86_64-pc-linux-gnu > > Bash Version: 5.0 > Patch Level: 3 > Release Status: release > > Description: > > A bug found in parse.y, that will treat reading of COMMAND and > $(COMMAND) differently, despite the info manual saying that: > > > When the old-style backquote form of substitution is used, backslash > > retains its literal meaning except when followed by '$', '`', or '\'. > > The first backquote not preceded by a backslash terminates the command > > substitution. When using the '$(COMMAND)' form, all characters between > > the parentheses make up the command; none are treated specially. > > It seems the NL after \\ will be removed when run as $(COMMAND) in parse.y? > > Repeat-By: > > This command will output $'hello \\\nworld\n': > > cat < hello \\ > world > EOF > > This command will output $'hello \\world\n' (missing the \n after \\): > echo "$( > cat < hello \\ > world > EOF > )" Consider quoting the here-document: cat <<'EOF' hello \\ world EOF )" -- Andreas (Kusalananda) Kähäri SciLifeLab, NBIS, ICM Uppsala University, Sweden .
Re: set -x path always returns 1 on fedora34 on arm64
On Wed, May 12, 2021 at 04:31:47PM +0800, Boleyn Su wrote: > Sorry, it is test -x instead of set -x. There are similar results for test > - r file, [ -r file] and so on. If "[ -r file]" is your code, then it fails because the "[" utility needs "]" as its last argument, and you are giving it "file]". Insert a space before that last "]". If that is not the code you are using, then consider posting the code you are using. If you don't, we can only really say "it works for me". > > On Wed, May 12, 2021, 13:34 Boleyn Su wrote: > > > Please refer to the subject. > > -- Andreas (Kusalananda) Kähäri SciLifeLab, NBIS, ICM Uppsala University, Sweden .
Re: syntax error while parsing a case command within `$(...)'
On Sun, Feb 14, 2021 at 12:02:02AM +0100, Andreas Schwab wrote:
> On Feb 14 2021, Robert Elz wrote:
>
> > Date:Sat, 13 Feb 2021 23:21:36 +0300
> > From:=?UTF-8?B?T8SfdXo=?=
> > Message-ID:
> >
> >
> > | $ bash -c ': $(case x in x) esac)'
> >
> > This is a well known bash deficiency. When parsing command substitutions
> > it (approximately) simply counts (unquoted) parentheses to find the end.
> > Anything with a valid closing ')' but with no opening '(' confuses it.
>
> Bash already handles that properly, when the compound-list is non-empty.
>
> $ bash -c ': $(case x in x) :; esac)'
>
> Andreas.
And using (x) doesn't help:
% bash -c ': $(case x in (x) esac)'
bash: -c: line 1: unexpected EOF while looking for matching `)'
bash: -c: line 2: syntax error: unexpected end of file
--
Andreas (Kusalananda) Kähäri
SciLifeLab, NBIS, ICM
Uppsala University, Sweden
.
Re: syntax error while parsing a case command within `$(...)'
On Sat, Feb 13, 2021 at 03:41:30PM -0500, Lawrence Velázquez wrote: > > On Sat, Feb 13, 2021, 21:34 Alex fxmbsw7 Ratchev wrote: > > > > you didnt end the case, wrong syntax > > echo $( case x in y) printf 1 ;; x) printf 2 ;; esac ) > > $ case x in x) esac > $ echo $? > 0 > > > On Feb 13, 2021, at 3:36 PM, Alex fxmbsw7 Ratchev wrote: > > > > you have to specify something for ) even when its just a * wildcard > > Oğuz did specify a pattern. It's the second 'x'. > > vq .. but he never had to: % bash -c 'case x in esac; echo $?' 0 -- Andreas (Kusalananda) Kähäri SciLifeLab, NBIS, ICM Uppsala University, Sweden .
Re: 'Find' inside loop buggy, incorrectly make up dir.
On Fri, Jan 01, 2021 at 06:12:32PM +0700, Budi wrote:
> find or bash or anything has made a bit buggy behavior
>
> for n in dircopy dircopy1 ;{
>
> sudo find /usr/bin /usr/local -regextype posix-extended -iregex
> '.*|.*' '(' -type d '(' -path '* *' -printf ''\''%p/'\''\n' -o -printf
> '%p/\n' ')' -o '(' -path '* *' -printf ''\''%p'\''\n' -o -printf
> '%p\n' ')' ')' -exec cp -r '{}' "$n" ';'
>
> }
>
> find make up bin dir. inside dircopy and target results are put there
> instead of on dircopy
This has nothing to do with the bash shell. It is also not surprising
that you get strange results as you are recursively copying every found
directory into your two directories dircopy and dircopy1.
That is, you copy /usr/local into dircopy recursively, then you copy
/usr/local/share into dircopy (even though it's already been copied),
then you copy /usr/local/bin etc. In some cases, depending on a file's
depth, you would copy the same files many many times.
Also note that -regextype posix-extended -iregex .*|.*' just means
"every name" since the given pattern would match all possible filenames.
Your -printf arguments contain empty strings (the first '' can be
removed from both), and they can be simplified into -printf "'%p/'\n"
and -print "'%p'\n".
Unfortunately, it's unclear what it is you really want to achieve, but
this is not the list to discuss it as it has nothing to do with bash.
You may want to try https://unix.stackexchange.com/ or some similar
place instead.
--
Andreas (Kusalananda) Kähäri
SciLifeLab, NBIS, ICM
Uppsala University, Sweden
.
Re: Checking executability for asynchronous commands
On Fri, Dec 25, 2020 at 10:40:17AM +0100, Markus Elfring wrote: > Hello, > > I am looking for another bit of clarification according to an implementation > detail. > > The manual is providing the following information. > https://git.savannah.gnu.org/cgit/bash.git/tree/doc/bash.1?id=76404c85d492c001f59f2644074333ffb7608532#n627 > > “… >If a command is terminated by the control operator &, the shell > executes the command in the background in a subshell. The shell does not > wait for the command to finish, and the >return status is 0. > …” > > > Thus I observe a behaviour like the following for a simple test with the > software “bash 5.0.18-3.1” according to a “program” which does not exist here. > > elfring@Sonne:~> xy & > [1] 4063 > xy: Befehl nicht gefunden > [1]+ Exit 127xy > > > I imagine that it can be occasionally helpful to determine the execution > failure > in the synchronous way. > Would it make sense to configure the error reporting for selected asynchronous > commands so that they would become background processes only after the > required > check for executability? How would you propose that the shell handle something like the following? ( cmd1 && cmd2 ) & Are you maybe saying cmd & should be a special case? -- Andreas (Kusalananda) Kähäri SciLifeLab, NBIS, ICM Uppsala University, Sweden .
Re: find len of array w/name in another var...(bash 4.4.12)
On Tue, Oct 20, 2020 at 12:58:36AM -0700, L A Walsh wrote:
> There's got to be an easier way to do this, but not remembering or finding
> it:
>
> First tried the obvious:
> declare -a ar1=([0]="1" [1]="2" [2]="3" [3]="44")
> an=ar1
> echo ${#!an[@]}
> -bash: ${#!an[@]}: bad substitution
>
> This works but feels kludgy
>
> an=ar1
> eval echo \${#$an[@]}
> 4
>
>
> I thought the !name was supposed to take the place
> of using $an, but haven't seen a case where !an works where
> an points to an array name.
>
> Is there a place in the bash manpage that gives an example of using !name
> where name points to an array?
>
> Thanks...
> -l
>
>
In bash 4.3+, I would manke your "ar" variable a name reference variable
instead:
$ ar1=(1 2 3 44)
$ declare -n ar=ar1
$ echo "${#ar[@]}"
4
--
Andreas (Kusalananda) Kähäri
SciLifeLab, NBIS, ICM
Uppsala University, Sweden
.
Re: Create an alias on the fly?
On Mon, Mar 30, 2020 at 04:24:07AM -0400, Jeffrey Walton wrote: > Hi Everyone, > > I'm testing some software from Master. My testing machines sometimes > lack the distro tools like makeinfo. It results in things like this: > > ./bootstrap: 255: makeinfo: not found > ./bootstrap: Error: 'makeinfo' not found > > I tried the MAKEINFO=true tricks but they did not work. > > How can I create an alias on the fly using code like this in Bash? > > if ! ./bootstrap; > then > echo "Failed to bootstrap Wget2" > exit 1 > fi > > Thanks in advance. This does not seem to be a bug in the bash shell. Maybe you meant to post this the help-bash list? Also, why not just install the prerequisites for the software you're building? -- Andreas (Kusalananda) Kähäri SciLifeLab, NBIS, ICM Uppsala University, Sweden .
Re: bash 5.0.11 – Output not redirected
On Thu, Feb 27, 2020 at 09:39:35AM +0200, Ricky Tigg wrote: > Hey. Goal: scheduling tasks along with visual output in terminal. I > concieved it could be achieved under Linux. I had defined a use-case for > that purpose.. > > $ at -q c now + 1 minute > warning: commands will be executed using /bin/sh > at> dnf check-update --security | gnome-terminal > at> > job 24 at Thu Feb 27 09:35:00 2020 This is not a bash bug and has nothing to do with bash. I don't use X and hence know very little about gnome-terminal, but an ordinary terminal (such as xterm) may take a command to execute with e.g. xterm -e 'dnf check-update --security' Whether this would work with gnome-terminal, I don't know. I also don't know whether at would be able to open a terminal window on your display from one of its jobs. Note that this is totally unrelated to whatever shell you happen to be running. -- Andreas (Kusalananda) Kähäri SciLifeLab, NBIS, ICM Uppsala University, Sweden .
Re: Backslash missing in brace expansion
On Sun, Dec 08, 2019 at 11:00:03AM +0100, Martin Schulte wrote:
> Hello,
>
> thanks a lot for all the answers!
>
> I would like to suppose (Ilkka already argued in this direction) that in
> future versions of bash {x..C} should expand to x y z A B C.
>
> Best regards,
>
> Martin
Another idea would be to treat {x..C} just like {1..C} would be treated,
i.e as not a brace expansion at all but just as the literal string
{x..C}.
The current brace expansion impelementation in bash requires both points
of a range to be "of the same type". This currently means "both must be
numbers, or both must be characters", but that second part could be made
stronger: "both must be characters with the same case".
It's obviously far too late to do anything about this at this point in
time.
--
Andreas (Kusalananda) Kähäri
SciLifeLab, NBIS, ICM
Uppsala University, Sweden
Re: make install failed; dump core in mkdir
On Mon, Dec 02, 2019 at 08:51:27AM -0500, Greg Wooledge wrote:
> On Sun, Dec 01, 2019 at 03:20:54PM +, George R Goffe via Bug reports for
> the GNU Bourne Again SHell wrote:
> > mkdir ()
> > {
> > dirs="$@";
> > for dir in $dirs;
> > do
> > /bin/mkdir -p "$dir";
> > done
> > }
>
> This function is severely flawed. I believe this is what you wanted:
>
> mkdir() {
> command mkdir -p "$@"
> }
The original function, with a loop, may have been written to avoid
an error on getting a too long list of arguments. The loop can be
re-introduced in Greg's code like this:
mkdir_p () {
local dirpath
for dirpath do
command mkdir -p "$dirpath" || return
done
}
This would additionally stop as soon as there was an issue with creating
any of the directories (for example, due to permissions) and return the
exit status of the failing "mkdir -p".
mkdir_p () {
local dirpath err
err=0
for dirpath do
command mkdir -p "$dirpath" || err=$?
done
return "$err"
}
This would not stop at the first error, but would return the the most
recently failing mkdir's exit status to the caller if it failed to
create one or more of the directories.
I believe both alternatives are allowed in the mkdir POSIX description.
Regards,
Kusalananda
>
> Your function smashes an array into a string (using first-char-of-IFS
> as a delimiter), then breaks up that string using IFS, which may or
> may not reproduce the original array. There's no reason for that
> double conversion at all. On top of that, your function messes with
> two variables that aren't local to it.
>
> Either of those flaws could conceivably break a script that uses this
> function unexpectedly.
>
> Another way your function could break a script is if the script is
> *counting* on mkdir to perform the atomic make-or-fail-trying
> operation (no -p option), for example when trying to create a directory
> as a form of mutual exclusion locking. Adding -p breaks that usage
> of mkdir. Granted, I find it unlikely that a "make install" operation
> would be using mkdir in that highly specific way. But just in general,
> altering the basic operations of the core shell utilities is unwise.
--
Andreas (Kusalananda) Kähäri
SciLifeLab, NBIS, ICM
Uppsala University, Sweden
Re: declare -g reports as invalid option on MacOS (10.14.6) Bash (5.0.11)
On Fri, Aug 30, 2019 at 06:03:37PM -0600, Ray Sutton wrote: > Firstly apologies for not using bashbug, I'm having an issue on a > machine I'm rebuilding and don't have email readily available yet > > The issue is on a late 2013 MBP running MacOS 10.14.6 and > bash -version reports 5.0.11(1)-release (x86-64-apple-darwin18.6.0) > > The error is occuring in my .bash_profile and reports as > > -bash: declare: -g: invalid option > declare usage: declare [-afFirtx] [-p] [name[=value]...] > > Which does not agree with the man page. > > My work MBP (mid 2014) is running exactly the same version of both > MacOS and bash, the problem doesn't occur there > > In both cases bash was installed via brew. > > The behavior seems consistent with the original bash 3 declare > statement persisting after the bash 5 install which seems unlikely. > > Any Advice on how to fix this issue? > > Thanks > > Ray Sutton > It seems likely that you are in fact running /bin/bash (3.2.57(1)-release, from the macOS base system) instead of /usr/local/bin/bash (5.0.11(1)-release, current bash from Homebrew). How do you start your bash login shell?
Re: Functions that update themselves
On Mon, Jun 03, 2019 at 03:54:59PM +0800, konsolebox wrote:
> Hi Chet,
>
> Do you explicitly allow functions to do this? I just want to know.
>
> a() { a() { ...; }; a; }
> b() { unset -f b; command b "$@"; }
>
> My current use case for this is to have a function simplify itself
> when condition checks are no longer necessary and just adds
> unnecessary runtime load. I also had many other previous ones.
>
> --
> konsolebox
This does not seem to be a bug report. Maybe you meant to send this to
the help-bash list?
--
Kusalananda
Sweden
Re: bash bug - unexpect file deleted using rm command
On Tue, May 28, 2019 at 04:43:42PM +0200, Andreas Kusalananda Kähäri wrote: > On Tue, May 28, 2019 at 11:56:04AM +, r...@minigeek.srve.com wrote: > > Configuration Information [Automatically generated, do not change]: > > Machine: x86_64 > > OS: linux-gnu > > Compiler: gcc > > Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' > > -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-redhat-linux-gnu' > > -DCONF_VENDOR='redhat' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' > > -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -D_GNU_SOURCE > > -DRECYCLES_PIDS -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions > > -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -fwrapv > > uname output: Linux minigeek.srve.com 2.6.32-754.10.1.el6.x86_64 #1 SMP Tue > > Jan 15 17:07:28 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux > > Machine Type: x86_64-redhat-linux-gnu > > > > Bash Version: 4.1 > > Patch Level: 2 > > Release Status: release > > > > Description: > > I deleted the file .DS_Store fom a fat32 partition as root. bash > > properly warned me and I answered y which deleted that file. > > A second different file, named ._.DS_Store was also erased - but > > without warning, and I did not ask for this. > > Therein lies the bug. > > I recreated two text files with different contents having those same > > names, and repeated the steps - same problem - both files got erased with > > the one rm command for just one of them. > > > > Repeat-By: > > Create those 2 files. Delete just one. > > > > Fix: > > probably some shell filename matching code has an error? > > > > > > What was your actual command when deleting the file(s)? If no filename > globbing pattern was used, then I think the shell can be ruled out as > the culprit. If a globbing pattern was used, e.g. .*DS_Store .DS_Store Sorry, that last line got mangled by vim. That should read: If a globbing pattern was used, then there may be an issue with the pattern rather than with the shell. > > $ touch .DS_Store ._.DS_Store > $ ls -la > total 8 > drwx-- 2 kkwheel 512 May 28 16:41 . > drwxrwxrwt 7 root wheel 512 May 28 16:41 .. > -rw-r--r-- 1 kkwheel0 May 28 16:41 .DS_Store > -rw-r--r-- 1 kkwheel0 May 28 16:41 ._.DS_Store > $ rm .DS_Store > $ ls -la > total 8 > drwx-- 2 kkwheel 512 May 28 16:41 . > drwxrwxrwt 7 root wheel 512 May 28 16:41 .. > -rw-r--r-- 1 kkwheel0 May 28 16:41 ._.DS_Store > > Note that bash, the shell, would not warn you about deleting files. > This may possibly be something that rm does if used with its -i option, > or under some other circumstances having to do with the permissions on > the files. > > -- > Kusalananda > Sweden -- Kusalananda Sweden
Re: bash bug - unexpect file deleted using rm command
On Tue, May 28, 2019 at 11:56:04AM +, r...@minigeek.srve.com wrote: > Configuration Information [Automatically generated, do not change]: > Machine: x86_64 > OS: linux-gnu > Compiler: gcc > Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' > -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-redhat-linux-gnu' > -DCONF_VENDOR='redhat' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' > -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -D_GNU_SOURCE > -DRECYCLES_PIDS -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions > -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -fwrapv > uname output: Linux minigeek.srve.com 2.6.32-754.10.1.el6.x86_64 #1 SMP Tue > Jan 15 17:07:28 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux > Machine Type: x86_64-redhat-linux-gnu > > Bash Version: 4.1 > Patch Level: 2 > Release Status: release > > Description: > I deleted the file .DS_Store fom a fat32 partition as root. bash > properly warned me and I answered y which deleted that file. > A second different file, named ._.DS_Store was also erased - but > without warning, and I did not ask for this. > Therein lies the bug. > I recreated two text files with different contents having those same > names, and repeated the steps - same problem - both files got erased with the > one rm command for just one of them. > > Repeat-By: > Create those 2 files. Delete just one. > > Fix: > probably some shell filename matching code has an error? > > What was your actual command when deleting the file(s)? If no filename globbing pattern was used, then I think the shell can be ruled out as the culprit. If a globbing pattern was used, e.g. .*DS_Store .DS_Store $ touch .DS_Store ._.DS_Store $ ls -la total 8 drwx-- 2 kkwheel 512 May 28 16:41 . drwxrwxrwt 7 root wheel 512 May 28 16:41 .. -rw-r--r-- 1 kkwheel0 May 28 16:41 .DS_Store -rw-r--r-- 1 kkwheel0 May 28 16:41 ._.DS_Store $ rm .DS_Store $ ls -la total 8 drwx-- 2 kkwheel 512 May 28 16:41 . drwxrwxrwt 7 root wheel 512 May 28 16:41 .. -rw-r--r-- 1 kkwheel0 May 28 16:41 ._.DS_Store Note that bash, the shell, would not warn you about deleting files. This may possibly be something that rm does if used with its -i option, or under some other circumstances having to do with the permissions on the files. -- Kusalananda Sweden
Re: Backslash mysteriously disappears in command expansion when unescaping would reference an existing file
On Wed, May 22, 2019 at 05:34:22PM +, Charles-Henri Gros wrote:
[cut]
> The problem I'm trying to solve is to iterate over regex-escaped file
> names obtained from a "find" command. I don't know how to make this
> work. It works with other versions of bash and with other shells.
>
> The original is closer to something like this:
>
> for file in $(find ... | sed 's/\$/\\$/g'); do grep -e "$file"
> someinput; done
You may want to use "grep -F" to match fixed strings (not regular
expressions):
find ... -exec grep -F -e {} someinput \;
Add -x to grep if you want full line matches only.
Tis is assuming you'd want to look for the found pathnames in
"someinput".
>
> It used to work. Now it doesn't. I do not know how to make it work again.
>
>
> --
> Charles-Henri Gros
>
--
Kusalananda
Sweden
Re: "here strings" and tmpfiles
On Thu, Apr 11, 2019 at 09:01:50PM +0800, konsolebox wrote: > On Thu, Apr 11, 2019, 4:04 PM Andreas Schwab wrote: > > > On Apr 10 2019, Daniel Kahn Gillmor wrote: > > > > > data written to the local filesystem can be discovered by someone > > > analyzing the disk controller data path, or by someone with access to > > > the underlying storage medium. > > > > Do you have swap enabled? > > > > It's 2019. > > -- > konsolebox The point of Andreas' comment is, I presume, that if you have swap enabled, sensitive data may be written to that swap, either in low memory situations or when hibernating your laptop. Discussion about whether temporary files are used or not for certain operations becomes less interesting if the data anyway runs the risk of being written to an unencypted swap. It implicitly also gives the hint that using an encrypted temporary storage area may be considered by those with such needs (because they would hopefully already have thought about enabling some form of encryption of their swap partition or swap files). I'm sorry for adding to this overly long thread. Regards, -- Andreas Kusalananda Kähäri, National Bioinformatics Infrastructure Sweden (NBIS), Uppsala University, Sweden.
Re: [doc] missing doc about :+ vs + expansion
On Mon, Mar 25, 2019 at 11:19:08AM +0100, Christophe Lyon wrote: > Hi, > > I think I've noticed a bit of explanation missing in the documentation > about parameter expansion. > > bash supports :+ and + expansion, but 'man bash' describes the former only. > This is also true for the similar expansions (:-, :=, :?) > > Some documentation is available at: > http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_06_02 > and > https://www.tldp.org/LDP/abs/html/parameter-substitution.html > > Thanks, > > Christophe It is not omitted. The paragraph before the list of parameters expansions in the manual reads When not performing substring expansion, using the forms documented below (e.g., :-), bash tests for a parameter that is unset or null. Omitting the colon results in a test only for a parameter that is unset. Regards, -- Andreas Kusalananda Kähäri, National Bioinformatics Infrastructure Sweden (NBIS), Uppsala University, Sweden.
Re: Unable to dereference function-local nameref to global variable of same name
On Fri, Aug 12, 2016 at 09:34:40AM -0400, Chet Ramey wrote: > On 8/10/16 12:06 PM, Andreas Kusalananda Kähäri wrote: > > > Bash Version: 4.3 > > Patch Level: 46 > > Release Status: release > > > > Description: > > When declaring a variable in a function as a nameref, it can not > > be dereferenced if the variable it's a nameref to happen to have > > the same name as the nameref itself. This imposes unnecessary > > restrictions on the caller. > > There was extensive discussion about namerefs on bug-bash earlier this > year. I have a reasonable suggestion about how to change this behavior, > and I will be looking at it after bash-4.4 is released. Thanks Chet. I'm mostly a ksh user, and the background to my report above is that I was trying to make a tiny library of shell functions for manipulating PATH-like shell variables available to bash users while still maintaining functionality in both shells. All functions were using a local nameref called "var" and the issue came up when one function tried to use one of the others. My workaround is currently to slightly obfuscate the name of the local nameref previously called "var" in each function so that their names won't clash within the library and so that it's less likely that they clash with global variables in the shell. I'm looking forward to a future bash release! Regards, signature.asc Description: PGP signature
Unable to dereference function-local nameref to global variable of same name
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: openbsd6.0
Compiler: cc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='openbsd6.0' -DCONF_MACHTYPE='x86_64-unknown-openbsd6.0'
-DCONF_VENDOR='unknown' -DLOCALEDIR='/usr/local/share/locale' -DPACKAGE='bash'
-DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -DUSE_MKTEMP
-DUSE_MKSTEMP -I/usr/local/include -O2 -pipe
uname output: OpenBSD uerfale 6.0 GENERIC.MP#38 amd64
Machine Type: x86_64-unknown-openbsd6.0
Bash Version: 4.3
Patch Level: 46
Release Status: release
Description:
When declaring a variable in a function as a nameref, it can not
be dereferenced if the variable it's a nameref to happen to have
the same name as the nameref itself. This imposes unnecessary
restrictions on the caller.
Also seen in GNU bash, version 4.3.39(1)-release (x86_64-apple-darwin15).
Repeat-By:
function bug {
typeset -n var="$1"
printf "%s\n" "$var"
}
var="hello"
bug var
Result:
bash: warning: var: circular name reference
Expected result: The string "hello" outputted with a terminating
newline (as with ksh93).
