cursor positioning errors
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 -g -O2 -Wall uname output: Linux psychosis 2.6.27.3 #1 SMP Wed Oct 22 23:21:57 EDT 2008 x86_64 GNU/Linux Machine Type: x86_64-pc-linux-gnu Bash Version: 3.2 Patch Level: 39 Release Status: release Description: There are some cursor positioning errors that I occasionally run into, particularly when using reverse-isearch. While trying to reproduce it, I noticed that this seems dependent on the locale, at least. Repeat-By: Make sure you have en_US and en_US.UTF-8 locales generated. $ env -i LC_CTYPE=en_US PS1='\[\e[0m\]12345' INPUTRC=/dev/null bash --norc --noprofile Note that the cursor appears at the end of the prompt, after the "5", as expected. $ env -i LC_CTYPE=en_US.UTF-8 PS1='\[\e[0m\]12345' INPUTRC=/dev/null bash --norc --noprofile Now the cursor appears in the middle of the prompt, after the "1". -jim
Fixing coproc race condition bug
#!/usr/bin/env bash
set -e -u
coproc date
sleep 1
# In bash 5.0.17, this aborts with "COPROC[0]: unbound variable"
# if the coproc exits before the main process gets here.
read -u ${COPROC[0]} line
# Discussion:
#
# To prevent this race condition, Bash must not close the coproc output pipe
# when the coprocess exits, but keep it open until the main process has had
# a chance to read buffered data.
#
# However bash must prevent unbounded leaking file descriptors/pipes
# -- see ideas below.
#
# (The coproc *input* pipe can be closed when the coprocess exits because
# it can no longer be used -- a SIGPIPE error would occur if written to.)
#
# SUGGESTED STRATEGY:
#
# Close the coproc output pipe after the main process reads EOF from it.
# --This handles all cases where the coproc writes but does not read.
#
# Close both pipes before executing another 'coproc' command with the
# same effective NAME, i.e. which will overwrite the "COPROC" array.
# --This prevents leaking fds in loops or repetitive code.
#
# Close both pipes and undef COPROC if the main process reaps a coproc
# child with 'wait'.
# --This allows scripts to explicitly release coproc resources
#
# The above is probably good enough.
#
# Another tweak would be define a "no-op" coproc command to be a special
# case which does not create new pipes, but only closes any previous pipes
# associated with the same NAME (as described above).
# e.g.
# coproc; # implied NAME is "COPROC"
# coproc NAME {}; # explicit NAME
#
# However this would be unnecessary (i.e. redundant) if doing 'wait' on
# a coproc child implicitly closes it's pipes.
#
# Note: Ignore errors when closing pipes, as the user might have
manually closed
# the fds using 'exec {varname}>&-' or similar.
#
#(END)
Re: Fixing coproc race condition bug
On 10/24/21 1:44 PM, Jim Avera wrote:
# Note: Ignore errors when closing pipes, as the user might have
manually closed
# the fds using 'exec {varname}>&-' or similar.
Actually this isn't a good idea because the fd might have been re-used
for something else; so an error should be reported to make that
bug-condition noticeable so it can be fixed.
Instead, bash should search all active CPROC variables for any file
descriptors being closed explicitly, and undef the corresponding COPROC
slot; that will prevent bash from calling close() on a previously-closed
file descriptor.
-Jim
"here document" causing failures. Implementation is inconsistent and not documented.
Bug: Trailing white space after the delimiting tag cause the here document to fail with an error like /./: line : warning: here-document at line delimited by end-of-file (wanted `msg_end')Trailing white space/ Trailing white space after the start of the here statement is ignored. This doesn't appear to be documented anywhere. All the material I have seen on here documents I've seen so far never mention the requirement that the tag a the end must be free of any trailing white space. _Inconsistency _: If white space after the start of the here statement is permitted and ignored then it should be the same with a tag terminating the here statement. Test script ___ #/usr/bin/bash cat << msg_end Bash version $(bash --version) msg_end ___ > *# This fails* *> cat -A test_here* #/usr/bin/bash$ cat << msg_end $ $ Bash version$ $(bash --version)$ $ msg_end $ > > *# This works* *> cat -A test_here* #/usr/bin/bash$ cat << msg_end $ $ Bash version$ $(bash --version)$ $ msg_end$ > _ Tested on these, all virtual machines excdept MSYS2 which runs alongside MS Win10. MS WSL2 is a virtual machine. Output is from bash --version and uname -a commands. Zorin Linux - GNU bash, version 5.0.17(1)-release (x86_64-pc-linux-gnu) Linux 5.15.0-78-generic #85~20.04.1-Ubuntu SMP Mon Jul 17 09:42:39 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux MS Windows WSL2 (Ubuntu) GNU bash, version 5.1.16(1)-release (x86_64-pc-linux-gnu) Linux 5.15.90.1-microsoft-standard-WSL2 #1 SMP Fri Jan 27 02:56:13 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux MS Windows MSYS2 (derived from Cygwin) GNU bash, version 5.2.15(1)-release (x86_64-pc-msys) MSYS_NT-10.0-19045 bob 3.4.6.x86_64 2023-02-15 18:03 UTC x86_64 Msys Oracle on ARM GNU bash, version 5.1.16(1)-release (aarch64-unknown-linux-gnu) Linux ub01 5.15.0-1034-oracle #40-Ubuntu SMP Wed Apr 19 16:10:04 UTC 2023 aarch64 aarch64 aarch64 GNU/Linux
Re: bug#9129: Built-in printf Sits Awkwardly with UDP.
retitle 9129 printf: RFE: reject field width larger than INT_MAX tags 9129 notabug thanks Eric Blake wrote: > [adding coreutils] > > On 07/20/2011 07:34 AM, Ralph Corderoy wrote: >> BTW, the code for the built-in printf has a bug. For negative >> field-widths it negates a negative integer without checking it will fit. >> E.g. on this 64-bit machine >> >> $ printf '%-9223372036854775808s.\n' foo >> foo. >> $ > > Coreutils' printf shares this misfortune. Sadly, it might even be a > bug in the underlying glibc printf(), although I haven't tried to > write a test program to check that, yet. This is not about a negative field width. You can induce misbehavior without the "-". The "-" is just the left-alignment option. Compare these: $ printf '_%2s_\n' o _ o_ $ printf '_%-2s_\n' o _o _ The trouble is that whenever you specify a field width larger than INT_MAX, you enter into unspecified (or was it undefined?) territory. Applications like printf or bash's built-in printf should be able to detect and diagnose such questionable inputs before passing the offending directive to an underlying *printf function. I've marked this "not a bug" but have left the ticket open, since I see it as a reasonable request for improvement.
Russian translation for GNU Bourne-Again SHell page
Hello, we've translated to Russian your great documentation page http://tiswww.case.edu/php/chet/bash/bashtop.html Please place a link to translated article from your site: http://tiswww.case.edu/php/chet/bash/bashtop.html Text of link: http://www.portablecomponentsforall.com/edu/gnu-bourne-again-shell-be/";>Russian translation provided by http://www.portablecomponentsforall.com ">PortableComponentsForAll Best Regards, Jim
set -e in (subshells) does not work independently of outer context
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 -g -O2 -Wall uname output: Linux lxjima 3.0.0-15-generic #25-Ubuntu SMP Mon Jan 2 17:44:42 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux Machine Type: x86_64-pc-linux-gnu Bash Version: 4.2 Patch Level: 10 Release Status: release Description: set -e in (subshells) should be independent of surrounding context. The man page says "[set -e] applies to the shell environment and each subshell environment separately", but actually set -e is prevented from working in a (subshell) if it is disabled in the surrounding context. Repeat-By: set +e ( set -e cat /non/existent/path echo "Did not abort. Isn't this a bug?" ) || true Discussion: Set -e rightly ignores errors in the outer shell because of the || expression, but it is not clear why that should have any effect inside the (subshell) expression. For example, if you say set -e set -o errtrace trap 'echo -e "Command failed unexpectedly at \c"; caller 0; exit 1' ERR then you might hope to find out the location of any unexpected command failures. However, commands which fail in (subshell code) like above will not cause the trap because they will not abort the subshell. In summary, shouldn't set -e in (subshell code) operate independently of the surrounding context?
printf -v array[$i] "%b" "" poisons array causing segfault later
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
-g -O2 -Wall
uname output: Linux lxjima 3.0.0-15-generic #26-Ubuntu SMP Fri Jan 20
17:23:00 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu
Bash Version: 4.2
Patch Level: 10
Release Status: release
Description:
If printf is used to set an array element, and the format
contains %b and the corresponding arg is empty, then the
array is somehow poisoned such that later use of array[*] or [@]
causes a segfault.
No segfault occurs if the string interpolated by %b is not empty,
or if %s is used instead of %b (in those cases, setting an array
element with printf seems to work fine).
Repeat-By:
bash -c 'declare -a ary; printf -v ary[0] "%b" ""; x="${ary[*]}"'
#!/bin/bash
declare -a ary
printf -v ary[0] "%b" ""
echo "after printf"
x="${ary[*]}" # segfaults here
echo "after use"
using the variable name, GROUPS, in a read list
FYI, if I attempt to read into the built-in array variable, GROUPS, this doesn't work: $ bash -c 'while read GROUPS; do echo $GROUPS; done < /etc/passwd'|wc -l 0 Comparing with dash, I see what the author expected, i.e., that the while loop iterates once per line in /etc/passwd: $ dash -c 'while read GROUPS; do echo $GROUPS; done < /etc/passwd'|wc -l 57 With bash, I can work around that by first doing "unset GROUPS". Is there a moral here, other than to avoid using special variable names? Probably to prefer lower-case variable names.
backslash at end of input causes eval parse error
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='/usr/local/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -g -O2 uname output: Linux lxjima 3.11.0-26-generic #45-Ubuntu SMP Tue Jul 15 04:02:06 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux Machine Type: x86_64-unknown-linux-gnu Bash Version: 4.3 Patch Level: 0 Release Status: release Description: A \ is supposed to be ignored, but if it occurs at the very end of the input then it causes a prior eval containing an array assignment to be mis-parsed. However if the eval contains something other than an array assignment then no error occurs. Repeat-By: #!/bin/bash PATH=/path/to/bash-4.3:$PATH; export PATH type bash # This one fails with the following error: # bash: eval: line 1: syntax error near unexpected token `foo' # echo "*** eval containing array assignment; backslash-newline (FAILS)" bash -ex <<'EOF' eval "array=(foo bar)" ; echo AAA\ EOF # But these work fine... # echo "*** eval containing something else; backslash-newline (works)" bash -ex <<'EOF' eval "scalar='(foo bar)'" ; echo AAA\ EOF echo "*** eval containing array assignment; backslash-newline; text (works)" bash -ex <<'EOF' eval "array=(foo bar)" ; echo AAA\ BBB EOF
Final backslash causes array assignment mis-parse in previous eval
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='/usr/local/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -g -O2 uname output: Linux lxjima 3.11.0-26-generic #45-Ubuntu SMP Tue Jul 15 04:02:06 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux Machine Type: x86_64-unknown-linux-gnu Bash Version: 4.3 Patch Level: 0 Release Status: release Description: NOTE: This repeats (approximately) a bug I sent a few minutes ago, but with an invalid From: address. Most likely my ISP dropped the message as spam, but if not, please accept my appoligies for the dup. \ is supposed to be effectively ignored, but if it appears at the end of the script then parse errors sometimes occur with previous statements. In particular eval "array=(values...)" is mis-parsed if a subsequent statement ends with and there is nothing further in the script. However, no error occurs if the eval contains something other than an array assignment. Or if something follows the \. Repeat-By: #!/bin/bash PATH=/home/jima/ptmp/downloads/bash-4.3:$PATH; export PATH ; type bash # This one shows the problem # An error occurs: # bash: eval: line 1: syntax error near unexpected token `foo' # echo "*** eval containing array assignment; backslash-newline (FAILS)" bash -ex <<'EOF' eval "array=(foo bar)" ; echo AAA\ EOF # But these work fine... echo "*** eval containing something else; backslash-newline (WORKS)" bash -ex <<'EOF' eval "scalar='(foo bar)'" ; echo AAA\ EOF echo "*** eval containing array assignment; backslash-newline; text (works)" bash -ex <<'EOF' eval "array=(foo bar)" ; echo AAA\ BBB EOF
"source" cmd creates entry in BASH_SOURCE etc. only if within function
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='/usr/local/share/locale' -DPACKAGE='bash'
-DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -g -O2
uname output: Linux lxjima 3.11.0-26-generic #45-Ubuntu SMP Tue Jul 15 04:02:06
UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-unknown-linux-gnu
Bash Version: 4.3
Patch Level: 0
Release Status: release
Description:
The "source" (or ".") command, if invoked from within a function,
creates a call frame, setting $FUNCNAME[0] to "source" and
$BASH_SOURCE[1] and $BASH_LINENO[1] to the location of the "source"
statement.
However this does not occur if the "source" statement occurs in
mainline code, i.e. outside of any function.
This means that code in "sourced" files can not reliably
display the location of their call, i.e., the location of
the "source" (or ".") statement which invoked them.
Repeat-By:
cat <<'EOF' >/tmp/sourced
echo "\$@=$@ \$0=$0 #FUNCNAME=${#FUNCNAME[@]}"
for ((i=0 ; i < ${#FUNCNAME[@]}; i=i+1)) ; do
echo "(i=$i) FUNCNAME ${FUNCNAME[$i]} called from line ${BASH_LINENO[$i]} in
${BASH_SOURCE[$i+1]}"
done
EOF
cat <<'EOF' >/tmp/test
#!/bin/bash
myfunc() {
echo "- Sourcing from inside a function:"
source /tmp/sourced
}
myfunc
echo "- Sourcing from mainline code:"
source /tmp/sourced
EOF
bash /tmp/test
Actual Results:
- Sourcing from inside function:
$@= $0=/tmp/test #FUNCNAME=3
(i=0) FUNCNAME source called from line 4 in /tmp/test
(i=1) FUNCNAME myfunc called from line 6 in /tmp/test
(i=2) FUNCNAME main called from line 0 in
- Sourcing directly from mainline code:
$@= $0=/tmp/test #FUNCNAME=0
Expected Results:
- Sourcing from inside function:
$@= $0=/tmp/test #FUNCNAME=3
(i=0) FUNCNAME source called from line 4 in /tmp/test
(i=1) FUNCNAME myfunc called from line 6 in /tmp/test
(i=2) FUNCNAME main called from line 0 in
- Sourcing directly from mainline code:
$@= $0=/tmp/test #FUNCNAME=1
(i=0) FUNCNAME source called from line 8 in /tmp/test
[(i=1) FUNCNAME main called from line 0 in]
Re: read -t 0 causes segfault on SIGINT
> Repeat-By: > [EMAIL PROTECTED]:~$ bash > [EMAIL PROTECTED]:~$ while sleep 1; do read -t 0; done > ... type ^C ... > Segmentation fault > [EMAIL PROTECTED]:~$ Hi Heike, This bug sounds like the one I just reported to Debian: http://bugs.debian.org/331381 There's a patch there. -jim ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
More Parser Errors in 3.2
Been trying to compile swig with the current bash 3.2 have ran into
several issues that I have been able to fix except for this one.
checking whether Guile's SCM_ API works... no
./configure: line 10204: syntax error near unexpected token `('
./configure: line 10204: `s,^[ ]*#[]*define[ ][ ]*\([^
(][^(]*\)\(([^)]*)\)[
]*\(.*\)$,${ac_dA}\1${ac_dB}\1\2${ac_dC}\3${ac_dD},gp'
Here's the section from configure
cat >confdef2sed.sed <<\_ACEOF
s/[\\&,]/\\&/g
s,[\\$`],\\&,g
t clear
: clear
s,^[ ]*#[]*define[ ][ ]*\([^ (][^
(]*\)\(([^)]*)\)[
]*\(.*\)$,${ac_dA}\1${ac_dB}\1\2${ac_dC}\3${ac_dD},gp'
t end
s,^[ ]*#[]*define[ ][ ]*\([^ ][^ ]*\)[
]*\(.*\)$,${ac_dA}\1${ac_dB}\1${ac_dC}\2${ac_dD},gp
: end
_ACEOF
Any ideas
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
Install Issue - 3.2 - invalid multibyte sequence
Here's an issue we just had reported to me from my build team. make[2]: [EMAIL PROTECTED]' is up to date. rm -f ru.gmo && /usr/bin/msgfmt -c --statistics -o ru.gmo ru.po ru.po:21:9: invalid multibyte sequence ru.po:21:10: invalid multibyte sequence ru.po:21:11: invalid multibyte sequence ru.po:21:12: invalid multibyte sequence ru.po:21:13: invalid multibyte sequence ru.po:21:14: invalid multibyte sequence ru.po:21:15: invalid multibyte sequence ru.po:21:16: invalid multibyte sequence ru.po:21:17: invalid multibyte sequence ru.po:21:18: invalid multibyte sequence ru.po:21:19: invalid multibyte sequence ru.po:21:20: invalid multibyte sequence ru.po:21:22: invalid multibyte sequence ru.po:21:23: invalid multibyte sequence ru.po:21:24: invalid multibyte sequence ru.po:21:25: invalid multibyte sequence ru.po:21:26: invalid multibyte sequence ru.po:21:27: invalid multibyte sequence ru.po:21:29: invalid multibyte sequence ru.po:21:30: invalid multibyte sequence /usr/bin/msgfmt: too many errors, aborting make[2]: *** [ru.gmo] Error 1 ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Problem with echo -e in bash 3.2
Eric Blake <[EMAIL PROTECTED]> wrote: > According to Chet Ramey on 10/21/2006 11:52 AM: >> Jochen Roderburg wrote: >>> >>> I finally tracked this down to a changed behaviour of the builtin echo >>> command. >>> >>> Namely, the formecho -e '\nnn' with a 3-digit octal number does not >>> work >>> any longer, only the variant echo -e '\0nnn' with a leading zero. >>> >>> Don't know it this is a bug or feature ;-) >> >> It's intentional. The xpg_echo and `echo -e' code should be identical, >> and the xpg_echo code is required by POSIX/XSI to interpret octal constants >> only with the leading `0'. There are lots of ways to indicate that >> backslash escapes should be interpreted -- maybe too many -- but when >> they are, they should behave consistently. >> >>> The 'program' echo from current GNU coreutils interprets the \nnn form >>> (correctly?). >> >> I don't think the coreutils echo wants echo -e to be POSIX-conformant >> the way bash is (it's an implementation choice -- POSIX doesn't specify >> echo -e). > > It looks like it is time for coreutils to revisit how /bin/echo should > behave, with or without the presence of POSIXLY_CORRECT. It would be good > for coreutils 6.4 to match bash 3.2 in what escape sequences it understands. These days, people should be using printf in new scripts, and changing echo -e might break legacy scripts. I don't see that much to gain by staying in sync with bash, when e.g., zsh still works the other way. Maybe they're about to change, too? That said, if you can make a good case and want to do the work, I'll consider a patch. ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Bash 3.2: defect in jobs.c
Missing macro wrappers for a few uses of status from struct PROCESS.
Some compilers dislike this.
diff -r -c bash-3.2.orig/jobs.c bash-3.2/jobs.c
*** bash-3.2.orig/jobs.cSat Jul 29 16:40:48 2006
--- bash-3.2/jobs.c Thu Mar 8 09:48:16 2007
***
*** 2225,2231
p = jobs[job]->pipe;
do
{
! if (p->status != EXECUTION_SUCCESS) fail = p->status;
p = p->next;
}
while (p != jobs[job]->pipe);
--- 2225,2231
p = jobs[job]->pipe;
do
{
! if (WSTATUS(p->status) != EXECUTION_SUCCESS) fail =
WSTATUS(p->status);
p = p->next;
}
while (p != jobs[job]->pipe);
***
*** 2234,2240
for (p = jobs[job]->pipe; p->next != jobs[job]->pipe; p = p->next)
;
! return (p->status);
}
/* Return the exit status of job JOB. This is the exit status of the last
--- 2234,2240
for (p = jobs[job]->pipe; p->next != jobs[job]->pipe; p = p->next)
;
! return (WSTATUS(p->status));
}
/* Return the exit status of job JOB. This is the exit status of the last
***
*** 2367,2373
if (r == -1 && errno == ECHILD)
{
child->running = PS_DONE;
! child->status = 0;/* XXX -- can't find true status */
js.c_living = 0; /* no living child processes */
if (job != NO_JOB)
{
--- 2367,2373
if (r == -1 && errno == ECHILD)
{
child->running = PS_DONE;
! WSTATUS(child->status) = 0; /* XXX -- can't find true status */
js.c_living = 0; /* no living child processes */
if (job != NO_JOB)
{
___
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
Bash 3.2: defect in lib/readline/rltty.c
Missing macro line continuation in middle of declaration. diff -r -c bash-3.2.orig/lib/readline/rltty.c bash-3.2/lib/readline/rltty.c *** bash-3.2.orig/lib/readline/rltty.c Mon Dec 26 17:21:50 2005 --- bash-3.2/lib/readline/rltty.c Thu Mar 8 10:23:43 2007 *** *** 862,868 } #define RESET_SPECIAL(c) \ ! if (c != -1 && kmap[(unsigned char)c].type == ISFUNC) kmap[(unsigned char)c].function = rl_insert; static void --- 862,868 } #define RESET_SPECIAL(c) \ ! if (c != -1 && kmap[(unsigned char)c].type == ISFUNC) \ kmap[(unsigned char)c].function = rl_insert; static void ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Array declaration doesn't seem to work properly in Ver 3.2
From: [EMAIL PROTECTED]
To: bug-bash@gnu.org,[EMAIL PROTECTED]
Subject: Array declaration doesn't seem to work properly in Ver 3.2
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 Demos 2.6.22-15-generic #1 SMP Tue Oct 21 23:47:12 GMT
2008 i686 GNU/Linux
Machine Type: i486-pc-linux-gnu
Bash Version: 3.2
Patch Level: 25
Release Status: release
Description:
Declare: not found error
read: -a illegal option
I have two machines running Bash ver. 3.2 and one running 3.1. I get the
above errors always on the 3.2 boxes but not the 3.1 box.
statements that cause the problem are:
declare -a arrayname
read -a arrayname
Repeat-By:
here is a test script that repeats the errors:
#!/bin/bash
declare -a colors
# Permits declaring an array without specifying size.
echo "Enter your favorite colors (separated from each other by a space)."
read -a colors
# Special option to 'read' command,
# allowing it to assign elements in an array.
echo
[EMAIL PROTECTED] # Special syntax to extract number of elements
in array.
# element_count=${#colors[*]} works also.
index=0
# List all the elements in the array.
while [ $index -lt $element_count ]
do
echo ${colors[$index]}
let "index = $index + 1"
done
# Each array element listed on a separate line.
# If this is not desired, use echo -n "${colors[$index]} "
echo
# Again, list all the elements in the array, but using a more elegant
method.
echo [EMAIL PROTECTED]
# echo ${colors[*]} works also.
echo
exit 0
_
Fix:
I sure wish I knew!! if you can help me figure out why this works
on one machine but not the two with newer versions
could you please let me know.
Thanks,
Jim Adamson
[EMAIL PROTECTED]
RE: Array declaration doesn't seem to work properly in Ver 3.2**SOLVED"**
My problem was with "sh" not "bash"! I was initiating the script
incorrectly.
Pierre Gaston pointed out my mistake and it works fine now.
Sorry for the alarm and my stupidity!
Best,
Jim
-Original Message-
From: Jim Adamson [mailto:[EMAIL PROTECTED]
Sent: Monday, November 10, 2008 2:11 PM
To: 'bug-bash@gnu.org'; '[EMAIL PROTECTED]'
Subject: Array declaration doesn't seem to work properly in Ver 3.2
From: [EMAIL PROTECTED]
To: bug-bash@gnu.org,[EMAIL PROTECTED]
Subject: Array declaration doesn't seem to work properly in Ver 3.2
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 Demos 2.6.22-15-generic #1 SMP Tue Oct 21 23:47:12 GMT
2008 i686 GNU/Linux Machine Type: i486-pc-linux-gnu
Bash Version: 3.2
Patch Level: 25
Release Status: release
Description:
Declare: not found error
read: -a illegal option
I have two machines running Bash ver. 3.2 and one running 3.1. I get the
above errors always on the 3.2 boxes but not the 3.1 box.
statements that cause the problem are:
declare -a arrayname
read -a arrayname
Repeat-By:
here is a test script that repeats the errors:
#!/bin/bash
declare -a colors
# Permits declaring an array without specifying size.
echo "Enter your favorite colors (separated from each other by a space)."
read -a colors
# Special option to 'read' command,
# allowing it to assign elements in an array.
echo
[EMAIL PROTECTED] # Special syntax to extract number of elements
in array.
# element_count=${#colors[*]} works also.
index=0
# List all the elements in the array.
while [ $index -lt $element_count ]
do
echo ${colors[$index]}
let "index = $index + 1"
done
# Each array element listed on a separate line.
# If this is not desired, use echo -n "${colors[$index]} "
echo
# Again, list all the elements in the array, but using a more elegant
method.
echo [EMAIL PROTECTED]
# echo ${colors[*]} works also.
echo
exit 0
_
Fix:
I sure wish I knew!! if you can help me figure out why this works
on one machine but not the two with newer versions
could you please let me know.
Thanks,
Jim Adamson
[EMAIL PROTECTED]
Testing Bash 4.0
2 Issues 1 configure script is not executable. Just had to chmod +x configure 2 when running scripts the script works, but get constant output of TRACE: pid 7958: parse_and_execute: turned on CMD_IGNORE_RETURN from comsub_ignore_return TRACE: pid 7964: parse_and_execute: turned on CMD_IGNORE_RETURN from comsub_ignore_return TRACE: pid 7968: parse_and_execute: turned on CMD_IGNORE_RETURN from comsub_ignore_return How do I disable that? Thank you for your assistance Jim Gifford
Cursor positioning in prompt is sometimes wrong, depending on locale and PS1
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 -g -O2 -Wall uname output: Linux pilot 2.6.26-2-amd64 #1 SMP Fri Mar 27 04:02:59 UTC 2009 x86_64 GNU/Linux Machine Type: x86_64-pc-linux-gnu Bash Version: 4.0 Patch Level: 24 Release Status: release Description: The cursor positioning in the prompt is sometimes wrong, depending on the contents of PS1 and the locale. Repeat-By: With this command, the cursor is positioned after the '5', as expected: env -i LC_CTYPE=en_US PS1='\[\e[0m\]12345' INPUTRC=/dev/null bash --norc --noprofile With this command, the cursor is incorrectly positioned after the '1': env -i LC_CTYPE=en_US.UTF-8 PS1='\[\e[0m\]12345' INPUTRC=/dev/null bash --norc --noprofile -jim
Re: Cursor positioning in prompt is sometimes wrong, depending on locale and PS1
Chet Ramey wrote: > Jim Paris wrote: > > The cursor positioning in the prompt is sometimes wrong, > > depending on the contents of PS1 and the locale. > > > > Repeat-By: > > > > With this command, the cursor is positioned after the '5', as expected: > > > > env -i LC_CTYPE=en_US PS1='\[\e[0m\]12345' INPUTRC=/dev/null bash --norc > > --noprofile > > > > > > With this command, the cursor is incorrectly positioned after the > > '1': > > > > env -i LC_CTYPE=en_US.UTF-8 PS1='\[\e[0m\]12345' INPUTRC=/dev/null bash > > --norc --noprofile > > It's not really the locale per se, but the horizontal scroll mode that > needs attention. (I didn't really think anybody used it anymore, but > you forced it when you started bash without TERM defined.) Try the > attached patch. Yes, it fixes this, thanks. The real problem I'm trying to track down is that the cursor is sometimes put in the wrong position after a reverse-isearch. This was what I came up with when trying to reproduce in a simple test case. I'll run with the new patch and see if that helps my other problem too (which can be a bit tricky to reproduce). -jim
how to start in "overwrite-mode"
Hi bug-bash, I have a user we're trying to encourage to migrate from tcsh to bash, who is used to his shell starting up in overwrite mode (as opposed to the default Insert mode.) Long story short, while I can easily bind a key to the "overwrite-mode" readline function, I can't figure out how to make bind start up that way as I can't find an "overwrite" readline variable which I can manipulate. And the user doesn't want to hit "Ins" every time he starts a shell. Anyone know how to do this? -- Jim Lawson Systems Architecture & Administration Enterprise Technology Services University of Vermont Burlington, VT USA
compiling BASH on windows without cygwin not possible
bash 4.1 XP Pro SP3 32-bit, using MinGW compiler short description: I have discovered that the installation method for BASH is actually recursive in nature, if I am not mistaken, requiring BASH to install BASH. read the first steps of the install. " 1. `cd' to the directory containing the source code and type `./configure' to configure Bash for your system. If you're using `csh' on an old version of System V, you might need to type `sh ./configure' instead to prevent `csh' from trying to execute `configure' itself." configure is a BASH script. Am I not correct in stating that BASH requires BASH to install? windows does not come with any such sh shell. and I need to be able to build one from scratch. you are not doing me any favors here, and I need BASH. please fix. would a special implementation be required for Windows due to the Win32 API-specific OS calls to handle processes? I would like this to be compilable with straight mingw and no more than make that it comes with. that will probably mean a separate tarball or zip file. MSYS, a companion set of unix tools for mingw, doesn't necessarily make usable executables, since anything generated with it requires some DLL's (shared libraries), and I need the generated file to be monolithic (the shared libraries can clash as things can stand now). I don't want to deal with MSYS, I want a straight BASH shell. Jim Michaels jmich...@yahoo.com(main) JesusnJim.com (my site) DoLifeComputers.JesusnJim.com (Do Life Computers group site which I lead) while (stone != rolling) moss++; --- Computer memory/disk size measurements: [KB KiB] [MB MiB] [GB GiB] [TB TiB] [10^3B=1000B=1KB][10^6B=100B=1MB][10^9B=10B=1GB][10^12B=1B=1TB] [2^10B=1024B=1KiB][2^20B=1048576B=1MiB][2^30B=1073741824B=1GiB][2^40B=1099511627776B=1TiB] Note that with disks, a disk size is measured in GB or TB, not in GiB or TiB. computer memory (RAM) is measured in MiB and GiB. --- Robot dog food: Cables n' Bits --- adress=seg<<4+ofs; (ambiguity - a double-minded compiler is unstable in all its ways) biosdsk2.h:733: warning: suggest parentheses around '+' inside '<<' --- I'm bald on top (:-) ---
using `set -e' in a subshell
Hi, Is the following behavior intended? I was surprised by the behavior of bash/zsh/ash/dash/pdksh, yet Solaris 5.9's /bin/sh does what I expected: # Solaris 5.9's /bin/sh $ echo a; (set -e; false; echo foo) && echo b a # Yet bash/zsh/ash do this: $ echo a; (set -e; false; echo foo) && echo b a foo b The POSIX spec for set's -e option says the following, so it all comes down to how you interpret being ``part of an AND or OR list'': -e When this option is on, if a simple command fails for any of the reasons listed in Section 2.8.1 (on page 46) or returns an exit status value >0, and is not part of the compound list following a while, until, or if keyword, and is not a part of an AND or OR list, and is not a pipeline preceded by the ! reserved word, then the shell shall immediately exit. My take was to consider the subshell commands in isolation, where I expected the `set -e' to take effect. There, the simple command `false' fails, so I expected that subshell to exit nonzero and not print `foo'. I'm using: $ bash --version GNU bash, version 3.00.16(1)-release (i386-pc-linux-gnu) ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
processes hanging in STOPPED state
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' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I../bash -I../bash/include -I../bash/lib -g -O2 uname output: Linux neurosis 2.6.11 #1 Fri Mar 4 13:53:50 EST 2005 i686 GNU/Linux Machine Type: i386-pc-linux-gnu Bash Version: 3.0 Patch Level: 16 Release Status: release Description: Bug at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=224543 (reported back on 2.05) still exists on 3.0... re-reporting to bug-bash so hopefully it gets noticed. Bash is apparently improperly setting up process groups in a way that causes processes to become stuck in the STOPPED state. Repeat-By: env -i EDITOR=emacs TERM=linux SHELLOPTS=monitor bash --noprofile --norc -c "while true; do crontab -e ; done" Hit ^X ^C rapidly to keep exiting emacs. Soon, a copy hangs on startup, process in stopped state (T), cannot be restarted with SIGCONT, only killed with SIGKILL. Fix: http://groups-beta.google.com/group/linux.kernel/msg/757fd571c7cecc35 ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: processes hanging in STOPPED state
Chet Ramey wrote: > > Bash is apparently improperly setting up process groups in > > a way that causes processes to become stuck in the STOPPED > > state. > > And did changing the definition of PGRP_PIPE in config.h solve the problem? Yes, defining PGRP_PIPE does appear to make the problem go away. But the previously referenced post from Linus said that PGRP_PIPE may cause other problems, and that there exists a "proper fix" that you have not yet included in the bash sources? As before, I cannot find that patch, do you have it? -jim ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Issues with history substitution and its documentation
Hi All,
Below are some issues I found with history substitution. I am duplicating
its behavior in a somewhat different use, and found issues with the
documentation and bugs as described.
Jim Monte
From: jim
To: bug-bash@gnu.org
Subject: Issues with history substitution and its documentation
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 T5500-Ubuntu 4.18.0-22-generic #23~18.04.1-Ubuntu SMP
Thu J$
Machine Type: x86_64-pc-linux-gnu
Bash Version: 4.4
Patch Level: 19
Release Status: release
Description:
=
Documentation of quick substitution is incorrect (or does not match
behavior).
I believe this issue is an error with the documentation of history
"Quick Substitution" that has existed since the first snapshot available at
web.archive.org in 2007 at
https://web.archive.org/web/20071223174140/http://www.gnu.org/software/bash/manual/html_node/Event-Designators.html
At the least it is true that bash does not behave as the documentation
states,
but it does act in a way that is more reasonable (to me) than what is
written.
The documentation states that ^string1^string2^ is equivalent to
!!:s/string1/string2/. However, bash treats it as equivalent to
!!:s^string1^string2^.
jim@T5500-Ubuntu:~$ echo /a
/a
jim@T5500-Ubuntu:~$ ^/a^b^
echo b
b
jim@T5500-Ubuntu:~$ echo /a
/a
jim@T5500-Ubuntu:~$ !!:s//a/b/
echo ab/
ab/
jim@T5500-Ubuntu:~$ echo /a
/a
jim@T5500-Ubuntu:~$ !!:s^/a^b^
echo b
b
=
Behavior of empty "old" string in a substitution is undefined.
The earlier example also shows a related but different issue with the
!!:s//a/b/ command, where the string to locate is empty.
It causes /a to be replaced by a and the b/ is appended.
But
jim@T5500-Ubuntu:~$ echo ///a
///a
jim@T5500-Ubuntu:~$ !!:s//z/
echo //z
//z
Here the empty string caused /a to be replaced by z.
However,
jim@T5500-Ubuntu:~$ echo ///abcdefg
///abcdefg
jim@T5500-Ubuntu:~$ !!:s//z/
echo //zbcdefg
//zbcdefg
Here a slash and the first character of the second word are replaced by z.
jim@T5500-Ubuntu:~$ echo a b c
a b c
jim@T5500-Ubuntu:~$ !!:s//z/
echo z b c
z b c
jim@T5500-Ubuntu:~$ echo ///
///
jim@T5500-Ubuntu:~$ !!:s//z/
bash: :s//z/: substitution failed
Using :gs instead of :s does not change the results.
=
BUG
If an event designator has a leading - character, it is ignored.
jim@T5500-Ubuntu:~/tmp$ cat main.c
#include
int main(void)
{
(void) fprintf(stdout, "Hello, world!\n");
return 0;
}
jim@T5500-Ubuntu:~/tmp$ gcc main.c -o"-a"
jim@T5500-Ubuntu:~/tmp$ gcc main.c -o"-b"
jim@T5500-Ubuntu:~/tmp$ -a
Hello, world!
jim@T5500-Ubuntu:~/tmp$ !-a:s/a/b
bpt-cache abc
=
Documentation of the :h and :t modifiers in section 9.3.3 is incomplete.
:h removes the last / and everything after it if a / is present. Otherwise
it does nothing.
:t removes everything before and including the last / if one is present.
Otherwise it does nothing.
If a slash is present, !!:h/!!:t is equivalent to !!.
jim@T5500-Ubuntu:~$ echo /a/b/c/d
/a/b/c/d
jim@T5500-Ubuntu:~$ !!:h
echo /a/b/c
/a/b/c
jim@T5500-Ubuntu:~$ echo /a/b/c/d
/a/b/c/d
jim@T5500-Ubuntu:~$ !!:h:h
echo /a/b
/a/b
jim@T5500-Ubuntu:~$ echo /a/b/c/d
/a/b/c/d
jim@T5500-Ubuntu:~$ !!:h:h:h
echo /a
/a
jim@T5500-Ubuntu:~$ echo /a/b/c/d
/a/b/c/d
jim@T5500-Ubuntu:~$ !!:h:h:h:h
echo
jim@T5500-Ubuntu:~$
jim@T5500-Ubuntu:~$ echo /a/b/c/d
/a/b/c/d
jim@T5500-Ubuntu:~$ !!:t
d
d: command not found
jim@T5500-Ubuntu:~$ echo a/b
a/b
jim@T5500-Ubuntu:~$ !!:h/!!:t
echo a/b
a/b
jim@T5500-Ubuntu:~$ echo a/b
a/b
jim@T5500-Ubuntu:~$ !!
echo a/b
a/b
=
Documentation of the :r and :e modifiers is incomplete.
:r removes the last ".suffix" and everything after it, if a ".suffix" is
present. Otherwise it does nothing.
:e leaves the last ".suffix" and everything after it, if a ".suffix" is
present. Otherwise it does nothing.
jim@T5500-Ubuntu:~$ echo .suffix a b .suffix c d
.suffix a b .suffix c d
jim@T5500-Ubuntu:~$ !!:r
echo .suffix a b
.suffix a b
jim@T5500-Ubuntu:~$ echo .suffix a b .suffix c d
.suffix a b .suffix c d
jim@T5500-Ubuntu:~$ !!:r:r
echo
jim@T5500-Ubuntu:~$ echo .suffix a b .suffix c d
.suffix a b .suffix c d
jim@T5500-Ubuntu:~$ !!:e
.suffix c d
jim@T5500-Ubuntu:~$ echo a b c
a b c
jim@T5500-Ubuntu:~$ !!:r
echo a b c
a b c
jim@T5500-Ubuntu:~$ echo a b c
a b c
jim@T5500-Ubuntu:~$ !!:e
echo a b c
a b c
====
Re: Issues with history substitution and its documentation
Hi,
This bug report has been my first one for Bash. I have not found how to
check the status of the bug. Would you please provide this information?
Below are a couple more issues I found.
There is an inconsistency with the documentation and behavior of the ^ word
designator. According to documentation, it refers to the first argument but
does not require a ':' before it if it starts the word designator. However,
it does not act like the numerical word designator 1 at the end of a range.
[root@localhost ~]# echo a b c
a b c
[root@localhost ~]# echo !!:1-1
echo a
a
[root@localhost ~]# echo a b c
a b c
[root@localhost ~]# echo !!:^-^
echo a b^
a b^
Also it is not explicitly documented that :- is equivalent to :0-
[root@localhost ~]# echo a b c d
a b c d
[root@localhost ~]# echo !!:-
echo echo a b c
echo a b c
[root@localhost ~]# echo a b c d
a b c d
[root@localhost ~]# echo !!:0-
echo echo a b c
echo a b c
Jim Monte
On Thu, Oct 3, 2019 at 6:19 PM Jim Monte wrote:
> Hi All,
>
> Below are some issues I found with history substitution. I am duplicating
> its behavior in a somewhat different use, and found issues with the
> documentation and bugs as described.
>
> Jim Monte
>
>
>
>
> From: jim
> To: bug-bash@gnu.org
> Subject: Issues with history substitution and its documentation
>
> 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 T5500-Ubuntu 4.18.0-22-generic #23~18.04.1-Ubuntu SMP
> Thu J$
> Machine Type: x86_64-pc-linux-gnu
>
> Bash Version: 4.4
> Patch Level: 19
> Release Status: release
>
> Description:
>
> =
> Documentation of quick substitution is incorrect (or does not match
> behavior).
>
> I believe this issue is an error with the documentation of history
> "Quick Substitution" that has existed since the first snapshot available at
> web.archive.org in 2007 at
>
>
> https://web.archive.org/web/20071223174140/http://www.gnu.org/software/bash/manual/html_node/Event-Designators.html
>
> At the least it is true that bash does not behave as the documentation
> states,
> but it does act in a way that is more reasonable (to me) than what is
> written.
>
> The documentation states that ^string1^string2^ is equivalent to
> !!:s/string1/string2/. However, bash treats it as equivalent to
> !!:s^string1^string2^.
>
> jim@T5500-Ubuntu:~$ echo /a
> /a
> jim@T5500-Ubuntu:~$ ^/a^b^
> echo b
> b
> jim@T5500-Ubuntu:~$ echo /a
> /a
> jim@T5500-Ubuntu:~$ !!:s//a/b/
> echo ab/
> ab/
> jim@T5500-Ubuntu:~$ echo /a
> /a
> jim@T5500-Ubuntu:~$ !!:s^/a^b^
> echo b
> b
>
>
> =
> Behavior of empty "old" string in a substitution is undefined.
>
> The earlier example also shows a related but different issue with the
> !!:s//a/b/ command, where the string to locate is empty.
> It causes /a to be replaced by a and the b/ is appended.
>
> But
> jim@T5500-Ubuntu:~$ echo ///a
> ///a
> jim@T5500-Ubuntu:~$ !!:s//z/
> echo //z
> //z
>
> Here the empty string caused /a to be replaced by z.
>
> However,
> jim@T5500-Ubuntu:~$ echo ///abcdefg
> ///abcdefg
> jim@T5500-Ubuntu:~$ !!:s//z/
> echo //zbcdefg
> //zbcdefg
>
> Here a slash and the first character of the second word are replaced by z.
>
>
> jim@T5500-Ubuntu:~$ echo a b c
> a b c
> jim@T5500-Ubuntu:~$ !!:s//z/
> echo z b c
> z b c
>
>
> jim@T5500-Ubuntu:~$ echo ///
> ///
> jim@T5500-Ubuntu:~$ !!:s//z/
> bash: :s//z/: substitution failed
>
> Using :gs instead of :s does not change the results.
>
>
> =========
> BUG
> If an event designator has a leading - character, it is ignored.
>
> jim@T5500-Ubuntu:~/tmp$ cat main.c
> #include
> int main(void)
> {
> (void) fprintf(stdout, "Hello, world!\n");
> return 0;
> }
>
> jim@T5500-Ubuntu:~/tmp$ gcc main.c -o"-a"
> jim@T5500-Ubuntu:~/tmp$ gcc main.c -o"-b"
> jim@T5500-Ubuntu:~/tmp$ -a
> Hello, world!
> jim@T5500-Ubuntu:~/tmp$ !-a:s/a/b
> bpt-cache abc
>
>
>
> =====
> Documentation of the :h and :t modifiers in section 9.3.3 is incomplete.
> :h removes the last / and everything after it if a / is present. Otherwise
> it does nothing.
>
> :t removes everything before and includi
Re: Issues with history substitution and its documentation
Two more documentation issues I have found are below. It appears that an empty substring event designator uses the string of the previous substring event designator if none is provided and does not find the event if there is no previous string. [root@localhost ~]# ls dos hello.c [root@localhost ~]# cat hello.c > /dev/nul [root@localhost ~]# echo !?s? echo ls ls [root@localhost ~]# echo !?? echo echo ls echo ls [root@localhost ~]# ls -al > /dev/nul [root@localhost ~]# echo !?? echo ls -al > /dev/nul [root@localhost ~]# echo s s [root@localhost ~]# echo !?? echo echo s echo s [root@localhost ~]# echo !?l? echo echo ls -al > /dev/nul [root@localhost ~]# echo !?? echo echo echo ls -al > /dev/nul [root@localhost ~]# bash [root@localhost ~]# echo !?? bash: !??: event not found This action is not documented. An empty "old" string in a substitute word modifier uses the previous "old" if none is given, but uses an empty string if new is empty. If there was no previous "old" string, an error is reported. [root@localhost ~]# echo f g i f g i [root@localhost ~]# echo !:s/g/k/ echo echo f k i echo f k i [root@localhost ~]# echo af ag ai af ag ai [root@localhost ~]# echo !:s/// echo echo af a ai echo af a ai [root@localhost ~]# echo bf bg bi bf bg bi [root@localhost ~]# echo !:s//1/ echo echo bf b1 bi echo bf b1 bi [root@localhost ~]# echo gf gg gi gf gg gi [root@localhost ~]# echo !:gs//2/ echo echo 2f 22 2i echo 2f 22 2i [root@localhost ~]# bash [root@localhost ~]# echo a b c a b c [root@localhost ~]# echo !:s//1/ bash: :s//1/: no previous substitution Again, this behavior is not documented. On Thu, Oct 10, 2019 at 10:35 PM Jim Monte wrote: > Hi, > > This bug report has been my first one for Bash. I have not found how to > check the status of the bug. Would you please provide this information? > > Below are a couple more issues I found. > > There is an inconsistency with the documentation and behavior of the ^ > word designator. According to documentation, it refers to the first > argument but does not require a ':' before it if it starts the word > designator. However, it does not act like the numerical word designator 1 > at the end of a range. > > [root@localhost ~]# echo a b c > a b c > [root@localhost ~]# echo !!:1-1 > echo a > a > [root@localhost ~]# echo a b c > a b c > [root@localhost ~]# echo !!:^-^ > echo a b^ > a b^ > > Also it is not explicitly documented that :- is equivalent to :0- > > [root@localhost ~]# echo a b c d > a b c d > [root@localhost ~]# echo !!:- > echo echo a b c > echo a b c > [root@localhost ~]# echo a b c d > a b c d > [root@localhost ~]# echo !!:0- > echo echo a b c > echo a b c > > > Jim Monte > > On Thu, Oct 3, 2019 at 6:19 PM Jim Monte wrote: > >> Hi All, >> >> Below are some issues I found with history substitution. I am duplicating >> its behavior in a somewhat different use, and found issues with the >> documentation and bugs as described. >> >> Jim Monte >> >> >> >> >> From: jim >> To: bug-bash@gnu.org >> Subject: Issues with history substitution and its documentation >> >> 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 T5500-Ubuntu 4.18.0-22-generic #23~18.04.1-Ubuntu SMP >> Thu J$ >> Machine Type: x86_64-pc-linux-gnu >> >> Bash Version: 4.4 >> Patch Level: 19 >> Release Status: release >> >> Description: >> >> = >> Documentation of quick substitution is incorrect (or does not match >> behavior). >> >> I believe this issue is an error with the documentation of history >> "Quick Substitution" that has existed since the first snapshot available >> at >> web.archive.org in 2007 at >> >> >> https://web.archive.org/web/20071223174140/http://www.gnu.org/software/bash/manual/html_node/Event-Designators.html >> >> At the least it is true that bash does not behave as the documentation >> states, >> but it does act in a way that is more reasonable (to me) than what is >> written. >> >> The documentation states that ^string1^string2^ is equivalent to >> !!:s/string1/string2/. However, bash treats it as equivalent to >> !!:s^string1^string2^. >> >> jim@T5500-Ubuntu:~$ echo /a >> /a >> jim@T5500-Ubuntu:~$ ^/a^b^ >> echo b >> b >> jim@T5500-Ubuntu:~$ echo /a
Re: Issues with history substitution and its documentation
Related to the issues with the ? event designator, the %word designator substitutes the *first* word matched by the ? event designator or nothing if the match begins with a space. These details are not documented. [root@localhost ~]# echo a b c d >/dev/nul [root@localhost ~]# echo !?b c? echo echo a b c d >/dev/nul [root@localhost ~]# echo "!%" echo "b" b [root@localhost ~]# echo a1 >/dev/nul [root@localhost ~]# echo !? a? echo echo a1 >/dev/nul [root@localhost ~]# echo "!%" echo "" Jim On Sun, Nov 3, 2019 at 9:18 AM Jim Monte wrote: > Two more documentation issues I have found are below. > > It appears that an empty substring event designator uses the string of the > previous substring event designator if none is provided and does not find > the event if there is no previous string. > > [root@localhost ~]# ls > dos hello.c > [root@localhost ~]# cat hello.c > /dev/nul > [root@localhost ~]# echo !?s? > echo ls > ls > [root@localhost ~]# echo !?? > echo echo ls > echo ls > [root@localhost ~]# ls -al > /dev/nul > [root@localhost ~]# echo !?? > echo ls -al > /dev/nul > [root@localhost ~]# echo s > s > [root@localhost ~]# echo !?? > echo echo s > echo s > [root@localhost ~]# echo !?l? > echo echo ls -al > /dev/nul > [root@localhost ~]# echo !?? > echo echo echo ls -al > /dev/nul > > [root@localhost ~]# bash > [root@localhost ~]# echo !?? > bash: !??: event not found > > This action is not documented. > > > > > > An empty "old" string in a substitute word modifier uses the previous > "old" if none is given, but uses an empty string if new is empty. If there > was no previous "old" string, an error is reported. > > [root@localhost ~]# echo f g i > f g i > [root@localhost ~]# echo !:s/g/k/ > echo echo f k i > echo f k i > [root@localhost ~]# echo af ag ai > af ag ai > [root@localhost ~]# echo !:s/// > echo echo af a ai > echo af a ai > [root@localhost ~]# echo bf bg bi > bf bg bi > [root@localhost ~]# echo !:s//1/ > echo echo bf b1 bi > echo bf b1 bi > [root@localhost ~]# echo gf gg gi > gf gg gi > [root@localhost ~]# echo !:gs//2/ > echo echo 2f 22 2i > echo 2f 22 2i > > [root@localhost ~]# bash > [root@localhost ~]# echo a b c > a b c > [root@localhost ~]# echo !:s//1/ > bash: :s//1/: no previous substitution > > Again, this behavior is not documented. > > On Thu, Oct 10, 2019 at 10:35 PM Jim Monte wrote: > >> Hi, >> >> This bug report has been my first one for Bash. I have not found how to >> check the status of the bug. Would you please provide this information? >> >> Below are a couple more issues I found. >> >> There is an inconsistency with the documentation and behavior of the ^ >> word designator. According to documentation, it refers to the first >> argument but does not require a ':' before it if it starts the word >> designator. However, it does not act like the numerical word designator 1 >> at the end of a range. >> >> [root@localhost ~]# echo a b c >> a b c >> [root@localhost ~]# echo !!:1-1 >> echo a >> a >> [root@localhost ~]# echo a b c >> a b c >> [root@localhost ~]# echo !!:^-^ >> echo a b^ >> a b^ >> >> Also it is not explicitly documented that :- is equivalent to :0- >> >> [root@localhost ~]# echo a b c d >> a b c d >> [root@localhost ~]# echo !!:- >> echo echo a b c >> echo a b c >> [root@localhost ~]# echo a b c d >> a b c d >> [root@localhost ~]# echo !!:0- >> echo echo a b c >> echo a b c >> >> >> Jim Monte >> >> On Thu, Oct 3, 2019 at 6:19 PM Jim Monte wrote: >> >>> Hi All, >>> >>> Below are some issues I found with history substitution. I am >>> duplicating its behavior in a somewhat different use, and found issues with >>> the documentation and bugs as described. >>> >>> Jim Monte >>> >>> >>> >>> >>> From: jim >>> To: bug-bash@gnu.org >>> Subject: Issues with history substitution and its documentation >>> >>> 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 T5500-Ubuntu 4.18.0-22-generic #23~18.04.1-Ubuntu >>> SMP Thu J$ >>> Machine Type: x86_64-pc-linux-gnu >>> >
Re: Issues with history substitution and its documentation
The availability of the % string only after a command unrelated to it (not using !??) is executed as shown below is not documented, but it probably falls under the category of a bug. That is, it seems reasonable that both echo "!%" commands should behave as the second one does. [root@localhost ~]# bash [root@localhost ~]# echo "!%" bash: !: event not found [root@localhost ~]# echo a >/dev/nul [root@localhost ~]# echo "!%" echo "" [root@localhost ~]# Jim On Mon, Nov 4, 2019 at 9:42 AM Jim Monte wrote: > Related to the issues with the ? event designator, the %word designator > substitutes the *first* word matched by the ? event designator or nothing > if the match begins with a space. These details are not documented. > > [root@localhost ~]# echo a b c d >/dev/nul > [root@localhost ~]# echo !?b c? > echo echo a b c d >/dev/nul > [root@localhost ~]# echo "!%" > echo "b" > b > [root@localhost ~]# echo a1 >/dev/nul > [root@localhost ~]# echo !? a? > echo echo a1 >/dev/nul > [root@localhost ~]# echo "!%" > echo "" > > Jim > > > > > > On Sun, Nov 3, 2019 at 9:18 AM Jim Monte wrote: > >> Two more documentation issues I have found are below. >> >> It appears that an empty substring event designator uses the string of >> the previous substring event designator if none is provided and does not >> find the event if there is no previous string. >> >> [root@localhost ~]# ls >> dos hello.c >> [root@localhost ~]# cat hello.c > /dev/nul >> [root@localhost ~]# echo !?s? >> echo ls >> ls >> [root@localhost ~]# echo !?? >> echo echo ls >> echo ls >> [root@localhost ~]# ls -al > /dev/nul >> [root@localhost ~]# echo !?? >> echo ls -al > /dev/nul >> [root@localhost ~]# echo s >> s >> [root@localhost ~]# echo !?? >> echo echo s >> echo s >> [root@localhost ~]# echo !?l? >> echo echo ls -al > /dev/nul >> [root@localhost ~]# echo !?? >> echo echo echo ls -al > /dev/nul >> >> [root@localhost ~]# bash >> [root@localhost ~]# echo !?? >> bash: !??: event not found >> >> This action is not documented. >> >> >> >> >> >> An empty "old" string in a substitute word modifier uses the previous >> "old" if none is given, but uses an empty string if new is empty. If there >> was no previous "old" string, an error is reported. >> >> [root@localhost ~]# echo f g i >> f g i >> [root@localhost ~]# echo !:s/g/k/ >> echo echo f k i >> echo f k i >> [root@localhost ~]# echo af ag ai >> af ag ai >> [root@localhost ~]# echo !:s/// >> echo echo af a ai >> echo af a ai >> [root@localhost ~]# echo bf bg bi >> bf bg bi >> [root@localhost ~]# echo !:s//1/ >> echo echo bf b1 bi >> echo bf b1 bi >> [root@localhost ~]# echo gf gg gi >> gf gg gi >> [root@localhost ~]# echo !:gs//2/ >> echo echo 2f 22 2i >> echo 2f 22 2i >> >> [root@localhost ~]# bash >> [root@localhost ~]# echo a b c >> a b c >> [root@localhost ~]# echo !:s//1/ >> bash: :s//1/: no previous substitution >> >> Again, this behavior is not documented. >> >> On Thu, Oct 10, 2019 at 10:35 PM Jim Monte wrote: >> >>> Hi, >>> >>> This bug report has been my first one for Bash. I have not found how to >>> check the status of the bug. Would you please provide this information? >>> >>> Below are a couple more issues I found. >>> >>> There is an inconsistency with the documentation and behavior of the ^ >>> word designator. According to documentation, it refers to the first >>> argument but does not require a ':' before it if it starts the word >>> designator. However, it does not act like the numerical word designator 1 >>> at the end of a range. >>> >>> [root@localhost ~]# echo a b c >>> a b c >>> [root@localhost ~]# echo !!:1-1 >>> echo a >>> a >>> [root@localhost ~]# echo a b c >>> a b c >>> [root@localhost ~]# echo !!:^-^ >>> echo a b^ >>> a b^ >>> >>> Also it is not explicitly documented that :- is equivalent to :0- >>> >>> [root@localhost ~]# echo a b c d >>> a b c d >>> [root@localhost ~]# echo !!:- >>> echo echo a b c >>> echo a b c >>> [root@localhost ~]# echo a b c d >>> a b c d >>> [r
Re: Issues with history substitution and its documentation
Regarding the & word modifier, it would be useful to note in the documentation that it applies the previous substitution whether it had been successful or not, as shown below. [root@localhost ~]# echo a a [root@localhost ~]# !:s/a/z/ echo z z [root@localhost ~]# echo a1 a1 [root@localhost ~]# !:& echo z1 z1 [root@localhost ~]# echo a2 a2 [root@localhost ~]# !:s/b/y/ bash: :s/b/y/: substitution failed [root@localhost ~]# echo b2 b2 [root@localhost ~]# !:& echo y2 y2 [root@localhost ~]# Jim On Tue, Nov 5, 2019 at 11:44 AM Jim Monte wrote: > The availability of the % string only after a command unrelated to it (not > using !??) is executed as shown below is not documented, but it probably > falls under the category of a bug. That is, it seems reasonable that both > echo "!%" commands should behave as the second one does. > [root@localhost ~]# bash > [root@localhost ~]# echo "!%" > bash: !: event not found > [root@localhost ~]# echo a >/dev/nul > [root@localhost ~]# echo "!%" > echo "" > > [root@localhost ~]# > > Jim > > On Mon, Nov 4, 2019 at 9:42 AM Jim Monte wrote: > >> Related to the issues with the ? event designator, the %word designator >> substitutes the *first* word matched by the ? event designator or nothing >> if the match begins with a space. These details are not documented. >> >> [root@localhost ~]# echo a b c d >/dev/nul >> [root@localhost ~]# echo !?b c? >> echo echo a b c d >/dev/nul >> [root@localhost ~]# echo "!%" >> echo "b" >> b >> [root@localhost ~]# echo a1 >/dev/nul >> [root@localhost ~]# echo !? a? >> echo echo a1 >/dev/nul >> [root@localhost ~]# echo "!%" >> echo "" >> >> Jim >> >> >> >> >> >> On Sun, Nov 3, 2019 at 9:18 AM Jim Monte wrote: >> >>> Two more documentation issues I have found are below. >>> >>> It appears that an empty substring event designator uses the string of >>> the previous substring event designator if none is provided and does not >>> find the event if there is no previous string. >>> >>> [root@localhost ~]# ls >>> dos hello.c >>> [root@localhost ~]# cat hello.c > /dev/nul >>> [root@localhost ~]# echo !?s? >>> echo ls >>> ls >>> [root@localhost ~]# echo !?? >>> echo echo ls >>> echo ls >>> [root@localhost ~]# ls -al > /dev/nul >>> [root@localhost ~]# echo !?? >>> echo ls -al > /dev/nul >>> [root@localhost ~]# echo s >>> s >>> [root@localhost ~]# echo !?? >>> echo echo s >>> echo s >>> [root@localhost ~]# echo !?l? >>> echo echo ls -al > /dev/nul >>> [root@localhost ~]# echo !?? >>> echo echo echo ls -al > /dev/nul >>> >>> [root@localhost ~]# bash >>> [root@localhost ~]# echo !?? >>> bash: !??: event not found >>> >>> This action is not documented. >>> >>> >>> >>> >>> >>> An empty "old" string in a substitute word modifier uses the previous >>> "old" if none is given, but uses an empty string if new is empty. If there >>> was no previous "old" string, an error is reported. >>> >>> [root@localhost ~]# echo f g i >>> f g i >>> [root@localhost ~]# echo !:s/g/k/ >>> echo echo f k i >>> echo f k i >>> [root@localhost ~]# echo af ag ai >>> af ag ai >>> [root@localhost ~]# echo !:s/// >>> echo echo af a ai >>> echo af a ai >>> [root@localhost ~]# echo bf bg bi >>> bf bg bi >>> [root@localhost ~]# echo !:s//1/ >>> echo echo bf b1 bi >>> echo bf b1 bi >>> [root@localhost ~]# echo gf gg gi >>> gf gg gi >>> [root@localhost ~]# echo !:gs//2/ >>> echo echo 2f 22 2i >>> echo 2f 22 2i >>> >>> [root@localhost ~]# bash >>> [root@localhost ~]# echo a b c >>> a b c >>> [root@localhost ~]# echo !:s//1/ >>> bash: :s//1/: no previous substitution >>> >>> Again, this behavior is not documented. >>> >>> On Thu, Oct 10, 2019 at 10:35 PM Jim Monte >>> wrote: >>> >>>> Hi, >>>> >>>> This bug report has been my first one for Bash. I have not found how to >>>> check the status of the bug. Would you please provide this information? >>>> >>>> Below are a couple more issues I found. >>>> >>>
Re: Issues with history substitution and its documentation
Another documentation issue for :s, and a bug, or two bugs, although it seems to be one of each. Instead of "Any delimiter may be used in place of ‘/’.", it should be clarified that any character may be used in place of '/' as a delimiter, although if '&' is used, it looses its special property of being the value of old when it appears in new and if '\' is used, it looses is ability to escape '&'. However, there is still an issue with an escape being lost in some cases. [root@localhost ~]# echo a b c a b c [root@localhost ~]# echo "!:s&b&\\\&&&" echo "echo a \& c&" *** one less '\' escape echo a \& c& [root@localhost ~]# echo a b c a b c [root@localhost ~]# echo "!:s/b/\\\&&/" echo "echo a \\&b c" *** echo a \&b c [root@localhost ~]# echo a b c a b c [root@localhost ~]# echo "!:szbz\\\&&z" echo "echo a \\&b c" *** echo a \&b c [root@localhost ~]# echo a b c a b c [root@localhost ~]# echo "!:s\b&&\" echo "echo a c\\&&\" > " echo a c\&&" [root@localhost ~]# echo a b c a b c [root@localhost ~]# echo "!:s\b\z\&&y\" echo "echo a z c&&y\" > " echo a z c&&y" Jim On Wed, Nov 6, 2019 at 8:04 AM Jim Monte wrote: > Regarding the & word modifier, it would be useful to note in the > documentation that it applies the previous substitution whether it had been > successful or not, as shown below. > > [root@localhost ~]# echo a > a > [root@localhost ~]# !:s/a/z/ > echo z > z > [root@localhost ~]# echo a1 > a1 > [root@localhost ~]# !:& > echo z1 > z1 > [root@localhost ~]# echo a2 > a2 > [root@localhost ~]# !:s/b/y/ > bash: :s/b/y/: substitution failed > [root@localhost ~]# echo b2 > b2 > [root@localhost ~]# !:& > echo y2 > y2 > [root@localhost ~]# > > > Jim > > On Tue, Nov 5, 2019 at 11:44 AM Jim Monte wrote: > >> The availability of the % string only after a command unrelated to it >> (not using !??) is executed as shown below is not documented, but it >> probably falls under the category of a bug. That is, it seems reasonable >> that both echo "!%" commands should behave as the second one does. >> [root@localhost ~]# bash >> [root@localhost ~]# echo "!%" >> bash: !: event not found >> [root@localhost ~]# echo a >/dev/nul >> [root@localhost ~]# echo "!%" >> echo "" >> >> [root@localhost ~]# >> >> Jim >> >> On Mon, Nov 4, 2019 at 9:42 AM Jim Monte wrote: >> >>> Related to the issues with the ? event designator, the %word designator >>> substitutes the *first* word matched by the ? event designator or nothing >>> if the match begins with a space. These details are not documented. >>> >>> [root@localhost ~]# echo a b c d >/dev/nul >>> [root@localhost ~]# echo !?b c? >>> echo echo a b c d >/dev/nul >>> [root@localhost ~]# echo "!%" >>> echo "b" >>> b >>> [root@localhost ~]# echo a1 >/dev/nul >>> [root@localhost ~]# echo !? a? >>> echo echo a1 >/dev/nul >>> [root@localhost ~]# echo "!%" >>> echo "" >>> >>> Jim >>> >>> >>> >>> >>> >>> On Sun, Nov 3, 2019 at 9:18 AM Jim Monte wrote: >>> >>>> Two more documentation issues I have found are below. >>>> >>>> It appears that an empty substring event designator uses the string of >>>> the previous substring event designator if none is provided and does not >>>> find the event if there is no previous string. >>>> >>>> [root@localhost ~]# ls >>>> dos hello.c >>>> [root@localhost ~]# cat hello.c > /dev/nul >>>> [root@localhost ~]# echo !?s? >>>> echo ls >>>> ls >>>> [root@localhost ~]# echo !?? >>>> echo echo ls >>>> echo ls >>>> [root@localhost ~]# ls -al > /dev/nul >>>> [root@localhost ~]# echo !?? >>>> echo ls -al > /dev/nul >>>> [root@localhost ~]# echo s >>>> s >>>> [root@localhost ~]# echo !?? >>>> echo echo s >>>> echo s >>>> [root@localhost ~]# echo !?l? >>>> echo echo ls -al > /dev/nul >>>> [roo
Re: Issues with history substitution and its documentation
Thank you for looking into all of these reports. My issue here was that in both cases there had not yet been any ?string? search, so they should behave the same way -- an event is not required to not have a most recent ?string? search. So if the default is to use an empty string as the previous string when there is none, for consistency from the perspective of the user, both instances of echo "!%" should output echo "" as the second one does. [root@localhost ~]# bash [root@localhost ~]# echo "!%" bash: !: event not found [root@localhost ~]# echo a >/dev/nul [root@localhost ~]# echo "!%" echo "" Jim On Mon, Nov 18, 2019 at 11:20 AM Chet Ramey wrote: > On 11/5/19 11:44 AM, Jim Monte wrote: > > The availability of the % string only after a command unrelated to it > (not > > using !??) is executed as shown below is not documented, but it probably > > falls under the category of a bug. That is, it seems reasonable that both > > echo "!%" commands should behave as the second one does. > > [root@localhost ~]# bash > > [root@localhost ~]# echo "!%" > > bash: !: event not found > > If there is no history list, and hence no history entries, there are no > events to find. Hence the error message. > > -- > ``The lyf so short, the craft so long to lerne.'' - Chaucer > ``Ars longa, vita brevis'' - Hippocrates > Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/ >
Re: Issues with history substitution and its documentation
Thanks again for looking at these reports. I have thankfully essentially completed my implementation of history for ngspice (an open-source successor to SPICE 3F5 with a csh-like front end that handles parsing a bit differently than a shell would), so I believe this report will be the final one. Jim Related to the other report, there is some more missing documentation regarding the :s word modifier. If the line ends after "old", it is equivalent to :s/old/new/ (assuming old and new do not contain '/'). If the line ends after the first delimiter, it is equivalent to :s///, i.e., the previous old pattern is used and new is an empty string. If the line ends after :s, no action is performed. [root@localhost ~]# echo a b c a b c [root@localhost ~]# echo !:s/a echo echo b c echo b c [root@localhost ~]# echo a b c a b c [root@localhost ~]# echo !:s/ echo echo b c echo b c [root@localhost ~]# echo a b c a b c [root@localhost ~]# echo !:s echo echo a b c echo a b c Jim On Mon, Nov 18, 2019 at 11:14 AM Chet Ramey wrote: > On 11/3/19 9:18 AM, Jim Monte wrote: > > Two more documentation issues I have found are below. > > > > It appears that an empty substring event designator uses the string of > the > > previous substring event designator if none is provided and does not find > > the event if there is no previous string. > > Thanks for the report. I'll add text documenting the behavior. (FWIW, csh > doesn't document it, either.) > > > > An empty "old" string in a substitute word modifier uses the previous > "old" > > if none is given, but uses an empty string if new is empty. If there was > no > > previous "old" string, an error is reported. > > As I said in a previous message, this is documented in the man page but > omitted in the texinfo manual. > > > -- > ``The lyf so short, the craft so long to lerne.'' - Chaucer > ``Ars longa, vita brevis'' - Hippocrates > Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/ >
extglob features less useful since shell scripts turn them off
Configuration Information [Automatically generated, do not change]:
Machine: i686
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i686'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i686-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL
-DHAVE_CONFIG_H -I. -I../bash-3.2p17si2 -I../bash-3.2p17si2/include
-I../bash-3.2p17si2/lib -Os
uname output: Linux aa 2.6.39.3-v11 #9 SMP PREEMPT Tue Dec 13 11:07:11 HST 2011
i686 GNU/Linux
Machine Type: i686-pc-linux-gnu
Bash Version: 3.2
Patch Level: 17
Release Status: release
Description:
My interactive environment contains some shell functions that are
cleaner making use of "extglob on" of the interactive shell. But
as soon as any other shell script is run they cause, e.g.,
aa ~ > bashbug
/bin/sh: pushdHelper: line 14: syntax error near unexpected token `('
/bin/sh: pushdHelper: line 14: ` +@([1-9])*([0-9]))'
/bin/sh: error importing function definition for `pushdHelper'
because the script is running "extglob off" and trying to interpret
the functions already in the environment.
Repeat-By:
Put an extglob feature in a function in the environment and run
a shell script.
:(
Mahalo,
Jim
Bash Reference Manual: broken link
Hello GNU, 1. Perhaps there is a broken link in the bread crumb list of the index page of the Bash Reference Manual, found at: https://www.gnu.org/software/bash/manual/html_node/index.html The bread crumb list shows: Next: Introduction, Previous: (dir), Up: (dir) [Contents][Index] Each "(dir)" points to: "https://www.gnu.org/software/bash/manual/dir/index.html"; Clicking "(dir)" gave a "404 - Page Not Found" error/screen. Did you want to go here instead? https://www.gnu.org/software/bash/manual/ 2. The same problem was found in the one-web-page edition: https://www.gnu.org/software/bash/manual/bash.html Best regards, jimb. Jim Blackson A1Data Corp. -- Jim Blackson
