anomalies during "make test"
Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -g -O2 uname output: Linux treehug.home.kurahaupo.gen.nz 5.15.0-73-generic #80-Ubuntu SMP Mon May 15 15:18:26 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux Machine Type: x86_64-pc-linux-gnu Bash Version: 5.2 Patch Level: 0 Release Status: rc4 Description: The following tests produce unexpected output during "make test". These definitely appear to indicate bugs: run-execscript (the bashdb directory isn't created during test installation, so debugger can't run) run-read(too few characters read) run-redir (reports "bad N") This is a bug in the test, rather than in bash: run-type(incorrectly assumes "m" does not exist in $PATH) These are just because I don't have the relevant locales installed: run-glob-test run-intl(and the number of tests differs) I've edited the output of "make test" to highlight the issues and to redact personal information. $ configure --prefix=$HOME/lib/perl/$( git log -n1 --format=%H ) ⦠lots of output ⦠$ make test |& sed "s#$PWD#\$SRC#g s#$HOME#~#g" | grep "$info_about_anomalous_tests" # actually edit manually ⦠build parameters, bash version, etc, then some tests ⦠run-execscript ⦠warning ⦠63,64d62 < bash: ~/lib/bash/9cef6d01181525de119832d2b6a925899cdec08e/share/bashdb/bashdb-main.inc: No such file or directory < bash: warning: cannot start debugger; debugging mode disabled ⦠other tests ⦠run-glob-test 2,3d1 < glob2.sub: warning: you do not have the zh_HK.big5hkscs locale installed; < glob2.sub: warning: that will cause some of these tests to fail. 9d6 < ./glob2.sub: line 44: warning: setlocale: LC_ALL: cannot change locale (zh_HK.big5hkscs): No such file or directory 11c8 < argv[1] = --- > argv[1] = 14,15c11,12 < argv[1] = < 000 141 316 261 142 --- > argv[1] = > 000 141 243 134 142 18,19d14 < ./glob2.sub: line 65: warning: setlocale: LC_ALL: cannot change locale (zh_HK.big5hkscs) < $SRC/bash: warning: setlocale: LC_ALL: cannot change locale (zh_HK.big5hkscs) ⦠other tests ⦠run-intl intl2.sub: warning: you do not have the de_DE.UTF-8 locale installed; intl2.sub: that will cause some of these tests to fail. unicode1.sub: warning: you do not have the fr_FR.ISO8859-1 locale installed; unicode1.sub: that will cause some of these tests to be skipped. unicode1.sub: warning: you do not have the ja_JP.SJIS locale installed; unicode1.sub: that will cause some of these tests to be skipped. 13a14 > 1, 18,19c19 < 1. < 1. --- > 1, 24c24 < Passed all 998 Unicode tests --- > Passed all 1378 Unicode tests ⦠other tests ⦠run-read warning: please do not consider output differing only in the amount of warning: white space to be an error. 47c47 < abc --- > abcde 80c80 < abcd --- > abcde run-redir ⦠warning ⦠157,158d156 < redir11 bad 5 < redir11 bad 6 ⦠other tests ⦠run-type 27,29c27 < file < m is ~/bin/m < ~/bin/m --- > ./type.tests: line 56: type: m: not found 43c41 < m is ~/bin/m --- > ./type.tests: line 80: type: m: not found ⦠other tests ⦠Repeat-By: configure --prefix=$HOME/lib/perl/$( git log -n1 --format=%H ) make test |& sed "s#$PWD#\$SRC#g; s#$HOME#~#g" | grep -v "$stuff_that_is_not_interesting" Fix: To fix the trivial errors, I could modify PATH to exclude "m", and install the de_DE.UTF-8, fr_FR.ISO8859-1, ja_JP.SJIS, and zh_HK.big5hkscs locales.
complete -p fails to properly quote argument to -C option
Configuration Information [Automatically generated, do not change]: Machine: i486 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i486' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i486-pc-linux-gnu' -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I../bash -I../bash/include -I../bash/lib -g -O2 uname output: Linux esau 2.6.17.9 #1 PREEMPT Mon Aug 21 13:42:56 EDT 2006 i586 GNU/Linux Machine Type: i486-pc-linux-gnu Bash Version: 3.1 Patch Level: 17 Release Status: release Description: According to the manpage, "complete -p" output should be useable at the command line to recreate the same completion. However, if you have a completion using -C where -C is a command with an argument, the complete -p output is incorrect. Repeat-By: Imagine you have a local command called 'foo'. Imagine that the legal arguments to foo can be determined by running another local command '/usr/local/bin/fooinfo -l'. (The '-l' option is necessary to get fooinfo to only list the available options, one at a time) Now, one reasonable completion entry would be: complete -C '/usr/local/bin/fooinfo -l' -X\!\&\* foo And this works. Unfortunately, "complete -p" prints this as: complete -X '!&*' -C /usr/local/bin/fooinfo -l foo That is, no quotes around the argument to -C. This means that the output of 'complete -p' cannot in this case be typed back in at the command line, or directed into a file to be sourced by future sessions. ___ Bug-bash mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-bash
Vorbildliche Aktion
Lese selbst: http://www.npd.de/npd_info/deutschland/2004/d1204-24.html ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
'wait' in command group in pipeline fails to recognize child process
Hello!
I ran into something that looks like a bug to me, although I'm not super
familiar curly-brace command groups.
Bash version: latest from GitHub mirror (commit ce23728: Bash-5.1 patch 7)
Minimal repro:
$ sleep 1 & { wait $!; } | cat
[1] 665454
bash: wait: pid 665454 is not a child of this shell
I was expecting a success, just like we get without the pipeline:
$ sleep 1 & { wait $!; }
[1] 665591
[1]+ Donesleep 1
The following scripts are similar but print PIDs along the way:
failing script
$ cat wait-for-child
echo "main pid: $$"
/usr/bin/sleep 1 &
job_pid=$!
echo "job pid: $job_pid"
{
echo "command group pid: $$"
wait "$job_pid" || echo "wait failed!"
} | cat
Output:
$ ./bash wait-for-child
main pid: 664755
job pid: 664756
wait-for-child: line 7: wait: pid 664756 is not a child of this shell
command group pid: 664755
wait failed!
^ We see that the current PID in the command group is the same as in the
rest of the shell, as it should be. It is unclear to me why 'wait'
believes that the background job's PID is not of a child.
successful script
Compare to the same script without having the command group in a
pipeline (I removed '| cat'):
$ cat wait-for-child-ok
echo "main pid: $$"
/usr/bin/sleep 1 &
job_pid=$!
echo "job pid: $job_pid"
{
echo "command group pid: $$"
wait "$job_pid" || echo "wait failed!"
}
$ ./bash wait-for-child-ok
main pid: 664705
job pid: 664706
command group pid: 664705
^ OK
Martin
Re: 'wait' in command group in pipeline fails to recognize child process
On 6/22/21 6:15 AM, Chet Ramey wrote: On 6/22/21 5:42 AM, Martin Jambon wrote: Hello! I ran into something that looks like a bug to me, although I'm not super familiar curly-brace command groups. It's not the brace command; it's the pipeline. Thank you! It's the $$ that confused me since I thought incorrectly that it would print the current process ID. I was also misled by the term "subshell" which is not a proper shell like a subprocess is just another process.
Re: 'wait' in command group in pipeline fails to recognize child process
On 6/22/21 4:31 AM, Greg Wooledge wrote:
On Tue, Jun 22, 2021 at 02:42:40AM -0700, Martin Jambon wrote:
I ran into something that looks like a bug to me, although I'm not super
familiar curly-brace command groups.
Bash version: latest from GitHub mirror (commit ce23728: Bash-5.1 patch 7)
Minimal repro:
$ sleep 1 & { wait $!; } | cat
[1] 665454
bash: wait: pid 665454 is not a child of this shell
I was expecting a success, just like we get without the pipeline:
A pipeline creates two or more subshells, one for each command in the
pipeline. Therefore, your wait command is running in a different
process than the one which created the sleep background job.
The curly braces are irrelevant here.
unicorn:~$ sleep 1 & wait "$!"|cat
[1] 1290127
bash: wait: pid 1290127 is not a child of this shell
Thank you! Now I know that a subshell is not a shell, $$ being the
process ID of the shell, not of the subshell.
Re: 'wait' in command group in pipeline fails to recognize child process
On 6/22/21 1:37 PM, Greg Wooledge wrote: On Tue, Jun 22, 2021 at 01:12:10PM -0700, Martin Jambon wrote: On 6/22/21 4:31 AM, Greg Wooledge wrote: A pipeline creates two or more subshells, one for each command in the pipeline. Therefore, your wait command is running in a different process than the one which created the sleep background job. The curly braces are irrelevant here. unicorn:~$ sleep 1 & wait "$!"|cat [1] 1290127 bash: wait: pid 1290127 is not a child of this shell Thank you! Now I know that a subshell is not a shell, $$ being the process ID of the shell, not of the subshell. It's a forked child process of bash, and as such, it's still a shell. Specifically, it's bash. There's some formal definition that you can ignore. The real definition of a subshell is "the direct result of a fork()". It inherits all of the shell variables, functions, aliases, and so on that the parent shell process had at the time of the fork. This is different from a direct call to "bash", which would not inherit shell variables and so on -- only environment variables. Great, then I would change the documentation of '$$'. Currently it says this: ($$) Expands to the process ID of the shell. In a () subshell, it expands to the process ID of the invoking shell, not the subshell. This first mentions just "the shell". I suggest calling it the "root shell" instead, i.e. the process where "exec bash" took place. I would also mention pipelines here, since these are more commonly used than () subshells. I don't know if there are other ways of creating subshells. If that's all, I think it would be valuable to mention those two cases rather than just one. Well, I suppose "root shell" could be misunderstood as a shell run by the 'root' user but this doesn't make much sense in this context. I can't find a better name. Here's how we might change the description of '$$': ($$) Expands to the process ID of the root shell. In a pipeline or in a () subshell, it expands to the process ID of the root shell, not the subshell. I also changed "invoking shell" to "root shell" because the invoking shell or parent shell is not necessarily the same as the root shell e.g. $ echo $$; (echo $$; (echo $$)) 688918 688918 688918 In the pipeline, there are two subshells created. One of them runs the command wait "$!", and the other runs the command cat. The special parameter $! is inherited from the parent shell, and contains the PID of the sleep process that the parent shell created. But the child subshell can't wait for that process, because it belongs to someone else. Hence the error message. 👍 Yup. I think the error message is clear. No complaint about that.
Re: 'wait' in command group in pipeline fails to recognize child process
On 6/22/21 5:00 PM, Lawrence Velázquez wrote: Maybe something like this would get the point across: ($$) Expands to the process ID of the shell. In a subshell, it expands to the value that $$ has in the invoking shell. It's better. However, the reader is still left wondering what "the shell" is referring to in first sentence. Here's my next suggestion, which borrows some language from the documentation for BASHPID: ($$) Expands to the ID of the process that initialized Bash. The value of $$ is inherited in subshells, such as pipelines, regardless of their own process ID. See also the Bash variable BASHPID. For reference, the documentation for 'BASHPID' is this: Expands to the process ID of the current Bash process. This differs from $$ under certain circumstances, such as subshells that do not require Bash to be re-initialized. Assignments to BASHPID have no effect. If BASHPID is unset, it loses its special properties, even if it is subsequently reset.
Re: 'wait' in command group in pipeline fails to recognize child process
On 6/22/21 6:11 PM, Lawrence Velázquez wrote: On Tue, Jun 22, 2021, at 8:52 PM, Martin Jambon wrote: It's better. However, the reader is still left wondering what "the shell" is referring to in first sentence. Subshells aside, I have a hard time believing that "the process ID of the shell" confuses anybody in practice. Even POSIX doesn't overcomplicate this: $ Expands to the decimal process ID of the invoked shell. In a subshell (see Shell Execution Environment), '$' shall expand to the same value as that of the current shell. (https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_05_02) This language implies that a subshell is part of the shell but not a shell in itself. This is what I pointed out earlier but I received a conflicting answer. This is confirmed by this definition from posix: A subshell environment shall be created as a duplicate of the shell environment, except that signal traps that are not being ignored shall be set to the default action. Changes made to the subshell environment shall not affect the shell environment. Command substitution, commands that are grouped with parentheses, and asynchronous lists shall be executed in a subshell environment. Additionally, each command of a multi-command pipeline is in a subshell environment; as an extension, however, any or all commands in a pipeline may be executed in the current environment. All other commands shall be executed in the current shell environment. (https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_12) In the posix definition, a subshell - is not necessarily implemented as a separate process - belongs to a unique shell - is not a shell This makes the term "the shell" unambiguous to a reader who's aware of this - but it's obvious to me that "subshell" should be clarified in the context of '$$'. A subset is a set, a subgroup is a group, a subtype is a type, a subtree is a tree, a subprocess is a process. However a submarine is not a marine, and a subshell is not a shell (sea stuff!). Anyway, I left a suggestion to revise the documentation for '$$' in my previous email. That's the best I can produce at this time. Martin
Re: 'wait' in command group in pipeline fails to recognize child process
On 6/23/21 6:24 AM, Chet Ramey wrote: On 6/22/21 9:54 PM, Martin Jambon wrote: In the posix definition, a subshell - is not necessarily implemented as a separate process - belongs to a unique shell - is not a shell Why is it not "a shell?" Because '$$' doesn't match its process ID. What is the magic quality that imparts shellness? '$$' matching the process ID. Posix: '$' shall expand to the same value as that of the current shell. (https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_05_02) Bash: ($$) Expands to the process ID of the shell. (https://www.gnu.org/software/bash/manual/bash.html#Special-Parameters) I'm not sure why I have to fight over this. It's clearly my misunderstanding. That's why I suggest clarifications in the documentation, if you're interested in creating a better experience for users like me.
Option for read to handle incomplete last line
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 (probably relying on undocumented features)
when reading the whole line into one variable (see below).
The attached patch for bash-5.1.8 will add an -E option to the builtin read
that will avoid the problem.
To test it run the patched bash on the following script:
>>>
input=$'Line 1\nLine 2\nIncomplete line 3'
echo "while read line"
printf '%s' "$input" | while read line; do printf ' %s\n' "$line"; done
echo "while read line || [[ \$line != '' ]]"
printf '%s' "$input" | while read line || [[ $line != '' ]]; do printf ' %s\n'
"$line"; done
echo "while read -E line"
printf '%s' "$input" | while read -E line; do printf ' %s\n' "$line"; done
echo "while read -E line with no characters between last \\n and EOF"
printf '%s\n' "$input" | sed 's/Incomplete l/L/' | while read -E line; do
printf ' %s\n' "$line"; done
<<<
The patch has not been tested intensely - first I would like to hear if I'm on
a sensible way.
Best regards
Martin
--- ../bash-5.1.8-ori/builtins/read.def 2020-06-05 19:18:28.0 +0200
+++ builtins/read.def 2021-10-23 21:23:37.067915781 +0200
@@ -22,7 +22,7 @@
$BUILTIN read
$FUNCTION read_builtin
-$SHORT_DOC read [-ers] [-a array] [-d delim] [-i text] [-n nchars] [-N nchars] [-p prompt] [-t timeout] [-u fd] [name ...]
+$SHORT_DOC read [-eErs] [-a array] [-d delim] [-i text] [-n nchars] [-N nchars] [-p prompt] [-t timeout] [-u fd] [name ...]
Read a line from the standard input and split it into fields.
Reads a single line from the standard input, or from file descriptor FD
@@ -40,6 +40,7 @@
-d delim continue until the first character of DELIM is read, rather
than newline
-e use Readline to obtain the line
+ -E return text between last newline and EOF
-i text use TEXT as the initial text for Readline
-n nchars return after reading NCHARS characters rather than waiting
for a newline, but honor a delimiter if fewer than
@@ -179,7 +180,7 @@
int size, nr, pass_next, saw_escape, eof, opt, retval, code, print_ps2, nflag;
volatile int i;
int input_is_tty, input_is_pipe, unbuffered_read, skip_ctlesc, skip_ctlnul;
- int raw, edit, nchars, silent, have_timeout, ignore_delim, fd;
+ int raw, edit, eof_terminates_line, nchars, silent, have_timeout, ignore_delim, fd;
int lastsig, t_errno;
int mb_cur_max;
unsigned int tmsec, tmusec;
@@ -209,6 +210,7 @@
USE_VAR(input_is_pipe);
/* USE_VAR(raw); */
USE_VAR(edit);
+ USE_VAR(eof_terminates_line);
USE_VAR(tmsec);
USE_VAR(tmusec);
USE_VAR(nchars);
@@ -229,6 +231,7 @@
i = 0; /* Index into the string that we are reading. */
raw = edit = 0; /* Not reading raw input by default. */
+ eof_terminates_line = 0;
silent = 0;
arrayname = prompt = (char *)NULL;
fd = 0; /* file descriptor to read from */
@@ -245,7 +248,7 @@
ignore_delim = nflag = 0;
reset_internal_getopt ();
- while ((opt = internal_getopt (list, "ersa:d:i:n:p:t:u:N:")) != -1)
+ while ((opt = internal_getopt (list, "eErsa:d:i:n:p:t:u:N:")) != -1)
{
switch (opt)
{
@@ -263,6 +266,9 @@
edit = 1;
#endif
break;
+ case 'E':
+ eof_terminates_line = 1;
+ break;
case 'i':
#if defined (READLINE)
itext = list_optarg;
@@ -788,7 +794,14 @@
discard_unwind_frame ("read_builtin");
- retval = eof ? EXECUTION_FAILURE : EXECUTION_SUCCESS;
+ if (!eof_terminates_line)
+{
+ retval = eof ? EXECUTION_FAILURE : EXECUTION_SUCCESS;
+}
+ else
+{
+ retval = eof && strlen (input_string) == 0 ? EXECUTION_FAILURE : EXECUTION_SUCCESS;
+}
assign_vars:
Re: Option for read to handle incomplete last line
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 solution seems to solve more real world problems than it
introduces ;-)
> This intentionally skips a trailing incomplete line that has too few
> fields, as in:
>
> ...
>
> The incomplete line here only has one field, so the "lastvar" (b) is
> empty, and therefore the incomplete line isn't counted. I consider
> this a feature, but others may not.
Yes, one might discuss this...
Nevertheless, am I right that this solution relies on an undocumented feature?
Best regards
Martin
Re: Option for read to handle incomplete last line
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 "happy accident" and won't take it away.
>
> Are you thinking of the equivalence of "$array" and "${array[0]}"? I
> think that's documented somewhere, but I'm not going to dig for it right
> now.
Before reading the source I would never have thought that read sets variables
although it returns FAILURE.
Best regards
Martin
Re: Interesting bug
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
Re: Interesting bug
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, but it is not a syntax
error either.
- Since bash interprets the code the problem with the closing brace is only
detected when the offending line is passed.
My personal opinion (although I'll probably be bashed here for it ;-) ): Except
for a very few exceptions like small wrappers avoid writing new shell scripts
at all - for example use python instead. There are many historically founded
flaws and odds with shell proramming.
Anyhow, bug-bash@gnu.org is not the right place for these topics, better try
help-b...@gnu.org.
Best regards
Martin
Re: forwarded weirdness report
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 --noprofile --norc -i -c "echo \$BASH_VERSION; shopt -s expand_aliases ; source <(echo \"alias x='echo hallo'\"); alias; x" 5.1.4(1)-release alias x='echo hallo' bash: x: command not found Best regards Martin
Re: forwarded weirdness report
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, rather than a semicolon.
>
> Or -- and I know this answer will be rejected, because it's too simple
> and sensible -- stop using aliases in scripts.
Or even stop using them at all,
alias egrep1='grep -E'
doesn't save much compared to
egrep2() { grep -E "$@" ; }
Or is there a reason why one shouldn't use this in an interactive shell?
Best regards
Martin
Re: Bash regexp parsing would benefit from safe recursion limit
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 didn't really surprise me). Best regards Martin
bash seems confused about it's state after unclosed single quotes in nested command substitution
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 substitution: line 417: unexpected EOF while looking for matching `'' bash: command substitution: line 418: syntax error: unexpected end of file bash: unexpected EOF while looking for matching `)' $ At this point it looks as if bash has encountered the problem and thus not executed the command line - fine. Things get strange when you enter a command, e.g. echo: $ echo > To get out of this you can enter the missing single quote followed by two closing braces: > ')) expr: non-integer argument sleep: missing operand Try 'sleep --help' for more information $ Now you can go on as expected, the last command in history is $'echo\n\'))' and the 'sleep ...' is not in the history at all. I would either have expected to get PS2 and no error messages after entering the line starting with sleep or being able to just enter the next command. Best regards Martin
internal command cd ; additional arguments are not ignored
Configuration Information [Automatically generated, do not change]: Machine: amd64 OS: freebsd12.3 Compiler: cc Compilation CFLAGS: -O2 -pipe -fno-omit-frame-pointer -DLIBICONV_PLUG -fstack-protector-strong -isystem /usr/local/include -fno-strict-aliasing uname output: FreeBSD bxlr.sk 12.3-RELEASE FreeBSD 12.3-RELEASE releng/12.3-n1-70cb68e7a BXLR amd64 Machine Type: amd64-portbld-freebsd12.3 Bash Version: 5.1 Patch Level: 16 Release Status: release Description: Bash internal command cd doesn't ignore additional arguments following dir as stated in its man page. This is not OS dependent, reproducible on Linux/FreeBSD since version 4.4. Repeat-By: $ cd /tmp /root -bash: cd: too many arguments While cd-ing to more dirs doesn't make sense this issue was discovered by some bad regex in SAP profiles. bash before 4.4 was silently ignoring this. If this is expected behavior man page should be updated as those arguments are not ignored any more. martin
Re: BASH recursion segfault, FUNCNEST doesn't help
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 advantage of a "maximum source nesting level exceeded" error over a segmentation fault? Next we will need MAXARRUSAGE, MAXBRACEEXPAN, ... > There's a slim chance this might be exploitable. I would really be interested in an example. Best regards, Martin
Re: Feature request
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 logic to prevent them from being executed by
>accident (they tell you to source them instead).
Just don't give them execute permission (at least when running on a unix
system).
Best regards,
Martin
Gettings LINES and COLUMNS from stderr instead of /dev/tty
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.1; done with standard error redirected to a file (or - even more strange ;-) - another terminal). A quick POC shows that replacing tty = input_tty (); with tty = open( "/dev/tty", O_RDONLY ); in get_new_windows_size in lib/sh/winsize.c gives the "expected" result. In case there is some reason not to use /dev/tty, wouldn't it then be better to ask stdin instead of stderr? The script will most probably be interested in the size of device it is writing to, not the one it is logging to. Best regards Martin
Re: Gettings LINES and COLUMNS from stderr instead of /dev/tty
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 obtained from. Sorry, maybe my mail was somewhat too short... I didn't find anything in the man pages that states where these variables are obtained from. To show the behaviour do the following: - Open a (resizable) terminal window (with a bash in it), say it is /dev/pts/5 - In a second terminal window start the script #!/bin/bash shopt -s checkwinsize trap 'echo $LINES $COLUMNS' SIGWINCH while true; do sleep 0.1; done with ./winsize 2> /dev/pts/5 Whenn you now resize this window, the script will show you the size of the other one. The sources (get_new_windows_size in lib/sh/winsize.c) seem to explain well why this happens. Hope this helps to understand the problem! Best regards Martin
Re: Gettings LINES and COLUMNS from stderr instead of /dev/tty
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.
>
> ...
> When it's not interactive, all bets are off, and stderr is usually
> a safe default. There's no consistent approach across shells.
At least I lost my bet ;-)
Since I still have the opinion that either stdout or /dev/tty should be asked
to set the variables (because it's the "natural assumption" that you want to
format what you write there) please consider the following script:
#!/bin/bash
shopt -s checkwinsize
( : ) # set LINES/COLUMNS for first time
while true; do
if ((EPOCHSECONDS%86400==11655)); then
printf -v msg '%S' "It's pi o'clock UTC"
else
printf -v msg '%(%T)T' $EPOCHSECONDS
fi
tput clear ; tput cup 0 $(((COLUMNS-${#msg})/2)) ; echo "$msg"
sleep 1
done
It fails with a "bash: printf: `S': invalid format character" once a day but
I've no chance to catch this error - either it is cleared on the screen or
logging stderr breaks the output.
BTW: tput first tries stderr, then stdout, then stdin, then /dev/tty.
Best regards
Martin
Re: Parameter expansion with extended pattern make system hang
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
Re: Parameter expansion with extended pattern make system hang
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 disable globbing first, with set -f. Sure, thanks! > I also don't understand why you used a '%s ' format and then changed > spaces to newlines with a second process. You might as well just use > a '%s\n' format in the first place, and skip the sed/tr. I just changed the last one! Best regards, Martin
Re: reporting a bug
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
Re: UBSAN error in lib/sh/random.c:79
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... Best regards, Martin
Re: Segmentation Fault in bash --posix
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
Echo() {
echo test }
Echo test
}
Echo
to get an insight was is happening.
So, it's no surprise that bash finally crashes.
Most probably you want to insert a ; before the first closing }:
echo() { echo test ; }
But even now bash will crash.
Best regards
Martin
Re: Logical expressions and job control
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 is because sleep "exits" with an exit status of 148 (=128+SIGTSTP) when it is stopped. If you replace the && with an ;, you get "yes" immediately after pressing ^Z. Best regards Martin
Re: bash login shell detection broken using default compile options
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 Debian 11 the default ~/.profile cares for sourcing ~/.bashrc, that might explain the effect you describe. Best regards, Martin
Re: Bash Reference Manual Type
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
Re: Bash Reference Manual Type
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 such a low precedence that the marked pair of brackets could be omitted, like in id|cut -c1-3 or in the ERE ^(-L|-P( -e)?)?$ But situation seems to be different here. Best regards, Martin
Possible problem with ${var%%[...]*}
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 --version | head -n 1
GNU bash, version 5.2.15(1)-release (x86_64-pc-linux-gnu)
$ bash-c 'option2="test{<().["; echo "${option2%%[<().[]*}"'
test{<()
$ bash-5.2.15 -c 'option2="test{<().["; echo "${option2%%[<().[]*}"'
test{<()
$ dash-c 'option2="test{<().["; echo "${option2%%[<().[]*}"'
test{
Am I missing something?
I tried to find a smaller example showing the difference but so far I didn't
succeed.
Best regards,
Martin
Some minor notes on manual chapter 4 "Shell Builtin Commands"
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 of 2 to indicate incorrect usage, generally invalid options or missing arguments." but cd with two or more non-optional arguments returns an exit status of 1. - The same is true if exit is called with two or more argument where the first is numeric. This exit doesn't terminate bash. - When exit is invoked with a non-numeric first argument it terminates bash. That seems to be inconsistent with the behaviour described before, while the exit status of the shell is 2 and consistent in some way. Best regards Martin
Re: inconsistent handling of closing brace inside no-fork command substitution
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; esac }
> Linux
I couldn't reproduce this with neither 5.1.4 nor 5.2.15 - in both cases
${ case } in }) echo uname; esac }
results in
bash: syntax error near unexpected token `)'
Any help appreciated!
Thanks,
Martin
No filename expansion in shell-expand-line
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 splitting, filename
expansion and quote removal.
$ echo $BASH_VERSION
5.2.15(1)-release
$ echo R*
README
$ echo
$ ls !! {a..c} ~root $TERM $(date +%F) $((6*7)) <(cat /etc/passwd) "hello" R*
After pressing ESC CTRL-E the last line is replaced by:
ls --color=auto echo {a..c} ~root xterm-256color 2024-01-12 42 /dev/fd/63 hello
So, everything works fine execept filename expansion, which seems to be missing.
Or do I understand something wrong?
Best regards,
Martin
Re: No filename expansion in shell-expand-line
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 expansion, tilde
> expansion, shell parameter expansion, command substitution, arithmetic
> expansion, process substitution (if supported by the operation system), word
> splitting, filename expansion and quote removal.
>
> $ echo $BASH_VERSION
> 5.2.15(1)-release
> $ echo R*
> README
> $ echo
>
> $ ls !! {a..c} ~root $TERM $(date +%F) $((6*7)) <(cat /etc/passwd) "hello" R*
>
> After pressing ESC CTRL-E the last line is replaced by:
>
> ls --color=auto echo {a..c} ~root xterm-256color 2024-01-12 42 /dev/fd/63
> hello
>
> So, everything works fine execept filename expansion, which seems to be
> missing.
>
> Or do I understand something wrong?
>
> Best regards,
>
> Martin
Re: It is possible to remove the readonly attribute from {BASH, SHELL}OPTS
t's not marked as a new-style function, then the answer must be yes; but if it *is* recognisable as a new-style function, sound software engineering principles would come down firmly on 'no'. > | even when we claim it's local" and "unset can even mess with the poor > | protection afforded by 'local'". > > I'm guessing you mean bash's bizarre unset definition wrt locals. > I consider that to just be a bug. Yes that's the one, and I agree it's a bug. But now it's also an implementation "feature" that people may rely on. I've heard rumours that 'upvar' needs it, so I would want to hear from people who have a use for its current behaviour, before deciding to "fix" it. -Martin
Re: Document ulimit's "unlimited" limit in manual page
Il 03/04/24 15:10, Martin Guy ha scritto: The "unlimited" keyword is not mentioned in the manual page, and should be. Oops. Yes it is. Only dash lacks a mention of it. Sorry for the noise. M OpenPGP_signature.asc Description: OpenPGP digital signature
Document ulimit's "unlimited" limit in manual page
Hi. ulimit -c unlimited The "unlimited" keyword is not mentioned in the manual page, and should be. (nor is it for dash(1) so it looks like someone copied some else's manual page!) With thanks M OpenPGP_signature.asc Description: OpenPGP digital signature
Here document / redirection / background process weirdness
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-unknown-linux-gnu' -DCONF_VENDOR='unknown' -DLOCALEDIR='/home/mjackson/src/bash-4.2/_install/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -g -O2 uname output: Linux stagecoach 3.5.0-25-generic #39-Ubuntu SMP Mon Feb 25 18:26:58 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux Machine Type: x86_64-unknown-linux-gnu Bash Version: 4.2 Patch Level: 0 Release Status: release Description: When executing a here document in bash, with the here document piped to another instance of bash, where the here document contains "echo <&- &; wait", the here document gets executed twice. I have seen this on Ubuntu both with the current 4.2.37 from ubuntu and the latest bash tarball (details above) Repeat-By: #!/home/mjackson/src/bash-4.2/_install/bin/bash /home/mjackson/src/bash-4.2/_install/bin/bash <
Re: Here document / redirection / background process weirdness
I didn't see any acknowledgement of this bug report, did I fill in enough info? Thanks & regards, Martin Jackson On Tue, Mar 5, 2013 at 1:52 PM, Martin Jackson 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-unknown-linux-gnu' > -DCONF_VENDOR='unknown' > -DLOCALEDIR='/home/mjackson/src/bash-4.2/_install/share/locale' > -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib > -g -O2 > uname output: Linux stagecoach 3.5.0-25-generic #39-Ubuntu SMP Mon Feb 25 > 18:26:58 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux > Machine Type: x86_64-unknown-linux-gnu > > Bash Version: 4.2 > Patch Level: 0 > Release Status: release > > Description: > When executing a here document in bash, with the here document piped to > another instance of bash, where the here document contains "echo <&- &; > wait", the here document gets executed twice. I have seen this on Ubuntu > both with the current 4.2.37 from ubuntu and the latest bash tarball > (details above) > > Repeat-By: > #!/home/mjackson/src/bash-4.2/_install/bin/bash > > /home/mjackson/src/bash-4.2/_install/bin/bash < declare -i a=0 > echo BASHPID is \$BASHPID > true let a++ > echo a is \$a, BASHPID is \$BASHPID > EOF > > Prints: > BASHPID is 30866 > a is 1, BASHPID is 30866 > a is 2, BASHPID is 30866 > > Fix: > Adding a manual 'exit' statement at the end of the here document seems > to be a workaround: > > #!/home/mjackson/src/bash-4.2/_install/bin/bash > > /home/mjackson/src/bash-4.2/_install/bin/bash < declare -i a=0 > echo BASHPID is \$BASHPID > true let a++ > echo a is \$a, BASHPID is \$BASHPID > exit > EOF > > Prints: > BASHPID is 30895 > a is 1, BASHPID is 30895 > >
Ctrl-D exits unexpectedly
From: mo...@cam.ac.uk Subject: [50 character or so descriptive subject here (for reference)] 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='l$ uname output: Linux krakow 3.8.0-19-generic #30-Ubuntu SMP Wed May 1 16:35:23 U$ Machine Type: x86_64-pc-linux-gnu Bash Version: 4.2 Patch Level: 45 Release Status: release Description: The IGNOREEOF behavior changed in Bash 4.2 (in Ubuntu 13.04) compared to bash in Ubuntu 12.10. I used to have in my .bashrc set -o ignoreeof export IGNOREEOF=10 and in this case, Ctrl-D would never exit the shell, even if pressed more than 10 times. In the newer Bash 4.2 (patch 45), it *does* exit the shell after 10 Ctrl-D. The bug is that set -o ignoreeof does not have an effect. Even after unsetting IGNOREEOF, the shell exits. The set -o ignoreeof by itself does not make the shell ignore EOF; the only way seems to be to set IGNOREEOF to a very large number. Thanks, Martin
[BUG] directory tree error (probably)
It seams that "cd [/]{1,}" should take you to the root node. (as showed up
by 'ls')
But when we try with two "/" something goes wrong:
ls works as to be in the root node,
pwd report "//" as path instead of "/"
the bash line report "//" as path too
How to reproduce:
user@pc:/home/user$ cd /
user@pc:/$ pwd
/
user@pc:/$ ls
bin dev homeliblost+found mnt proc run selinux sys
usr vmlinuz
boot etc initrd.img lib64 media opt root sbin srv tmp var
user@pc:/home/user$ cd //
user@pc://$ pwd
//
user@pc://$ ls
bin dev homeliblost+found mnt proc run selinux sys
usr vmlinuz
boot etc initrd.img lib64 media opt root sbin srvtmp var
user@pc:/home/user$ cd ///
user@pc:/$ pwd
/
user@pc:/$ ls
bin dev homeliblost+found mnt proc run selinux sys
usr vmlinuz
boot etc initrd.img lib64 media opt root sbin srv tmp var
Confirmed on:
- Debian 7
GNU bash, version 4.2.37(1)-release (x86_64-pc-linux-gnu)
- Fedora 19
GNU bash, version 4.2.45(1)-release (x86_64-redheat-linux-gnu)
[PATCH] bash: add socket server support
Currently, an outbound socket connection (client) can be created using the
syntax:
exec 5<> /dev/tcp/HOST/PORT
This patch implements support for accepting incoming connections (server)
using a slightly different syntax:
exec 6<> /dev/tcp/HOST/:PORT # note the colon
The listen/accept call will block until a connection is received and it
will be bound to the redirection.
Included in the patch is a small test that has an example of usage. I've
also attach a minimal web server that leverages this functionality (pure
bash except for a call to wc and cat).
Please include me in Cc since I am not on the list.
Thanks,
Joel Martin (kanaka)
From 04df5a7a23325a7e9b42ee3d4b306fa222326d99 Mon Sep 17 00:00:00 2001
From: Joel Martin
Date: Tue, 12 Nov 2013 15:30:47 -0500
Subject: [PATCH] Listening socket support via /dev/tcp/HOST/:PORT
In addition to the ability to create normal outgoing socket
connections (/dev/tcp/HOST/PORT) this adds the ability to create
a listen socket connection. The creation of the listener will block
until a new connection is created via the listener.
Signed-off-by: Joel Martin
---
lib/sh/netopen.c | 110 +++--
tests/misc/dev-tcp-serv.tests | 44 +
2 files changed, 127 insertions(+), 27 deletions(-)
create mode 100644 tests/misc/dev-tcp-serv.tests
diff --git a/lib/sh/netopen.c b/lib/sh/netopen.c
index 736d413..0a2a9f1 100644
--- a/lib/sh/netopen.c
+++ b/lib/sh/netopen.c
@@ -69,9 +69,9 @@ extern int inet_aton __P((const char *, struct in_addr *));
#ifndef HAVE_GETADDRINFO
static int _getaddr __P((char *, struct in_addr *));
static int _getserv __P((char *, int, unsigned short *));
-static int _netopen4 __P((char *, char *, int));
+static int _netopen4 __P((char *, char *, int, int));
#else /* HAVE_GETADDRINFO */
-static int _netopen6 __P((char *, char *, int));
+static int _netopen6 __P((char *, char *, int, int));
#endif
static int _netopen __P((char *, char *, int));
@@ -154,14 +154,16 @@ _getserv (serv, proto, pp)
* traditional BSD mechanisms. Returns the connected socket or -1 on error.
*/
static int
-_netopen4(host, serv, typ)
+_netopen4(host, serv, typ, listener)
char *host, *serv;
- int typ;
+ int typ, listener;
{
struct in_addr ina;
struct sockaddr_in sin;
unsigned short p;
- int s, e;
+ int optval = 1;
+ int s, c, e;
+ const char *step;
if (_getaddr(host, &ina) == 0)
{
@@ -189,16 +191,39 @@ _netopen4(host, serv, typ)
return (-1);
}
- if (connect (s, (struct sockaddr *)&sin, sizeof (sin)) < 0)
+ if (!listener)
+{
+ step = "connect";
+ if (connect (s, (struct sockaddr *)&sin, sizeof (sin)) < 0)
+goto cleanup;
+}
+ else
{
- e = errno;
- sys_error("connect");
+ //internal_error("Listening (4) on: %s:%s %c\n", host, serv, typ);
+ step = "setsockopt";
+ if (setsockopt(s, SOL_SOCKET, SO_REUSEADDR, &optval, sizeof optval) <0)
+goto cleanup;
+ step = "bind";
+ if (bind(s, (struct sockaddr*)&sin, sizeof(sin)) < 0)
+goto cleanup;
+ step = "listen";
+ if (listen(s, 1) < 0)
+goto cleanup;
+ step = "accept";
+ if ((c = accept(s, (struct sockaddr*)NULL, NULL)) < 0)
+goto cleanup;
close(s);
- errno = e;
- return (-1);
+ s = c;
}
return(s);
+
+ cleanup:
+e = errno;
+sys_error(step);
+close(s);
+errno = e;
+return (-1);
}
#endif /* ! HAVE_GETADDRINFO */
@@ -209,13 +234,15 @@ _netopen4(host, serv, typ)
* on error.
*/
static int
-_netopen6 (host, serv, typ)
+_netopen6 (host, serv, typ, listener)
char *host, *serv;
- int typ;
+ int typ, listener;
{
- int s, e;
+ int s, c, e;
struct addrinfo hints, *res, *res0;
+ int optval = 1;
int gerr;
+ const char *step;
memset ((char *)&hints, 0, sizeof (hints));
/* XXX -- if problems with IPv6, set to PF_INET for IPv4 only */
@@ -247,22 +274,45 @@ _netopen6 (host, serv, typ)
freeaddrinfo (res0);
return -1;
}
- if (connect (s, res->ai_addr, res->ai_addrlen) < 0)
+ if (!listener)
{
- if (res->ai_next)
- {
- close (s);
- continue;
- }
- e = errno;
- sys_error ("connect");
- close (s);
- freeaddrinfo (res0);
- errno = e;
- return -1;
+ step = "connect";
+ if (connect (s, res->ai_addr, res->ai_addrlen) < 0)
+ goto cleanup;
+ }
+ else
+ {
+ //internal_error("Listening 6 on: %s:%s %c\n", host, serv, typ);
+ step = "setsockopt";
+ if (setsockopt(s, SOL_SOCKET, SO_REUSEADDR, &optval, sizeof optval) < 0)
+ goto cleanup;
+ step = "bind";
+ if (bind(s, res->ai_addr, res->ai_addrlen) < 0)
+ goto cleanup;
+ step = "list
Re: [PATCH] bash: add socket server support
Hi Piotr, Thanks for the feedback. I don't believe this functionality changes the attack surface. Most systems with bash also have nc/netcat or an equivalent program which can do the same thing. Even the nc version in busybox has listen capability. In fact, if you can create a file with arbitrary content and mark it as executable then you have access to the system calls needed to listen on a socket. All existing security permissions still apply (e.g. ports < 1024 requiring elevated privilege, SELinux, etc). Do you have a specific attack or vector that is enabled or made worse by this addition? Regards, Joel Martin (kanaka) On Wed, Nov 13, 2013 at 1:35 AM, Piotr Grzybowski wrote: > Hi Everyone, hi Joel, > > the idea is nice, and I can really see that it is useful, but I would > be extremely careful with introducing those kind of changes, it can be > easily interpreted as "backdoor feature", that is: from security point > of view it could be a disaster. > > cheers, > pg > > > > On Tue, Nov 12, 2013 at 10:02 PM, Joel Martin > wrote: > > Currently, an outbound socket connection (client) can be created using > the > > syntax: > > > > exec 5<> /dev/tcp/HOST/PORT > > > > This patch implements support for accepting incoming connections (server) > > using a slightly different syntax: > > > > exec 6<> /dev/tcp/HOST/:PORT # note the colon > > > > The listen/accept call will block until a connection is received and it > > will be bound to the redirection. > > > > Included in the patch is a small test that has an example of usage. I've > > also attach a minimal web server that leverages this functionality (pure > > bash except for a call to wc and cat). > > > > Please include me in Cc since I am not on the list. > > > > Thanks, > > > > Joel Martin (kanaka) >
Re: [PATCH] bash: add socket server support
Irek,
Great feedback. Comments inline.
On Wed, Nov 13, 2013 at 6:39 AM, Irek Szczesniak wrote:
> ':' in *any* Unix paths is not wise because its already used by $PATH.
> Likewise ';' is already occupied by version file systems.
>
I had considered that issue when I was trying to come up with a alternate
syntax. A colon often precedes listening port numbers in various
representations so that was why it seemed attractive. After considering it
back and forth, eventually I decided that since /dev/tcp/* is in effect a
URL rather than a file path, it should be an issue to include a colon.
However, I'm not stuck on a colon by any means. Perhaps a dot or dash
instead?
> The other problems I see is:
> How can the script get access to the data returned by accept()? Unlike
> ksh93 bash4 has no compound variables yet.
> How can the accept() socket be passed to a child process so that
> request processing can be passed to a fork()ed child process?
The accept socket is not exposed to the script by this change. The call
blocks until a connection is accepted and that inbound connection is bound
to the file descriptor (right after the accept socket is closed). To handle
multiple connections the script can spawn a handler subshell (with a dup of
the descriptor), and immediately close the socket and establish a new
listening socket. For example:
while true; do
exec 5<> /dev/tcp/localhost/: || die 1
(
while read -u 5 -r LINE; do
echo "Echo: ${LINE}" >&5
done
) &
# Close the socket
exec 5>&-
done
Admittedly, there is a very small window when an incoming connection might
get rejected while the handler is being spawned. However, with this model
the implementation is very straight forward and the interface it exposes is
basically the same as creating an outgoing socket. But the point here is
about adding a very useful utility to bash, not about allowing a bash
script to implement a high performance and fully robust server.
Regards,
Joel Martin (kanaka)
bug-bash@gnu.org
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-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL
-DHAVE_CONFIG_H -I. -I../bash -I../bash/include -I../bash/lib
-D_FORTIFY_SOURCE=2 -g -O2 -fstack-protector --param=ssp-buffer-size=4
-Wformat -Wformat-security -Werror=format-security -Wall
uname output: Linux treehug.home.kurahaupo.gen.nz 3.2.0-54-generic
#82-Ubuntu SMP Tue Sep 10 20:08:42 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu
Bash Version: 4.2
Patch Level: 25
Release Status: release
Description:
The value of $? after starting a backgrounded command is
inconsistent:
$? is unchanged after starting a sufficiently complex command, but
after starting a simpler command it is set to 0.
Determining "sufficiently complex" has been a bit tricky, but it
appears to depend only on the type of the top-level node of the
parse-tree:
An unbracketed conditional chain of pipelines will leave $? set to 0
regardless of the complexity of its components. Likewise invoking a
function will leave $? set to 0 no matter how complex the body of
the function may be.
Conversely, grouping even a single simple command with brackets or
using any control structure will leave $? untouched.
Repeat-By:
( (exit 42) ; :& echo $? ; wait ) # says 0
( (exit 42) ; : | : && : || : & echo $? ; wait ) # says 0
( (exit 42) ; : | if :; then :; fi & echo $? ; wait ) # says 0
( (exit 42) ; if :; then :; fi & echo $? ; wait ) # says 42
( (exit 42) ; { : ; } & echo $? ; wait ) # says 42
bug-bash@gnu.org
I wrote: > Description: > The value of $? after starting a backgrounded command is inconsistent: > $? is unchanged after starting a sufficiently complex command, but > after starting a simpler command it is set to 0. > From: Chet Ramey > Thanks for the report. The exit status of any asynchronous command is 0. > I will fix this for bash-4.3-release. > On Sat, 14 Dec 2013, dethrop...@web.de wrote: > I thought the value was only 0 if the fork/spawn was succesful. > i.e. if it fails for lack of resources or something it's non zero. > > or have I miss understood it's [sic] significance? I'm inclined to agree; there seems little point in arbitrarily always setting it to 0, when it could be used to provide information -- either the success-or-failure of the fork() (or spawn()), or simply retaining the previous status. While on the subject of exit status, any chance of being able to wait on a list of processes (or "any"), and get back the exit status and pid of the next one to finish? And to find out status of a stopped job? And to distinguish between an exit status of 129 and SIGHUP? (That lack had me rewriting a significant chunk of code in Perl when it was otherwise nearly finished in Bash.) I'm thinking of these additions: wait -o [JOB ...] wait for one child process out of the given list, or for any single child process if no list is given. sets $! to the pid of a child process which has terminated (or stopped), and sets $? in the normal manner pertaining to that process if no child process can be waited for, unsets $! and sets $? to 1 for ECHILD or 2 for EAGAIN if waiting for one-of-many but not "any" is unsupported, unsets $! and sets $? to 3 (-o is implied if one or more JOBs are given) wait -e shopt -s exitstatus when a child process is terminated or stopped by a signal, set $? to zero minus the signal number (rather than 128 plus the signal number), so that the full 8-bit range of exit statuses are distinguishable wait -t implies -o report a child process which has stopped or terminated sets $? to indicate the signal which cause the process to stop or terminate wait -tt like -t, but only report on a child process which has stopped, not terminated sets $? to 3 if unsupported by the OS Names for options are negotiable, but I chose to avoid '-s' because it's rather ambiguous in this context: single? signal? status? stopped? Long option names might also be nice. Waiting for multiple processes (but not all) presents some challenges; Perl implements this by waiting for all, and stashing the statuses until the script actually waits for them. -Martin
multi-line alias executed out of order
Configuration Information [Automatically generated, do not change]:Machine: x86_64OS: linux-gnuCompiler: gccCompilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu' -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I../bash -I../bash/include -I../bash/lib -D_FORTIFY_SOURCE=2 -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -Walluname output: Linux ubuntu 3.11.0-12-generic #19-Ubuntu SMP Wed Oct 9 16:20:46 UTC 2013 x86_64 x86_64 x86_64 GNU/LinuxMachine Type: x86_64-pc-linux-gnu Bash Version: 4.2Patch Level: 45Release Status: release Description:In a multi-line alias, where entries are separated by semi-colon, "source" commands are not executed in-step with all the other commands. After all the non "source" commands are executed, the "source" commands are executed in reverse order. See below for an example. Repeat-By: ubuntu@ubuntu:~$ cat script.sh#!/bin/bash(echo -n "$1 "; date +%S.%N)ubuntu@ubuntu:~$ alias foo1alias foo1='~/script.sh one; source ~/script.sh two; source ~/script.sh three; ~/script.sh four'ubuntu@ubuntu:~$ alias foo2alias foo2='~/script.sh one;source ~/script.sh two;source ~/script.sh three;~/script.sh four;'ubuntu@ubuntu:~$ foo1one 09.742581873two 09.745315889three 09.749212492four 09.761410711ubuntu@ubuntu:~$ foo2one 11.805819275four 11.819741270three 11.828260887two 11.829470548 Fix: Use a single-line alias. Or use the "&&" operator to chain commands (which changes the functionality to be short-circuit evaluations). Also verified this behavior on RHEL6 with bash 4.1.2(1). Thanks!Andrew Martin
Re: FW: multi-line alias executed out of order
Chet & Pierre: My apologies, the newlines were somehow removed by my email client. First, here's a properly formatted pastebin link: http://pastebin.com/raw.php?i=AhF89GfT And here's another attempt at a properly formatted report: 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-pc-linux-gnu' -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I../bash -I../bash/include -I../bash/lib -D_FORTIFY_SOURCE=2 -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -Wall uname output: Linux ubuntu 3.11.0-12-generic #19-Ubuntu SMP Wed Oct 9 16:20:46 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux Machine Type: x86_64-pc-linux-gnu Bash Version: 4.2 Patch Level: 45 Release Status: release Description: In a multi-line alias, where entries are separated by semi-colon, "source" commands are not executed in-step with all the other commands. After all the non "source" commands are executed, the "source" commands are executed in reverse order. See below for an example. Repeat-By: ubuntu@ubuntu:~$ cat script.sh #!/bin/bash (echo -n "$1 "; date +%S.%N) ubuntu@ubuntu:~$ alias foo1 alias foo1='~/script.sh one; source ~/script.sh two; source ~/script.sh three; ~/script.sh four' ubuntu@ubuntu:~$ alias foo2 alias foo2='~/script.sh one; source ~/script.sh two; source ~/script.sh three; ~/script.sh four; ' ubuntu@ubuntu:~$ foo1 one 09.742581873 two 09.745315889 three 09.749212492 four 09.761410711 ubuntu@ubuntu:~$ foo2 one 11.805819275 four 11.819741270 three 11.828260887 two 11.829470548 Fix: Use a single-line alias. Or use the "&&" operator to chain commands (which changes the functionality to be short-circuit evaluations). Also verified this behavior on RHEL6 with bash 4.1.2(1). Thanks, Andrew Martin On Tue, Dec 17, 2013 at 8:41 PM, Andrew Martin wrote: > > >> Date: Tue, 17 Dec 2013 10:14:23 -0500 >> From: chet.ra...@case.edu >> To: andrewcmar...@msn.com >> CC: bug-bash@gnu.org; b...@packages.debian.org; chet.ra...@case.edu >> Subject: Re: multi-line alias executed out of order > >> >> >> > Description:In a multi-line alias, where entries are separated by >> > semi-colon, "source" commands are not executed in-step with all the other >> > commands. After all the non "source" commands are executed, the "source" >> > commands are executed in reverse order. See below for an example. >> > Repeat-By: >> > ubuntu@ubuntu:~$ cat script.sh#!/bin/bash(echo -n "$1 "; date >> > +%S.%N)ubuntu@ubuntu:~$ alias foo1alias foo1='~/script.sh one; source >> > ~/script.sh two; source ~/script.sh three; ~/script.sh >> > four'ubuntu@ubuntu:~$ >> > alias foo2alias foo2='~/script.sh one;source ~/script.sh two;source >> > ~/script.sh three;~/script.sh four;'ubuntu@ubuntu:~$ foo1one >> > 09.742581873two >> > 09.745315889three 09.749212492four 09.761410711ubuntu@ubuntu:~$ foo2one >> > 11.805819275four 11.819741270three 11.828260887two 11.829470548 > >> > Fix: >> > Use a single-line alias. Or use the "&&" operator to chain commands >> > (which changes the functionality to be short-circuit evaluations). >> >> I can't reproduce this on Mac OS X or RHEL 5. You might also consider >> adding a few newlines into your report for readability. >> >> Chet >> -- >> ``The lyf so short, the craft so long to lerne.'' - Chaucer >> ``Ars longa, vita brevis'' - Hippocrates >> Chet Ramey, ITS, CWRU c...@case.edu http://cnswww.cns.cwru.edu/~chet/
Invalid pointer when misuse hash/string
Hello,
I've found this bug, when changed an string variable to hash, but left the
following code for test of zero code. It happens just inside function. I'm
using 4.1.2(1)-release,
BASH=/bin/bash
BASHOPTS=checkwinsize:cmdhist:expand_aliases:extquote:force_fignore:hostcomplete:interactive_comments:login_shell:progcomp:promptvars:sourcepath
BASH_VERSINFO=([0]="4" [1]="1" [2]="2" [3]="1" [4]="release"
[5]="i386-redhat-linux-gnu")
BASH_VERSION='4.1.2(1)-release'
The minimal example:
#!/bin/bash
function bug() {
declare -A hash=""
[ ! -z "$hash" ] && echo test
}
bug
*** glibc detected *** /bin/bash: munmap_chunk(): invalid pointer: 0x080fb47a
***
=== Backtrace: =
/lib/libc.so.6[0x3c9e31]
/bin/bash(hash_flush+0x63)[0x8092843]
/bin/bash(assoc_dispose+0x1f)[0x809c5cf]
/bin/bash[0x807860b]
/bin/bash(dispose_variable+0x57)[0x8078677]
/bin/bash(hash_flush+0x58)[0x8092838]
/bin/bash(pop_var_context+0x3e)[0x807743e]
/bin/bash(pop_context+0x18)[0x8077988]
/bin/bash[0x80959ef]
/bin/bash(run_unwind_frame+0x35)[0x8095655]
/bin/bash[0x8075450]
/bin/bash[0x8072dc0]
/bin/bash(execute_command_internal+0x8e0)[0x80737e0]
/bin/bash(execute_command+0x64)[0x80744e4]
/bin/bash(reader_loop+0x97)[0x8060797]
/bin/bash(main+0xd39)[0x805fe19]
/lib/libc.so.6(__libc_start_main+0xe6)[0x36fd26]
/bin/bash[0x805e021]
=== Memory map:
00253000-00254000 r-xp 00:00 0 [vdso]
00333000-00351000 r-xp fd:01 167869 /lib/ld-2.12.so
00351000-00352000 r--p 0001d000 fd:01 167869 /lib/ld-2.12.so
00352000-00353000 rw-p 0001e000 fd:01 167869 /lib/ld-2.12.so
00359000-004ea000 r-xp fd:01 167870 /lib/libc-2.12.so
004ea000-004ec000 r--p 00191000 fd:01 167870 /lib/libc-2.12.so
004ec000-004ed000 rw-p 00193000 fd:01 167870 /lib/libc-2.12.so
004ed000-004f rw-p 00:00 0
004f2000-004f5000 r-xp fd:01 167877 /lib/libdl-2.12.so
004f5000-004f6000 r--p 2000 fd:01 167877 /lib/libdl-2.12.so
004f6000-004f7000 rw-p 3000 fd:01 167877 /lib/libdl-2.12.so
005bd000-005d3000 r-xp fd:01 167889 /lib/libtinfo.so.5.7
005d3000-005d6000 rw-p 00015000 fd:01 167889 /lib/libtinfo.so.5.7
006ae000-006cb000 r-xp fd:01 164941
/lib/libgcc_s-4.4.7-20120601.so.1
006cb000-006cc000 rw-p 0001d000 fd:01 164941
/lib/libgcc_s-4.4.7-20120601.so.1
08047000-08118000 r-xp fd:01 196650 /bin/bash
08118000-0811d000 rw-p 000d fd:01 196650 /bin/bash
0811d000-08122000 rw-p 00:00 0
09bea000-09c0b000 rw-p 00:00 0 [heap]
b77e9000-b77eb000 rw-p 00:00 0
b77f4000-b77f6000 rw-p 00:00 0
bfbaf000-bfbc4000 rw-p 00:00 0 [stack]
Aborted (core dumped)
Best regard,
BruXy
?
history-search-backward documentation
Hi all, The man page says: history-search-backward Search backward through the history for the string of characters between the start of the current line and the point. This is a non-incremental search. That's not completely clear.. I think the following makes it much clearer: history-search-backward Search backward through the history for [ a line starting with ] the string of characters between the start of the current line and the point. This is a non-incremental search. The same goes for history-search-forward. -- Lincoln Martin <[EMAIL PROTECTED]> _ On the road to retirement? Check out MSN Life Events for advice on how to get there! http://lifeevents.msn.com/category.aspx?cid=Retirement ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
[50 character or so descriptive subject here (for reference)]
Configuration Information [Automatically generated, do not change]: Machine: sparc OS: solaris2.7 Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='sparc' -DCONF_OSTYPE='solaris2.7' -DCONF_MACHTYPE='sparc-sun-solaris2.7' -DCONF_VENDOR='sun' -DSHELL -DHAVE_CONFIG_H -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -I. -I. -I./lib -I/usr/local/depot/bash-2.03/include -g -O2 uname output: SunOS xn-sysadm-4 5.10 Generic_118822-30 sun4u sparc SUNW,Sun-Blade-100 Machine Type: sparc-sun-solaris2.7 Bash Version: 2.03 Patch Level: 0 Release Status: release Description: Bash may inadvertently execute a command that the user did not anticipate if STDIN is closed. Repeat-By: Unfortunately I can't construct a test case that doesn't need our local s/ware. But the problem is ... When bash reads input (in interactive mode) if it gets EOF it then executes any partial command that is in the input buffer - even though has not been entered by the user Fix: Incomplete commands should not be executed - they can have disasterous results. Example: If the command being entered were "rm -rf /home/username/tmp/junk" but the input is terminated just at the point where username has been entered then the user's /home dircetory is trashed. ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: terminating lines with accidental eof
Bob Proulx wrote: Martin Wheatley wrote: You also asked ... Is there an example of another command shell which handles this situation in a different and possibly better way? /bin/sh handles the situation correctly (in our opinion) On my system /bin/sh is a symlink to /bin/bash and behaves similarly. But on other systems it may be a symlink to other shells or may be a native posix shell implementation. Or on some systems trying to be antiquated it may be a classic Bourne shell. Many posix shell implementations are based upon the AT&T ksh. On the systems I tested they all behaved like bash does here. Bob We ran the same test against ksh on our systems and it behaves as we would expect (ie commands are only executed when the user hits enter and NOT executed when an I/O error occurs on the input stream). Our (Solaris) systems are shipped by the supplier with a classic bourne shell which is what our developers are required to use for production scripts however, for interactive use we all prefer bash for its more powerful, user friendly, features. Linking /bin/sh to /bin/bash does NOT maintain the bourne shell API. For example, Tradition using a traditional bourne shell ... xn-sysadm-4 $ sh xn-sysadm-4 $ PWD=fred xn-sysadm-4 $ cd / xn-sysadm-4 $ echo $PWD fred xn-sysadm-4 $ But with bash linked as "sh"... xn-CDO-2 $ cd /tmp xn-CDO-2 $ ln -s /bin/bash ./sh xn-CDO-2 $ ./sh xn-CDO-2 $ PWD=fred xn-CDO-2 $ cd / xn-CDO-2 $ echo $PWD / Note the difference in output from the echo. And there are other similar cases (notable the fact the the 'cd' builtin has options [-L|-P] in bash but not in /bin/sh) - which makes it very hard to write a shell script that is going to be executed either in a traditional /bin/sh or a /bin/sh that is a (sym-)link to /bin/bash. Thus we consider that having /bin/sh as a (sym-)link to /bin/bash to be a bad idea or that the implementation is wrong. -- +------+ | Martin Wheatley| Voice : +44-(0)1235 464784 | | CODAS | Mobile: +44-(0)468 894818 | | UKAEA, Culham Division | FAX : +44-(0)1235 464404 | | Culham Science Centre | | | Abingdon, Oxfordshire | | | OX14 3DB | E-mail: [EMAIL PROTECTED] | | United Kingdom | or: [EMAIL PROTECTED]| +--+ ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: terminating lines with accidental eof
Bob Proulx wrote: Please keep your replies to the mailing list to keep everyone involved in the discussion instead of singling out one individual. Also the mailing list is archived and others may search the archive to find previous discussions. Martin Wheatley wrote: The following can be used to reproduce the problem... * Start an xterm window * "su" to another user in this new xterm window * As this new user enter "touch /tmp/somefile" but do not hit ENTER * kill the xterm where the "su" was entered * The window evaporates but /tmp/somefile now exists! Thank you for making a small test case example. I was able to recreate that behavior on my system too. I am using the Debian su based upon the 'shadow' system in the 'login' package. Without the "su" there isn't a problem because the shell receives a SIGHUP and doesn't run the command. However, with the "su" the SIGHUP cannot be delivered to the shell with the partial command so it gets EOF and proceeds to execute what is in its buffer This really seems like a bug in the su program. When it receives a SIGHUP it should pass it on. Assuming that it is getting a SIGHUP. I did not look into the su and signal interaction. The 'su' command is irrelevant really, it is only a vehicle for demonstrating the problem with bash. Bash may get an I/O for any number of reasons. In reality the xterm may die for any number of reasons (workstation panic, Xserver reset, ...) We don't think it is right that any buffered user input should be actioned until the user explicitly requests the action (via the ENTER key). A small point. You are aware that the tty driver converts enter from the keyboard into a newline? See the tty driver 'icrnl' flag setting. Programs never read a carriage return. Programs actually read a newline character. This would, of course, break legacy programs which do not terminate their input with a newline. The concept of entering commands with a # at the start is well known to computing staff but to educate all users (bothe technical and non-technical) around the world of this issue is not realistic. It is a behavior gained by experience. Experience has sometimes been desribed as being the toothmarks left behind after being bitten. I suggested it because it is what I normally do when I am concerned about that a command may be accidentally executed before I am ready to execute it. It is not just commands that are, in themselves dangerous, that have to be considered, it is ALL commands since any partial command is going to do something different to what the user intends. It follows, therefore, that every command has to be commented until fully formed and, further, that command history browsing must, similarly, present "commented" commands in case thay are executed as a result of this issue. Clearly this is not a realistic solution. A realistic solution is for interactive bash NOT to execute a command until the user actions it (ie when bash executes a read() system call if the return code is <=0 then bash should shutdown). This is not a hypothetical situation - a user had "su'ed" and pre-typed a command and was waiting for permission to executed the command when the xterm window was accidentally killed by another user and the buffered input was executed - resulting in unscheduled (and costly) shutdown of some of our plant equipment. Thank you for providing that real world example. Surely the argument should not be as to whether the situation can or cannot happen (for whatever reason) - it clearly can (as we have experienced) and the code should be fixed to prevent this happening at all. Until you provided the example and the report of an actual occurrence there was no reason to believe this had ever happened. It is a continuing challenge to keep the system design functioning in good ways. It is a judgement call in most cases. I believe it was Andrew Koenig who proposed this thought problem. Have you ever cut yourself on a kitchen knife? Most of us have at oneype time or another. Can you design a knife so that it is now impossible to injure yourself with it? How effective will this new design be in the kitchen? Would you use such a knife yourself? I feel for you in the situation that you described. But I also feel that the user you mentioned pulled out a kitchen knife to cut some vegetables. They were holding it in their hand prepared and waiting to start chopping when someone accidentally bumped into them from behind when they were not looking. Because of this they cut something they did not want to cut with the knife they were holding. Actually I was only thinking about getting the knife out of the drawer - but it cut me anyway! There is only so much that can be done to make the world a safe place. I
printf builtin doesn't handle stdout errors correctly
Configuration Information [Automatically generated, do not change]:
Machine: i586
OS: linux
Compiler: gcc -I/usr/src/packages/BUILD/bash-2.05b
-L/usr/src/packages/BUILD/bash-2.05b/../readline-4.3
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i586'
-DCONF_OSTYPE='linux' -DCONF_MACHTYPE='i586-suse-linux' -DCONF_VENDOR='suse'
-DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -O2 -march=i586
-mcpu=i686 -fmessage-length=0 -Wall -D_GNU_SOURCE -Wall -pipe -g
-fbranch-probabilities
uname output: Linux biker 2.6.5-7.201-default #1 Thu Aug 25 06:20:45 UTC 2005
i686 i686 i386 GNU/Linux
Machine Type: i586-suse-linux
Bash Version: 2.05b
Patch Level: 0
Release Status: release
Description:
The printf builtin doesn't correctly handle errors generating from writing to
stdout, e.g. if the stdout file descriptor is closed. No error condition is
returned, and the fd error status isn't reset.
Repeat-By:
The following script demonstrates the problem:
printf x >&-
PRINTF_STAT=$?
echo
ECHO_STAT=$?
echo "printf: $PRINTF_STAT (should be 1), echo: $ECHO_STAT (should be 0)"
Fix:
The following patch adds echo's stdout error handling to printf.
Patch was tested successfully.
--- bash-2.05b/builtins/printf.def.orig 2002-05-13 20:36:04.0 +0200
+++ bash-2.05b/builtins/printf.def 2006-07-05 10:32:16.618545838 +0200
@@ -96,6 +96,11 @@ #define PRETURN(value) \
conv_buf = 0; \
} \
fflush (stdout); \
+ if (ferror (stdout)) \
+{ \
+ clearerr (stdout); \
+ return (EXECUTION_FAILURE); \
+} \
return (value); \
} \
while (0)
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
local undefined array expands to ASCII 127 instead of nothing.
Configuration Information [Automatically generated, do not change]:
Machine: i486
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i486'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i486-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL
-DHAVE_CONFIG_H -I. -I../bash -I../bash/include -I../bash/lib -g -O2
uname output: Linux gnap 2.6.15-28-686 #1 SMP PREEMPT Thu May 10 09:56:30 UTC
2007 i686 GNU/Linux
Machine Type: i486-pc-linux-gnu
Bash Version: 3.1
Patch Level: 17
Release Status: release
Description:
Hello,
When referencing local array "${uninitialized[*]}" within a
function, an ASCII 127 appears instead of nothing iff
${uninitialized[*]} is double-quoted and followed by something, as
in "${uninitialized[*]}foo"
The problem also occurs with 3.2.0(1)-release (home built, same arch)
Christophe
Repeat-By:
toto() {
typeset x
echo "${x[*]} "
}
toto | od -c
produces
000 177 \n
003
instead of :
000 \n
002
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
Broken parsing of quoted strings in backquotes
Configuration Information [Automatically generated, do not change]: Machine: sparc OS: solaris2.7 Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='sparc' -DCONF_OSTYPE='solaris2.7' -DCONF_MACHTYPE='sparc-sun-solaris2.7' -DCONF_VENDOR='sun' -DLOCALEDIR='/usr/local/depot/bash-3.2/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -g -O2 uname output: SunOS xn-sysadm-4 5.10 Generic_118833-33 sun4u sparc SUNW,Sun-Blade-100 Machine Type: sparc-sun-solaris2.7 Bash Version: 3.2 Patch Level: 0 Release Status: release Description: Parsing of quoted strings broken when string contains "# " sequence Repeat-By: Execution of... OKAY: echo "H" | sed -e 's/ /XXX/' OKAY: echo "H" | sed -e 's# #XXX#' OKAY: a=`echo "H" | sed -e 's/ /XXX/'` FAIL: a=`echo "H" | sed -e 's# #XXX#'` The fault has been introduced since version 3.1.17(1) We think this maybe related to item 31 of the COMPAT notes ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Follow up to previous report
Configuration Information [Automatically generated, do not change]: Machine: sparc OS: solaris2.7 Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='sparc' -DCONF_OSTYPE='solaris2.7' -DCONF_MACHTYPE='sparc-sun-solaris2.7' -DCONF_VENDOR='sun' -DLOCALEDIR='/usr/local/depot/bash-3.2/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -g -O2 uname output: SunOS xn-sysadm-4 5.10 Generic_118833-33 sun4u sparc SUNW,Sun-Blade-100 Machine Type: sparc-sun-solaris2.7 Bash Version: 3.2 Patch Level: 0 Release Status: release Description: The previous report stated the problem was with embedded strings containing "# ". We now think it is " #" Sorry Repeat-By: OKAY: a=`echo "H" | sed -e 's/H/# /'` FAILS: a=`echo "H" | sed -e 's/H/ #/'` ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
bash should retry a fork() returning EAGAIN
Hi all,
I'm using bash 3.1 on interix. There fork() may fail with EAGAIN if
e.g. several builds (configures) are running in parallel.
Unfortunately, fork() isn't retried and configure stops.
So I suggest adding this patch to bash which retries fork() when it
fails with EAGAIN. Idea is from pdksh. At least 3.2 doesn't have
such a patch, I didn't look though all the patches after 3.2, however.
Martin--- bash/jobs.c.origWed Jun 20 00:02:39 2007
+++ bash/jobs.c Sun Sep 16 23:29:41 2007
@@ -1611,6 +1611,7 @@
{
sigset_t set, oset;
pid_t pid;
+ unsigned int forksleep;
sigemptyset (&set);
sigaddset (&set, SIGCHLD);
@@ -1631,9 +1632,16 @@
#endif /* BUFFERED_INPUT */
/* Create the child, handle severe errors. */
- if ((pid = fork ()) < 0)
+ forksleep = 1;
+ while ((pid = fork ()) < 0 && errno == EAGAIN && forksleep < 32)
{
- sys_error ("fork");
+ if (sleep (forksleep)) break; /* break on signals, e.g. ^C */
+ forksleep <<= 1;
+}
+
+ if (pid < 0)
+{
+ sys_error ("fork");
/* Kill all of the processes in the current pipeline. */
terminate_current_pipeline ();
functions using process substitution error when exported (declare)
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: x86_64-redhat-linux-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
-O2 -g -pipe -m64
uname output: Linux stuxsh04 2.6.9-55.EL #1 Fri Apr 20 16:25:34 EDT
2007 x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-redhat-linux-gnu
Bash Version: 3.0
Patch Level: 15
Release Status: release
Description:
My apologies for not using a newer bash version, but I do not have
full control of my environment.
A gnu.bash.bug post on 2006-06-20T12:05 - titled "functions that
use process substitution are not exported correctly" from author
"Ittay Dror" has gone unanswered to date (that I can tell).
I have the same problem. That usenet posting is the only relevant
information I have found so far.
Is this truly a bug for our version of bash? I highly suspect that it
is, hence this email.
Repeat-By:
$ cat func
function func {
while read stuff; do
echo $stuff | grep nonsense
done < <(ps -ef)
echo Done func!
return 0
}
$ source func
$ declare -fx func
$ declare -F
declare -fx func
$ cat my.sh
echo In our shell.
func
echo Done with shell.
exit 0
$ ./my.sh
bash: func: line 2: syntax error near unexpected token `('
bash: func: line 2: ` done <<(ps -ef);'
bash: error importing function definition for `func'
In our shell.
./my.sh: line 3: func: command not found
Done with shell.
--
Jeffery Martin
piping output is delayed
hi! i'm stuck into a strange problem. i'm piping the output of one program into a textfile, and with a ruby script i'm parsing it. it works fine on my laptop, but on the pc i need it to install the output in the file is blocked every 10 seconds. the parser has therfore a delay of maximal 10 second which isn't ok for this application. both systems are in the same setup (debian sid, same kernel, bash version 3.2.39(1), tested with ubuntu too) and on the laptop i'm having just a delay of 1 second. id would be nice if anyone has a idea or a hint where i could search. google didn't help me too. bye...masc. -- ___ Surf the Web in a faster, safer and easier way: Download Opera 9 at http://www.opera.com Powered by Outblaze
Re: piping output is delayed
> > i'm stuck into a strange problem. i'm piping the output of one > > program into a textfile, and with a ruby script i'm parsing it. > > Did you mean redirecting to a text file? Piping implies that there is > a program reading from the pipe but then there wouldn't be any files > involved. yes. redirecting. > > it works fine on my laptop, but on the pc i need it to install the > > output in the file is blocked every 10 seconds. > > That sentence didn't parse for me. I am unable to understand it. i have the same setup on a laptop and a desktop ps. while it works on the laptop the redirecting to the textfile hast a too long delay on the desktop pc (same dist, same binaries). meanwhile i found a explanation at http://osdir.com/ml/linux.suse.programming-e/2005-08/msg00030.html i changed the main program (that one with the output) so that it writes direct into a textfile instead to stdout and this solves my problem. but i still don't know if it's possible and how i can modify the output buffer to stdout. thanx & bye...masc. -- ___ Surf the Web in a faster, safer and easier way: Download Opera 9 at http://www.opera.com Powered by Outblaze
Re: piping output is delayed
Ken Irving wrote: > Try comparing terminal settings on each platform, e.g., with stty -a, > and look into any differences. they are the same on both machines: [EMAIL PROTECTED]:~$ stty -a speed 38400 baud; rows 55; columns 160; line = 12; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0; -parenb -parodd cs8 -hupcl -cstopb cread -clocal -crtscts -ignbrk brkint ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff -iuclc -ixany imaxbel -iutf8 opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke bye...masc. -- ___ Surf the Web in a faster, safer and easier way: Download Opera 9 at http://www.opera.com Powered by Outblaze
${parameter+word} not documented in bash.info or bash(1)
I'm running bash 3.2.39(1)-release (under Ubuntu 8.04 (Hardy)
GNU/Linux). Neither bash.info or bash(1) documents parameter
expansion of the form:
${parameter+word}
This is different to ${parameter:+word}, is clearly implemented by
bash and is documented in the standard (The Open Group Base
Specifications Issue 6, IEEE Std 1003.1, 2004 Edition).
This may be useful:
http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_06_02
Thanks for bash, it rocks... :-)
peace & happiness,
martin
Re: ${parameter+word} not documented in bash.info or bash(1)
>>>>> "Paul" == Paul Jarc writes:
Paul> "Martin Schwenke" wrote:
>> Neither bash.info or bash(1) documents parameter expansion of
>> the form:
>>
>> ${parameter+word}
Paul> It's documented, but it's easy to miss. Just before the
Paul> list of parameter expansion forms is this paragraph:
Paul>In each of the cases below, word is subject to tilde
Paul>expansion, parameter expansion, command substitution,
Paul>and arithmetic expansion. When not performing
Paul>substring expansion, bash tests for a parameter that
Paul>is unset or null; omitting the colon results in a
Paul>test only for a parameter that is unset.
Ouch! Can I suggest that this documentation could be improved, since
it is so easy to miss and that I missed it at least 4 times when
actually looking for it? ;-)
I think the main issue is that when people use reference documentation
they tend to scan through it to find what they're looking for.
My suggestion would be to break the list of expansions before
substring expansion and insert a paragraph containing the above text.
Then, rather than necessarily listing all of the examples as the
standard does, perhaps provide a single example that compares the
effect of using the colon with the effect of excluding it.
The bash documentation is so long that I don't think adding this will
make it too long... :-)
peace & happiness,
martin
Re: ${parameter+word} not documented in bash.info or bash(1)
>>>>> "Bob" == Bob Proulx writes:
Bob> [...] Let me suggest that something similar to the following
Bob> addition would help here.
Bob> is unset or null; omitting the colon (':') results in a
Bob> test only for a parameter that is unset.
Bob> Then searches on ":" would also find that descriptive text
Bob> too.
I agree.
However, I would still suggest going further and including at least
one full example.
peace & happiness,
martin
Change in behaviour regarding subshell handling?
I noticed that bash has changed behaviour regarding subshell handling, breaking a script of mine. Now a script with -e fails when a subshell fails whereas it didn't before. I looked at the CHANGES file and couldn't find anything about this, so I wanted to ask if this change was intentional or if this is a bug. In fact, there's something in CHANGES that might be relevant but the description isn't really clear at all: l. Changed behavior of shell when -e option is in effect to reflect consensus of Posix shell standardization working group. Anyway, the test program and output is below. Take this script: set -e set -x echo "1" (echo "x" | grep -v "x") echo "2" On Debian lenny with 3.2.39(1)-release: foobar:~# bash t + echo 1 1 + grep -v x + echo x + echo 2 2 On Debian testing with 4.0.28(1)-release: foobar:~# bash t + echo 1 1 + echo x + grep -v x With dash (same output for lenny and testing): foobar:~# dash t + echo 1 1 + echo x + grep -v x + echo 2 2 -- Martin Michlmayr http://www.cyrius.com/
bash 4 parse error on here-document in $()
Configuration Information [Automatically generated, do not change]: Machine: i386 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i386' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i386-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 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i586 -mtune=generic -fasynchronous-unwind-tables uname output: Linux mslaptop 2.6.30.5-43.fc11.i586 #1 SMP Thu Aug 27 21:18:54 EDT 2009 i686 i686 i386 GNU/Linux Machine Type: i386-redhat-linux-gnu Bash Version: 4.0 Patch Level: 23 Release Status: release Description: Bash 4.0 errors on a here-document enclosed in $(). For example: x=$(cat <
Re: Change in behaviour regarding subshell handling?
* Chet Ramey [2009-09-24 08:29]: > > l. Changed behavior of shell when -e option is in effect to reflect > > consensus > > of Posix shell standardization working group. > > This behavior is one of the consequences of the Austin Group's interpretation. > Failures of user-specified subshells cause the shell to exit when set -e is > in effect. The key piece of the interpretation was to widen the scope of > commands that cause the shell to exit without an explicit exception from > simple commands to all commands. Thanks for the confirmation. Maybe CHANGES can be updated to list all the changes that were made as a consequence of the Austin Group's interpretation. -- Martin Michlmayr http://www.cyrius.com/
Re: bash 4 parse error on here-document in $()
Thank you for setting me straight! I had checked the POSIX spec before sending the report but missed the part about the delimiter having to be immediately followed by newline. Martin On 09/24/2009 06:39 AM, Chet Ramey wrote: Machine Type: i386-redhat-linux-gnu Bash Version: 4.0 Patch Level: 23 Release Status: release Description: Bash 4.0 errors on a here-document enclosed in $(). For example: x=$(cat< The shell is allowed to do this. A here-document is supposed to be terminated by a line containing the delimiter followed by a newline, not EOF. However, the behavior is useful enough that I changed the parser to support it in bash-4.1. Chet
Bug in array populating does not respect quotes
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-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDI$
uname output: Linux bristol 2.6.31 #10 SMP Thu Sep 10 17:59:29 CEST
2009 x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu
Bash Version: 4.0
Patch Level: 33 (debian bash-4.0-7)
Release Status: release
Description:
When populating an array from a string in a variable does not
handle quotes.
Repeat-By:
~$ declare -a samplearray
~$ samplearray=( x y 'z k')
~$ echo ${samplearray[2]}
z k
~$ samplestring="x y 'z k'"
~$ samplearray=( $samplestring )
~$ echo ${samplearray[2]}
'z
Re: Bug in array populating does not respect quotes
Thank you for all and sorry for the noise, you were right.
David.
On Thu, Sep 24, 2009 at 6:38 PM, Chris F.A. Johnson
wrote:
> On Thu, 24 Sep 2009, David Martin 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-pc-linux-gnu'
>> -DCONF_VENDOR='pc' -DLOCALEDI$
>> uname output: Linux bristol 2.6.31 #10 SMP Thu Sep 10 17:59:29 CEST
>> 2009 x86_64 GNU/Linux
>> Machine Type: x86_64-pc-linux-gnu
>>
>> Bash Version: 4.0
>> Patch Level: 33 (debian bash-4.0-7)
>> Release Status: release
>>
>> Description:
>> When populating an array from a string in a variable does not
>> handle quotes.
>>
>> Repeat-By:
>>
>> ~$ declare -a samplearray
>> ~$ samplearray=( x y 'z k')
>> ~$ echo ${samplearray[2]}
>> z k
>> ~$ samplestring="x y 'z k'"
>> ~$ samplearray=( $samplestring )
>
> eval "samplearray=( $samplestring )"
>
>> ~$ echo ${samplearray[2]}
>> 'z
>
> --
> Chris F.A. Johnson, webmaster <http://woodbine-gerrard.com>
> ===
> Author:
> Shell Scripting Recipes: A Problem-Solution Approach (2005, Apress)
>
return from function doesn't work when used in tail of pipeline
Configuration Information [Automatically generated, do not change]:
Machine: i486
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i486'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i486-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL
-DHAVE_CONFIG_H -I. -I../bash -I../bash/include -I../bash/lib -g -O2 -Wall
uname output: Linux rover 2.6.32-23-generic #37-Ubuntu SMP Fri Jun 11 07:54:58
UTC 2010 i686 GNU/Linux
Machine Type: i486-pc-linux-gnu
Bash Version: 4.1
Patch Level: 5
Release Status: release
Description:
I don't believe that the following behaviour is sensible or
matches the standard/documentation:
$ f () { { echo 1 ; echo 2 ; } | while read line ; do echo $line ;
return 0 ; done ; echo foo ; return 1 ; }
$ f
1
foo
$ echo $?
1
I expect f to return 0 from within the loop because a function
is executing.
I know the return 0 is in a subprocess at the end of a
pipeline... but that whole pipeline is running within a
function.
Naturally, the above is a contrived, minimal example. In
general I expect to be able to pipe the output of a command
into a loop and have the loop read lines until some condition
occurs, at which point my function returns. This could
obviously be done using a out=$(cmd) subprocess... except in
the case where cmd can block before producing all of its
output. Hence, the above seems convenient.
Repeat-By:
See above.
Fix:
I'd expect a fix to be tricky... which probably explains the
current behaviour. ;-)
peace & happiness,
martin
Re: return from function doesn't work when used in tail of pipeline
On Thu, 12 Aug 2010 08:16:21 -0400, Greg Wooledge
wrote:
> You already know the reason it behaves the way it does, so I'm not
> quite sure what answer you expect to receive. It's not a bug -- it's
> the normal behavior of every shell.
>
> imadev:~$ sh -c 'f() { (return 0); return 1; }; f; echo $?'
> 1
> [...]
> A return that's run in a subshell doesn't cause the parent shell to
> return.
I want it to either obey the principle of least surprise or be more
clearly documented! return is syntax so I expect it to do what its
documentation says it does...
I've been programming in shell for 20 years and this one surprised me.
I have a very strong Unix background and I clearly understand things
like not being able to set variables in subshells. It also surprised
other people, with similar backgrounds, who I showed it to. It is much
less obvious than many other shell subtleties.
There are some obvious exceptions to the strict Unix subprocess model in
shell programming (e.g. I can set a variable without exporting it and
see it in a subshell) and I expected this to be one of them.
Adding something like this to the documentation for return would
probably be enough:
Note that many compound commands that might be used in a function
cause subshells to be created. In this subshells return will behave
as though it is being used outside a function.
> Use a process substitution in bash:
>
> f() {
> while IFS= read -r somevar; do
> [[ $somevar = *quit* ]] && return 0
> printf '%s\n' "$somevar"
> done < <(grep foo bar)
> return 1
> }
[...]
> The process substitution doesn't require cmd to finish before it
> starts producing data. It's equivalent to a pipeline, except that
> the reader doesn't need to be in a subshell.
Thanks, I'll use that unless I can come up with something more
portable! :-)
peace & happiness,
martin
ps occasionally reports: "31125 49710-06:28:15"
Configuration Information [Automatically generated, do not change]: Machine: i586 OS: linux Compiler: gcc -I/usr/src/packages/BUILD/bash-2.05b -L/usr/src/packages/BUILD/bash-2.05b/../readline-4.3 Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i586' -DCONF_OSTYPE='linux' -DCONF_MACHTYPE='i586-suse-linux' -DCONF_VENDOR='suse' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -O2 -march=i586 -mcpu=i686 -fmessage-length=0 -D_GNU_SOURCE -Wall -pipe -g -fbranch-probabilities uname output: Linux dsklinux 2.4.21-273-athlon #1 Mon Jan 17 13:03:46 UTC 2005 i686 athlon i386 GNU/Linux Machine Type: i586-suse-linux Bash Version: 2.05b Patch Level: 0 Release Status: release Description: Using the command line: ps --no-headers -o"\%p \%t" -C"exim4" via perl's backtick function. ps occasionally reports something like: "31125 49710-06:28:15" The process number is correct AFAIK, but the uptime is miles too big and seems to vary between: 49710-06:28:01 and 49710-06:28:15. Repeat-By: Repeating the command until it happens again. -- Regards, Martin Nicholas. E-mail: [EMAIL PROTECTED] ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
ps occasionally reports: "31125 49710-06:28:15"
Configuration Information [Automatically generated, do not change]: Machine: i386 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i386' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i386-pc-linux-gnu' -DCONF_VENDOR='pc' -DSHELL -DHAVE_CONFIG_H -I. -I/home/doko/$ uname output: Linux gu.tvscience.co.uk 2.4.27-0.3um #1 Thu Sep 2 11:39:16 GMT 2004 i686 unknown Machine Type: i386-pc-linux-gnu Bash Version: 2.05a Patch Level: 0 Release Status: release Description: Using the command line: ps --no-headers -o"\%p \%t" -C"exim4" via perl's backtick function. ps occasionally reports something like: "31125 49710-06:28:15" The process number is correct AFAIK, but the uptime is miles too big and seems to vary between: 49710-06:28:01 and 49710-06:28:15. The Configuration Information originally sent to bug-bash@gnu.org was incorrect. The correct version is above. My humble apologies. Repeat-By: Repeating the command until it happens again. -- Regards, Martin Nicholas. E-mail: [EMAIL PROTECTED] ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Strange behaviour when sending SIGTERM to bash
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
Strange (wrong?) behaviour of "test ! -a file"
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 ( file )" in bash while
it results in "! ( -a file )" in coreutils' test.
Given all the problems with "-a" as the AND and the fact that POSIX
doesn't have a "-a" filetest I suggest to mark "-a file" as strongly
deprecated in the help page or remove it at all from test rather than
thinking about if this is a bug and how to fix it.
There's a related discussion in the coreutils mailing list:
http://lists.gnu.org/archive/html/bug-coreutils/2018-10/msg00117.html
Regards,
Martin
address@hidden:~/langs/sh$ cat minus-a
#!/bin/bash
set -o nounset
file=/etc/passwd
echo $BASH_VERSION
/usr/bin/[ --version | head -1
for cmd in test /usr/bin/test
do
for op in -a -e
do
printf "%-30s -> " "$cmd ! $op $file" ; $cmd ! $op $file ; echo $?
done
done | cat -n
address@hidden:~/langs/sh$ ./minus-a
4.4.12(1)-release
[ (GNU coreutils) 8.26
1 test ! -a /etc/passwd -> 0
2 test ! -e /etc/passwd -> 1
3 /usr/bin/test ! -a /etc/passwd -> 1
4 /usr/bin/test ! -e /etc/passwd -> 1
bash-5.0: case command bug
Hi, I have a problem with bash 5.0: - machine1 ~ # bash --version GNU bash, version 5.0.0(1)-release (x86_64-pc-linux-gnu) Copyright (C) 2019 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software; you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. machine1 ~ # case "a-b" in *-*-*) echo "This is a BUG" ;; *) echo "This is not a BUG" ;; esac This is a BUG - as opposed to bash 4: - machine2 ~ # bash --version GNU bash, version 4.4.23(1)-release (x86_64-pc-linux-gnu) Copyright (C) 2016 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software; you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. machine2 ~ # case "a-b" in *-*-*) echo "This is a BUG" ;; *) echo "This is not a BUG" ;; esac This is not a BUG - Is it a bug or a feature? Because for me it completely crippled Gentoo compilation system, as the config.sub does not work correctly anymore. Which in turn means that any automake building does not work as it results to: - machine1 ~ # /usr/share/gnuconfig/config.sub x86_64-pc-linux-gnu Invalid configuration `x86_64-pc-linux-gnu': machine `x86_64-pc' not recognized - while it should do - machine2 # /usr/share/gnuconfig/config.sub x86_64-pc-linux-gnu x86_64-pc-linux-gnu - Thank you. Regards, Martin
Re: bash-5.0: case command bug
On 1/18/19 1:44 PM, Chet Ramey wrote: On 1/17/19 6:21 PM, Drab Martin wrote: Hi, I have a problem with bash 5.0: - machine1 ~ # bash --version GNU bash, version 5.0.0(1)-release (x86_64-pc-linux-gnu) Copyright (C) 2019 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software; you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. machine1 ~ # case "a-b" in *-*-*) echo "This is a BUG" ;; *) echo "This is not a BUG" ;; esac This is a BUG I tried this on Gentoo. ec2-user@ip-172-31-8-83 ~/build/bash-5.0 $ cat x1 case "a-b" in *-*-*) echo "This is a BUG" ;; *) echo "This is not a BUG" ;; esac ec2-user@ip-172-31-8-83 ~/build/bash-5.0 $ ./bash ./x1 This is not a BUG ec2-user@ip-172-31-8-83 ~/build/bash-5.0 $ uname -a Linux ip-172-31-8-83.ec2.internal 4.9.76-gentoo-r1 #1 SMP Mon Mar 5 06:42:49 UTC 2018 x86_64 Intel(R) Xeon(R) CPU E5-2676 v3 @ 2.40GHz GenuineIntel GNU/Linux ec2-user@ip-172-31-8-83 ~/build/bash-5.0 $ ./bash --version GNU bash, version 5.0.0(1)-release (x86_64-pc-linux-gnu) Copyright (C) 2019 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software; you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. ec2-user@ip-172-31-8-83 ~/build/bash-5.0 $ ./bash bash-5.0$ case "a-b" in *-*-*) echo "This is a BUG" ;; *) echo "This is not a BUG" ;; esac This is not a BUG bash-5.0$ exit exit So you installed bash-5.0 as /bin/bash? And kept the /bin/sh symlink? And still got these results? ec2-user@ip-172-31-8-83 ~/build/bash-5.0 $ sed 2q /usr/share/gnuconfig/config.sub #! /bin/sh # Configuration validation subroutine script. ec2-user@ip-172-31-8-83 ~/build/bash-5.0 $ ls -l /bin/sh lrwxrwxrwx 1 root root 4 Mar 1 2018 /bin/sh -> bash Because when I run bash-5.0 against that configure script, I get: ec2-user@ip-172-31-8-83 ~/build/bash-5.0 $ ./bash /usr/share/gnuconfig/config.sub x86_64-pc-linux-gnu x86_64-pc-linux-gnu Hi Chet, well, this is odd, because I tried again (manually patched the config.sub, so that it worked even if the bug is there) and tried re-compiling bash-5.0 the standard way in Gentoo and the bug is still there. machine1 ~ # emerge -av1 bash ... Calculating dependencies ... done! [ebuild R] app-shells/bash-5.0::gentoo USE="net nls plugins (readline) -afs -bashlogger -examples -mem-scramble" 0 KiB ... machine1 ~ # uname -a Linux xenomorph 4.19.9-gentoo #1 SMP PREEMPT Sun Dec 16 00:43:14 CET 2018 x86_64 Intel(R) Core(TM) i7-3820QM CPU @ 2.70GHz GenuineIntel GNU/Linux machine1 ~ # ls -l /bin/bash -rwxr-xr-x 1 root root 1364664 Jan 18 19:20 /bin/bash machine1 ~ # ls -l /bin/sh lrwxrwxrwx 1 root root 4 Jan 18 19:20 /bin/sh -> bash machine1 ~ # /bin/bash --version GNU bash, version 5.0.0(1)-release (x86_64-pc-linux-gnu) Copyright (C) 2019 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software; you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. machine1 ~ # /bin/bash -c 'case "a-b" in *-*-*) echo "This is a BUG" ;; *) echo "This is not a BUG" ;; esac' This is a BUG machine1 ~ # /usr/share/gnuconfig/config.sub.orig x86_64-pc-linux-gnu Invalid configuration `x86_64-pc-linux-gnu': machine `x86_64-pc' not recognized The config.sub.orig is the renamed original, which I had to temporarily replace with the patched variant. machine1 ~ # diff -Nau /usr/share/gnuconfig/config.sub.orig /usr/share/gnuconfig/config.sub --- /usr/share/gnuconfig/config.sub.orig2019-01-18 04:42:40.962952315 +0100 +++ /usr/share/gnuconfig/config.sub 2019-01-18 19:17:18.879097624 +0100 @@ -361,10 +361,10 @@ basic_machine=$basic_machine-pc ;; # Object if more than one company name word. - *-*-*) - echo Invalid configuration \`$1\': machine \`$basic_machine\' not recognized 1>&2 - exit 1 - ;; +# *-*-*) +# echo Invalid configuration \`$1\': machine \`$basic_machine\' not recognized 1>&2 +# exit 1 +# ;; # Recognize the basic CPU types with company name. 580-* \ | a29k-* \ Could it perhaps be a problem of some library, bash is using to work with the text or something? Or a problem of miscompiling GCC perhaps? machine1 ~ # gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/8.2.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-8.2.0-r6/work/gcc-8
@Q breaks set -o nounset
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; echo ${x/a/b}'
bash: x: unbound variable
"GNU bash, version 5.0.0(1)-release (x86_64-pc-linux-gnu)" behaves
identically.
So, @Q breaks the 'set -o nounset'.
Is this intended?
I like using @Q for output of variables with unknown content - is there a
better way to do this?
Best regards,
Martin
Re: T/F var expansion?
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
Output of jobs wrong
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: $ help -s % %: job_spec [&] $ sleep 10 ^C [Interrupted with CTRL-C - maybe "exactly" after 10 seconds] $ sleep 100 & $ sleep 200 & $ sleep 30 & $ % ^C [Interrupted with CTRL-C] $ sleep 300 & $ jobs [1] Running sleep 10 & [2]- Running sleep 10 & [3]+ Running sleep 300 & So job 1 and job 2 listed the wrong argument. I checked this from a second terminal with 'ps -lf' - and there were three sleep with arguments 100, 200 and 300... Systeminfo: $ uname -a Linux martnix4 4.9.0-9-amd64 #1 SMP Debian 4.9.168-1+deb9u5 (2019-08-11) x86_64 GNU/Linux $ echo $BASH_VERSION 4.4.12(1)-release Sorry, I would like to be more helpful - but maybe someone else has noticed a similiar problem or has an idea with the sources in mind. Best regards, Martin
Backslash missing in brace expansion
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 (between [ and ] in ASCII code) is missing in
brace expansion. The same behaviour seems to be found in bash 5.0.
Best regards,
Martin
Re: Backslash missing in brace expansion
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-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 (between [ and ] in ASCII code) is
> > missing in brace expansion. The same behaviour seems to be found in
> > bash 5.0.
>
> It's an unquoted backslash, which is removed by quote removal when the
> words are expanded. Look at the extra space between `[' and `]'; that's
> the null argument resulting from the unquoted backslash.
Yes - sure. But then I'm wondering why the unquoted backtick doesn't
start command substitution:
$ echo {Z..a}
Z [ ] ^ _ ` a
$ echo Z [ \ ] ^ _ ` a
>
Best regards,
Martin
Re: Backslash missing in brace expansion
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
Re: Two states of empty arrays
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 useful questions (Is there an element in the array? Is
there a value for a given key?) can be answered in a simpler way:
#!/bin/bash
set -o nounset
# From what I learned today it seems to be good practice to always
# assign and empty array to when declaring an associative array:
declare -A assoc=()
echo ${#assoc[@]} # Are there elements in it?
assoc[key1]=val1
assoc[key2]=
for key in key1 key2 key3; do
if [[ -n ${assoc[$key]+isset} ]]; then
echo "Element for $key is set"
else
echo "No Element for $key"
fi
done
Best regards,
Martin
Re: Fwd: read -t 0 fails to detect input.
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. It's not usable in a pipe in the way you try, but this is caused by the principles of a pipe, not by a bug in read. while ! read -t 0; do echo 'It works as intended - just press RETURN to see why' done Best regards, Martin
Assign Default Value expansion inserts ASCII DEL for empty 'word'
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
-Wno-parentheses -Wno-format-security
uname output: Linux arctic 5.5.6-artix1-1 #1 SMP PREEMPT Tue, 25 Feb
2020 14:57:48 + x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu
Bash Version: 5.0
Patch Level: 16
Release Status: release
Description:
Out of nowhere, bash inserts an ascii DEL in the first expansion. That
is very unexpected and shouldn't be there.
Repeat-By:
$ unset foo bar
$ echo "${foo:=}/baz:${foo}/bat"|xxd
: 7f2f 6261 7a3a 2f62 6174 0a ./baz:/bat.
$ echo "${foo:=$bar}/baz:${foo}/bat"|xxd
: 7f2f 6261 7a3a 2f62 6174 0a ./baz:/bat.
First lines of examples/startup-files/bashrc
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 file if it is invoked non-interactively. But, as far as I understand, a non-interactive bash doesn't read ~/.bashrc at all - so shouldn't we just omit them? Best regards, Martin
Re: Difference between EPOCHREALTIME and EPOCHSECONDS
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().
I didn't believe it ;-) but running
time_gettimeofday.c:
#include
#include
#include
int main(int argc, char *argv[]) {
struct timeval tv;
time_t t;
struct timespec sleep;
sleep.tv_sec = 0;
sleep.tv_nsec = 100;
for (int i=0; i<1001; i++) {
gettimeofday(&tv, NULL);
t = time(NULL);
printf("%d.%.6d %d %d\n", tv.tv_sec, tv.tv_usec, t, tv.tv_sec-t);
nanosleep( &sleep, NULL );
}
return 0;
}
with
gcc -o time_gettimeofday time_gettimeofday.c && ./time_gettimeofday |
egrep '\.(00|99)
shows it is right...
Thanks and best regards,
Martin
Re: Command substitution
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 right-hand side of an variable assignment*, word splitting and filename expansion are not performed on the results. at end of 3.5.4. Best regards, Martin
Re: echo builtin doesn't handle end-of-options flag
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$'\n' will print a -n in the bash. Best regards Martin
Bad substitution breaks conditional statement
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)
x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu
Bash Version: 5.0
Patch Level: 3
Release Status: release
Description:
It looks as if a bad substitution detected inside a case of if continues the
script flow immediately after the conditional statement skipping the remaining
statements inside the conditional. Please take a look into section "Repeat-By:".
I detected this when running a script containing "${OPTARG@Q}" with a bash
4.1.5 where @Q is not yet supported - the script continued to run in a bad
manner so this bug might cause real troubles...
Repeat-By:
schulte@t1:~$ cat bad_substitutions_breaks_conditional
#!/bin/bash
x=y
case $x in
y)
echo "x has value ${x@q} - stop now!"
exit 1;;
esac
echo "running"
if [[ $x == y ]]; then
echo "x has value ${x@q} - stop now!"
exit 1
fi
echo "still running"
echo "x has value ${x@q} - stop now!"
exit 1
echo "and running"
schulte@t1:~$ ./bad_substitutions_breaks_conditional
./bad_substitutions_breaks_conditional: line 6: x has value ${x@q} - stop now!:
bad substitution
running
./bad_substitutions_breaks_conditional: line 11: x has value ${x@q} - stop
now!: bad substitution
still running
./bad_substitutions_breaks_conditional: line 15: x has value ${x@q} - stop
now!: bad substitution
Re: Bad substitution breaks conditional statement
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 compound commands. > Bash has always behaved this way. > > 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. Best regards Martin
Re: Bad substitution breaks conditional statement
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
> differently from other invalid parameter expansions?
For sure all syntactical errors on parameter expansions should be handled in
the same way - I suggest they should be considered as fatal errors.
Consider the following script:
>>>
#!/bin/bash
echo "${x;:-}" ; echo "Not executed"
echo "Executed"
echo "${x:-}" ;; echo "Not executed"
echo "Not executed"
<<<
It just a source of problems that the two syntactical errors (both caused by an
extra semicolon) lead to different behaviour.
Martin
