take out vars
Hallo! T= echo '$T' # as expected echo "a '$T' b" # returns 66 ## NOT as expected. thanks, Andrew ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
LS_COLORS with ln=target not working
When using "ln=target" in LS_COLORS and having "colored-stats on",
I get "targetm" in front of every symlink when using tab-completion,
as well as indenting problems.
The implementation in lib/readline/colors.c just doesn't work.
I appended a small patch that shows the relevant parts and works well
for me.
Thanks for bash!
Andreas
(I am not a subscriber of the list, so please CC me in reply)
--- ./lib/readline/colors.c.orig2015-03-20 21:29:42.531215281 +0100
+++ ./lib/readline/colors.c 2015-03-20 21:38:11.119857048 +0100
@@ -109,6 +109,7 @@
const char* name;
char *filename;
struct stat astat;
+ struct stat lnkstat;
mode_t mode;
int linkok;
@@ -132,6 +133,17 @@
#endif
if( stat_ok == 0 ) {
mode = astat.st_mode;
+#if defined (HAVE_LSTAT)
+if (S_ISLNK(mode)) {
+ if (stat(name, &lnkstat) == -1) {
+linkok = 0;
+ } else {
+linkok = 1;
+if (strncmp (_rl_color_indicator[C_LINK].string, "target", 6) == 0)
+ mode = lnkstat.st_mode;
+ }
+} else
+#endif
linkok = 1; //f->linkok;
}
else
@@ -141,6 +153,8 @@
if (linkok == -1 && _rl_color_indicator[C_MISSING].string != NULL)
colored_filetype = C_MISSING;
+ else if (linkok == 0 && S_ISLNK(mode) &&
_rl_color_indicator[C_ORPHAN].string != NULL)
+colored_filetype = C_ORPHAN;
else if(stat_ok != 0)
{
static enum indicator_no filetype_indicator[] = FILETYPE_INDICATORS;
@@ -181,10 +195,7 @@
#endif
}
else if (S_ISLNK (mode))
-colored_filetype = ((linkok == 0
- && (!strncmp (_rl_color_indicator[C_LINK].string, "target", 6)
- || _rl_color_indicator[C_ORPHAN].string))
-? C_ORPHAN : C_LINK);
+colored_filetype = C_LINK;
else if (S_ISFIFO (mode))
colored_filetype = C_FIFO;
else if (S_ISSOCK (mode))
pgp6v1ntqIjFW.pgp
Description: PGP signature
Re: syntax error while parsing a case command within `$(...)'
On Feb 16 2021, Koichi Murase wrote: > Because the ending keywords---}, fi, done, and esac---are allowed to > be chained, which I think is undocumented though. See 2.4 Reserved Words. This recognition shall only occur when none of the characters is quoted and when the word is used as: * The first word of a command * The first word following one of the reserved words other than case, for, or in * The third word in a case command (only in is valid in this case) * The third word in a for command (only in and do are valid in this case) Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: syntax error while parsing a case command within `$(...)'
On Feb 17 2021, Koichi Murase wrote: > Yes, that's what I wanted to claim by the above example, that is, XCU > 2.4 isn't the (most) essential point for the reason that `fi esac' or > `fi fi` is a valid construct. The above example is just a > counter-example against explaining `fi esac` by solely XCU 2.4. XCU 2.4 only explains when words are to be recognized as reserved words (the lexer part of parsing). Only because of these rules the `fi esac' example contains two consecutive reserved words. The grammar depends on having these rules in place, and then applies more rules on the placement of tokens. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: Behaviour of test -v with assoc array and quote character in key
On Feb 23 2021, Greg Wooledge wrote: > No amount of quoting will make (( 'assoc[$var]'++ )) work. (( assoc[var]++ )) Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: unsetting associative array executes commands
On Mär 11 2021, Chet Ramey wrote:
> $ cat x1
> declare -A blah
> blah['$(DOESNOTEXIST)']=broken
> shopt -s assoc_expand_once
touch blah\$
> for i in "${!blah[@]}"; do unset blah["$i"]; done
> declare -p blah
> $ ../bash-5.1-patched/bash ./x1
> declare -A blah=()
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Re: missing way to extract data out of data
On Mär 19 2021, Alex fxmbsw7 Ratchev wrote: > yea well it does wonders, however was looking for a way without spawning > externals like gawk.. maybe in future there will be =) You know where to get perl or python. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: missing way to extract data out of data
On Mär 22 2021, Dale R. Worley wrote: > Greg Wooledge writes: >> Partly true. seq(1) is a Linux thing, and was never part of any >> tradition, until Linux people started doing it. > > Huh. I started with Ultrix, and then SunOS, but don't remember learning > seq at a later date. According to <https://www.freebsd.org/cgi/man.cgi?query=seq>, seq appeared in Version 8 AT&T UNIX. > I've never tracked down why, but the Perl executable is a lot smaller > than the Bash executable. Is it? $ size /usr/bin/perl /bin/bash textdata bss dec hex filename 2068661 27364 648 2096673 1ffe21 /usr/bin/perl 1056850 22188 61040 1140078 11656e /bin/bash Of course, a lot of perl is part of loadable modules. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: zsh style associative array assignment bug
On Mär 28 2021, Greg Wooledge wrote:
> Python is different:
>
>>>> y = ["a", "b", "c", "d"]
>>>> dict(zip(y[::2], y[1::2]))
> {'a': 'b', 'c': 'd'}
>>>> x = ["a", "b", "c"]
>>>> dict(zip(x[::2], x[1::2]))
> {'a': 'b'}
>
> It seems to discard the last (unmatched) value.
>>> dict(zip_longest(x[::2], x[1::2]))
{'a': 'b', 'c': None}
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Re: select syntax violates the POLA
On Apr 02 2021, Robert Elz wrote:
> Date:Thu, 01 Apr 2021 21:33:31 -0400
> From:wor...@alum.mit.edu (Dale R. Worley)
> Message-ID: <874kgpqxlg@hobgoblin.ariadne.com>
>
> | I was going to ask why "else {" works,
>
> Wrong question. That one is easy. What follows
> 'else' is a list and the simplest form of a list
> is a simple command, which starts with a command
> word, so reserved words are always going to work
> there, even without the "follows a reserved word'
> rule.
>
> The right question would be why '} else' works.
The two case are not really different, they are covered by the same
rule:
This recognition shall only occur when none of the characters is
quoted and when the word is used as:
* The first word following one of the reserved words other than
case, for, or in
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Re: Why does "mapfile -d delim" (delim != '\n') use unbuffered read?
On Mai 03 2021, Chet Ramey wrote: > It won't work on any system that doesn't return -1/ESPIPE when you try > to lseek on a terminal device. Glibc does; Glibc doesn't do anything, it just uses what the kernel says. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: Why does "mapfile -d delim" (delim != '\n') use unbuffered read?
On Mai 04 2021, Chet Ramey wrote: > On 5/4/21 3:26 AM, Andreas Schwab wrote: >> On Mai 03 2021, Chet Ramey wrote: >> >>> It won't work on any system that doesn't return -1/ESPIPE when you try >>> to lseek on a terminal device. Glibc does; >> Glibc doesn't do anything, it just uses what the kernel says. > > You'd think, but the manual says otherwise about ESPIPE: > > "The filedes corresponds to an object that cannot be positioned, such as a > pipe, FIFO or terminal device. (POSIX.1 specifies this error only for pipes > and FIFOs, but on GNU systems, you always get ESPIPE if the object is not > seekable.)" How does that contradict what I said? Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: Question about case statement in Bash docs
On Mai 10 2021, Greg Wooledge wrote: > On Mon, May 10, 2021 at 09:12:33PM +1000, AlvinSeville7cf wrote: >>x=test >>case $x in >>"test") echo Y >>esac >> >>Pattern is quoted but no quote removal is performed according to docs. > > Quote removal is essential, because of the way the empty string > is matched: > > case $foo in > "") echo "foo is empty";; > ... > > So, it may be a documentation omission, or maybe it's mentioned in some > other paragraph, but either way quote removal definitely happens here. IIUC there is no need for quote removal, because quoting is part of the rules for pattern matching. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: Question about case statement in Bash docs
On Mai 10 2021, Chet Ramey wrote: > Either way, quote removal happens, the double quotes are removed, and > the characters between the double quotes are treated specially. POSIX doesn't mention quote removal either. Is that a bug? There is the parenthetical remark "(which also describes the effect of quoting parts of the pattern)" which suggests that quote removal is indeed not needed. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: [patch #10070] toggle invert flag when reading `!'
On Mai 27 2021, Chet Ramey wrote: > On 5/26/21 9:55 PM, Dale R. Worley wrote: > >>>$ ! ! [ 1 -eq 1 ]; echo $? >>>0 >> That last one isn't defined by the manual page. I'm surprised you don't >> get a syntax error. > > It's clearly valid. According to the POSIX grammar, a pipeline can only be a pipe_sequence optionally preceded by a single Bang. If you want another Bang the pipe_sequnce needs to be either a subshell or a brace_group. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: [patch #10070] toggle invert flag when reading `!'
On Mai 27 2021, Chet Ramey wrote: > On 5/27/21 11:20 AM, Andreas Schwab wrote: >> On Mai 27 2021, Chet Ramey wrote: >> >>> On 5/26/21 9:55 PM, Dale R. Worley wrote: >>> >>>>> $ ! ! [ 1 -eq 1 ]; echo $? >>>>> 0 >>>> That last one isn't defined by the manual page. I'm surprised you don't >>>> get a syntax error. >>> >>> It's clearly valid. >> According to the POSIX grammar, a pipeline can only be a pipe_sequence >> optionally preceded by a single Bang. If you want another Bang the >> pipe_sequnce needs to be either a subshell or a brace_group. > > True, but bash accepts it. The manual doesn't document that extension, though. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: [patch #10070] toggle invert flag when reading `!'
On Mai 27 2021, Alex fxmbsw7 Ratchev wrote: > thought it would be useful, especially with PIPESTATUS You can always use a brace group. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: [patch #10070] toggle invert flag when reading `!'
On Mai 27 2021, Alex fxmbsw7 Ratchev wrote: > why doesnt it accept ! after | Because either side of | cannot be a pipeline. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: [patch #10070] toggle invert flag when reading `!'
On Mai 27 2021, Chet Ramey wrote: > You can argue that it's not clear enough that it allows multiple `!' > operators, Not from my reading of the description. It largely follows the POSIX gammar by only putting a single [!] into the pipeline syntax. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: shell-backward-kill-word needs to behave more like werase
On Jun 29 2021, Basin Ilya wrote: > However, shell-backward-kill-word erases the word immedeately > preceding the caret plus it erases one additional space. Does it? Not for me. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: Unexpected behaviour when using process substitution with stdout and stderr
On Jul 11 2021, Greg Wooledge wrote: > You're sending the stderr of generate to a subshell where the stderr() > function is executed. But the stderr() function writes to stdout. > Therefore, all of the output from generate is ultimately ending up going > to the script's stdout, with potentially weird interleaving depending > on the timing of the two background subshells. There is no interleaving. The output of stderr is connected to the current disposition of fd 1 which is redirected to the >(stdout) pipe. You can either switch the order of redirections, or save the previous disposition of fd 1 in another fd and redirect the output of stderr there. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: Infinite loop triggered by extglob +(!(x))y
On Jul 25 2021, Greg Wooledge wrote: > On Sun, Jul 25, 2021 at 07:09:50PM +0200, andrej--- via Bug reports for the > GNU Bourne Again SHell wrote: >> Description: >> An extglob like +(!(x))y causes Bash to freeze with a 100% CPU >> utilization. >> At the first glance the freeze doesn't seem to depend on the >> (non-)existence of matching paths. > > The files do seem to matter. > > unicorn:~/tmp$ echo +(!(x))y > servers-to-try > unicorn:~/tmp$ cd /tmp > unicorn:/tmp$ echo +(!(x))y > ^C^C^ZKilled It depends on the length of the existing file names. That pattern has quadratic complexity. > It's a really bad runaway, requiring SIGKILL from another terminal to > stop it. Not really. It's just that an interactive shell ignores or postpones a lot of signals during command execution. In a non-interactive shell, a simple SIGINT will stop it. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: Infinite loop triggered by extglob +(!(x))y
On Jul 25 2021, Chet Ramey wrote: > In the bash build directory, for instance, it fails right away, as it > should: there aren't any files ending in `y'. It doesn't matter whether the file name contains `y', just how long it is. Try creating a file with a name of 30 or more characters. Each additional character doubles the run time. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: Bug concatenating member of large array with string
On Aug 10 2021, Joe Pater wrote:
> The attached bash script (named 'test'), when run on my laptop,
> produces the following output:
>
> xyzerg
That's because the value of ${words[0]} ends with a CR. You can see
that if you pipe the output to `cat -A'.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Re: GROUPS
On Aug 11 2021, Štěpán Němec wrote: > Quoting POSIX.1-2017 on environment variables [1]: Note that GROUPS is not an environment variable in bash, it is not exported. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: Defect in manual section "Conditional Constructs" / case
On Aug 24 2021, dietmar_schind...@web.de wrote: > In the section > https://www.gnu.org/software/bash/manual/bash.html#Conditional-Constructs > in the description of the "case" command there is no mention (as far as I > can see, it doesn't follow from the documented expansions etc.) that a > _pattern_ undergoes quote removal, but it does [see e. g. case aa in a""a) > echo match;; esac]. (One might think it does self-evidently in the process > of "Shell Expansions" performed on the command line, but this expansion > series is not performed on the case command's _word_ and patterns - they for > example don't undergo brace expansion -; for _word_, it is explicitly said: > "The _word_ undergoes tilde expansion, parameter expansion, command > substitution, arithmetic expansion, and quote removal …"; for _pattern_: > "Each _pattern_ undergoes tilde expansion, parameter expansion, command > substitution, and arithmetic expansion." - quote removal is missing.) That's because quote removal is _not_ performed. The quotes are significant for pattern matching, which needs to respect quoting. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: BASH_BUILTINS(1) | 'man bash_builtins' | Manual not found
On Sep 30 2021, Greg Wooledge wrote: > No, they probably have a /usr/share/man/man1/alias.1.gz -> bash-builtins.1.gz > symlink or something, set up by their OS vendor. See the comment in doc/builtins.1: .\" This is a hack to force bash builtins into the whatis database .\" and to get the list of builtins to come up with the man command. This happens automagically. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: BASH_BUILTINS(1) | 'man bash_builtins' | Manual not found
On Sep 30 2021, Greg Wooledge wrote: > It's also possibly worth pointing out that the "builtins.7" provided > by Debian 11 contains a synopsis from bash 2.05b, listing a set of > builtin commands that's *vastly* out of date. But the actual content > provided by "bash-builtins.7" is newer, and includes builtins like > mapfile, which are not listed in the synopsis. That's a bug with debian's packaging. The manpage from the bash sources doesn't have that bug. Note that the bash sources do not contain any section 7 manpages. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: Using systemd-249's libnss_systemd.so.2 triggers a crash in bash-5.1's malloc.c
On Okt 04 2021, Julien Moutinho wrote:
> - bash crashes inside valgrind too,
> but apparently something different is happening
> because it crashes even without systemd being involved:
>
> $ nix build .#bash5-with-bash-malloc
> $ valgrind result/bin/bash --norc -c true
>> ==307088== Memcheck, a memory error detector
>> ==307088== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
>> ==307088== Using Valgrind-3.16.1 and LibVEX; rerun with -h for copyright info
>> ==307088== Command: result/bin/bash --norc -c true
>> ==307088==
>> ==307088== Invalid free() / delete / delete[] / realloc()
>> ==307088==at 0x483F8E9: free (in
>> /nix/store/7s7hzqaf5imxmpjlxh2n6fs7ixml98ya-valgrind-3.16.1/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
>> ==307088==by 0x47330F: xfree (xmalloc.c:150)
>> ==307088==by 0x4644FA: unwind_frame_run_internal (unwind_prot.c:325)
>> ==307088==by 0x4640B6: without_interrupts (unwind_prot.c:117)
>> ==307088==by 0x464656: run_unwind_frame (unwind_prot.c:143)
>> ==307088==by 0x479ACA: parse_and_execute (evalstring.c:523)
>> ==307088==by 0x41C0A5: run_one_command (shell.c:1440)
>> ==307088==by 0x41D6A1: main (shell.c:741)
>> ==307088== Address 0x404be10 is in the brk data segment 0x4033000-0x4054fff
Here is a patch:
diff --git i/builtins/evalstring.c w/builtins/evalstring.c
index 18928a17..ae684d26 100644
--- i/builtins/evalstring.c
+++ w/builtins/evalstring.c
@@ -197,6 +197,12 @@ parse_and_execute_cleanup (old_running_trap)
parse_and_execute_level = 0; /* XXX */
}
+static void
+free_string (char *string)
+{
+ xfree (string);
+}
+
static void
parse_prologue (string, flags, tag)
char *string;
@@ -247,7 +253,7 @@ parse_prologue (string, flags, tag)
add_unwind_protect (parser_restore_alias, (char *)NULL);
if (orig_string && ((flags & SEVAL_NOFREE) == 0))
-add_unwind_protect (xfree, orig_string);
+add_unwind_protect (free_string, orig_string);
end_unwind_frame ();
if (flags & (SEVAL_NONINT|SEVAL_INTERACT))
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Re: Using systemd-249's libnss_systemd.so.2 triggers a crash in bash-5.1's malloc.c
On Okt 04 2021, Chet Ramey wrote: > On 10/4/21 4:34 AM, Andreas Schwab wrote: >> On Okt 04 2021, Julien Moutinho wrote: >> >>> - bash crashes inside valgrind too, >>> but apparently something different is happening >>> because it crashes even without systemd being involved: >>> >>> $ nix build .#bash5-with-bash-malloc >>> $ valgrind result/bin/bash --norc -c true >>>> ==307088== Memcheck, a memory error detector >>>> ==307088== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. >>>> ==307088== Using Valgrind-3.16.1 and LibVEX; rerun with -h for copyright >>>> info >>>> ==307088== Command: result/bin/bash --norc -c true >>>> ==307088== >>>> ==307088== Invalid free() / delete / delete[] / realloc() >>>> ==307088==at 0x483F8E9: free (in >>>> /nix/store/7s7hzqaf5imxmpjlxh2n6fs7ixml98ya-valgrind-3.16.1/lib/valgrind/vgpreload_memcheck-amd64-linux.so) >>>> ==307088==by 0x47330F: xfree (xmalloc.c:150) >>>> ==307088==by 0x4644FA: unwind_frame_run_internal (unwind_prot.c:325) >>>> ==307088==by 0x4640B6: without_interrupts (unwind_prot.c:117) >>>> ==307088==by 0x464656: run_unwind_frame (unwind_prot.c:143) >>>> ==307088==by 0x479ACA: parse_and_execute (evalstring.c:523) >>>> ==307088==by 0x41C0A5: run_one_command (shell.c:1440) >>>> ==307088==by 0x41D6A1: main (shell.c:741) >>>> ==307088== Address 0x404be10 is in the brk data segment >>>> 0x4033000-0x4054fff >> >> Here is a patch: > > How does this fix the problem with valgrind? How does wrapping xfree in a > local function help? Because xfree is a function-like macro, so taking the address does not work. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: Using systemd-249's libnss_systemd.so.2 triggers a crash in bash-5.1's malloc.c
On Okt 04 2021, Chet Ramey wrote: > Nope, I don't buy that as the reason. xfree (name of function) and xfree(x) > (macro defined in xmalloc.h) are not the same thing. That's exactly the problem. You cannot pass the return value from sh_xmalloc to xfree, only sh_xfree. > and everything works correctly. Nope, it's undefined behaviour, as pointed out by valgrind. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: Using systemd-249's libnss_systemd.so.2 triggers a crash in bash-5.1's malloc.c
On Okt 04 2021, Chet Ramey wrote: > Nope. These are all functions internal to bash and the bash malloc, and > they are all defined. The problem is that the xmalloc macro redirects directly to the internal malloc implementation, whereas the xfree function calls it indirectly through the free function. The latter is seen by valgrind, the former isn't, so it didn't track it. Thus the xmalloc, xrealloc, xfree macros need to be disabled if valgrind is used. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: Using systemd-249's libnss_systemd.so.2 triggers a crash in bash-5.1's malloc.c
On Okt 04 2021, Chet Ramey wrote: > On 10/3/21 11:59 PM, Julien Moutinho wrote: >> Bash Version: 5.1 >> Patch Level: 8 >> Release Status: release >> Architecture: x86_64-linux >> >> Description: >> >> bash-5.1 reaches crashing code paths >> when launched by systemd-249 or valgrind. >> I cannot get such crashes when bash is built using: >> ./configure --without-bash-malloc > > I suspect this is a buffer overflow introduced between systemd-247 and > systemd-249. It's not caught when building bash without the bash malloc > because the default libc malloc probably doesn't do the bounds checking > the bash malloc does, even without malloc debugging turned on. If it's a buffer overflow, then valgrind should be able to catch it (when bash is configured --without-bash-malloc). valgrind's bounds checking is much more advanced than what a checking malloc can do. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: Using systemd-249's libnss_systemd.so.2 triggers a crash in bash-5.1's malloc.c
On Okt 04 2021, Chet Ramey wrote: > You'd think. This is the kind of overflow that will produce that error > message from the bash malloc: Only after the fact. valgrind finds it before it is happening, and even if the overflow hits a padding between memory blocks. $ valgrind ./a.out ==31974== Memcheck, a memory error detector ==31974== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==31974== Using Valgrind-3.16.1 and LibVEX; rerun with -h for copyright info ==31974== Command: ./a.out ==31974== ==31974== Invalid write of size 1 ==31974==at 0x4006CB: main (in /home/andreas/a.out) ==31974== Address 0x5213068 is 0 bytes after a block of size 40 alloc'd ==31974==at 0x4C312EF: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==31974==by 0x40068F: main (in /home/andreas/a.out) ==31974== ==31974== Invalid write of size 1 ==31974==at 0x4006ED: main (in /home/andreas/a.out) ==31974== Address 0x521318a is 0 bytes after a block of size 218 alloc'd ==31974==at 0x4C338CF: realloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==31974==by 0x4006DE: main (in /home/andreas/a.out) Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: read built-in command has a problem in shell function
On Okt 11 2021, Hyunho Cho wrote:
> this command works well in *shell script file*
> but in shell function does not work well
This has nothing to do with shell functions. It is a simple race
condition.
> sh$ echo 111 | myfunc# OK
> yes
>
> sh$ cat foo.c | myfunc# NOT WORK!
>
> sh$ date | myfunc # NOT WORK!
>
>
> if i change like this. then this time work well
>
> sh$ date | { date > /dev/null; myfunc ;}
> yes
This depends on the left side of the pipe producing output faster than
the right side performing read -t 0.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Re: read built-in command has a problem in shell function
On Okt 11 2021, Alex fxmbsw7 Ratchev wrote: > a sync in hope it syncs pipes It doesn't. It just alters the timing. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: hash not restored after running command -p
On Nov 01 2021, Oğuz wrote: > On Mon, Nov 1, 2021 at 1:33 PM Mike Jonkmans wrote: >> Temporarily using a default value of PATH is akin to modifying it. > > But they are not the same thing, and you know this. The standard is > neither on your side nor mine. I think it can be considered a bug either way. Either command -p is seen to modify PATH, then the hash should be reset afterwards, or command -p is seen to not search PATH, then the hash should be left alone. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: bash conditional expressions
On Nov 12 2021, Mischa Baars wrote: > Using Fedora 32 (bash 5.0.17) this returns a true, while on Fedora 35 (bash > 5.1.8) this returns a false: > touch test; if [[ -N test ]]; then echo true; else echo false; fi; What does `stat test' print respectively? Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: bash conditional expressions
FILE1 -nt FILE2 True if file1 is newer than file2 (according to modification date). Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: bash conditional expressions
On Nov 14 2021, Greg Wooledge wrote: > The significance of "setting the atime" will depend on the mount options > of the file system in question. On Debian 11, a file system of type ext4 > which is mounted with "defaults" (as specified in fstab) includes the > "relatime" option. Which is documented thus: AFAIK the "relatime" option has only an effect when the atime update is triggered as a side effect of reading a file. Explicit inode modifications via utime et.al. are always carried out independent of that option. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: bash conditional expressions
On Nov 17 2021, Michael J. Baars wrote: > When -N stands for NEW, and touch (-am) gives you a new file It doesn't. The file hasn't been modified after it was last read. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: Line is corrupted when pasting long string in vi mode with exit_attribute_mode prompt
On Dez 17 2021, Jack Pearson wrote: > PS1='$(tput sgr0)' # emit exit_attribute_mode capability string Non-printable characters in the prompt must be bracketed by \[ \]. PS1='\[$(tput sgr0)\]' -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: ~0, ~00, etc tilde expand to ~CURRENTUSER
~0 is the top of the directory stack, always the same as $PWD. If the characters following the tilde in the tilde-prefix consist of a number N, optionally prefixed by a '+' or a '-', the tilde-prefix is replaced with the corresponding element from the directory stack, as it would be displayed by the 'dirs' builtin invoked with the characters following tilde in the tilde-prefix as an argument (*note The Directory Stack::). If the tilde-prefix, sans the tilde, consists of a number without a leading '+' or '-', '+' is assumed. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: Bash not escaping escape sequences in directory names
On Jan 21 2022, Lawrence Velázquez wrote: > Depends what you consider to be an issue. Personally, I would be > less than pleased if my whole terminal turned red just because I > changed into a directory that happened to have a weird name. Put $(tput sgr0) in PS1. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: Bash-5.2-alpha available
bash --posix -c 'read -t1
Re: Bash-5.2-alpha available
On Jan 22 2022, Chet Ramey wrote: > Because they should behave identically to other forms of quoting that bash > handles in here-documents. Why should $'' be different from '' only within > here-document bodies? $'' is left as-is inside double quotes, why should it treated differently in here-documents? -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: Bash-5.2-alpha available
On Jan 21 2022, Chet Ramey wrote: > i. The non-incremental history searches now leave the current history offset >at the position of the last matching history entry, like incremental > search. That makes history-search-backward significantly less useful, because you can no longer use yank-last-arg to copy arguments from the preceding line. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: Interesting bug
On Feb 12 2022, David Hobach wrote:
> Yes, the interesting part is that depending on which space you accidentally
> forget, you'll either get the expected "Finished" or "bad code executed".
> foo="$(testCode)" || {echo "foo"; } # --> bad code
> foo="$(testCode)" || { echo "foo";} # --> Finished
There is no forgotten space in the latter line.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Re: the "-e" command line argument is not recognized
On Feb 16 2022, Viktor Korsun wrote: > runme.sh > #!/bin/bash > echo $0 > echo $1 > echo $2 > echo $3 > echo $4 > echo $5 > echo $6 Don't use echo to print unknown text. Use printf instead, which can handle this correctly. Also, don't forget to quote properly. printf "%s\n" "$4" > > command: > ./runme.sh -q -w -e -r -t -y > > produced output: > ./get_env.sh > -q > -w > $ help echo echo: echo [-neE] [arg ...] Write arguments to the standard output. Display the ARGs, separated by a single space character and followed by a newline, on the standard output. Options: -ndo not append a newline -eenable interpretation of the following backslash escapes -Eexplicitly suppress interpretation of backslash escapes -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: Bash-5.2-alpha available
On Feb 10 2022, Chet Ramey wrote:
> On 2/10/22 9:53 AM, Andreas Schwab wrote:
>> On Jan 21 2022, Chet Ramey wrote:
>>
>>> i. The non-incremental history searches now leave the current history offset
>>> at the position of the last matching history entry, like incremental
>>> search.
>> That makes history-search-backward significantly less useful, because
>> you can no longer use yank-last-arg to copy arguments from the preceding
>> line.
>
> It makes previous-history, next-history, and operate-and-get-next work as
> they do with incremental searches, which is more in line with user
> expectations.
But it clobbers the matched history line, replacing it with the
uncompleted input.
$ HOME=$PWD bash --norc
bash-5.2$ history
1 history
bash-5.2$ echo 1
1
bash-5.2$ history
1 history
2 echo 1
3 history
bash-5.2$ echo 1<-- type e
1
bash-5.2$ history
1 history
2 e
3 history
4 echo 1
5 history
bash-5.2$
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Re: Bash-5.2-alpha available
On Feb 17 2022, Chet Ramey wrote:
> Thanks for the report. This is a different issue; some assumptions that the
> change to history-search-{forward,backward} uncovered.
It's still broken. You get a double free when you modify the line
selected by , but then leave it and execute a
different line instead.
bash-5.2$ history
1 echo 1
2 echo 2
3 echo 3
4 history
Now type e, , , 4,
, .
bash-5.2$ history
1 echo 1
2 echo 2
3* echo 34
4 history
5 echo 2
6 history
Now type *4 (move to line 3), -> crash
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Re: Bash-5.2-alpha available
On Mär 01 2022, Chet Ramey wrote: > Thanks. I can easily fix the pointer aliasing issue, but it is not going to > be identical to incremental search. I'm still getting crashes due to double free. bash-5.2$ history 1 echo 1 2 history Type e, , , , . bash-5.2$ history 1* echo 1 2 history 3 history Type *2 (move to line 1), -> crash -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: 'hash foo' may fail, and would require something like 'hash /usr/bin/foo'
On Mär 09 2022, Chet Ramey wrote: > Basically, musl libc enabled the faccessat2(2) system call and started > using it in faccessat(2). access(2) ends up calling faccessat, which now > uses faccessat2 if it's available. Alpine Linux 3.14 incorrectly returned > EPERM for unknown system calls instead of ENOSYS when running under the > faulty Docker version, which didn't know about faccessat2. EPERM has the > obvious meaning when access(2) returns it; the caller can't just assume > that EPERM means "system call blocked by security policy." And so bash > assumed that access returning EPERM meant that the binary wasn't > executable. This is a recurring problem with docker, and all comes down to the syscall filter returning a bogus errno. It happens every time a new syscall is introduced. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: 'hash foo' may fail, and would require something like 'hash /usr/bin/foo'
On Mär 09 2022, Chet Ramey wrote: > Ultimately, this comes down to gaps in the release engineering. That won't help, the container image often comes from a different source than the docker package. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: 'hash foo' may fail, and would require something like 'hash /usr/bin/foo'
On Mär 11 2022, Ángel wrote: > On 2022-03-09 at 20:35 +0100, Andreas Schwab wrote: >> On Mär 09 2022, Chet Ramey wrote: >> >> > Ultimately, this comes down to gaps in the release engineering. >> >> That won't help, the container image often comes from a different source >> than the docker package. > > The system (under all those conditions) was simply broken. access(2) > didn't work. A good POSIX testsuite should have been able to catch it. That won't help if the docker package and the container image are provided by different organisations. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: Bash-5.2-alpha available
This is still mixing up undo history: bash-5.2$ history 1 echo 1 2 echo 2 3 echo 3 4 history Type e, , , . bash-5.2$ echo 2 2 bash-5.2$ history 1 echo 1 2 echo 2 3* echo 3 4 history 5 echo 2 6 history Type *4 (move to line 3), . bash-5.2$ echo 3 3 bash-5.2$ history 1 echo 1 2 echo 2 3 e 4 history 5 echo 2 6 history 7 echo 3 8 history -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: [Bug Report] The Unexpected Behavior When Using ANSI Escape Code
On Mär 20 2022, Michaelll Lee wrote: > 1) $ PS1='---Test \\ \e[0m ---\\$ ' Read the manual about non-printing characters in the prompt. https://www.gnu.org/software/bash/manual/html_node/Controlling-the-Prompt.html -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
parameter expansion null check fails for arrays when [*] or [@] is used
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-redhat-linux-gnu'
-DCONF_VENDOR='redhat' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL
-DHAVE_CONFIG_H -I. -I. -I./include -I./lib -D_GNU_SOURCE -DRECYCLES_PIDS
-DDEFAULT_PATH_VALUE='/usr/local/bin:/usr/bin' -DSYSLOG_HISTORY -O2 -g -pipe
-Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS
-fexceptions -fstack-protector-strong -grecord-gcc-switches
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection
-Wno-parentheses -Wno-format-security
uname output: Linux tst-rocky85.innovative-navigation.de
4.18.0-348.el8.0.2.x86_64 #1 SMP Sun Nov 14 00:51:12 UTC 2021 x86_64 x86_64
x86_64 GNU/Linux
Machine Type: x86_64-redhat-linux-gnu
Bash Version: 4.4
Patch Level: 20
Release Status: release
Description:
Bash fails to correctly test for parameter to be unset or null when the
parameter is an array reference [*] or [@].
Repeat-By:
myvar[0]=
echo "${myvar[0]:+nonnull}"
-> OK
echo "${myvar[*]:+nonnull}"
nunnull -> not OK, because "${myvar[*]}" is null
echo "${myvar[@]:+nonnull}"
nunnull -> likewise not OK, because "${myvar[@]}" is null
--
Andreas Luik
Leiter Systemintegration & IT / Head of System Integration & IT
in-innovative navigation GmbH
Leibnizstr. 11
D-70806 Kornwestheim
tel: +49 7154 807171 | fax: +49 7154 807154
email: andreas.l...@innovative-navigation.de
www.innovative-navigation.de
in-innovative navigation GmbH is ISO 9001:2015 certified.
Geschäftsführer: Dr. Thomas Gern, Dr. Reinhard Zimmermann, Uwe Vögele
Kreissparkasse Esslingen
BIC: ESSL DE 66 | IBAN: DE51 6115 0020 0008 5986 55 | SWIFT: ESSL DE 66
Handelsregister: Stuttgart HRB 205770 | Steuer-Nr.71330/00796 |
Umsatzsteuer-ID: DE201463746
Re: Bash-5.2-alpha available
I still see clobbered history lines: bash-5.2$ history 1 echo 1 2 echo 2 3 echo 3 4 history Type e, *2, bash-5.2$ echo 2 2 bash-5.2$ history 1 echo 1 2 echo 2 3* echo 2 4 history 5 echo 2 6 history Line 3 should not be modified just because I moved over it. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: defuncted printf process when using wpa_supplicant
On Mär 30 2022, Greg Wooledge wrote: > If it turns out that wpa_supplicant is the parent, then that's the > responsible party, and that's where you should send your bug reports. Processes don't know about process substitutions set up by the shell, thus they cannot be resposible for them. $ sleep 1000 < <(cat /dev/null) & [1] 10418 10418 pts/13 S 0:00 | \_ sleep 1000 10419 pts/13 Z 0:00 | | \_ [cat] -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: Bash-5.2-alpha available
Unfortunately I still see clobbered history lines. When moving to a previous history line, editing it, and then invoking history-search-backward and accepting it, the editing remains on this line (as of before history-search-backward), without a way to undo it (the undo list is empty). -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: Bash-5.2-alpha available
On Mär 31 2022, Chet Ramey wrote:
> So is this the scenario? If you have
>
> echo 1
> echo 2
> echo 3
> history
>
> in your history, type ^P^P^P to get back to the `echo 2'. Add `24' to
> the end, type ^A^F so the cursor is after the `e', then run
> history-search-backward? Hit the `echo 1' and accept-line?
Yes. Afterwards, I see this history:
1 echo 1
2 echo 24
3 echo 3
4 history
5 echo 1
6 history
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Re: bash seems confused about it's state after unclosed single quotes in nested command substitution
On Apr 15 2022, Martin Schulte wrote: > I would either have expected to get PS2 and no error messages after > entering the line starting with sleep That's what I get when trying this in 5.2-beta. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: Crash with 5.2 beta in compgen
On Apr 16 2022, Chet Ramey wrote: > On 4/16/22 1:45 AM, Sam James wrote: > >> Bash Version: 5.2 >> Patch Level: 0 >> Release Status: beta >> Description: >> Bash crashes when running compgen -c -X a. >> Repeat-By: >> # bash -c "compgen -c -X a" >> Segmentation fault (core dumped) > > I can't reproduce this. I wonder if it has to do with resource limits. It crashes in strchr due to NULL pointer (which comes from rl_completer_word_break_characters). #0 __strchr_sse2 () at ../sysdeps/x86_64/multiarch/../strchr.S:32 #1 0x5561b7f5 in mbschr (s=0x0, c=47) at mbschr.c:56 #2 0x555b1d7e in quote_word_break_chars ( text=0x55897b70 "/usr/bin/atoc_conv") at bashline.c:4150 #3 bash_quote_filename (s=s@entry=0x55897b30 "/usr/bin/atoc_conv", rtype=rtype@entry=1, qcp=qcp@entry=0x7fffd60f "") at bashline.c:4353 #4 0x555b2dd4 in executable_completion (searching_path=1, filename=0x55897b30 "/usr/bin/atoc_conv") at bashline.c:1951 #5 command_word_completion_function (hint_text=, state=) at bashline.c:2385 #6 0x77ba0186 in rl_completion_matches ( text=text@entry=0x556410e7 "", entry_function=0x555b2276 ) at ../complete.c:2219 #7 0x555b8164 in gen_action_completions ( text=text@entry=0x556410e7 "", cs=) at pcomplete.c:856 #8 0x555b74bd in gen_compspec_completions ( cs=cs@entry=0x5588e0d0, cmd=cmd@entry=0x55640771 "compgen", word=word@entry=0x556410e7 "", start=start@entry=0, end=end@entry=0, foundp=foundp@entry=0x0) at pcomplete.c:1333 #9 0x555cbdb2 in compgen_builtin (list=) at ./complete.def:721 -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: bash 5.1 heredoc pipes problematic, shopt needed
On Apr 26 2022, Alexey via Bug reports for the GNU Bourne Again SHell wrote: > My key point that we have two choices for future: > - make read from pipe faster, or > - provide options for force here-string to use temp files. > > I don't see any other options for fast-enough performance. Don't use the shell for performance critical tasks. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: -DSYS_BASHRC flag causes segfault on OpenBSD
On Jun 03 2022, Anna (cybertailor) Vyalkova wrote: > 1. export CPPFLAGS="-DSYS_BASHRC='/home/sysrq/bash2/etc/bash/bashrc'" SYS_BASHRC must be a string, not a multi-character constant. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: builtin man page for wait omits information from SIGNALS
On Jun 15 2022, Greg Wooledge wrote: > That builtins.1 file clearly does not contain the ROFF source code for > the content of builtins.0. Which makes me wonder where, exactly, the > content of builtins.0 came from. >From here: .nr zZ 1 .so bash.1 > builtins.1 also contains this line, which I do not understand: > > .TH BASH_BUILTINS 1 "2004 Apr 20" "GNU Bash 5.0" > > The version number and the date stamp do not match each other at all. The date has never been updated between commit 61deeb13 and f188aa6a. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: Bug: garbled history search when using "\e[K" is PS1
On Jun 30 2022, Constantine Bytensky wrote: > 1. Make PS1="\[\e[K\]" CSI K clears the whole line, clobbering the display region controlled by readline, so that is not a valid use of control sequences. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: Feature request
On Jul 06 2022, Brad Hayes wrote: > Perhaps something similar to PHP's __DIR__ and __FILE__ constants? You can get that from $0. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."
Re: $(( )): binary/unary VAR/NUM inconsistency
On Jul 06 2022, Steffen Nurpmeso wrote: > $ bash -c 'I=10; echo $((1++I)); echo $I' > bash: line 1: 1++I: syntax error in expression (error token is "++I") > $ bash -c 'I=10; echo $((1++1)); echo $I' > 10 > > $ bash -c 'I=10;echo "<$(( +10+++I ))>"' > <21> A C compiler would parse all those expressions as post-increment applied to a non-lvalue. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: $(()): "?:": false "assignment to non-variable"
On Jul 09 2022, Steffen Nurpmeso wrote: > $ bash -c 'I=3; echo "$((1?(I*=I):I+=I))";echo $I' The third operand of ?: cannot contain an assignment expression, thus, like in C, this is parsed as `(1?(I*=I):I)+=I'. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."
Re: functions can fully unset local vars in other scopes
On Jul 30 2022, Martin D Kealey wrote: > *2: Adding a new global setting just adds yet another unreasonably > difficulty when sourcing files maintained by multiple authors into one > shell script program. It's not really different to the situation with perl or python. If you use a perl or python module in your program, you need a version of that module that has been ported to the perl or python version in use. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: Bash Coding style - Adopting C99 declarations
On Aug 28 2022, Greg Wooledge wrote:
> On Sun, Aug 28, 2022 at 10:47:38AM -0400, Yair Lenga wrote:
>> Hi,
>>
>> I've noticed Bash code uses "old-style" C89 declarations:
>> * Parameters are separated from the prototype
>> * Variables declared only at the beginning of the function
>> * No mixed declaration/statements
>> * No block local variables
>>
>> intmax_t
>> evalexp (expr, flags, validp)
>> char *expr;
>> int flags;
>> int *validp;
>> {
>> intmax_t val;
>> int c;
>> procenv_t oevalbuf;
>>
>> val = 0;
>> noeval = 0;
>> already_expanded = (flags&EXP_EXPANDED);
>
> You're mistaken. What you're seeing is the "K&R" coding style, which
> predates C89.
Note that the next revision of the C standard removes support for K&R
declarations.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Re: test or [ does not handle parentheses as stated in manpage
On Sep 05 2022, Julian Gilbey wrote: > neither did using \( > instead of (, and neither did putting spaces around the parentheses. You need to do both. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Pending signal in EXIT trap causes pattern matching to fail
gmatch in lib/glob/sm_loop.c returns FNM_NOMATCH when a signal is pending. This can cause spurious pattern matching failures if a SIGPIPE is received while executing the EXIT trap: $ cat trap.sh trap 'set -x; echo trap; case a in *) echo match >&2;; esac; echo done >&2' EXIT while :; do :; done $ bash trap.sh | : ^C++ echo trap trap.sh: line 1: echo: write error: Broken pipe ++ case a in ++ echo done done -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."
Re: string substitution broken since 5.2
On Nov 03 2022, thierryb--- via Bug reports for the GNU Bourne Again SHell
wrote:
> Description:
> String substitution code running for years is broken in 5.2.
>
> Repeat-By:
> string = 'xdotool type "sudo apt update"'
> string="${string//\"/"}"
> printf '%s' "$string"
>
> previously outputs:
> xdotool type "sudo apt update"
>
> but now outputs:
> xdotool type "quot;sudo apt update"quot;
shopt -u patsub_replacement
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Re: Bad leaks file fd to child processes
On Nov 26 2022, "凋叶棕" via Bug reports for the GNU Bourne Again SHell wrote: > But when I execute pvs in the terminal opened through vscode（use Remote-SHH > to connect linux）, the File descriptor was leaked > > File descriptor 19 (/dev/ptmx) leaked on pvs invocation. Parent PID 3789: > /usr/bin/bash > File descriptor 20 (/dev/ptmx) leaked on pvs invocation. Parent PID 3789: > /usr/bin/bash > File descriptor 21 (/dev/ptmx) leaked on pvs invocation. Parent PID 3789: > /usr/bin/bash > File descriptor 99 > (/root/.vscode-server/bin/899d46d82c4c95423fb7e10e68eba52050e30ba3/vscode-remote-lock.root.899d46d82c4c95423fb7e10e68eba52050e30ba3) > leaked on pvs invocation. Parent PID 3789: /usr/bin/bash That looks more like the FD leak is in vscode (and bash just hands them through). -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: `declare -f "a="' fails unnecessarily
On Dez 04 2022, Dale R. Worley wrote:
> In default mode, you actually can do
> $ function a=b { printf hi\\n; }
> though you can't execute it:
> $ a=b foo
> bash: foo: command not found
You just have to quote any part of the function name upto the equal sign
to stop if from being interpreted as an assignment.
$ \a=b foo
hi
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Re: Pending signal in EXIT trap causes pattern matching to fail
On Okt 12 2022, Chet Ramey wrote: > But that's not really the issue right here. The question is whether the > shell should process additional terminating signals while it's running the > exit trap from the terminating signal handler. The problem is that the shell becomes uninterruptable while running the exit trap. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."
Re: reporting a bug
On Dez 15 2022, y...@liberman.co.il wrote:
> function sa {
> for y in $(seq $1 $e2); do
The variable e2 is not defined.
> echo "echo search $y "
> done
> }
>
>
>
> bug description:
> asking to search from 10 to 20 got search from 1 to 10
>
>
> example:
>
> source test.sh
> sa 10 20
The function ignores the second argument.
--
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
Re: for loop goes to stopped job when Ctrl+C is pressed
On Dez 17 2022, ks1322 ks1322 wrote: > When for loop output is piped to less and Ctrl+C is pressed, bash creates > unexpected stopped job That's because the process group receives SIGTTIN because less tries to read from the terminal while it doesn't own it. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: Arithmetic expression: evaluation order bug
On Dez 29 2022, Alain D D Williams wrote:
> On Thu, Dec 29, 2022 at 10:30:09PM +0100, Steffen Nurpmeso wrote:
>
>> only clang warns on sequencing when tested.
>
> Ah: so only clang gives the warning that the others should probably give.
$ gcc -Wall t.c
t.c: In function ‘main’:
t.c:7:11: warning: operation on ‘i’ may be undefined [-Wsequence-point]
i += j += i += j;
^~
t.c:11:11: warning: operation on ‘i’ may be undefined [-Wsequence-point]
i += j += i += i;
^~
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Re: Arithmetic expression: evaluation order bug
On Dez 30 2022, Steffen Nurpmeso wrote: > Andreas Schwab wrote in > <87358xambe@igel.home>: > |On Dez 29 2022, Alain D D Williams wrote: > |> On Thu, Dec 29, 2022 at 10:30:09PM +0100, Steffen Nurpmeso wrote: > |> > |>> only clang warns on sequencing when tested. > |> > |> Ah: so only clang gives the warning that the others should probably give. > | > |$ gcc -Wall t.c > > Sorry, that (-Wall) not. > > |t.c: In function ‘main’: > |t.c:7:11: warning: operation on ‘i’ may be undefined [-Wsequence-point] > | i += j += i += j; > | ^~ > |t.c:11:11: warning: operation on ‘i’ may be undefined [-Wsequence-point] > | i += j += i += i; > | ^~ > > Luckily it is not in real life. Luckily you are mistaken. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: Arithmetic expression: evaluation order bug
On Dez 30 2022, Steffen Nurpmeso wrote: > Not me!! Bash does it right for x=++x, There is no right answer. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: UBSAN error in lib/sh/random.c:79
On Jan 07 2023, Greg Wooledge wrote: > I think this patch might be correct: > > > --- lib/sh/random.c.orig 2023-01-07 12:26:09.049950519 -0500 > +++ lib/sh/random.c 2023-01-07 12:26:27.469974730 -0500 > @@ -70,8 +70,8 @@ > There are lots of other combinations of constants to use; look at > > https://www.gnu.org/software/gsl/manual/html_node/Other-random-number-generators.html#Other-random-number-generators > */ > > - bits32_t h, l, t; > - u_bits32_t ret; > + bits32_t t; > + u_bits32_t h, l, ret; > >/* Can't seed with 0. */ >ret = (last == 0) ? 123459876 : last; > > > I tested it briefly, and it builds cleanly and produces the same random > results as the unpatched version, at least on my system (compiled with > gcc 10.2.1). The assignment t = 16807 * l - 2836 * h can still overflow, because if l and h are unsigned, the computed value can never be negative, but it becomes bigger than INT_MAX if 2836 * h is bigger than 16807 * l (the unsigned result is computed modulo UINT_MAX+1). I think the original overflow can only happen if the argument of intrand32 is bigger than INT_MAX. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: UBSAN error in lib/sh/random.c:79
On Jan 07 2023, Martin Schulte wrote: > 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... Signed overflow is never intended. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: UBSAN error in lib/sh/random.c:79
On Jan 07 2023, Greg Wooledge wrote: > The variable l is a modulus, so its largest possible value is 127772. > If the code simply said "l = ret % 127773;" then it wouldn't even be > an issue. But the % was rewritten, presumably for efficiency. Presumably the assumption was that two divides are more costly than a divide and a multiply (although nowadays, compilers will try to combine the two divides if the target architecture has a divmod insn). -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: Logical expressions and job control
On Feb 10 2023, Godmar Back wrote: > It appears to be mistaking the wait status for the exit status if your > hypothesis is correct. Easy to verify: $ sleep 10 && echo yes || echo $? ^Z [1]+ Stopped sleep 10 148 -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
umask doesn't accept some valid symbolic modes
According to https://pubs.opengroup.org/onlinepubs/9699919799/utilities/chmod.html the symbolic mode can contain more than one action concatenated, for example "g+r-x", which is the same as "g+r,g-x". -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."
Re: command_not_found_handle not run when PATH is empty
On Mär 08 2023, Grisha Levit wrote: > I think it might make sense to change code that looks at the value of > PATH to explicitly treat an empty value as `.' so that all such > behavior is consistent. But an unset PATH is *not* the same as PATH=. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."
Re: $SECONDS and timeout values use realtime `gettimeofday()`
On Mär 23 2023, William Kennington via Bug reports for the GNU Bourne Again SHell wrote: > We have systems that start off with inaccurate clocks and at some point > after the boot process synchronize with the network and jump forward in > time. This has the potential to break any scripts that are sitting in > loops, calculating a timeout based on the $SECONDS variable. The current > behavior using realtime instead of monotime is surprising to us. > > It would be nice if $SECONDS was using `clock_gettime(CLOCK_MONOTONIC, > &val)` as it would usually make the most sense when you want to know the > time since the script started. Even CLOCK_MONOTONIC can jump forward. The only requirement is that it doesn't jump backward. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."
Re: IFS field splitting doesn't conform with POSIX
On Mär 30 2023, Felipe Contreras wrote: > On Thu, Mar 30, 2023 at 10:10 AM Oğuz İsmail Uysal > wrote: >> >> On 3/30/23 2:12 PM, Felipe Contreras wrote: >> > IFS=, >> > str='foo,bar,,roo,' >> > printf '"%s"\n' $str >> zsh is the only shell that generates an empty last field, no other shell >> exhibits this behavior. > > So? This is argumentum ad populum. The fact that most shells do X > doesn't imply that POSIX says X. > > It could very well mean that all shells are implementing POSIX wrong. > Except zsh. Note that zsh by default is not a POSIX shell, and even in sh compatibilty mode it doesn't strive to be POSIX compliant. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: nounset option: Error message points to the wrong variable when accessing associative arrays
On Mai 10 2023, Baumann, Moritz wrote:
> Repeat-By:
> set -u
> declare -r -A myarray=( [foo]='bar' )
> # typo in name of the associative array
> echo ${my_array[foo]}
>
> Expected output: bash: my_array: unbound variable
> Actual output: bash: foo: unbound variable
This is expected. If the array is an indexed array, the subscript is an
arithmetic expression. When bash tries to evaluate the subscript, it
finds that foo is unbound.
--
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
Re: ! history expansion occurs within arithmetic substitutions
On Aug 08 2023, Dale R. Worley wrote:
> More troublesome, I think, are several variable substitutions which
> include "!" followed by a name. But I doubt they're used much in
> interactive mode.
The history expansion is smart enough to not interfere with ${!var}.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Re: using exec to close a fd in a var crashes bash
On Aug 23 2023, Greg Wooledge wrote: > Then again... leaving an FD open in a shell script usually won't matter, > because the script will exit, and that'll just take care of it. The > only times it actually matters are long-running bash processes -- either > interactive shells, or some kind of weird daemon that's been implemented > in bash for some reason -- or scripts that open and (fail to) close lots > of temp FDs in a loop. It will also cause the open FD to be passed to all subsequent commands, and keeps a reference to the underlying file, which may affect EOF processing if the file is a pipe. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."
Re: Warn upon "declare -ax"
On Tue, Sep 05, 2023 at 04:04:50PM +0200, alex xmb ratchev wrote: > On Mon, Sep 4, 2023, 15:19 Kerin Millar wrote: > > > On Mon, 4 Sep 2023 14:46:08 +0200 > > Léa Gris wrote: > > > > > Le 04/09/2023 à 14:18, Dan Jacobson écrivait : > > > > Shouldn't "declare -ax" print a warning that it is useless? > > > > > > There don's seem to be any warning system in Bash or other shells. As > > > long as it is not a fatal error condition and errexit is not set, > > > execution continue. > > > > > > There are static analysis tools like Shellcheck which might be expanded > > > to ware of such incompatible flags but that's it. > > > > Curiously, ARRAY_EXPORT can be defined in config-top.h. It's probably safe > > to say that nobody uses it (nor should anybody wish to upon realising how > > it works). > > > > does it make too big copies or wha .. > > greets , peace .. > On Unix systems, environment variables are plain key-value pairs of strings. An array in bash is not a key-value pair of strings, but a list of strings (and corresponding indexes). The ARRAY_EXPORT configuration option (which I believe isn't settable from the "configure" script, and which I've never tried enabling) presumably makes arrays exportable somehow (probably only to other bash shell instances, similar to how "exportable functions" work). However, since this is not generally supported, and definitely not supported by the default configuration of bash, using this feature makes your scripts hopelessly non-portable. That's part of the "or wha". I haven't looked at the implementation, so Kerin's view may be more informed than mine. -- Andreas (Kusalananda) Kähäri SciLifeLab, NBIS, ICM Uppsala University, Sweden .
Re: Prompt messed up if PS1 contains ANSI escape sequences
On Thu, Sep 07, 2023 at 04:03:39PM +0200, Gioele Barabucci wrote:
> On 07/09/23 15:50, Greg Wooledge wrote:
> > On Thu, Sep 07, 2023 at 03:46:23PM +0200, Gioele Barabucci wrote:
> > > On 07/09/23 15:00, alex xmb ratchev wrote:
> > > > u have to \[ esc-seq \]
> > > > eg inside \[ and \]
> > > >
> > > > PS1=$'\u\[\e[1m\]\h\[\e[0m- '
> > > >
> > > > should display hostname bold
> > >
> > > Thanks for the suggestion, but adding \] does not really fix the problem,
> > > it
> > > just masks it in many cases (better than nothing).
> >
> > The \[ \] wrappings are required. They're not "masking" the problem.
> > Your prompt is literally set incorrectly without them.
>
> Agreed that \] is required. With "masking" I mean that the use of \]
> prevents the problem I'm referring to from showing up easily. But the
> problem is still there even when \] is used.
>
> The following snippet shows that, even with the final \], Bash produces the
> same erroneous output and miscalculates the cursor position (it just needs a
> longer prompt):
>
> $ long_name="$(printf 'abcdef0123456789/%.0s' {0..20})"
> $ mkdir -p /tmp/$long_name
> $ cd /tmp/$long_name
> $ PS1=$'\n\[\e[1m\]\w\[\e[m\] \$ '
>
> Now press the up arrow, then the down arrow)
>
> Regards,
>
> --
> Gioele Barabucci
I can't really reproduce the issue that you are seeing, but isn't the \n
(the newline) also a non-printable character that should be wrapped in
\[ \], since it has no width?
--
Andreas (Kusalananda) Kähäri
Uppsala, Sweden
.
Re: "here document" causing failures. Implementation is inconsistent and not documented.
On Wed, Oct 11, 2023 at 11:56:42AM +1100, Jim McD wrote: > 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 Here, "msg_end" is a word in the shell script. It is not initiating the here-document *at that instance*. The here-document starts on the next line. The here-document is terminated by the occurence of the "msg_end" word on a line by itself. Consider also cat << msg_end | mailx -s "Test" u...@example.com my message goes here msg_end This would be impossible if the shell interpreted the first instance of "msg_end" as anything other than an ordinary word in the script. I'm using the word "word" loosely here. I'm not a grammar expert, but I might mean "token". > > 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 -- Andreas (Kusalananda) Kähäri Uppsala, Sweden .
Re: nullglob is documented incorrectly
On Sun, Nov 05, 2023 at 11:15:50AM +0100, Emanuele Torre wrote: > Today, a user in the #bash IRC channel of libera.chat, misunderstood how > nullglob is supposed to work because is documented incorrectly in the > man page: > > 'nullglob' > If set, Bash allows filename patterns which match no files to > expand to a null string, rather than themselves. > > globs expand to nothing if there are no matches with nullglob set, not > to the null/empty string. > > o/ > emanuele6 It may even be better to say that the patterns that do not match any names are *removed*. That way one avoids the complications and ambiguities of explaining what the pattern expands or not expands to. -- Andreas (Kusalananda) Kähäri Uppsala, Sweden .
Re: nullglob is documented incorrectly
On Nov 06 2023, Chet Ramey wrote: > If nullglob is set, the non-matching pattern expands to the null string, > which is removed by word splitting. Since filename expansion happens after word splitting, this cannot be true. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."
