Hello Lawrence!
Am Fri, 30 May 2025 04:53:06 -0400 schrieb Lawrence Velázquez :
> Your example commands demonstrate something else. The command
>
> PATH=~/foo:~/bar
>
> has always assigned a value like '/myhome/foo:/myhome/bar', POSIX
> mode or not. This is broken in bash 5.1 POSIX mode
Hello,
https://www.gnu.org/software/bash/manual/bash.html#Bash-POSIX-Mode says:
19. Literal tildes that appear as the first character in elements of the PATH
variable are not expanded as described above under Tilde Expansion.
Is this no longer true from version 5.2 on?
$ bash--posix -c
Hello Ethan,
I can't reproduce the problem:
> Repeat-By:
> Open a terminal with bash as the shell
> Type `;exit`
This results in
bash: syntax error near unexpected token `;'
but not in closing the shell.
> Re-open the terminal, it will immediately close
Is there maybe
Hello,
in 9.3.2 of https://www.gnu.org/software/bash/manual/bash.html we find:
!!:$ designates the last argument of the preceding command. This may be
shortened to !$.
Shouldn't this be "the last word" instead of the "the last argument":
$ echo hello > /dev/null
$ echo !!:$
echo /dev/null
/dev
Sorry, I falied to copy and paste R*, the last line is replaced by
ls --color=auto echo {a..c} ~root xterm-256color 2024-01-12 42 /dev/fd/63 hello
R*
> Hello,
>
> from the documentation I understand that shell-expand-line (ESC CTRL-E)
> should do alias expansion, history expansion, brace expan
Hello,
from the documentation I understand that shell-expand-line (ESC CTRL-E) should
do alias expansion, history expansion, brace expansion, tilde expansion, shell
parameter expansion, command substitution, arithmetic expansion, process
substitution (if supported by the operation system), word
Hello Oğuz!
> See:
>
> $ ${ case } in }) echo uname; esac }
> Linux
> $ ${ case }x in }x) echo uname; esac }
> bash: command substitution: line 25: syntax error near unexpected token
> `x'
> bash: command substitution: line 25: `}x)'
> $ ${ case }x in \}x) echo uname;
Hello,
I took a closer look on the online manual chapter 4 "Shell Builtin Commands"
and found some inconsistencies:
- true and false seem to be missing (in 4.1 Bourne Shell Builtins).
The following has been tested with bash 5.2.15:
- 3.7.5 Exit Status says: "All builtins return an exit status
Hello,
in the following lines I consider dash's behaviour as correct an bash's as
wrong:
$ uname -a
Linux martnix4 5.10.0-21-amd64 #1 SMP Debian 5.10.162-1 (2023-01-21) x86_64
GNU/Linux
$ bash--version | head -n 1
GNU bash, version 5.1.4(1)-release (x86_64-pc-linux-gnu)
$ bash-5.2.15 --
Hi Chet!
> >> Thanks for the report. The synopsis should read
> >>
> >> cd [-L|[-P [-e]]] [-@] [dir]
> > ^ ^
> > But aren't these two brackets just superfluous?
>
> -L and -P are mutually exclusive, and -e is valid only when -P is
> supplied.
Yes, my feeling was just that | has s
Hi Chet!
> Thanks for the report. The synopsis should read
>
> cd [-L|[-P [-e]]] [-@] [dir]
^ ^
But aren't these two brackets just superfluous?
Best regards,
Martin
Hello Tycho!
> the login shell detection (leading dash: -bash) is apparently broken - at
> least, ~/.bashrc is not sourced.
As far as I understand the manual ~/.bashrc is not sourced from a login-shell,
see https://www.gnu.org/software/bash/manual/bash.html#Bash-Startup-Files
At least in Debia
Hi Godmar!
> For instance:
>
> gback@lat2022:~$ sleep 10 && echo yes
> ^Z
> [1]+ Stopped sleep 10
> gback@lat2022:~$ fg
> sleep 10
> gback@lat2022:~$
>
> ...
>
> What's the rationale for bash's behavior in this case and is this something
> that should be changed?
I assume this
Hello Nicolas!
> bash-5.1$ echo () { echo test }
> > echo test
> > }
> bash-5.1$ echo
You have defined a function echo that
- calls itself with the first argument 'test' and the second argument '}' (!!!)
- calls itself with the first and only argument test
Try
type -a echo
and
Hello!
Am Sat, 07 Jan 2023 19:08:06 +0100 schrieb Andreas Schwab
:
> On Jan 07 2023, Greg Wooledge wrote:
> ...
> I think the original overflow can only happen if the argument of
> intrand32 is bigger than INT_MAX.
Question might be if an overflow does any harm - or maybe even is intended...
B
Hello!
> function sa {
> for y in $(seq $1 $e2); do
> echo "echo search $y "
> done
> }
I assume you should write $2 instead of $e2 in line 2.
Best regards,
Martin
Hi!
> > Here's another:
> >
> > printf -- '%s ' $(gcc --help) | sed 's/ $/\n/'
> >
> > Let just do the shell most of the work ;-)
>
> That's not safe. The unquoted substitution will undergo word splitting,
> which we want, and also globbing, which we do *not* want.
>
> You should at least dis
Hi!
> Running with this assumption, now that we know bash's extglob matching
> will not perform suitably for this task, we can look at other approaches.
Here's another:
printf -- '%s ' $(gcc --help) | sed 's/ $/\n/'
Let just do the shell most of the work ;-)
Best regards,
Martin
Hello Chet,
on 2022-07-18 10:26:05 -0400 you wrote:
> On 7/16/22 11:18 AM, Martin Schulte wrote:
> > Hello,
> >
> > I'm just wondering that bash (reproduced with 5.2-rc1 under Debian 11)
> > seems to determine LINES and COLUMNS from stderr.
>
> ...
>
Hello Dale!
> Martin Schulte writes:
> > I'm just wondering that bash (reproduced with 5.2-rc1 under Debian 11)
> > seems to determine LINES and COLUMNS from stderr.
>
> It's not clear to me that the manual page says where the LINES and
> COLUMNS values are ob
Hello,
I'm just wondering that bash (reproduced with 5.2-rc1 under Debian 11) seems to
determine LINES and COLUMNS from stderr.
For example, this will lead to strange results when starting the script
#!/bin/bash
shopt -s checkwinsize
trap 'echo $LINES $COLUMNS' SIGWINCH
while true; do sleep 0.
Hello Brad!
> It would be fantastic if there was a nicer way to source files from the
> same folder instead of copy-pasting complicated logic in every script.
I'm not sure if I understand your questions correctly, but did you try
source "${0%/*}/file.ext"
?
>- my sourceables also need logi
Hi Gergely!
> I stumbled upon a recursion overflow crash in BASH.
There are many ways to exhaust memory (and other) recources, recursion is one
them. In your case a variable like SRCNEST (and all the code with its
performance impacts needed behind it) might help, but what exactly is the
advant
Hello bash-bughunters,
please consider the following interactive lines:
$ echo $BASH_VERSION
5.1.4(1)-release
$ uname -a
Linux t1 5.10.0-13-amd64 #1 SMP Debian 5.10.106-1 (2022-03-17) x86_64 GNU/Linux
$ echo $BASH_VERSION
5.1.4(1)-release
$ sleep $(expr 60 - $(date +%s')) ; date
bash: command su
Hello Willi!
> Fix:
> Count the stack frames during recursive parsing and emit error before stack
> resources are entirely consumed.
What exactly should happen and what is the benefit of this solution?
BTW: I tried
trap 'echo "Ohohoh..."; exit 1;' SIGSEGV
but the signal wasn't caught (which di
Hello Greg, hello *!
> And here's a workaround:
>
> unicorn:~$ bash --noprofile --norc -i -c $'alias x="echo hallo"; x'
> bash: x: command not found
> unicorn:~$ bash --noprofile --norc -i -c $'alias x="echo hallo"\nx'
> hallo
Really cool - thanks!
> Put a literal newline in the -c argument, ra
Hello,
on Mon, 28 Mar 2022 20:34:40 +0200 Alex fxmbsw7 Ratchev
wrote:
> https://pastebin.com/raw/T7ZnFapt
>
> about inconsitency, about chets 'uh no bugs'
>
> ive experienced this and such x times already ( got better, this is not my
> code )
Here's a somewhat stripped down version:
$ bash -
Hi David!
> A syntax error would be nice instead.
I see - also from you second answer - that you have some fundamental
misunderstandings about shell programming:
- Your code will, in case the testCode fails, try execute a program called
{echo. This is certainly not a good name for a program, b
Hello David!
> I guess 99% of programmers would either expect "Finished" to be printed or
> some syntax error.
Well, 99% of shell programmers will (hopefully ;-) ) put a blank between "{"
and "echo" in the line
foo="$(testCode)" || {echo "foo";}
Best regards
Martin
Hi Greg!
> > Nevertheless, am I right that this solution relies on an undocumented
> > feature?
>
> Which "undocumented" feature did you have in mind? Most things are
> documented, somewhere.
>
> Are you thinking of -d '' signifying NUL as the delimiter? Chet told
> us that he supports this "
Hi Greg, hi *!
> For bash scripts using this, I'd go a little bit fancier:
>
> read_line() {
> if (($# == 0)) || [[ ${!#} = -* ]]; then
> declare -n _rl_lastvar=REPLY
> else
> declare -n _rl_lastvar=${!#}
> fi
> read -r "$@" || test -n "$_rl_lastvar"
> }
Great, thanks - this solu
Hello,
my apologies if there's a much easier solution for the following problem - in
this case please let me know!
>From time to time a run into troubles when reading a file with a while-read
>loop where the last "line" is not terminated with a newline.
I found an ugly looking solution (probab
Hello Ilkka, hello *!
> Bash's echo is a builtin, so using it doesn't involve an execve().
Sure – but while passing a string (however it will be encoded) containing a
null byte to builtins would be possible in principle (as zsh shows) this would
lead to a large bunch of problems, e.g. another i
Hello Hans, hello Eduardo!
> On Sun, Jan 17, 2021 at 12:05 PM wrote:
> > (...)
> > The nul byte is not echoed by $'\0'.
>
> This is expected. Bash uses NUL-byte terminated character sequences to
> store strings, so it can't actually store NUL bytes themselves.
To be exact, this is alrea
Hello!
Am Tue, 20 Oct 2020 00:58:36 -0700 schrieb L A Walsh :
> 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
>
> T
Hello!
Am Tue, 20 Oct 2020 00:58:36 -0700 schrieb L A Walsh :
> 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
>
> T
Hello Lawrence, hello *!
> >> However, invalid parameter transformation operators are not considered
> >> fatal errors, even in posix mode. Maybe they should be.
> >
> > Yes, please :-)
> >
> > Or no error at all.
>
> Why should invalid parameter transformation operators be treated
> differentl
Hi Chet, hi all!
> In general, variable expansion errors cause posix-mode shells to exit and
> bash default mode shells to abort execution of the current command and
> return to the top level, whether that is the command line or the next
> command in the script. This aborts lists and other compoun
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-sec$
uname output: Linux t1 4.19.0-10-amd64 #1 SMP Debian 4.19.132-1 (2020-07-24)
x
Hello Todd,
Eric Cook wrote:
> This is an intentional relic of the past, you really should use printf.
See
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/echo.html#tag_20_37_18
BTW/1:
Because of this /bin/echo behaves the same way in most Linux distribution.
BTW/2:
echo -n -n$'
Hello Felix!
> Quoting is useless when assigning variable from ouptut of command or
> another variable:
Yes, I assume you are right.
> Unfortunely, I don't retrieve this behaviour in man page.
Me neither, maybe the manual should read
If the substitution appears within double quotes *or as the
Hello Chet, hello Felix, hello all!
> > Bash Version: 5.0
> > Patch Level: 16
> > Release Status: release
> >
> > Description:
> > Integer part of $EPOCHREALTIME could increase more than 8000
> > microseconds before $EPOCHSECONDS
>
> It's the difference between time() and gettimeofday().
Hello bash developers,
my apologies in advance if I'm overlooking something trivial but I'm
really wondering about the first lines in examples/startup-files/bashrc
(which are copied to Debian's skeleton ~/.bashrc):
case $- in
*i*);;
*) return ;;
esac
Well, bash terminates sourcing the f
Hello!
> Could you please comment about this assertions:
>
> 1.- bash will either do a select() or an ioctl(FIONREAD), or neither
> of them, but not both, as it should for it to work. read -t0 is broken.
> 2.- Conclusion: read -t0 is *broken* in bash. Don't use it. –
No. It works as intended
Hello Léa!
Léa Gris wrote:
> I was trying to play the the -v test to detect when an array or
> associative array has been declared, not necessarily assigned entries
> key, values, to not error when Bash runs with -o nounset
Just for the curious: What is your attention here?
I think that most us
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
Hi Chet, hi all!
On Thu, 5 Dec 2019 12:01:31 -0800
Chet Ramey wrote:
> On 12/5/19 11:11 AM, Martin Schulte wrote:
> > Hello,
> >
> > please have a look:
> >
> > $ uname -a
> > Linux martnix4 4.9.0-11-amd64 #1 SMP Debian 4.9.189-3+deb9u2
> > (2019-1
Hello,
please have a look:
$ uname -a
Linux martnix4 4.9.0-11-amd64 #1 SMP Debian 4.9.189-3+deb9u2 (2019-11-11)
x86_64 GNU/Linux $ echo ${BASH_VERSINFO[@]}
4 4 12 1 release x86_64-pc-linux-gnu
$ set -x
$ echo {Z..a}
+ echo Z '[' '' ']' '^' _ '`' a
Z [ ] ^ _ ` a
It looks as if the backslash (bet
Hello,
I'm not feeling well writing this mail because so far I've not been able
to reproduce the behaviour I describe in the following...
I was trying to understand the "[Patch] (tiny problem) bad short_doc for
% command" thread when I entered more or less the following sequence of
commands:
$ h
Hello!
> Is there a T/F var expansion that does:
>
> var=${tst:+$yes}${tst:-$no}
>
> but with yes/no in 1 expansion?
At least if you are only working with numbers you can use
((var=(tst!=0?42:31)))
But is this a question for bug-bash?
Best regards,
Martin
Hello,
with "GNU bash, version 4.4.12(1)-release (x86_64-pc-linux-gnu)" I get
the following behaviour:
+ bash -c 'set -o nounset; echo $x'
bash: x: unbound variable
+ bash -c 'set -o nounset; echo ${x}'
bash: x: unbound variable
+ bash -c 'set -o nounset; echo ${x@Q}'
+ bash -c 'set -o nounset;
Hello,
"help test" states that "-a file" and "-e file" do them same ("True if
file exists.")
This is not true when negating the result as you can see from the output
below. The bash builtin even behaves different than the test from
coreutils.
It looks as if "! -a file" results in "( ! ) -a ( fil
Hello,
I'm running bash under Debian Stretch:
$ echo $BASH_VERSION
4.4.12(1)-release
$ trap
$ echo $$
1100
$ kill 1100
$
=> Looks fine for me
Then I do a
kill 1100
from another session and the bash above terminates.
=> Looks wrong for me
Greetings,
Martin
53 matches
Mail list logo
