Re: procsub doesn't release the terminal without reading one byte

2024-10-13 Thread Andreas Schwab
On Okt 13 2024, Oğuz wrote:

> Why though? Can't bash just close the procsub's stdin when `:' returns?

bash has no handle on the command's stdin.

-- 
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: Fwd: New feature

2024-10-12 Thread Andreas Schwab
On Okt 12 2024, Saint Michael wrote:

> After using printf, right now I need to lunch a second command if I
> need to expand the \n  into real new lines.

$ printf %b '\n'

-- 
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: Suggested BASH Improvement

2024-09-18 Thread Andreas Schwab
On Sep 17 2024, BRUCE FOWLER via Bug reports for the GNU Bourne Again SHell 
wrote:

> of C-language compatibility. I could use the [base#]n form
> but that gets awkward.

Why is that awkward?  It's a general solution to a general problem, and
does not require any new features.

> Even the venerable BASH shell still has room for modernization
> and improvement. Thank you for your interest and consideration.

How is $((10#${data_line:12:2})) not modern?

-- 
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: [PATCH 1/2] printf: fix heap buffer overflow in printf_builtin

2024-08-29 Thread Andreas Schwab
On Aug 29 2024, Andrey Kovalev wrote:

> -  for (fmt = format; *fmt; fmt++)
> +  for (fmt = format; fmt - format < strlen(format); fmt++)

How is that different (apart from turing a linear runtime into quadratic
runtime)?

-- 
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-search-backward clobbers history

2024-07-01 Thread Andreas Schwab
The wrong thing is that the history contains commands that were never
executed: echo 13456 and echo 21234.

-- 
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-search-backward clobbers history

2024-07-01 Thread Andreas Schwab
On Jul 01 2024, Chet Ramey wrote:

> On 7/1/24 3:54 AM, Andreas Schwab wrote:
>
>> So what did change in 5.3 that this is now broken?
>
> If you want to report a bug, report one. Be specific about what you
> think is wrong and what you think the correct behavior is.

The correct behvious is not to clobber the history, like it did in 5.2
and earlier.

-- 
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-search-backward clobbers history

2024-07-01 Thread Andreas Schwab
On Jun 27 2024, Chet Ramey wrote:

> It took me a long time to figure this out, and it's completely dependent
> on this particular set of data. You have `histappend' set (it's set by
> default, but this would happen anyway because you have fewer history lines
> added during that shell session than are in the history list). Bash adds
> four commands to the history list during this session, starting with the
> `echo 21234' (it doesn't know about readline's changes to the history
> list). It appends those four commands to the history file, which happens to
> leave the `echo 3456' unchanged -- coincidentally the first history entry
> changed by moving around the history list and editing.

So what did change in 5.3 that this is now broken?

-- 
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."



history-search-backward clobbers history

2024-06-19 Thread Andreas Schwab
$ printf 'echo 1234\necho 2345\necho 3456\n' > history
$ HOME=$PWD HISTFILE=history TERM=xterm bash --norc -i 
<<<$'\20\eb1\e[5~\nhistory\n\20\20\eb2\e[5~\nhistory'
bash-5.3$ echo 1234
1234
bash-5.3$ history
1  echo 1234
2  echo 2345
3  echo 13456
4  echo 1234
5  history
bash-5.3$ echo 2345
2345
bash-5.3$ history
1  echo 1234
2  echo 2345
3  echo 13456
4  echo 21234
5  history
6  echo 2345
7  history
bash-5.3$ exit
$ cat history 
echo 1234
echo 2345
echo 3456
echo 21234
history
echo 2345
history

-- 
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: set -a leads to truncated output from ps

2024-06-13 Thread Andreas Schwab
Why do you think this is a bug in bash?  You are telling the shell to
export any modified variable, and you get what you asked for.

-- 
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] globsort: handle int overflow in cmp functions

2024-05-20 Thread Andreas Schwab
On Mai 17 2024, Grisha Levit wrote:

> The current cmp implementation for size and blocks subtracts the two
> values and returns the difference as an int. This subtraction can
> overflow, and the returned int can end up having the wrong sign.

In the case of globsort_sizecmp, since off_t is wider than int, it can
return a wrong value even if the subtraction doesn't overflow.

-- 
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 in bash

2024-05-14 Thread Andreas Schwab
On Mai 14 2024, Chet Ramey wrote:

> Setting the process group might solve this particular issue, at the cost of
> losing keyboard-generated signals. That's not so bad for SIGINT, though
> people do expect to be able to kill a procsub when you interrupt the job
> using it, but you also wouldn't be able to suspend the procsub with ^Z any
> more. When you're  running a job that contains a process substitution, the
> historical behavior has been that you're able to suspend it along with the
> rest of the job. Same with hitting the job pgrp with something like SIGHUP.

But leaving it in the process group of the parent shell does not
accomplish that, which is actually the point of this thread.  A process
substitution is similar to a pipeline; it really belongs to the process
group of the command that reads from it.

-- 
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."



Changed behaviour of ${PARAMETER/#PATTERN/STRING} and ${PARAMETER/%PATTERN/STRING}

2024-05-13 Thread Andreas Schwab
In 5.3-alpha, it is no longer possible to quote the special % and #
characters in a pattern replacement expansion.

$ a=1/%2/%3
$ echo "${a/\%/##}"
1/%2/%3##
$ echo "${a/\/%/##}"
1##2/%3

The second example shows that quoting still works as expected for
${PARAMETER//PATTERN/STRING}.

-- 
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: bug in bash

2024-05-12 Thread Andreas Schwab
On Mai 12 2024, Greg Wooledge wrote:

> Ah... I assumed bk was an existing file.
>
> hobbit:~$ cat <(wc -l) <.bashrc
> wc: 'standard input': Input/output error
> 0
> hobbit:~$ 

Even then there can be a race when the foreground command finishes fast
enough that bash switches the terminal process group back before the
background process starts reading from the terminal (won't happen in
this example since the cat command blocks on reading the process
substitution file).

-- 
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 in bash

2024-05-12 Thread Andreas Schwab
On Mai 12 2024, Greg Wooledge wrote:

> On Sun, May 12, 2024 at 03:55:21AM +0200, Quốc Trị Đỗ wrote:
>> I found a bug when i tried with syntax <(cmd). this is an example
>> cat <(wc -l) < bk
>
> What is "wc -l" supposed to read from?  It counts lines of standard input,
> until EOF is reached.  But its standard input is a terminal.  And you're
> running it as a background process.
>
> I would *expect* this command to fail with an error message of some
> kind, because a background process shouldn't be allowed to read
> input from a terminal.

Since the redirection fails and the cat command is never started, bash
doesn't switch the terminal process group, and the background wc command
goes on competing with bash for the terminal.

-- 
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: Linux reports memfd_create() being called without MFD_EXEC or MFD_NOEXEC_SEAL set

2024-04-28 Thread Andreas Schwab
On Apr 28 2024, Chet Ramey wrote:

> On 4/27/24 8:09 AM, Andreas Schwab wrote:
>> On Apr 27 2024, Kerin Millar wrote:
>> 
>>> At some point after upgrading to bash-5.3-alpha, the following message 
>>> appeared in my kernel ring buffer.
>>>
>>> [700406.870502] bash[3089019]: memfd_create() called without MFD_EXEC or 
>>> MFD_NOEXEC_SEAL set
>> This warning has been tuned down in later kernels, but nevertheless,
>> bash should pass MFD_NOEXEC_SEAL (if defined) when it calls
>> memfd_create.
>
> OK, I'll bite. What does that buy me?

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=105ff5339f49

-- 
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: ":?xxx" filename broken on autocomplete

2024-04-27 Thread Andreas Schwab
On Apr 27 2024, Kerin Millar wrote:

> In the course of trying this in bash-5.3-alpha, I noticed something else. If 
> ':?aa' is not the only entry in the current working directory, readline 
> behaves as if : is an ambiguous completion. That is:
>
> # mkdir ':?aa'
> # touch 'something-else'
> # rmdir :
>
> ... produces nothing until pressing the tab key a second time, after which 
> both entries are listed while the content of readline's input buffer remains 
> unchanged.

':' is in $COMP_WORDBREAKS.

-- 
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: Linux reports memfd_create() being called without MFD_EXEC or MFD_NOEXEC_SEAL set

2024-04-27 Thread Andreas Schwab
On Apr 27 2024, Kerin Millar wrote:

> At some point after upgrading to bash-5.3-alpha, the following message 
> appeared in my kernel ring buffer.
>
> [700406.870502] bash[3089019]: memfd_create() called without MFD_EXEC or 
> MFD_NOEXEC_SEAL set

This warning has been tuned down in later kernels, but nevertheless,
bash should pass MFD_NOEXEC_SEAL (if defined) when it calls
memfd_create.

-- 
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: Examples of concurrent coproc usage?

2024-04-16 Thread Andreas Schwab
On Apr 16 2024, Carl Edquist wrote:

> Well, you _can_ shovel binary data too: (*)
>
>   while IFS= read -rd '' X; do printf '%s\0' "$X"; done
>
> and use that pattern to make a shell-only version of tee(1) (and I suppose
> paste(1)).  Binary data doesn't work if you're reading newline-terminated
> records, because you cannot store the NUL character in a shell
> variable. But you can delimit your records on NULs, and use printf to
> reproduce them.

Though that will likely add a spurious null at EOF.

-- 
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: syntax error with lone > or < as string in [ ] tests with -a or -o operators

2024-04-15 Thread Andreas Schwab
On Apr 15 2024, Greg Wooledge wrote:

> And that's a bug.  That code is wrong, and it should be written this way
> instead:
>
> [ -z "$var1" ] && [ -z "$var2" ] && continue

Or just [ -z "$var1$var2" ] && continue

-- 
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: Potential Bash Script Vulnerability

2024-04-08 Thread Andreas Schwab
On Apr 08 2024, Greg Wooledge wrote:

> Now imagine what happens if the shell is killed by a SIGKILL, or if
> the system simply crashes during the script's execution.  The script
> is left with altered permissions.

Or the script is executed by more than one process at the same time.

-- 
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: Docco

2024-03-27 Thread Andreas Schwab
On Mär 27 2024, Greg Wooledge wrote:

>> $ [ ! -a /tmp ] && echo ok || echo nok
>> ok
>
> Here, you have three arguments, and argument 2 is a "binary primary"
> (POSIX wording again), so it's treated as if you had written this:
>
> [ ! ] && [ /tmp ] && echo ok || echo nok
>
> This is simply performing two string length tests.  Both strings are
> non-empty (the first is one character, and the second is four), so
> the result is true.
>
> The check for whether the first argument is '!' is not performed,
> because the "$2 is a binary primary" check comes first.  This is how
> POSIX documents it.

FWIW, ksh parses it the other way round:

$ ksh93 -c '[ ! -a /tmp ]; echo $?; [ . -a /tmp ]; echo $?; [ - -a /tmp ]; echo 
$?' 
1
0
ksh93: [: -: unknown operator
2

-- 
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: human-friendly ulimit values?

2024-02-29 Thread Andreas Schwab
On Feb 29 2024, Martin D Kealey wrote:

> Should octal or hexadecimal be allowed (since they're easier to express
> powers of two)?

For this, $(( )) already provides enough support.

-- 
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: human-friendly ulimit values?

2024-02-21 Thread Andreas Schwab
On Feb 21 2024, Christian Convey wrote:

> E.g., for limiting virtual memory to 8 gigabytes, the invocation is "ulimit
> -v 8388608", rather than something like "ulimit -v 8gb".

Or ulimit -v $((8*1024*1024))

-- 
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: About `M-C-e` expand result `'` failed

2024-02-01 Thread Andreas Schwab
On Feb 01 2024, Mike Jonkmans wrote:

> As end user I would expect that, running shell-expand-line then accept-line,
> would do the same as just an accept-line.

If you want to execute the line, let bash expand it.  The
shell-expand-line function's purpose is to let you edit the expansion
further.

> I think that escaping is needed after quote removal in shell-expand-line.

The function is called shell-expand-line, not
shell-expand-and-requote-line.

-- 
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: About `M-C-e` expand result `'` failed

2024-01-30 Thread Andreas Schwab
On Jan 30 2024, Zachary Santer wrote:

> For that matter:
>
> $ echo \${var} # enter
> ${var}
> $ echo \${var} # M-C-e
> $ echo ${var} # enter
> foo
> # Would've expected: echo \${var}
>
> There's no way this is the intended behavior, right?

The command is doing exactly what it is documented to do, that is do all
of the shell word expansions.

-- 
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: wait -n misses signaled subprocess

2024-01-29 Thread Andreas Schwab
On Jan 29 2024, Robert Elz wrote:

> I always wondered why the option was 'n'

n = next?

-- 
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: complete NAME seems to diasable completion for NAME in the case of git

2023-12-21 Thread Andreas Schwab
On Dez 21 2023, Britton Kerin wrote:

> But if I do `complete git' at a new shell

That overwrites the completion spec for git (with the empty set, ie. no
completions at all).  If you want to print existing completions, use
complete -p [NAME...].

-- 
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: funsub questions

2023-12-14 Thread Andreas Schwab
On Dez 13 2023, Greg Wooledge wrote:

> If you'd like to read the contents of a file into a variable, the
> "read" and "readarray" (aka "mapfile") builtins are usually better
> choices anyway.  $(< file) would only be useful if you want the entire
> content in a single string variable, which is a questionable idea in
> most programs.

For interactive use, $(< ...) is convenient and less verbose than the
alternatives.

-- 
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: Missing documentation "-bash_input"

2023-11-28 Thread Andreas Schwab
On Nov 28 2023, Klaus Frank wrote:

> I just noticed that the man pages are missing documentation for the
> "-bash" (or better "-bash_input") parameter.

There is no such thing as a -bash or -bash_input parameter.

> be better readable when being passed as an argument itself to e.g. nspawn
> or docker: `echo test1234 | bash -c "echo $@"`, `bash -c "echo $@" -bash
> "test1234"`, `bash -c "echo $@" -bash_input "test1234"`.

The first argument passed after -c ... is just a placeholder here, it is
used to set the $0 special parameter.

$ bash -c 'echo $0 $2 $1' foo bar mumble
foo mumble bar

-- 
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: Many of the example loadable builtins don't work anymore

2023-11-25 Thread Andreas Schwab
On Nov 25 2023, Emanuele Torre wrote:

> But the bash executable still does not contain the legal_ symbols:

If bash does not reference any of the symbols in lib/sh/compat.c there
is nothing pulling it in.

-- 
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: Command hangs when using process substitution

2023-11-18 Thread Andreas Schwab
On Nov 18 2023, Daniel Barrett via Bug reports for the GNU Bourne Again SHell 
wrote:

> If it's helpful, here's another interesting piece of the puzzle: the
> "xsel -i" command (which also copies stdin to the X primary selection,
> like "xclip -i" does) works fine in the original pipeline, without
> needing the redirect to /dev/null:
>
> $ echo foo | tee >(xsel -i) | tr o x
> fxx

That's because xsel is properly daemonizing itself, disconnecting from
its stdin/out/err.

-- 
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: Command hangs when using process substitution

2023-11-18 Thread Andreas Schwab
On Nov 18 2023, Greg Wooledge wrote:

> On Sat, Nov 18, 2023 at 08:36:06AM -0500, dbarrett--- via Bug reports for the 
> GNU Bourne Again SHell wrote:
>> echo foo | tee >(xclip -i) | tr o x
>> 
>> The command does print "fxx" but then it hangs.
>> 
>> The same command behaves correctly when run in zsh.
>
> For the record, here's what processes are running on the terminal while
> it's in the "hanging" state:
>
> unicorn:~$ ps f -ft pts/28
> UID  PIDPPID  C STIME TTY  STAT   TIME CMD
> greg 1082506 1082504  0 09:21 pts/28   Ss 0:00 bash
> greg 1082862 1082506  0 09:35 pts/28   S+ 0:00  \_ tr o x
> greg 1082864   1  0 09:35 pts/28   S+ 0:00 xclip -i
>
> The tee process has exited, but somehow the tr process has not --
> which must mean that tr's stdin is still open.
>
> One additional observation: if I highlight something (e.g. that ps
> output), this causes the pipeline to terminate.  I assume the xclip
> process somehow notices the highlighting and exits, which causes
> tr to exit, because (presumably) it's the orphaned xclip process
> whose output was still connected to tr's input.

xclip puts itself into the background, unless it is called with -quiet
or -verbose.

   -silent
  fork  into the background to wait for requests, no informational
  output, errors only (default)

   -quiet show informational messages on the terminal and run in the fore-
  ground

   -verbose
  provide a running commentary of what xclip is doing

-- 
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: Idea: jobs(1) -i to print only :%ID:s

2023-11-09 Thread Andreas Schwab
On Nov 09 2023, Greg Wooledge wrote:

> re='^\[([0-9]+)\]'
> jobspecs=()
> while IFS= read -r line; do
> if [[ $line =~ $re ]]; then
> jobspecs+=( "%${BASH_REMATCH[1]}" )
> fi
> done < <(jobs -l)

That fails for multi-line commands that happen to contain matches for
re.

$ (sleep 100; printf $'\n[100]\n') &

-- 
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: nullglob is documented incorrectly

2023-11-06 Thread Andreas Schwab
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."



Re: using exec to close a fd in a var crashes bash

2023-08-23 Thread Andreas Schwab
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: ! history expansion occurs within arithmetic substitutions

2023-08-08 Thread Andreas Schwab
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: nounset option: Error message points to the wrong variable when accessing associative arrays

2023-05-10 Thread Andreas Schwab
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: IFS field splitting doesn't conform with POSIX

2023-03-30 Thread Andreas Schwab
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: $SECONDS and timeout values use realtime `gettimeofday()`

2023-03-29 Thread Andreas Schwab
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: command_not_found_handle not run when PATH is empty

2023-03-09 Thread Andreas Schwab
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."



umask doesn't accept some valid symbolic modes

2023-02-22 Thread Andreas Schwab
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: Logical expressions and job control

2023-02-10 Thread Andreas Schwab
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."



Re: UBSAN error in lib/sh/random.c:79

2023-01-07 Thread Andreas Schwab
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: UBSAN error in lib/sh/random.c:79

2023-01-07 Thread Andreas Schwab
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

2023-01-07 Thread Andreas Schwab
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: Arithmetic expression: evaluation order bug

2022-12-29 Thread Andreas Schwab
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: Arithmetic expression: evaluation order bug

2022-12-29 Thread Andreas Schwab
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

2022-12-29 Thread Andreas Schwab
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: for loop goes to stopped job when Ctrl+C is pressed

2022-12-18 Thread Andreas Schwab
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: reporting a bug

2022-12-15 Thread Andreas Schwab
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: Pending signal in EXIT trap causes pattern matching to fail

2022-12-07 Thread Andreas Schwab
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: `declare -f "a="' fails unnecessarily

2022-12-04 Thread Andreas Schwab
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: Bad leaks file fd to child processes

2022-11-26 Thread Andreas Schwab
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: string substitution broken since 5.2

2022-11-03 Thread Andreas Schwab
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."



Pending signal in EXIT trap causes pattern matching to fail

2022-10-12 Thread Andreas Schwab
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: test or [ does not handle parentheses as stated in manpage

2022-09-05 Thread Andreas Schwab
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."



Re: Bash Coding style - Adopting C99 declarations

2022-08-28 Thread Andreas Schwab
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: functions can fully unset local vars in other scopes

2022-07-29 Thread Andreas Schwab
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: $(()): "?:": false "assignment to non-variable"

2022-07-11 Thread Andreas Schwab
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: $(( )): binary/unary VAR/NUM inconsistency

2022-07-06 Thread Andreas Schwab
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: Feature request

2022-07-06 Thread Andreas Schwab
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: Bug: garbled history search when using "\e[K" is PS1

2022-06-30 Thread Andreas Schwab
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: builtin man page for wait omits information from SIGNALS

2022-06-15 Thread Andreas Schwab
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: -DSYS_BASHRC flag causes segfault on OpenBSD

2022-06-04 Thread Andreas Schwab
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: bash 5.1 heredoc pipes problematic, shopt needed

2022-04-25 Thread Andreas Schwab
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: Crash with 5.2 beta in compgen

2022-04-16 Thread Andreas Schwab
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 seems confused about it's state after unclosed single quotes in nested command substitution

2022-04-15 Thread Andreas Schwab
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: Bash-5.2-alpha available

2022-03-31 Thread Andreas Schwab
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-5.2-alpha available

2022-03-31 Thread Andreas Schwab
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: defuncted printf process when using wpa_supplicant

2022-03-30 Thread Andreas Schwab
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

2022-03-22 Thread Andreas Schwab
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: [Bug Report] The Unexpected Behavior When Using ANSI Escape Code

2022-03-20 Thread Andreas Schwab
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."



Re: Bash-5.2-alpha available

2022-03-11 Thread Andreas Schwab
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: 'hash foo' may fail, and would require something like 'hash /usr/bin/foo'

2022-03-11 Thread Andreas Schwab
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: 'hash foo' may fail, and would require something like 'hash /usr/bin/foo'

2022-03-09 Thread Andreas Schwab
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'

2022-03-09 Thread Andreas Schwab
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: Bash-5.2-alpha available

2022-03-02 Thread Andreas Schwab
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: Bash-5.2-alpha available

2022-02-27 Thread Andreas Schwab
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

2022-02-16 Thread Andreas Schwab
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: the "-e" command line argument is not recognized

2022-02-16 Thread Andreas Schwab
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: Interesting bug

2022-02-12 Thread Andreas Schwab
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: Bash-5.2-alpha available

2022-02-10 Thread Andreas Schwab
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: Bash-5.2-alpha available

2022-01-22 Thread Andreas Schwab
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

2022-01-22 Thread Andreas Schwab
bash --posix -c 'read -t1 

Re: Bash not escaping escape sequences in directory names

2022-01-22 Thread Andreas Schwab
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: ~0, ~00, etc tilde expand to ~CURRENTUSER

2021-12-26 Thread Andreas Schwab
~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: Line is corrupted when pasting long string in vi mode with exit_attribute_mode prompt

2021-12-18 Thread Andreas Schwab
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: bash conditional expressions

2021-11-17 Thread Andreas Schwab
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: bash conditional expressions

2021-11-15 Thread Andreas Schwab
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

2021-11-12 Thread Andreas Schwab
  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

2021-11-12 Thread Andreas Schwab
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: hash not restored after running command -p

2021-11-03 Thread Andreas Schwab
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: read built-in command has a problem in shell function

2021-10-11 Thread Andreas Schwab
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: read built-in command has a problem in shell function

2021-10-11 Thread Andreas Schwab
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: Using systemd-249's libnss_systemd.so.2 triggers a crash in bash-5.1's malloc.c

2021-10-04 Thread Andreas Schwab
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: Using systemd-249's libnss_systemd.so.2 triggers a crash in bash-5.1's malloc.c

2021-10-04 Thread Andreas Schwab
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

2021-10-04 Thread Andreas Schwab
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

2021-10-04 Thread Andreas Schwab
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

2021-10-04 Thread Andreas Schwab
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

2021-10-04 Thread Andreas Schwab
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."



  1   2   3   4   5   6   7   8   >