Re: [feature request] Add ".sh" or ".bash" extension to tmpfile generated by `fc`
On 9/21/24 1:03 AM, Oğuz wrote:
On Saturday, September 21, 2024, Koichi Murase <mailto:myoga.mur...@gmail.com>> wrote:
Emacs has `auto-mode-alist'. VS Code has `files.associations'.
I think he meant a command line option. Like something you can put in FCEDIT
I did. But if there aren't any options to select the syntax editing mode,
you can use an approach like this:
: ${EDITOR:=emacs}
case $1 in
*.bash) FN=$1 MV=':' ;;
*) FN=${1}.bash MV=mv ;;
esac
$MV "$1" "$FN"
$EDITOR "$FN"
$MV "$FN" "$1"
Wrap that in a script or function and assign it to FCEDIT. You could
also use ln and rm instead of mv, but this works. And test it; I didn't.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
OpenPGP_signature.asc
Description: OpenPGP digital signature
Re: [feature request] Add ".sh" or ".bash" extension to tmpfile generated by `fc`
On 9/20/24 2:41 AM, shynur . wrote: `fc` will create a temporary file named something like "bash-fc.Esf9by", which seldom benefits from editors that use *suffixes* to infer what syntax highlighting should be enabled. Do these editors have an option that sets the language for syntax checking? -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/ OpenPGP_signature.asc Description: OpenPGP digital signature
Re: printf inconsistent results for %.0f
On 9/19/24 1:39 AM, Stephane Chazelas wrote:
Looks like printf(3) gets called with a `Lf' conversation specifier and
a double argument.
Yes, I came to the same conclusion with an essentially identical fix.
[...]
Would it be possible to have a 5.2 patch released with the
backport of those two fixes?
Sure, when I get a chance I'll do the patch engineering. Here's what it
will be.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
*** ../bash-20231106/configure.ac Fri Aug 11 14:52:31 2023
--- configure.acTue Nov 21 12:00:25 2023
***
*** 899,903
[AC_LANG_PROGRAM(
[[#include ]],
! [[long double r; char *foo, bar; r = strtold(foo, &bar);]]
)],
[bash_cv_strtold_broken=no],[bash_cv_strtold_broken=yes])
--- 900,904
[AC_LANG_PROGRAM(
[[#include ]],
! [[long double r; char *foo, *bar; r = strtold(foo, &bar);]]
)],
[bash_cv_strtold_broken=no],[bash_cv_strtold_broken=yes])
*** ../bash-20231106/configure Fri Aug 18 16:27:53 2023
--- configure Tue Nov 21 12:00:30 2023
***
*** 15923,15927
main (void)
{
! long double r; char *foo, bar; r = strtold(foo, &bar);
;
--- 15932,15936
main (void)
{
! long double r; char *foo, *bar; r = strtold(foo, &bar);
;
*** ../bash-5.2-patched/builtins/printf.def Fri Jun 24 10:09:50 2022
--- builtins/printf.def Tue Aug 13 10:36:55 2024
***
*** 710,714
p = getfloatmax ();
! f = mklong (start, "L", 1);
PF (f, p);
}
--- 710,714
p = getfloatmax ();
! f = mklong (start, FLOATMAX_CONV, USE_LONG_DOUBLE);
PF (f, p);
}
OpenPGP_signature.asc
Description: OpenPGP digital signature
Re: Question on $IFS related differences (Was: Question on $@ vs $@$@)
On 9/19/24 2:42 AM, Robert Elz wrote:
Date:Thu, 19 Sep 2024 00:45:44 +0200
From:Steffen Nurpmeso
Message-ID: <20240918224544.aXWgbZu-@steffen%sdaoden.eu>
| Woops. I did not know that, i always separate {} at the beginning
| an the end, yet not ().
'(' and ')' (parentheses) are operators, '{' and '}' (braces) are not,
nor are '[' and ']' (brackets) - though I have never really understood
bash's rules for '[[' and ']]' in this context.
`[[' and `]]' are reserved words, and `']]' is recognized as a reserved
word if it appears in a command position, with the provision that after a
`[[', what's between the brackets is a conditional command, with its own
grammar rules, so operators like `;' will cause a parse error.
This is similar to `{' and `}'.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
OpenPGP_signature.asc
Description: OpenPGP digital signature
Re: Suggested BASH Improvement
On 9/18/24 1:10 PM, Greg Wooledge wrote:
Thanks for the proposal. I think the [base#]n syntax is reasonable
here without adding a new shell option.
Do recall, however, that negative numbers break the workaround suggested
by Andreas.
$((10#${line:12:2}))
Not part of the original problem statement.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: Suggested BASH Improvement
On 9/17/24 7:50 PM, BRUCE FOWLER via Bug reports for the GNU Bourne Again
SHell wrote:
An interesting problem I ran into recently:
I have a shell script that I run about once a month that
"screen-scrapes" from the output of another program using the
substring capability, e.g. ${data_line:12:2}. This is pulling
out the two-digit month ranging from "01" to "12".
This worked fine, even giving the right answers, for
months earlier in the year. Then came August, and it went
sideways because the leading "0" was forcing the number to be
interpreted as octal. My first reaction was, What's going on,
this has run just fine for months. The second reaction was,
WTF, who uses octal anymore? But I understand it is because
of C-language compatibility. I could use the [base#]n form
but that gets awkward.
Thanks for the proposal. I think the [base#]n syntax is reasonable
here without adding a new shell option.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: Question on $IFS related differences (Was: Question on $@ vs $@$@)
On 9/18/24 1:05 AM, Oğuz wrote:
On Wed, Sep 18, 2024 at 4:19 AM Steffen Nurpmeso wrote:
It boils down to this:
f(){ echo $#;}; set "" "" ""; IFS=x; f $*
bash, NetBSD and FreeBSD sh, and ksh88 all agree and print 2. pdksh
prints 3 but mksh and oksh print 1. dash, ksh93, yash, and zsh print
0.
It's an implementation difference.
The shells that print `0' treat the `may' as `shall' in this sentence from
https://pubs.opengroup.org/onlinepubs/9799919799/utilities/V3_chap02.html#tag_19_05_02
"When the expansion occurs in a context where field splitting will be
performed, any empty fields may be discarded and each of the non-empty
fields shall be further split as described in 2.6.5 Field Splitting."
So they immediately expand the $* to nothing.
The shells that print `2' don't immediately discard the empty fields and
separate them with the first character of IFS. After quote removal and
removing the empty fields, since the individual words in $* are subject
to additional expansion, you're left with `xx'. When you split that,
you get two empty fields.
I'm not sure what's going on with the shells that print `1' unless they
somehow don't use the first character of IFS to separate the arguments
and let multiple sequential delimiters terminate the first field.
I assume that pdksh just expands each positional parameter to a quoted
empty string and passes them all to f.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: 'wait -n' with and without id arguments
On 9/9/24 10:45 AM, Zachary Santer wrote: He wants interactive shells to notify the user less frequently about job status changes so `wait -n' works better. That's one option, but not my preferred option. I'll attempt a tl;dr: Stipulating that this is for interactive shells only. A) Solve 'wait -n' inconsistency through changes to job status notification: Pretty non-specific, but I assume you want notifications to behave like POSIX specifies in the latest version of the standard. - Would require more user-facing changes to bash's behavior in default mode - Potentially more difficult to implement correctly - Would leave some loose ends that would just have to be documented in the man page Like `set -b'? B) Solve 'wait -n' inconsistency by allowing it to act on the list of saved pids and statuses of jobs whose termination has already been notified to the user: - POSIX doesn't agree with the existence of that list POSIX says everything should disappear when you get notified or the subject of `wait', so there's that (bash just does it on `wait'). Those semantics have defenders just as ardent as you are. - 'set -o posix' exists so bash's default behavior can differ from that specified by POSIX when POSIX is wrong-headed - now I think 'wait' with id arguments should clear those ids and statuses from the list of notified jobs, which does increase the user-facing changed behavior a bit That's more POSIX semantics, and it's already implemented in posix mode. You have to do that anyway, to avoid handing back the same pid repeatedly when `wait -n' is called. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: Readline Documentation
On 9/14/24 2:45 PM, G. Branden Robinson wrote: At 2024-09-13T15:24:15-0400, Chet Ramey wrote: It has no effects in its default state. If you don't change it, nothing happens. If you change it, you change `bell-style' instead. The fact that its usage continues suggests documenting it as deprecated would be beneficial. Maybe. Or maybe it's just time to remove it once and for all. I am reminded of <https://lists.gnu.org/archive/html/bug-bash/2016-02/msg00186.html>. :) The original report included that link. https://lists.gnu.org/archive/html/bug-bash/2024-09/msg00028.html -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/ OpenPGP_signature.asc Description: OpenPGP digital signature
Re: bash builtins mapfile issue - Unexpected parameter passing of causes rce
On 9/14/24 7:46 AM, ~ via Bug reports for the GNU Bourne Again SHell wrote: Dear bug-bash team: I hope this email finds you well. During my recent security assessment of bash, I identified a potential security vulnerability that I believe may impact the security of your product and its users. Thanks for the note. You have not yet identified a security vulnerability. 1、mapfile -C xxx will call run_callback 2、evil "execstr" parameter passing causes rce mapfile.def for example in bash shell: echo -e "line1\nline2\nline3\nline4\nline5\nline6\nline7\nline8\nline9\nline10" > test.txt mapfile -t -C "whoami #111" -c 5 my_array < test.txt This is how the mapfile callback is intended to work. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/ OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Readline Documentation
On 9/13/24 11:00 AM, John Devin wrote: As you said, it's been deprecated -- and undocumented -- for over 30 years (and remains only for backwards compatibility). There's no reason to document it. I understand it's been superseded, but I do want to point this out: running `bind -v` in bash 5.2.21 right now still lists 'set prefer-visible-bell on' in its output. Sure, the variable corresponding to the option has a default value -- all variables do. That variable is literally never used. I considered that maybe it would only do this in response to being set directly, but neither ~/.bashrc nor /etc/bash.bashrc on my system include it, nor any other file I can find. Unless this has been changed between that version and now, it means bash is currently reporting a variable with no way to discover what it means or what its effects are without changing it and testing. It has no effects in its default state. If you don't change it, nothing happens. If you change it, you change `bell-style' instead. The fact that its usage continues suggests documenting it as deprecated would be beneficial. Maybe. Or maybe it's just time to remove it once and for all. Many of the stackoverflow/reddit/etc discussions I found while looking into this included people using both 'bell-style' and 'prefer-visual-bell' simply because they didn't know what one meant, and then keeping both in their config once they found the combination that did what they wanted. Essentially, I think it's being cargo-culted. The fact that `bind -v` still reports it certainly doesn't help. Did these discussions note that it's not documented? -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/ OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Readline Documentation
On 9/11/24 3:19 PM, John Devin wrote: Hello all, Sorry in advance if this is poorly formatted; I used plain-text mode in gmail but who knows if that works properly. It looks just fine. While hunting down some problems on a terminal, I ran across the option 'prefer-visible-bell'. It took me some time looking into this before finding out it was deprecated in favor of 'bell-style' about 20 years ago, per: https://lists.gnu.org/archive/html/bug-bash/2016-02/msg00186.html. As the last line in that message says, it was never documented. Readline didn't really even have documentation until version 2.1 in 1997, well after bell-style. Despite that, it still shows up in stackoverflow answers and reddit threads even from as recently as six months ago: https://www.reddit.com/r/bashonubuntuonwindows/comments/1b55k9f/that_stupid_bell/kt3l0hm/. Could this option be documented in the man page? As you said, it's been deprecated -- and undocumented -- for over 30 years (and remains only for backwards compatibility). There's no reason to document it. It would have saved me a bit of wasted time, and it would give me a resource to point to (other than an old mailing list thread) to authoritatively state it's been superseded. It's been superseded. It's not just undocumented; it's not supposed to be used. But there was no reason to break users' startup files, and that is still true. (Yes, I would have hoped usage would have dried up, but change is hard.) Is it non-functional now? No. If so, is it synonymous with setting bell-style visual? Yes, setting it to on changes bell-style to visual. And is setting it off synonymous with bell-style none? No, it's a synonym for bell-style audible. That was the original meaning of prefer-visible-bell. One of the reasons I added bell-style in 1993 was to support `none' as a value. Before that, you couldn't turn it off. Additionally, as discussed in the mail link above, I think the 'convert-meta' and 'input-meta' need slightly more description. For example, is this statement accurate: "The convert-meta variable has no effect if input-meta is off." From the manpage I would think so, but I'm just not confident. I also can't tell conclusively whether the output-meta variable is affected by convert-meta, or vice-versa. Those descriptions have undergone fairly significant changes, the result of this thread: https://lists.gnu.org/archive/html/bug-readline/2024-08/msg3.html Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/ OpenPGP_signature.asc Description: OpenPGP digital signature
Re: "make depend(s)" broken
On 9/10/24 8:21 PM, Martin D Kealey wrote:
Problem 2: it appears that “make depends” and “make depend” have been
broken since:
commit 6078dd9a9708077bb32d7027b3699a4bcc3d0a93
Author: Chet Ramey
Date: 2018-04-20 11:38:52 -0400
which replaced support/mkdep with a version that lacked the “-c compiler”
option and the “--” end-of-options marker, both of which are required for
the “depends” make target:
$(Program) $(SUPPORT_SRC)mkdep* -c ${CC} -- *${CCFLAGS} ${CSOURCES}
If you want to use it, I'll fix it up.
PS: It seems like that Makefile line should use “sh” rather than
“$(Program)”, otherwise it would be impossible to go “make depend” before
the initial build.
The dependencies already in the Makefile are assumed to be correct, plus
you're making everything the first time through anyway. But it doesn't
really matter.
PPS: "mkdep" seems like a deficient exemplar of a robust shell script; lack
of quoting; broken and missing error checking; error messages to stdout
instead of stderr.
The BSDs still use it.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
OpenPGP_signature.asc
Description: OpenPGP digital signature
Re: "make depend(s)" broken
On 9/10/24 8:21 PM, Martin D Kealey wrote:
As part of merging "shopt" and "set -o", I've had to update quite a lot of
files, including adding and removing #includes.
So I thought I should run "make depends" to fix up the Makefile.
I don't use that target any more. Bash is mature enough that I'm not making
extensive enough changes to include files.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: Feature request: process title with exec -a "" for oneself
On 9/5/24 8:37 PM, Lockywolf wrote:
Chet Ramey writes:
So I assume that you want to change the kernel's idea of the process
arguments as seen and displayed by `ps'. If so, I'm not really interested
in adding that as a feature. It doesn't seem to add anything for shell
users.
Well, I am a shell user :).
Indeed, that is true.
I would really love to have such a feature because I have two use-cases
for it.
1. I would use it as a super minimalist progress indicator for one-shot
scrips written with little consideration.
For example, I sometimes find myself writing something like:
`while true; do try_something_slow && exit 0 ; sleep 1 ; done &`
With a setproctitle I would write something like:
`I=0 ; while true; do try_something_slow && exit 0 ; I=$((I + 1)) ;
setproctitle "trier_$I-times" sleep 1 ; done &`
And this leaves no lingering files, does not require finding a PID to
look at `/proc/$pid/environ`, et cetera. I can just query the progress
using `ps`.
You could just as easily have a function write to your terminal window's
title bar.
2. I would use it to distinguish subshells from the current script in
`ps`.
By default a subshell has the same name as the parent shell.
So when I run `ps/pgrep`, I often get processes with the same name, and
I'd have to parse the output of `pstree` to find out which is which.
And running exec -a "${BASH_ARGV0}_child" while true ; do sleep 1 ; done &
is not a valid syntax.
exec -a "${BASH_ARGV0}_child" bash -c 'while true ; do sleep 1 ; done &'
or put the command in a shell script.
I think this is appropriate for a loadable builtin. This one is Linux-
specific.
I am not experienced enough to have an opinion on whether a loadable
built-in is better than a feature of "exec".
It's more of a per-user opt-in that doesn't require changes to the shell.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: autoconf can't cope with picky compiler, typo in shmbutil.h
On 9/10/24 7:22 AM, Martin D Kealey wrote: Apart from that, this managed to uncover an *actual* bug: Thanks for the report. Nothing currently uses that define. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: Temporary history file not being removed from home directory
On 9/7/24 6:04 AM, Dmytro Bagrii wrote: Bash Version: 5.2 Patch Level: 32 Release Status: release Description: Sometimes .bash_history-X.tmp file remains present in $HOME directory. Both ~/.bash_history and ~.bash_history-X.tmp are 65536 lines long, as specified by $HISTFILESIZE. ~/.bash_history-X.tmp contain older commands and doesn't contain more recent commands, as expected. After manual removal of ~/.bash_history-X.tmp after some time new tmp file emerges. This doesn't seem like the whole story. You probably have PROMPT_COMMAND set to append the history at every command (otherwise, the temp file would not `reappear' after some time). It looks like one of the writes or renames fails, so the history library leaves the temp file there in case it needs to be manually modified, but a subsequent write succeeds, updating the `real' history file. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/ OpenPGP_signature.asc Description: OpenPGP digital signature
Re: 'wait -n' with and without id arguments
On 9/8/24 11:13 PM, Oğuz wrote: On Monday, September 9, 2024, Zachary Santer <mailto:zsan...@gmail.com>> wrote: Slightly improved wait-n-failure attached. It's >100 lines and your replies are too long. Summarize what you want so others can contribute too without having to waste time reading the whole thread. He wants interactive shells to notify the user less frequently about job status changes so `wait -n' works better. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/ OpenPGP_signature.asc Description: OpenPGP digital signature
Re: No error for missing semicolon before "then"
On 9/6/24 11:44 AM, Ulrich Mueller wrote: Bash Version: 5.2 Patch Level: 32 Release Status: release Description: The following command does not error out, in spite of a semicolon missing before "then": $ if [[ x ]] then :; fi Previous versions (e.g. 4.4.23) used to report an error: bash: syntax error near unexpected token `then' POSIX says that construct, even though the particular compound command isn't part of the standard, should be accepted. Here's the report about it, from a discussion about a broader topic: https://lists.gnu.org/archive/html/bug-bash/2021-02/msg00140.html All shells that implement [[...]] (bash/ksh/mksh/zsh) behave this way. Bash changed in version 5.2. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/ OpenPGP_signature.asc Description: OpenPGP digital signature
Re: 'wait -n' with and without id arguments
On 8/30/24 11:06 PM, Zachary Santer wrote:
New wait-n-failure attached.
I'll look at this. These always take a long time.
(Apparently ${SECONDS} can't be declared local
and still work.)
Making a variable local removes the special behavior on assignment and
reference.
$ source ~/random/wait-n-failure run monitor
run true
explicit_pids false
monitor true
notify false
posix false
bash 5.3.0(1)-alpha
[5]+ Done wait-n-failure_random_sleep
[1] Done wait-n-failure_random_sleep
[2] Done wait-n-failure_random_sleep
[3] Done wait-n-failure_random_sleep
[4]- Done wait-n-failure_random_sleep
[5]- Done wait-n-failure_random_sleep
[6]- Done wait-n-failure_random_sleep
[7]- Done wait-n-failure_random_sleep
[8] Done wait-n-failure_random_sleep
[9] Done wait-n-failure_random_sleep
[10]+ Done wait-n-failure_random_sleep
[1]+ Done wait-n-failure_random_sleep
[1]+ Done wait-n-failure_random_sleep
[1]+ Done wait-n-failure_random_sleep
[... All following "Done" notifications are for jobs with job id 1.]
96 processes waited / 100 processes forked
11 seconds
I did not expect to see job notifications here. The changelog seems pretty
clear that there shouldn't be any.
There are other code paths where the shell notifies, and this is probably
one of them. I will take a look at where. Certainly the conditions under
which the shell notifies about changed job status should be consistent.
On Mon, Aug 26, 2024 at 10:57 AM Chet Ramey <mailto:chet.ra...@case.edu>> wrote:
>
> On 8/14/24 11:22 PM, Zachary Santer wrote:
> > On Wed, Aug 14, 2024 at 3:22 PM Chet Ramey <mailto:chet.ra...@case.edu>> wrote:
> >>
> >> On 8/7/24 2:47 PM, Zachary Santer wrote:
> >
> >>> If you want the behavior of 'wait -n' to be
> >>> consistent between scripts and the interactive shell, then it should
> >>> choose one terminated child process from the list of those that is
> >>> maintained in the interactive shell, if it's nonempty, to report to
> >>> the user and to clear from that list, any time it is called.
> >>
> >> I'm not sure returning the status of some random process from some
> >> arbitrary point in the past is going to be valuable.
> >
> > I think the value is in the consistent behavior of 'wait -n', which
> > this would provide. If the user is intent on running 'wait -n' without
> > id arguments in the interactive shell, they can ensure that child
> > processes forked long ago are ignored by simply calling 'wait' without
> > -n before moving on to what they're trying to do.
>
> Sure, they can do that. That's a new requirement, though.
I've seen you point out "I can't imagine why a person would do X, so it
must never happen" as being fallaciou.
I'm sure I've been guilty of it myself.
However, I think the benefit to
consistent behavior far outweighs the hardship caused to whoever would
write a script intended for use within the interactive shell that depends
on 'wait -n' without id arguments ignoring background processes that the
user has already been notified of via the 'jobs' output.
Consider programmable completion frameworks, commands executed via
`bind -x', or traps (e.g., DEBUG) intended to provide enhancements to
the standard behavior, all of which exist and have generated reports or
requests for features.
People put pretty complicated stuff into PROMPT_COMMAND and other prompts,
too.
We don't know how the existing uses would be affected by changes until I
make them.
If the behavior here isn't modified, the man page really should note that
'wait -n' without id arguments won't return the termination status of a
child process that has already been notified through the 'jobs' output.
That is exactly the behavior posix seems to require (`wait -n' aside, but
see below): once you notify the user, you delete the job and it disappears
forever. Bash doesn't delete jobs like that in all cases, and that's the
source of at least kre's objections (as you note below).
The only real question is when (and under what circumstances) you do the
notification, and that's what we're trying to hash out.
> > On Wed, Aug 14, 2024 at 4:44 PM Robert Elz <mailto:k...@munnari.oz.au>> wrote:
> >>
> >> | Maybe the thing to do is to retain jobs in the job list, even after
Re: 'wait -n' with and without id arguments
On 8/30/24 11:06 PM, Zachary Santer wrote: CWRU/CWRU.chlog: > 8/26 > > execute_cmd.c > [...] > - execute_connection: in default mode, bash performs jobs notifications > in an interactive shell between commands separated by ';' or '\n'. > It shouldn't do this in posix mode, since posix now specifies when > notifications can take place I forgot your comment below about the shell not being interactive any time it's not accepting input from the user and took this to mean that 'jobs' notifications would only ever be printed immediately prior to a prompt when bash is in posix mode. I don't understand what posix mode changes relative to the existing behavior if not that. In default mode, bash prints job notifications when executing a list (it calls lists `connections' internally). Commands in lists can be delimited by a `;' or newline; bash performs notifications between executing, say, the left and right sides of `command 1; command 2'. Now it doesn't do that in posix mode. It still does job notifications in other places that aren't strictly posix conformant. > jobs.c > - notify_and_cleanup: make interactive shells notifying during sourced > scripts dependent on the shell compatibility level and inactive in > versions beyond bash-5.2 > Inspired by report from Zachary Santer <mailto:zsan...@gmail.com>> Making 'jobs' notifications not happen while the interactive shell is sourcing a script misses the cases where a function is otherwise executed directly from the command line and of course a whole bunch of commands separated by semicolons entered in one command line. What behavior do you want from the command lists that differs from what I described above? Since shell functions are essentially lists, you should get the same behavior from both. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/ OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Feature request: process title with exec -a "" for oneself
On 9/4/24 5:54 PM, Emanuele Torre wrote: Not super relevant, but I have a bash loadable builtin that can set the script's proctitle that I wrote for fun ~1 year ago. I think this is appropriate for a loadable builtin. This one is Linux- specific. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/ OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Feature request: process title with exec -a "" for oneself
On 8/31/24 10:43 PM, Lockywolf wrote:
Dear Bash developers,
May I ask for a small feature to be added to bash?
At the moment exec changes IO redirections for the newly started
processes, but if there is no command for exec'ing, it changes those
redirections for the bash process itself.
The exec -a, however, allows setting the current process title (argv0)
only for the newly exec'ed processes, and "exec -a whatever" (without a
command) does nothing.
However it seems to be possible (albeit in a series of 8 syscalls) to
change the _current_ process' cmdline and argv0:
Currently, the shell's argc/argv are exposed to the user as
$1...$n - the positional parameters (argv[1]...argv[argc])
$# - the number of positional parameters (argc)
$0 - argv[0]
You can change the positional parameters and $# using the `set' builtin,
and, in bash versions newer than bash-4.4, you can change $0 by assigning
to BASH_ARGV0.
So I assume that you want to change the kernel's idea of the process
arguments as seen and displayed by `ps'. If so, I'm not really interested
in adding that as a feature. It doesn't seem to add anything for shell
users.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
OpenPGP_signature.asc
Description: OpenPGP digital signature
Re: [PATCH 2/2] printf: fix heap buffer overflow in bexpand
On 8/29/24 10:22 AM, Andrey Kovalev wrote: In the loop, when iterating through the array, there was no check whether an element of the array goes beyond its limits. And with certain input data, there is an outflow from the array. Thanks for the report. This was fixed back in May, 2023, the result of https://lists.gnu.org/archive/html/bug-bash/2023-05/msg00131.html -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/ OpenPGP_signature.asc Description: OpenPGP digital signature
Re: [PATCH 1/2] printf: fix heap buffer overflow in printf_builtin
On 8/30/24 10:41 AM, Martin D Kealey wrote:
Hi Andrei
Ok, I see the problem.
This fault is triggered when the format string has '%(' but is missing the
closing ')' - so the entire remainder of the format string is tentatively
recorded as the time-format substring.
Yes.
This line:
if (*++fmt != 'T')
should be changed to:
if (n > 0 || *++fmt != 'T')
I prefer checking whether *fmt == ')', which is equivalent but clearer.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
OpenPGP_signature.asc
Description: OpenPGP digital signature
Re: [PATCH 1/2] printf: fix heap buffer overflow in printf_builtin
On 8/29/24 10:21 AM, Andrey Kovalev wrote: In the loop, when iterating through the array, there was no check whether an element of the array goes beyond its limits. And with certain input data, there is an outflow from the array. Thanks for the report. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/ OpenPGP_signature.asc Description: OpenPGP digital signature
Re: bash - reproducible SEGFAULT on rapid SIGINTs
On 8/30/24 5:05 AM, Eduardo A. Bustamante López wrote: On Wed, Aug 28, 2024 at 01:16:57PM +0200, Tycho Kirchner wrote: Hi, Sending rapid SIGINTs from another shell quickly results in a SEGFAULT of the bash instance receiving them. Steps to reproduce: * Open up a shell SHELL_1 and record its pid, e.g. "echo $$" * Launch another shell and send rapid SIGINTs: while true ; do kill -INT OTHER_PID; done SHELL_1 quickly dies with a SEGAULT Tested on GNU bash, version 5.2.32(1)-release (x86_64-pc-linux-gnu), compiled via plain ./configure && make Thanks and Kind Regards Tycho I am able to reproduce this as well, on the latest devel version (2610d40b32301cd7256bf1dfc49c9f8bfe0dcd53). The shell crashes due to what seems runaway self-recursion while handling the interrupt signal in readline: Thanks, this backtrace was extremely helpful. I'll have a fix in the next devel branch push. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/ OpenPGP_signature.asc Description: OpenPGP digital signature
Re: bash - reproducible SEGFAULT on rapid SIGINTs
On 8/28/24 7:16 AM, Tycho Kirchner wrote: Hi, Sending rapid SIGINTs from another shell quickly results in a SEGFAULT of the bash instance receiving them. Steps to reproduce: * Open up a shell SHELL_1 and record its pid, e.g. "echo $$" * Launch another shell and send rapid SIGINTs: while true ; do kill -INT OTHER_PID; done SHELL_1 quickly dies with a SEGAULT Tested on GNU bash, version 5.2.32(1)-release (x86_64-pc-linux-gnu), compiled via plain ./configure && make I can't reproduce this with the current devel branch on RHEL 9. I let it go for a few minutes without any crash. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/ OpenPGP_signature.asc Description: OpenPGP digital signature
Re: bash - reproducible SEGFAULT on rapid SIGINTs
On 8/28/24 7:16 AM, Tycho Kirchner wrote: Hi, Sending rapid SIGINTs from another shell quickly results in a SEGFAULT of the bash instance receiving them. Steps to reproduce: * Open up a shell SHELL_1 and record its pid, e.g. "echo $$" * Launch another shell and send rapid SIGINTs: while true ; do kill -INT OTHER_PID; done SHELL_1 quickly dies with a SEGAULT A stack backtrace would be useful. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/ OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Patch to unify shopt & set-o
On 8/29/24 1:58 AM, Martin D Kealey wrote:
Hi Chet
On Wed, 28 Aug 2024 at 23:58, Chet Ramey <mailto:chet.ra...@case.edu>> wrote:
On 8/24/24 1:46 PM, Martin D Kealey wrote:
> I've been making some tentative patches to the `devel` branch, and
since I
> have a fairly large bashrc, when I compile Bash with maximal debugging
> support, its startup is ... underwhelmingly slothful.
You're seeing the memory tracing and debugging code.
Thanks for that.
The patch I was referring to is at https://github.com/kurahaupo/bash/tree/
patch_options <https://github.com/kurahaupo/bash/tree/patch_options> and
it's almost ready to go; time to let some other eyeballs take a look at it.
Thanks for this. I'll take a look at it at some point; it probably will
not be part of bash-5.3.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
OpenPGP_signature.asc
Description: OpenPGP digital signature
Re: bash passes changed termios to backgrounded process(es) groups?
On 8/29/24 4:59 PM, Martin D Kealey wrote: On Fri, 30 Aug 2024 at 04:17, Robert Elz <mailto:k...@munnari.oz.au>> wrote: SIGTTOU is also sent, unconditionally, by any attempt to change any of the terminal's attributes, and the process (group) (by default) stops. (I don't recall off hand whether simply fetching the attributes is enough to generate SIGTTOU.) Just as there's no stty option to avoid SIGTTIN (reading from the terminal) there's no option to avoid this kind of SIGTTOU - or there shouldn't be. I've encountered something related to this, where the shell takes charge of the terminal, away from another process that is using it. This happens when trying to debug a modified version of Bash, with "gdb ./ bash" then "run". Gdb then stops twice before Bash prints its prompt, even though Bash doesn't (seem to) print or read anything. Most likely, bash can't make itself a process group leader to perform job control. It will try a number of times, then give up and turn job control off. Since gdb catches all signals sent to the target process, it reacts. Look at jobs.c:initialize_job_control(). -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/ OpenPGP_signature.asc Description: OpenPGP digital signature
Re: bash passes changed termios to backgrounded process(es) groups?
On 8/29/24 2:17 PM, Robert Elz wrote: Date:Thu, 29 Aug 2024 10:40:25 -0400 From:Chet Ramey Message-ID: | It's not a big problem. You're in the background if your process group is | not equal to the terminal's process group. That's more or less sufficient to determine if the process is in a background job - but being a background process simply means that the shell is not waiting for it to complete, before doing other things. Sure, but you have to play the percentages. In the non-job-control case, you don't have any way to check and can't do really anything if you manage to find out you're in the background. If that's true then the system's definition of how tostop works is broken. "stty tostop" means "stop the process (group) if an attempt is made to send output to the terminal". The stop is done by sending SIGTTOU. Setting the window size will send SIGTTOU. If you want to stop if you're not in the foreground, that's an easy, transparent way to do it. | Sure. But if you are restarted (and get your SIGCONT) due to the equivalent | of a `bg', you still have to check whether you're in the foreground. Well, kind of, the more common approach, by most applictions, is to not bother to test, never ignore SIGTTIN/SIGTTOU, and simply go ahead and do whatever is needed, if the process stops because of one of those, and then is resumed as a background job, it will simply stop again when whatever made it stop is repeated. When it is resumed in foreground, it can do whatever is needed, and then (perhaps) be moved back to background later. Yeah, but that's the problem here. If you're going to fetch the terminal attributes and restore them later, you want to make sure you're in the foreground when you do it. You don't know what the foreground process has modified -- in this case, readline set up the terminal to do editing input before Mail fetched the attributes. That way, even if you're in the foreground when you finally exit and restore the terminal attributes, they're the right ones. The safest way to do that is to either force the stop at startup, or before you try to fetch the terminal attributes. Don't try to ignore SIGTTIN or SIGTTOU. Or you could fetch the attributes every time you get a SIGCONT and trust that the shell does the right thing. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/ OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Question on $@ vs $@$@
On 8/28/24 11:41 PM, Robert Elz wrote: The reason all this is messy, is that it is (more or less) the way it was implemented in the original Bourne shell. That tells you that the implementation must be simple - the rules might seem complex to explain, but the implementation is sure to be simple, because that shell wasted no code it could avoid. Mostly. The POSIX splitting algorithm is mostly ksh's, so it modifies some of Bourne's more questionable design choices. The significant ones are that we don't split all words, and multiple consecutive non-whitespace IFS characters can delimit empty fields, where the Bourne shell skips all IFS characters when looking for the next field, whitespace or no. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/ OpenPGP_signature.asc Description: OpenPGP digital signature
Re: bash passes changed termios to backgrounded process(es) groups?
On 8/28/24 4:12 PM, Steffen Nurpmeso wrote:
Chet Ramey wrote in
<3ca901aa-5c5e-4be3-9a71-157d7101f...@case.edu>:
|On 8/27/24 7:46 PM, Steffen Nurpmeso wrote:
|> Hello.
|>
|> I got a bug report for my mailer which stated
|>
|> $ ( echo blah | Mail root ) &
|>[1] 2754649
|> $ ^M^M^M^M^C^C
|>
|>[1]+ Stopped ( echo blah | Mail root )
|> $ fg
|>( echo blah | Mail root )
|> $
|>
|> I turns out i answered him now
|>
|>The thing is that if i apply the patch (this to [master])
|>
|> diff --git a/src/mx/termios.c b/src/mx/termios.c
|> index 733974ebce..08dd045226 100644
|> --- a/src/mx/termios.c
|> +++ b/src/mx/termios.c
|> @@ -152,6 +152,8 @@ a_termios_norm_query(void){
|>&a_termios_g.tiosg_normal->tiose_state) == 0);
|> /* XXX always set ECHO and ICANON in our "normal" canonical \
|> state */
|> a_termios_g.tiosg_normal->tiose_state.c_lflag |= ECHO | ICANON;
|> + a_termios_g.tiosg_normal->tiose_state.c_iflag |= ICRNL;
|> +
|> /*NYD2_OU;*/
|> return rv;
|>}
|>
|>then everything is working as should in an otherwise unchanged MUA.
|>It seems readline does this:
|>
|> ./lib/sh/shtty.c: ttp->c_iflag |= ICRNL; /* make sure \
|> we get CR->NL on input */
|> ./lib/readline/rltty.c: tiop->c_iflag &= ~(ICRNL | INLCR);
|>
|> ..and it seems that if bash starts a normal process then ICRNL is
|> set, but if it starts a (process)& or only process&, then not!
|> (I was about to send this to bug-readline first.)
|
|Under no circumstances should a background process attempt to fetch or
|modify terminal attributes. Why isn't your Mail process checking for that?
How could it do so?
(getpid()==tcgetpgrp() or what the function name is is the only
idea i have, but note it is false for (EXE), too. *Big problem*!)
It's not a big problem. You're in the background if your process group is
not equal to the terminal's process group. A simple test suffices:
tty = fileno (stderr); /* pick your file descriptor */
pgrp = getpgid(0);
tpgrp = tcgetpgrp (tty);
running_in_background = (pgrp != tpgrp);
|Chances are excellent that it will fetch the terminal attributes as they've
|been set by readline when it goes to read the next command, then modify (?)
|them out from underneath readline.
Yes, it is not right what readline does there.
No, readline does the right thing. It fetches and sets the terminal
attributes while it has control, and it relies on the caller to make
sure it's in the right process group (that is, it doesn't try to set
the process group itself). It tries to set the window size immediately --
before fetching the terminal attributes -- so it gets a SIGTTOU if it's
in the background, even though that can be defeated by `stty -tostop'.
It restores the terminal attributes before it returns a value to its
caller.
And for me, two things. For one we ensure we give to child
processes, and to restore whenever we go, the original settings as
we inherit them.
If you're in the background, you have no idea what the foreground process
group has done to the terminal settings before you query them. You only
fetch and modify the terminal settings if you're in the foreground.
We requery what means "original" whenever we get
back from a suspension, because user etc may apply changes, and we
should reflect (i have seen that, or even got a bug report).
Sure. But if you are restarted (and get your SIGCONT) due to the equivalent
of a `bg', you still have to check whether you're in the foreground.
And second, if there isatty(3) somewhere, we do termios stuff;
i agree this is bad, especially so since we look STDIN and STDOUT,
not STDIN and STDERR, as POSIX says a shell should do (i think
even dash that was notoriously "wrong" with that will have fixed
this with the next release).
You're not a shell, but looking at stderr is probably the right thing.
"Interactive" we are only if both
are isatty(3), and maybe i will change all that because we are no
shell and never will be, to only be interactive and do termios
stuff if all relevant FDs are terminals.
Also probably the right thing.
(Anyhow, in the example we start a child process, and since STDERR
is passed "as is", we try to restore termions settings (which,
btw, have never been changed in the above snippet, but that
aside), *if* i remember the context correctly. Our termios code
is a stack, and it is terribly complicated.)
Still the wrong thing to do if you're in the background. It's an
inherent race condition.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
OpenPGP_signature.asc
Description: OpenPGP digital signature
Re: Bash History Behavior Suggestion
On 8/20/24 2:20 PM, supp...@eggplantsd.com wrote: The problem with the tagged format is that it's *not* usable by grep Awk would have no problem with it. limited to exactly whatever magic is built into the "history" command That's where the magic should be. If that were the official interface to `.bash_history`, then bash has freedom to innovate on what is stored, and how it is stored. Then we could add even more information. The history file and history list are not bash-specific. The history library is part of readline and shared by many other applications. The history timestamp is managed through a history library interface, not via something bash does on its own. It's possible to extend the history APIs to deal with timestamps that have additional information after the timestamp, but it's not been a priority. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: Bash History Behavior Suggestion
On 8/20/24 1:42 AM, supp...@eggplantsd.com wrote: I know it can. The suggestion is that the default behavior needs some work: The default behavior provides mostly mechanism, not policy. There are ways to do what you want, but those are not suitable for (or desired by) everyone. So you can change your environment to suit your needs using the existing mechanisms. Extending the timestamp field in the history entry struct to contain more data after the timestamp has come up before, but I've never pursued it as a priority. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: Surprising results when profiling Bash
On 8/24/24 1:46 PM, Martin D Kealey wrote: I've been making some tentative patches to the `devel` branch, and since I have a fairly large bashrc, when I compile Bash with maximal debugging support, its startup is ... underwhelmingly slothful. You're seeing the memory tracing and debugging code. So I decided to build it with profiling enabled, and see if I'd done something to ruin its performance. (Short answer: nope.) What stood out immediately is that 50%~90% of the time is spent in mregister_free(). In theory gprof separates the time spent in subordinate function calls, but there's no reporting of find_entry(), perhaps because it's 'static', and therefore in-lined, so perhaps that's the real culprit. What puzzles me is that this is much more than mregister_alloc(), during a phase when *most* of the activity is defining new stuff rather than getting rid of stuff. It's a simple table; alloc only has to find an empty slot, while free has to potentially search for a while to find the associated alloc. I haven't tweaked anything in this area of the code. Is this expected behaviour? Do I need to change my compilation options, or make any other changes? If you don't want it, compile without MALLOC_DEBUG defined. That's what release versions do. I haven't delved very deeply into this code, but it does seem to be preoccupied with managing signals, presumably because the code isn't re-entrant; so I'm wondering if it would be worthwhile to investigate different kinds of allocators, or perhaps a different approach to handling signals? It only blocks signals if it's running from a trap handler or SIGINT or SIGCHLD are trapped. Mostly legacy stuff from when SIGINT traps were handled immediately. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: Out of bounds read in parse.y.
On 8/27/24 3:58 PM, Collin Funk wrote:
I suspect there is a decrement that isn't matched by a call to
set_word_top(). But a reproducer would help, otherwise we're all just
guessing.
Sure, the bad read was happening while reading my .profile and .bashrc
file. I've narrowed it down to a bash completion file installed by my
system packages. I've attached it to this message.
Thanks. Here's the simple reproducer:
x()
{
case y in
z)
if (! false); then
foo=bar
fi
;;
esac
}
It was what I suspected.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
OpenPGP_signature.asc
Description: OpenPGP digital signature
Re: bash passes changed termios to backgrounded process(es) groups?
On 8/27/24 7:46 PM, Steffen Nurpmeso wrote:
Hello.
I got a bug report for my mailer which stated
$ ( echo blah | Mail root ) &
[1] 2754649
$ ^M^M^M^M^C^C
[1]+ Stopped ( echo blah | Mail root )
$ fg
( echo blah | Mail root )
$
I turns out i answered him now
The thing is that if i apply the patch (this to [master])
diff --git a/src/mx/termios.c b/src/mx/termios.c
index 733974ebce..08dd045226 100644
--- a/src/mx/termios.c
+++ b/src/mx/termios.c
@@ -152,6 +152,8 @@ a_termios_norm_query(void){
&a_termios_g.tiosg_normal->tiose_state) == 0);
/* XXX always set ECHO and ICANON in our "normal" canonical state */
a_termios_g.tiosg_normal->tiose_state.c_lflag |= ECHO | ICANON;
+ a_termios_g.tiosg_normal->tiose_state.c_iflag |= ICRNL;
+
/*NYD2_OU;*/
return rv;
}
then everything is working as should in an otherwise unchanged MUA.
It seems readline does this:
./lib/sh/shtty.c: ttp->c_iflag |= ICRNL; /* make sure we get CR->NL
on input */
./lib/readline/rltty.c: tiop->c_iflag &= ~(ICRNL | INLCR);
..and it seems that if bash starts a normal process then ICRNL is
set, but if it starts a (process)& or only process&, then not!
(I was about to send this to bug-readline first.)
Under no circumstances should a background process attempt to fetch or
modify terminal attributes. Why isn't your Mail process checking for that?
Chances are excellent that it will fetch the terminal attributes as they've
been set by readline when it goes to read the next command, then modify (?)
them out from underneath readline.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: eval '<$(;)' causes Segmentation Fault
On 8/26/24 10:57 PM, Zachary Santer wrote: Bash Version: 5.3 Patch Level: 0 Release Status: alpha This is devel, commit 2e01122fe7. Really don't get what's going on here: You have two instances of the shell fighting over terminal input. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: Out of bounds read in parse.y.
On 8/27/24 12:41 AM, Collin Funk wrote:
Hi,
When compiling with undefined behavior sanitizer and then running:
Which version?
$ ./bash
parse.y:1000:93: runtime error: index -1 out of bounds for type 'int [257]'
Please send a reproducer.
The offending section of code:
case_command: CASE WORD newline_list IN newline_list ESAC
{
$$ = make_case_command ($2, (PATTERN_LIST *)NULL,
word_lineno[word_top]);
if (word_top >= 0) word_top--;
}
| CASE WORD newline_list IN case_clause_sequence newline_list ESAC
{
/* Access of word_lineno[word_top] causes bad read.
*/
$$ = make_case_command ($2, $5,
word_lineno[word_top]);
if (word_top >= 0) word_top--;
}
And the definition of word top and word_lineno:
#define MAX_COMPOUND_NEST 256
static int word_lineno[MAX_COMPOUND_NEST+1];
static int word_top = -1;
The value of word_top appears to only be set in 'set_word_top':
static inline int
set_word_top (int t)
{
switch (t)
{
case CASE:
case SELECT:
case FOR:
case IF:
case WHILE:
case UNTIL:
if (word_top < MAX_COMPOUND_NEST)
word_top++;
word_lineno[word_top] = line_number;
break;
default:
break;
}
return word_top;
}
Shouldn't all the decrements of word_top be protected by:
if (word_top > 0) word_top--;
instead of:
if (word_top >= 0) word_top--;
Why? 0 is a valid index. set_word_top increments word_top before assigning
to word_lineno[word_top].
Or is there something more complicated that I am missing here?
I suspect there is a decrement that isn't matched by a call to
set_word_top(). But a reproducer would help, otherwise we're all just
guessing.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: eval '<$(;)' causes Segmentation Fault
On 8/26/24 6:44 PM, youheng@gmail.com wrote:
Bash Version: 5.3
Patch Level: 0
Release Status: alpha
POC:
$ cat poc.sh
eval '<${;}'
The specific case is an empty command containing only a redirection that
results in an expansion error read from a script or string.
I can confirm that the error is triggerted in the "execute_null_command"
function and later containing a redirection.
Specifically the variable `INPUT_STREAM bashinput.location` is both a char
pointer and an int.
Thanks for the analysis.
At first it is used as a char pointer in the function "parse_and_execute"
BEFORE
```
gdb> p bash_input.location.string
$3 = 0x7fb3dc0db3b0 "<${;}"
```
However at shell.c:1758 in the fuction unset_bash_input it gets overwritten to
a fd:
```
bash_input.location.buffered_fd = -1;
This is an effect of the problem, not the problem itself. The subshell
forked to execute the empty command should not go back and try to read
from the script again after it encounters an expansion error. The fix is
to provide a target for longjmp in the forked subshell.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: eval '<$(;)' causes Segmentation Fault
On 8/26/24 9:52 PM, Dale R. Worley wrote: writes: Repeat-By: 1. Create a script, i.e. `poc.sh` with the problematic string 2. Execute `bash poc.sh` Interestingly, when I run it (bash 5.1.0(1), which is pretty old), I don't get the seg fault when I enter that string from the keyboard, only when it's read from a script file. https://lists.gnu.org/archive/html/bug-bash/2024-08/msg00205.html -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: Question on $@ vs $@$@
On 8/26/24 8:21 PM, Steffen Nurpmeso wrote:
Chet Ramey wrote in
:
|On 8/23/24 5:47 PM, Steffen Nurpmeso wrote:
|> If IFS has a value other than the default, then sequences of the
|> whitespace characters space, tab, and newline are ignored at the
|> beginning and end of the word, as long as the whitespace
|> character is in the value of IFS (an IFS whitespace charac‐
|> ter).
So an IFS whitespace character is one that is in the value of IFS.
|>
|> So IFS whitespace only if part of $IFS.
|>
|> Any character in IFS that is not IFS whitespace, along
|> with any adjacent IFS whitespace characters, delimits a field.
|>
|> So this "adjacent" even if *not* part of $IFS.
|
|I am genuinely curious how you concluded this, given the definition you
|previously quoted.
It is only skipping ("trimming away") further data without further
delimiting if only IFS whitespace is seen.
The definition of IFS whitespace requires that the characters be part of
the value of IFS, so I'm wondering how you arrived at the "not part of
$IFS" above. Do you mean that IFS whitespace characters are the only ones
where multiple instances of those characters can delimit a single field?
If I can increase that section's clarity, I'm all for it. It's a confusing
topic.
|> A sequence of IFS whitespace characters is also treated as
|> a delimiter.
|>
|> So this means that *regardless* of whatever $IFS is, the three IFS
|> whitespace characters are $IFS anyway *if* that is set to
|> a nin-empty non-default value.
|
|Nonsense.
How you interpret this "also" if not so, that is the question.
My impression was that you had an eye on the standard text and
tried to vaporise it down to the core. Very well.
You have to look at the definition of IFS whitespace.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: bash-5.2.32 fails "make install" on RHEL 9
On 8/24/24 11:53 PM, Dennis Clarke via Bug reports for the GNU Bourne Again SHell wrote: This seemed to happen over and over and only during "make install". There are a number of loadable builtins that require arrays and don't build without them. It's annoying, but everything else is already installed before the process gets to this point, so you're not really missing anything except the example loadables. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/ OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Question on $@ vs $@$@
On 8/24/24 11:49 PM, Lawrence Velázquez wrote: The bash manual says [1]: * ($*) Expands to the positional parameters, starting from one. When the expansion is not within double quotes, each positional parameter expands to a separate word. In contexts where it is performed, those words are subject to further word splitting and filename expansion. I think "it is" here is ambiguous. It would be better to use "these expansions are." -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/ OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Question on $@ vs $@$@
On 8/23/24 5:47 PM, Steffen Nurpmeso wrote: If IFS has a value other than the default, then sequences of the whitespace characters space, tab, and newline are ignored at the beginning and end of the word, as long as the whitespace character is in the value of IFS (an IFS whitespace charac‐ ter). So IFS whitespace only if part of $IFS. Any character in IFS that is not IFS whitespace, along with any adjacent IFS whitespace characters, delimits a field. So this "adjacent" even if *not* part of $IFS. I am genuinely curious how you concluded this, given the definition you previously quoted. A sequence of IFS whitespace characters is also treated as a delimiter. So this means that *regardless* of whatever $IFS is, the three IFS whitespace characters are $IFS anyway *if* that is set to a nin-empty non-default value. Nonsense. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/ OpenPGP_signature.asc Description: OpenPGP digital signature
Re: eval '<$(;)' causes Segmentation Fault
On 8/25/24 10:54 PM, Lawrence Velázquez wrote:
On Sun, Aug 25, 2024, at 6:24 PM, youheng@gmail.com wrote:
Bash Version: 5.1
Patch Level: 16
Note that this version of bash is outdated and will not receive
further updates. The current release is 5.2.
All the following scripts can create a Segmentation Fault
eval '<$[;]'
eval '<${;}'
eval '<$[|]'
These still cause the current devel branch to segfault, but (at
least for me, on macOS) only when invoked via argument, as OP
directed. For example, reading the scripts via stdin avoids the
segfault.
The specific case is an empty command containing only a redirection that
results in an expansion error read from a script or string.
% cat /tmp/poc.bash
eval '<$[;]'
% ./bash /tmp/poc.bash
/tmp/poc.bash: line 1: ;: arithmetic syntax error: operand expected (error token
is ";")
/tmp/poc.bash: line 1: 55480 Segmentation fault: 11
% ./bash
eval '<$(;)'
eval '<$(|)'
Current devel doesn't segfault with these. Maybe because of the
comsub parser rewrite?
Indirectly. The syntax error gets caught early.
eval '<${|}'
Current devel doesn't segfault with this, either.
This is a varsub that doesn't expand to anything, so it's a redirection
error.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
OpenPGP_signature.asc
Description: OpenPGP digital signature
Re: Why does case-pattern undergo "process substitution"?
On 8/23/24 3:41 PM, shynur . wrote: Hi, friends~ I'm reading the Bash Reference Manual, section 3.2.5.2. Here: <https://gnu.org/s/bash/manual/html_node/Conditional-Constructs.html>. case _word_ in [ [(] _pattern_ [| _pattern_]…) _command-list_ ;;]… esac Each _pattern_ undergoes tilde expansion, parameter expansion, command substitution, arithmetic expansion, process substitution, and quote removal. I'm confused. Why is "process substitution" being performed here? It's performed because it's one of the standard shell word expansions. POSIX specifies that the word and pattern undergo all the word expansions except word splitting, filename generation, and quote removal (for the pattern, not the word, and that has sparked some discussion), so bash does the same -- it happens to have more expansions than POSIX. The result is often unforeseen, e.g., '/dev/fd/13', '/dev/fd/42'... Can anyone give me a practical example? Thanks in advance! Expanding the word part is easy: since process substitution expands to a filename, one can infer the underlying implementation from the particular filename: case <(:) in /dev/fd*) echo process substitution uses anonymous pipes;; *sh-np*)echo process substitution uses named pipes;; esac Some scripts make use of this information. The pattern should undergo the same expansions as the word. If you don't want process substitution to occur, you can always quote it. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/ OpenPGP_signature.asc Description: OpenPGP digital signature
Re: 'wait -n' with and without id arguments
On 8/16/24 8:21 AM, Zachary Santer wrote: On Wed, Aug 14, 2024 at 11:22 PM Zachary Santer wrote: The implicit 'jobs' isn't happening before each PS1, but after each command completes. Thus, all the [1] Donerandom_sleep notifications when sourcing wait-n-failure, before it prints 3 processes waited / 8 processes forked 1 seconds and exits. So, actually only doing the implicit 'jobs' work and moving things from the jobs table to the list of saved pids and statuses before each PS1 *would* be a solution here. When sourcing wait-n-failure, it's going to do all its work before any PS1 prompt. Same deal if a user wants to call a function with 'wait -n' in it from the command line, invoke the edit-and-execute-command readline command, or just type a bunch of different commands separated by semicolons into a single command line. This breaks down with 'set -b'/'set -o notify'. Short of 'wait -n' printing a warning message or erroring out when it is invoked while 'set -b' is active, this isn't a complete solution. If you enable the notify option, which is not the default, you should be responsible for managing the consequences. notify is always going to result in different behavior; see https://pubs.opengroup.org/onlinepubs/9799919799/utilities/V3_chap02.html#tag_19_11 I really think the solution here is for 'wait -n' to return the termination status of a child process that has already terminated and that the user has already been informed of. Ultimately, whatever set of commands is being invoked together and the user who is being informed of terminated child processes are two different things. Informing the user does nothing for the set of commands. No, that counts as notification. After the user is notified, the shell is free to remove the job from the list. Bash happens to keep the status around for a while; kre, for instance, advocates removing it entirely. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/ OpenPGP_signature.asc Description: OpenPGP digital signature
Re: 'wait -n' with and without id arguments
On 8/14/24 11:22 PM, Zachary Santer wrote: On Wed, Aug 14, 2024 at 3:22 PM Chet Ramey wrote: On 8/7/24 2:47 PM, Zachary Santer wrote: Now I understand that this is because the list of terminated child processes that 'wait -n' currently ignores is only used in the interactive shell. It's not, but there might be some value here. I put a call to 'jobs' in the middle of the while loop in wait-n-failure, and I see I can break 'wait -n' in a script called normally by doing so. I've never called 'jobs' or used a jobspec in a script, and I don't know why one would. Presumably because you want to clear the jobs list of terminated jobs. If you want the behavior of 'wait -n' to be consistent between scripts and the interactive shell, then it should choose one terminated child process from the list of those that is maintained in the interactive shell, if it's nonempty, to report to the user and to clear from that list, any time it is called. I'm not sure returning the status of some random process from some arbitrary point in the past is going to be valuable. I think the value is in the consistent behavior of 'wait -n', which this would provide. If the user is intent on running 'wait -n' without id arguments in the interactive shell, they can ensure that child processes forked long ago are ignored by simply calling 'wait' without -n before moving on to what they're trying to do. Sure, they can do that. That's a new requirement, though. On Wed, Aug 14, 2024 at 4:44 PM Robert Elz wrote: | Maybe the thing to do is to retain jobs in the job list, even after | they're marked as notified, I'd do the opposite, once they're notified, they should be deleted from the jobs table, and everywhere else. But "notified" only happens when the script explicitly asks (in a non-interactive shell, never because of any other event than an appropriate command issued by the script, and in an interactive shell, the same, or the implicit "jobs" before each PS1). The implicit 'jobs' isn't happening before each PS1, This isn't what POSIX says to do, anyway. but after each command completes. Thus, all the [1] Donerandom_sleep notifications when sourcing wait-n-failure, before it prints 3 processes waited / 8 processes forked 1 seconds and exits. Kind of. The `interactive shell' isn't interactive while it's not reading input from the terminal, so the shell prints notifications when a job terminates. This is what happens when you source a file. So, actually only doing the implicit 'jobs' work and moving things from the jobs table to the list of saved pids and statuses before each PS1 *would* be a solution here. Before the next prompt, you probably mean. When sourcing wait-n-failure, it's going to do all its work before any PS1 prompt. The behavior of performing notifications and removing jobs from the table is long-standing: it's been this way since 1999, and is a mechanism to prevent long-running sourced scripts from filling up the jobs list (which was a lot smaller in '99). So you need to accommodate those backwards compatibility issues somehow. I'm less concerned about what happens when a user types 'wait -n' independently on the command line. The human is in the loop at that point. The shell is interactive at that point; different rules apply. So basically, 'wait -n' should be implemented such that sourcing the script with a false argument gives the same behavior as you've seen when sourcing it with a true argument: the infinite loop. How long should notification be deferred? Until the script completes? That's more or less the solution I presented above. 'wait -n' without id arguments returning the termination status of a child process that the user has already been informed of through the implicit 'jobs' output would also work, and might be less of a weird behavior change for users to get over. OK. How would you reconcile the backwards compatibility issue? There are only three approaches. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/ OpenPGP_signature.asc Description: OpenPGP digital signature
Re: [PATCH] Correct error message when using -n and -o ignoreeof in interactive mode
On 8/21/24 12:09 PM, Grisha Levit wrote: On Wed, Aug 21, 2024, 11:27 Chet Ramey <mailto:chet.ra...@case.edu>> wrote: On 8/19/24 9:52 AM, Ángel wrote: > On 2024-08-18 at 11:21 +0700, Robert Elz wrote: >> Interactive shells with -n (noexec) set are pointless > > The man page states: >> -n Read commands but do not execute them. This may be used >> to check a shell script for syntax errors. This is ig‐ >> nored by interactive shells. > > And indeed, doing a set -n on an interactive shell is ignored. > It is however possible to run an interactive noexec bash if it is set > on launch. It's not unreasonable to turn off that flag as part of interactive shell initialization. I've found using bash --norc -in <<< INPUT invaluable for testing input handling so I hope that remains an option. Good point. I think I can make that work; maybe turn off noexec only if stdin is a terminal or similar. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: please make the commit log clean
On 8/18/24 4:45 PM, shynur . wrote:
Hi, Chet.
I'm a beginner with Bash and recently stumbled upon the
Bash code repository (specifically the 'devel' branch).
I noticed that almost every commit includes thousands of
lines of changes.
Not really.
Out of curiosity, I randomly clicked on one of the commits
(e.g.,
<https://git.savannah.gnu.org/cgit/bash.git/commit/?h=devel&id=772e7e760e8a098e4d8dee21cf11090be4757918>).
I found that the majority of the changes were to documentation,
such as the `doc/bash.0` file, which had 4999 lines modified.
I periodically refresh the formatted documentation, since it's part of the
distribution, and try to do it at least every time I make a substantive
change to the man page or info manual.
The same thing happens when I update the translations.
While I'm not very familiar with the process of automatically
generating documentation, I can still infer that the `doc/bash.0`
file is an output produced by processing `doc/bash.info` with
some program.
It's not, but as you say, it's not familiar to you. Look at doc/Makefile
in the build directory for how make generates the formatted documentation.
I believe these output files should be added to `.gitignore`
and generated during the `make` process. Otherwise, they will
severely pollute the commit history, making it much harder for
future maintainers to understand and manage the repository.
There are ways you can ignore these files on your side.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: [PATCH] Correct error message when using -n and -o ignoreeof in interactive mode
On 8/19/24 9:52 AM, Ángel wrote: On 2024-08-18 at 11:21 +0700, Robert Elz wrote: Interactive shells with -n (noexec) set are pointless The man page states: -n Read commands but do not execute them. This may be used to check a shell script for syntax errors. This is ig‐ nored by interactive shells. And indeed, doing a set -n on an interactive shell is ignored. It is however possible to run an interactive noexec bash if it is set on launch. It's not unreasonable to turn off that flag as part of interactive shell initialization. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: 'wait -n' with and without id arguments
On 8/21/24 9:25 AM, Chet Ramey wrote: On 8/14/24 4:42 PM, Robert Elz wrote: the implicit "jobs" before each PS1). POSIX doesn't actually say that. It says, in a couple of different places, "the message shall be written immediately prior to writing the next prompt for input," which implies that you should write messages before $PS2 also. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: 'wait -n' with and without id arguments
On 8/21/24 9:27 AM, Chet Ramey wrote: On 8/15/24 2:39 AM, Zachary Santer wrote: I figured it out. I had to futz with Windows, MSYS, and then git to have the symlinks in the repo actually be real-deal symlinks. What are `real-deal' symlinks on Windows? The symlinks in the devel repo work fine on Unix machines. Ah, I found it. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: 'wait -n' with and without id arguments
On 8/15/24 2:39 AM, Zachary Santer wrote: I figured it out. I had to futz with Windows, MSYS, and then git to have the symlinks in the repo actually be real-deal symlinks. What are `real-deal' symlinks on Windows? The symlinks in the devel repo work fine on Unix machines. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/ OpenPGP_signature.asc Description: OpenPGP digital signature
Re: 'wait -n' with and without id arguments
On 8/14/24 4:42 PM, Robert Elz wrote: Date:Wed, 14 Aug 2024 15:21:44 -0400 From:Chet Ramey Message-ID: <1413a9a0-cbef-44c5-8072-a3be7294e...@case.edu> | I'm not sure returning the status of some random process from some | arbitrary point in the past is going to be valuable. Not "some random process" but a process that has terminated, and hasn't been waited upon before (and which hasn't been notified as complete via an explicit user execution of the "jobs" command or the implicit "jobs" which runs just before each PS1 output in an interactive shell). I suppose we could do this for `wait -n', but removing processes from the saved statuses list after `wait pid' only happens in posix mode. In default mode, bash allows you to wait for a process more than once. We've covered this before; it comes up every time. | Maybe the thing to do is to retain jobs in the job list, even after | they're marked as notified, I'd do the opposite, once they're notified, they should be deleted from the jobs table, and everywhere else. But "notified" only happens when the script explicitly asks (in a non-interactive shell, never because of any other event than an appropriate command issued by the script, and in an interactive shell, the same, or the implicit "jobs" before each PS1). We're only talking about interactive shells here. Once deleted, they're gone, and there's no way to get data from them, ever again. This should not require any magic options. It works this way in posix mode. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/ OpenPGP_signature.asc Description: OpenPGP digital signature
Re: [PATCH] bash_source_fullpath: add to reset_shopt_options
On 8/19/24 1:39 PM, Grisha Levit wrote: This was actually caught by the test suite Yes, thanks for the report. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: 'wait -n' with and without id arguments
On 8/12/24 11:57 AM, Zachary Santer wrote: On Mon, Aug 12, 2024 at 11:12 AM Chet Ramey wrote: That stuff changed last month, after bash-5.3-alpha was released. Before that change, neither interactive nor non-interactive shells checked the list of saved statuses. The difference was when the user was notified of a process's exit status and when a job was removed from the jobs list. Not sure I want to commit myself to spinning up a RHEL 9 VM just to keep this conversation moving, Nobody had any answers in my help-bash thread on this topic, but does the devel branch have any build dependency that differs from those of the master and pre-release branches? I don't include pre-built y.tab.[ch], so you need a modern version of bison. I also removed the pre-computed config.cache file support, since I have no way to keep that updated. What's the error you get? Note that if you're running on cygwin or mingw, I don't have any way to test those. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/ OpenPGP_signature.asc Description: OpenPGP digital signature
Re: 'wait -n' with and without id arguments
On 8/9/24 9:29 PM, Zachary Santer wrote: On Fri, Aug 9, 2024 at 10:38 AM Chet Ramey wrote: When I source your script on macOS with the current devel build, I get the set of notification messages and termination with a false argument, and an infinite loop with a true argument. So basically, 'wait -n' should be implemented such that sourcing the script with a false argument gives the same behavior as you've seen when sourcing it with a true argument: the infinite loop. How long should notification be deferred? Until the script completes? Because notification in an interactive shell is the core of what we're talking about here. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/ OpenPGP_signature.asc Description: OpenPGP digital signature
Re: 'wait -n' with and without id arguments
On 8/7/24 2:47 PM, Zachary Santer wrote:
Now I understand that this is because the list of terminated child
processes that 'wait -n' currently ignores is only used in the
interactive shell.
It's not, but there might be some value here.
If you want the behavior of 'wait -n' to be
consistent between scripts and the interactive shell, then it should
choose one terminated child process from the list of those that is
maintained in the interactive shell, if it's nonempty, to report to
the user and to clear from that list, any time it is called.
I'm not sure returning the status of some random process from some
arbitrary point in the past is going to be valuable.
Maybe the thing to do is to retain jobs in the job list, even after
they're marked as notified, until the user runs `jobs' or does a `wait',
as POSIX (more or less) wants. Since people aren't used to doing that,
and it would potentially explode the size of the jobs list, it would have
to be an opt-in thing based on a new shell option.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
OpenPGP_signature.asc
Description: OpenPGP digital signature
Re: Question on $@ vs $@$@
On 8/13/24 8:45 PM, Steffen Nurpmeso wrote:
Hello.
I include bug-bash even though i think bash is correct, but there
lots of people of expertise are listening, so, thus.
Sorry for cross-posting, nonetheless.
Given this snippet (twox() without argument it is)
one() { echo "$# 1<$1>"; }
two() { one "$@"; }
twox() { one "$@$@"; }
two
two x
twox
twox x
i get
$ dash shbug.sh
0 1<>
1 1
1 1<>
1 1
#?0|kent:tmp$ busybox.static sh shbug.sh
0 1<>
1 1
1 1<>
1 1
#?0|kent:tmp$ bash shbug.sh
0 1<>
1 1
0 1<>
1 1
When, as in this case, the result would be split if the double quotes
weren't there, $@ within double quotes expands to nothing if there are
no positional parameters, no matter how many times it appears.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
OpenPGP_signature.asc
Description: OpenPGP digital signature
Re: [PATCH] read: unsigned char delim issues
On 8/13/24 3:00 PM, Grisha Levit wrote:
The new read_mbchar code is missing an (unsigned char) cast, causing an
invalid continuation byte >0x7F to fail to be recognized as a delimiter
on platforms where char is signed.
$ printf '\317_' | { read -d _; echo "${REPLY@Q}"; }
$'\317'
$ printf '\317\360_' | { read -d $'\360'; echo "${REPLY@Q}"; }
$'\317\360_'
Also, the function cannot distinguish between an ignored delimiter and
a delimiter of 0xFF, since the value is stored as an unsigned char and
the separate ignore_delim flag is not passed along.
Thanks for the report. I agree that changing the delim to an int and
adding casts where necessary is the right fix for this.
This ambiguity affects edit_line as well. Eg. due to a separate issue
(rl_num_chars_to_read treated as a byte, not character count),
Thanks, I fixed this, too.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
OpenPGP_signature.asc
Description: OpenPGP digital signature
Re: shopt compat
On 8/14/24 2:25 AM, Martin Kealey wrote: Hi Chet I have worked up a patch that considerably simplifies the logic for setting and displaying the shopt compatXX settings, by getting rid of the numberous boolean variables and simply computing the setting level directly. Thanks. The boolean variables and corresponding shopt options are frozen and only remain for backwards compatibility; there are no compatXX shopt options beyond compat44; the BASH_COMPAT variable is the current way to set the compatibility level. However before I submit my compatXX patch, I would like to ensure I've correctly accounted for the intention of the commit below, which I assume is fairly described by this comment: If we're unsetting one of the compatibility options, make sure the current value is in the range of the compatNN space. In partiular, I'm puzzled by the introduction of this boolean expression (oldval > 44 && shell_compatibility_level < DEFAULT_COMPAT_LEVEL) There are no compat options beyond compat44, so any value greater than that must have been set via BASH_COMPAT. For example, once it's possible to use 'shopt -s compat52', we would then find that 'shopt -u compat52' would have no effect, unless the number "44" is updated to match any new available levels. We're not going to do that. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/ OpenPGP_signature.asc Description: OpenPGP digital signature
Re: printf inconsistent results for %.0f
On 8/13/24 7:05 PM, Grisha Levit wrote: On Mon, Aug 12, 2024, 11:04 Chet Ramey <mailto:chet.ra...@case.edu>> wrote: My question is why the (admittedly old) gnulib replacement strtod/strtold is messing things up. Looks like printf(3) gets called with a `Lf' conversation specifier and a double argument. Yes, I came to the same conclusion with an essentially identical fix. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/ OpenPGP_signature.asc Description: OpenPGP digital signature
Re: word selection in history expansion - !?word?%
On 8/12/24 5:15 PM, Jess M wrote:
Given the age of the behaviour, I would agree on not making it the default
behaviour.
To update the documentation to reflect that, how about something like this:
--- current --- lib/readline/doc/hsuser.texi
@item %
The first word matched by the most recent @samp{?@var{string}?} search,
if the search string begins with a character that is part of a word.
--- proposed ---
@item %
The first word matched by the most recent @samp{?@var{string}?} search,
if the search string begins with a character that is part of a word. The
search happens in reverse, so if multiple words on a line match, the word
nearer the end of the line is returned.
Thanks. I will add something similar.
Consider updating the word designator to accept a count. In this mode, `!?
word?:%3` would provide the third found item found in a reverse search.
I'd be wary of extending the history expansion syntax, even to the extent
of adding a new modifier. It's been basically identical for what, 46 years?
It's an interesting idea, though.
Implementing the search across lines might prove tricky. The current code
splits line match and word match; we don't even count words until after
we've identified the matched line.
History expansion is aggressively line-oriented.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: termios.h not included if sys/ioctl.h provides struct winsize
On 8/12/24 10:18 PM, Grisha Levit wrote:
On e.g. Alpine Linux, the following are set by configure:
bash_cv_struct_winsize_ioctl='yes'
bash_cv_struct_winsize_termios='yes'
bash_cv_struct_winsize_header='ioctl_h'
ac_cv_func_tcgetwinsize='yes'
and so config.h ends up with:
#define STRUCT_WINSIZE_IN_SYS_IOCTL 1
/* #undef STRUCT_WINSIZE_IN_TERMIOS */
#define HAVE_TCGETWINSIZE 1
This causes termios.h to not get included by lib/sh/winsize.c:
#if defined (STRUCT_WINSIZE_IN_TERMIOS) && !defined
(STRUCT_WINSIZE_IN_SYS_IOCTL)
# include
#endif
and a build failure:
Thanks for the report. The fix is to include if HAVE_TCGETWINSIZE
is defined.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: Incorrect positioning when long prompt contains ANSI escape sequences + UTF-8 LANG
On 8/8/24 3:40 PM, Gioele Barabucci wrote: Hi, bash 5.2.21 produces severely wrong artifacts under the following conditions: * the length of the prompt matches $COLUMN*2 + 1; * the prompt contains ANSI escape sequences; * the LANG variable is set to an installed UTF-8 locale. When all these conditions are met, pressing the up arrow/down arrow will place the cursor in the wrong spot. After that, all typed character will be shown in the same place, overwriting each other. This was fixed back in November, 2022, based on the original Debian bug report. Search for the bug number in the change log to find the fix description. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: word selection in history expansion - !?word?%
On 8/9/24 2:15 AM, Jess M wrote: Observed behaviour: ``` $ echo word01 word02 word03 floogle word01 word02 word03 floogle $ echo !?word?% echo word03 word03 $ # I expected to get word01 $ echo $BASH_VERSION 5.2.26(1)-release ``` The bash manual for word designators sounds to me as if word01 should be selected. That's certainly the csh behavior. Bash has done it this way for as long as its history expansion has been implemented. It dates back to at least 1988-89. I think the idea (that was a long time ago) was that it started as a way to perform searching for readline, and in that case you want the history to basically be treated as a single long string, in which you search backwards or forwards from the current location. The csh-style history expansion code inherited that behavior. It should not be difficult to provide an option to do it the csh way, but there's a lot of existing behavior there, so I don't know about making it the default. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/ OpenPGP_signature.asc Description: OpenPGP digital signature
Re: 'wait -n' with and without id arguments
On 8/7/24 2:47 PM, Zachary Santer wrote: Now I understand that this is because the list of terminated child processes that 'wait -n' currently ignores is only used in the interactive shell. Do you mean when no arguments are supplied? It's not. The difference is when a job is marked as notified and eligible to be removed from the jobs list. If you want the behavior of 'wait -n' to be consistent between scripts and the interactive shell, then it should choose one terminated child process from the list of those that is maintained in the interactive shell, if it's nonempty, to report to the user and to clear from that list, any time it is called. That would make it different from wait without -n. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/ OpenPGP_signature.asc Description: OpenPGP digital signature
Re: 'wait -n' with and without id arguments
On 8/7/24 2:47 PM, Zachary Santer wrote: On Wed, Aug 7, 2024 at 11:06 AM Chet Ramey wrote: On 7/31/24 11:40 AM, Zachary Santer wrote: I think I was missing more than that. Was the original 'wait -n' discussion from January specific to its use within the interactive shell? No, it was due to processes exiting due to signals. But you could have looked that up yourself. That was a big discussion, and I wasn't a part of it. Let's not miss my point, though. The "next" in the description of 'wait -n' in the manual currently means different things depending on if you're in a script or in the interactive shell, at least given the testing of bash-5.3-alpha that I performed. In a script, 'wait -n' without id arguments doesn't appear to skip child processes that have already terminated. This is good. In the interactive shell, it does. That stuff changed last month, after bash-5.3-alpha was released. Before that change, neither interactive nor non-interactive shells checked the list of saved statuses. The difference was when the user was notified of a process's exit status and when a job was removed from the jobs list. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/ OpenPGP_signature.asc Description: OpenPGP digital signature
Re: printf inconsistent results for %.0f
On 8/12/24 10:30 AM, Laur Aliste wrote:
Bash Version: 5.2
Patch Level: 21
Release Status: release
Description:
One of my old script that's been in use for 10+ years is using
built-in bash printf
for rounding float value to int via `printf`; as of today (Aug 12)
it started
returning erroneous and inconsistent results.
Note it doesn't require float input value - trying to format full integers
reproduces the problem the same.
It's probably a bug with configure, which a gcc update has triggered.
I've attached a patch.
Bash version hasn't been updated for ages so assuming it has to be
a dependency issue.
My question is why the (admittedly old) gnulib replacement strtod/strtold
is messing things up.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/*** ../bash-20231106/configure.ac Fri Aug 11 14:52:31 2023
--- configure.acTue Nov 21 12:00:25 2023
***
*** 899,903
[AC_LANG_PROGRAM(
[[#include ]],
! [[long double r; char *foo, bar; r = strtold(foo, &bar);]]
)],
[bash_cv_strtold_broken=no],[bash_cv_strtold_broken=yes])
--- 900,904
[AC_LANG_PROGRAM(
[[#include ]],
! [[long double r; char *foo, *bar; r = strtold(foo, &bar);]]
)],
[bash_cv_strtold_broken=no],[bash_cv_strtold_broken=yes])
*** ../bash-20231106/configure Fri Aug 18 16:27:53 2023
--- configure Tue Nov 21 12:00:30 2023
***
*** 15923,15927
main (void)
{
! long double r; char *foo, bar; r = strtold(foo, &bar);
;
--- 15932,15936
main (void)
{
! long double r; char *foo, *bar; r = strtold(foo, &bar);
;
OpenPGP_signature.asc
Description: OpenPGP digital signature
Re: whats wrong , exit code 11 on android termux
On 8/9/24 11:02 PM, Oğuz wrote: On Saturday, August 10, 2024, Martin D Kealey wrote: Sorry, that was supposed to be a personal reply off-list. Do you always harass foreigners like that or was it an exception? "Foreigner" is indeed tricky in this context. I'd guess that the four principals in this little sub-discussion (including Alex) are from four different countries, if not four different continents. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/ OpenPGP_signature.asc Description: OpenPGP digital signature
Re: whats wrong , exit code 11 on android termux
On 8/9/24 10:01 PM, Martin D Kealey wrote: On Thu, 8 Aug 2024 at 03:14, alex xmb sw ratchev wrote: mr chet I REALLY get annoyed when strangers call me "Mister Martin" or write "Mr Martin". I am NOT a child, so how DARE they mock me like that. The short version: Some folk don't care, others don't know any better, but if you suspect the person you're talking to is over 40, I would strongly recommend you avoid this style of address - unless of course you WANT to mock them. I'm always amazed at the human capacity to take offense. Of course, I'm on social media, so it shouldn't surprise me. Anyway, take a breath, maybe go out and touch grass. It was me he was addressing, and I don't feel mocked. And I'm well over 40. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/ OpenPGP_signature.asc Description: OpenPGP digital signature
Re: return from trap while reading with readline breaks completion
On 8/6/24 4:19 AM, Oğuz wrote: See: $ ls foo s $ cat s trap return INT read -e $ source s I press Ctrl-C here and bash prompts me for the next command. Then I press F and Tab; instead of producing the bell sound bash completes f to foo. If I press Ctrl-C again it prints "bash: return: can only `return' from a function or sourced script" and completion returns to normal. Thanks for the report. The unwind-protect to restore the completion function wasn't being installed in the right place. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/ OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Prompt color reset after using arrow keys
On 8/7/24 5:05 PM, Gioele Barabucci wrote:
Hi,
in bash 5.2.21 the following PS1 assignment
PS1=$'\[\e[0;34;42m\]'$(printf x%.0s {1..111})$'\[\e[0m\]\$ '
should make the prompt a long list of "x", displayed in blue on a red
background. This is in fact the case.
However, if the terminal window is smaller than 111 characters and, thus,
the prompt is split onto two lines, the following bug will appear:
Pressing the up arrow and then the down arrow, will reset the part of the
prompt in the last line. The last line will no longer be styled with blue-
on-green colors, but it will use the standard colors (white on black, in my
case).
I can't reproduce this on macOS with the current devel sources using
Terminal, xterm (from XQuartz), or iTerm.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: 'wait -n' with and without id arguments
On 7/31/24 3:52 PM, Zachary Santer wrote: On Wed, Jul 31, 2024 at 11:40 AM Zachary Santer wrote: Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: msys Compiler: gcc Compilation CFLAGS: -g -O2 uname output: MSYS_NT-10.0-19045 Zack2021HPPavilion 3.5.3-d8b21b8c.x86_64 2024-07-09 18:03 UTC x86_64 Msys Machine Type: x86_64-pc-msys Bash Version: 5.3 Patch Level: 0 Release Status: alpha See attached. When I was executing the script normally, not sourcing it, in that email, that was bash 5.2.26(1)-release. To avoid confusion, please reference the attachments to this email instead. OK, I see what's happening. When the shell is interactive, it notifies the user when a background job terminates and prints a message to the terminal. That's the series of [2] Donerandom_sleep messages you see. Once that happens, the shell considers the job `notified' and removes it from the jobs table. That's when it moves to the list of saved background pids and statuses. It's available there for `wait' when you supply a pid argument, but no longer eligible to be returned by `wait -n' without arguments, since it's already terminated and the user has been notified of the status. When I source your script on macOS with the current devel build, I get the set of notification messages and termination with a false argument, and an infinite loop with a true argument. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/ OpenPGP_signature.asc Description: OpenPGP digital signature
Re: whats wrong , exit code 11 on android termux
On 8/7/24 3:51 PM, alex xmb sw ratchev wrote: that means .. its in devel patch ? cause its 2023 .. Yes, it's in devel and has been since June, 2023. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/ OpenPGP_signature.asc Description: OpenPGP digital signature
Re: whats wrong , exit code 11 on android termux
On 8/7/24 1:14 PM, alex xmb sw ratchev wrote: mr chet .. any answer to this .. You already saw the right answer. https://lists.gnu.org/archive/html/bug-bash/2024-08/msg00040.html -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/ OpenPGP_signature.asc Description: OpenPGP digital signature
Re: 'wait -n' with and without id arguments
On 7/31/24 11:40 AM, Zachary Santer wrote: On Fri, Jul 26, 2024 at 10:37 AM Chet Ramey wrote: On 7/20/24 1:50 PM, Zachary Santer wrote: 'wait' without -n or pid arguments doesn't look in the list of saved pids and statuses simply because it would serve no purpose for it to do so. The return status will be 0, no matter how any child process terminated, or even if there never was a child process. * For 'wait -n', on the other hand: "If the -n option is supplied, wait waits for a single job from the list of ids or, if no ids are supplied, any job, to complete and returns its exit status." People are going to naturally expect 'wait -n' without pid arguments to return immediately with the exit status of an already-terminated child process, even if they don't provide id arguments. In order to do so, 'wait -n' obviously has to look in the list of saved pids and statuses. I think the part you're missing is that processes get moved to this list after the user has already been notified of their termination status. I think I was missing more than that. Was the original 'wait -n' discussion from January specific to its use within the interactive shell? No, it was due to processes exiting due to signals. But you could have looked that up yourself. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/ OpenPGP_signature.asc Description: OpenPGP digital signature
Re: proposed BASH_SOURCE_PATH
On 8/6/24 3:09 AM, konsolebox wrote: I just saw the new changes and tested it. It's not useful because BASH_SOURCE still expands to the relative form after `shopt -s bash_source_fullpath` is executed in the main script. You mean for the paths that were added to BASH_SOURCE before setting the option? If that's a concern for you, maybe start the script with that option enabled on the command line. This is why I was saying context directories would have to be stored and paths already stored in BASH_SOURCE would have to be converted to real path versions the moment the option is enabled; That's wrong for the same reason people didn't like doing it themselves: if the shell changes the working directory, prefixing the working directory is incorrect. If this is already final can the option at least be allowed to be enabled by default at compile time? Woe unto the poor soul who expects the default behavior and happens to use a distro compiled with that as the default. Not that that's likely to happen. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/ OpenPGP_signature.asc Description: OpenPGP digital signature
Re: waiting for process substitutions
On 8/5/24 11:00 PM, Zachary Santer wrote: On Mon, Aug 5, 2024 at 5:10 PM Chet Ramey wrote: But in the end, if you're waiting for a process that isn't going to terminate, you're going to be waiting for a long time. So, even with wait without id arguments restricted to the final procsub, if its process id is the same as $!, it's still trivial to create a scenario where the call to wait will hang. Given that, I don't see the benefit over simply waiting for all process substitutions. It's trivial to do a lot of things that may cause the shell to hang besides trying to wait for a process that will never terminate. What should the shell do about those? -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/ OpenPGP_signature.asc Description: OpenPGP digital signature
Re: 'wait -n' with and without id arguments
On 7/31/24 11:40 AM, Zachary Santer wrote: Thanks for your updates to the manual. "Wait for each specified child process id and return the termination status of the last id." Would it be better to say "Wait for each specified child process id and return the termination status of the last id argument," to emphasize that it's not returning the termination status of the last process to terminate from among those whose ids are listed? That's a pretty tortured reading. "Otherwise, the return status is the exit status of the last id." Is that correct? The final paragraph is in reference to 'wait -n', right? It could return the exit status of any one of the processes whose ids are listed. It is not. That language predates `wait -n'. The behavior of `wait -n' is completely specified in one paragraph. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/ OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Potentially misleading documentation of SECONDS variable
On 8/7/24 10:10 AM, G. Branden Robinson wrote: At the risk of splitting hairs, I would cast the added phrase as: "at a resolution of one second". I used "one-second resolution," actually. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/ OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Potentially misleading documentation of SECONDS variable
On 8/6/24 12:25 PM, Koichi Murase wrote: diff --git a/doc/bash.1 b/doc/bash.1 index 1f0a23d3..3ace21e9 100644 --- a/doc/bash.1 +++ b/doc/bash.1 @@ -2091,7 +2091,7 @@ the value returned upon subsequent references is the number of seconds since the assignment plus the value assigned. The number of seconds at shell invocation and the current time are always -determined by querying the system clock. +determined by querying the system clock at the resolution of a second. This is not unreasonable. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/ OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Potentially misleading documentation of SECONDS variable
On 8/6/24 11:17 AM, Bash-help via Bug reports for the GNU Bourne Again SHell wrote: Reading the manual at <https://www.gnu.org/software/bash/manual/bash.html#Bash-Variables> regarding the SECONDS variable, it states that " [..] Assignment to this variable resets the count to the value assigned, and the expanded value becomes the value assigned plus the number of seconds since the assignment. [..]" This implies that assigning the variable at time X with value Y would reset SECONDS to Y. When expanding the variable at time X+Z the value should be Y+Z. The text also implies whole seconds, i.e. not milliseconds or other fractions of seconds, are considered. However, it would seem as if the underlying mechanism to update SECONDS (the system clock) are actually considering fractions of seconds and not whole seconds. The system clock (at least on all of the systems worth considering at this point) has always kept fractions of a second. Bash has never looked at anything but whole seconds. From when I first added SECONDS in 1989 through bash-5.1, it used time(3). In bash-5.1, I changed it to use the tv_sec member of the struct from gettimeofday (which is essentially what modern versions of time(3) do), but it's never rounded up or attempted to perform tv_usec or tv_nsec arithmetic. If you're interested in that kind of sub-second precision, use EPOCHREALTIME. If you want something that's not affected by assignment, use EPOCHSECONDS. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: Bogus (intptr_t) casts
On 8/6/24 9:36 AM, Martin D Kealey wrote:
Why just those ones? Mainly:
(a) I'm looking at patching that area of the code for other reasons, so
they're the ones that I happened to encounter; and
(b) I didn't want to over-cook it, so I only included the ones where I
could see that it was actually a pointer (casting a number to an intptr_t
doesn't result in UB).
Other cases that involve casting a pointer to an intptr_t or uintptr_t, and
then comparing against a *numeric* zero should be similarly updated.
You didn't address the other part of my message. Since the pointers that
are in unwind-protects are the result of byte copies, not assignments, the
compiler's representation of NULL pointers isn't relevant.
To my knowledge all current compilers use a numeric zero to represent
NULL, but this is not guaranteed, and might change in the future.
It doesn't matter. The four (or eight) bytes in the (void *) that is cast
to an intptr_t are the result of copying the original four (or eight) bytes
in the int that's being saved.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: shell-expand-line working strangely without shebangs
> Thank you! Indeed a build from branch bash-5.3-testing shows the issue to be > fixed (devel did not build for me). I look forward to the release of the fix. What error did you get when you tried to build devel? (I assume this was on NixOS). Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: [bug #66068] built-in printf function not working with float
On 8/6/24 5:58 AM, anonymous wrote:
jesusm@liet:[~]$ bash --version
GNU bash, version 5.2.32(1)-release (x86_64-slackware-linux-gnu)
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
jesusm@liet:[~]$ printf "%f\n" 1.2
-nan
jesusm@liet:[~]$ /bin/printf "%f\n" 1.2
1.20
jesusm@liet:[~]$
Nothing changed here between 5.2.26 and 5.2.32; you probably updated your
compiler and fell victim to this:
https://lists.gnu.org/archive/html/bug-bash/2023-11/msg00104.html
I attached a patch.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
*** ../bash-5.2.32/configure.ac Fri Sep 23 10:12:27 2022
--- configure.acTue Aug 6 09:19:00 2024
***
*** 886,890
[AC_LANG_PROGRAM(
[[#include ]],
! [[long double r; char *foo, bar; r = strtold(foo, &bar);]]
)],
[bash_cv_strtold_broken=no],[bash_cv_strtold_broken=yes])
--- 886,890
[AC_LANG_PROGRAM(
[[#include ]],
! [[long double r; char *foo, *bar; r = strtold(foo, &bar);]]
)],
[bash_cv_strtold_broken=no],[bash_cv_strtold_broken=yes])
*** ../bash-5.2.32/configureWed Jul 31 09:44:19 2024
--- configure Tue Aug 6 09:20:18 2024
***
*** 15677,15681
main (void)
{
! long double r; char *foo, bar; r = strtold(foo, &bar);
;
--- 15677,15681
main (void)
{
! long double r; char *foo, *bar; r = strtold(foo, &bar);
;
Re: waiting for process substitutions
On 8/5/24 2:21 PM, Zachary Santer wrote: On Mon, Aug 5, 2024 at 9:54 AM Chet Ramey wrote: On 7/31/24 11:48 AM, Zachary Santer wrote: $ wait -n > >( cat ) would hang, in the event that there are no other un-waited-for child processes, right? Yes, it will wait for the next job or procsub to terminate. Basically the same situation as Oğuz's bug here: You mean the one I referenced below, right? https://lists.gnu.org/archive/html/bug-bash/2022-10/msg00107.html Sort of, but they're not the same. The issue with Oguz's bug is that $! had changed before `wait', and was no longer the same as the last process substitution -- the `wait' command should not have waited for it. The other issue was a bookkeeping problem -- even though the process substitution was performed by the same shell that executed the subshell command (because that's how bash optimizes forks), that command shouldn't inherit the process substitutions, since they're logically performed in a different execution context. But in the end, if you're waiting for a process that isn't going to terminate, you're going to be waiting for a long time. So $! is only set to the pid for a procsub that's being redirected to/from after the command (or compound command) whose output/input is being redirected to/from it has completed? Wow, that's a really complex sentence. And the answer is not really, and it's hard to tell. Since bash performs word expansions before redirections when executing simple commands, all the words in a simple command have been expanded before the process substitution changes $!. So it's not after it's completed, but it's after word expansions have been performed, so it's hard to tell. But if you ran something like this: echo $! <(echo $BASHPID > /dev/tty ) $! the second $! would be expanded to the pid of the procsub because the word expansion changed it. So in your example, the redirection sets $! (or its internal equivalent) to the pid of the procsub, and wait -n waits for it. These operations are performed by the same shell process. If that's the case, maybe the ideal solution for both 'wait' and 'wait -n' would be to wait for all background jobs and all procsubs that have ever been assigned to $! at that point. That's all procsubs. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/ OpenPGP_signature.asc Description: OpenPGP digital signature
Re: shell-expand-line working strangely without shebangs
On 8/5/24 4:57 AM, Jae Juang wrote: Bash Version: 5.2 Patch Level: 15 Release Status: release Description: In bash, the very useful shell-expand-line (`M-C-e`) expands command substitutions to their contents, on the current line. However, this works very strangely for commands without shebangs. Symptoms further described in "Repeat-By" section. Hi. Thanks for the report. This is the same issue as reported in https://lists.gnu.org/archive/html/bug-bash/2024-01/msg00095.html The fix is described in https://lists.gnu.org/archive/html/bug-bash/2024-01/msg00101.html and has been in the devel git branch since late January. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/ OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Bogus (intptr_t) casts
On 8/1/24 4:12 AM, Martin D Kealey wrote:
It follows that the following assertions are allowed to fail:
intptr_t i = 0;
assert(*(void*)i == (void*)0*);
void *p = 0;
assert(*(intptr_t)p == 0*);
Accordingly I provide the following patch:
I'm wondering why you chose these two cases, since there are other very
similar uses of intptr_t casts.
diff --git a/*subst.c* b/subst.c
index 37e0bfa7..140a3a92 100644
--- a/subst.c
+++ b/subst.c
@@ -6875,7 +6875,7 @@ uw_restore_pipeline (void *discard)
static void
uw_restore_errexit (void *eflag)
{
*- change_flag ('e', (intptr_t) eflag ? FLAG_ON : FLAG_OFF);+ change_flag
('e', eflag ? FLAG_ON : FLAG_OFF);*
set_shellopts ();
}
diff --git a/*variables.c* b/variables.c
index cd336c85..d44453fe 100644
--- a/variables.c
+++ b/variables.c
@@ -5444,7 +5444,7 @@ pop_scope (void *is_special)
FREE (vcxt->name);
if (vcxt->table)
{
*- if ((intptr_t) is_special)+ if (is_special)*
hash_flush (vcxt->table, push_builtin_var);
else
hash_flush (vcxt->table, push_exported_var);
You might want to look at the unwind-protect implementation, which doesn't
use assignments. It uses byte copies, so instead of using an assignment of,
say, 0, where the compiler can assign whatever it wants to denote a NULL
pointer, it copies 4-8 bytes, depending on the size of an integer. The cast
of that memory back to an intptr_t should be transparent on all reasonably
common systems.
Of course, if you can provide an example where it fails, I'll look at it
and fix it.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
OpenPGP_signature.asc
Description: OpenPGP digital signature
Re: waiting for process substitutions
On 7/31/24 11:48 AM, Zachary Santer wrote: On Fri, Jul 26, 2024 at 10:19 AM Chet Ramey wrote: You could have looked at the actual commit, which contains the change log, which says - wait_for_any_job: check for any terminated procsubs as well as any terminated background jobs wait_for_any_job is the function that backs `wait -n' without arguments. Thanks for the clarification. $ wait -n > >( cat ) would hang, in the event that there are no other un-waited-for child processes, right? Yes, it will wait for the next job or procsub to terminate. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/ OpenPGP_signature.asc Description: OpenPGP digital signature
Bash-5.2 Patch 32
BASH PATCH REPORT
=
Bash-Release: 5.2
Patch-ID: bash52-032
Bug-Reported-by:Albert Akchurin
Bug-Reference-ID: Mon, 11 Dec 2023 20:41:58 +0600
Bug-Reference-URL:
https://lists.gnu.org/archive/html/bug-bash/2023-12/msg00047.html
Bug-Description:
Patch (apply with `patch -p0'):
When printing functions containing coprocesses, the displayed coproc command
has the word COPROC inserted unconditionally, resulting in function bodies
that cannot be re-read as input.
*** ../bash-5.2-patched/print_cmd.c Mon Aug 21 16:09:44 2023
--- print_cmd.c Mon Dec 11 15:34:30 2023
***
*** 357,361
case cm_coproc:
! cprintf ("coproc %s ", command->value.Coproc->name);
skip_this_indent++;
make_command_string_internal (command->value.Coproc->command);
--- 357,363
case cm_coproc:
! cprintf ("coproc ");
! if (command->value.Coproc->command->type != cm_simple)
! cprintf ("%s ", command->value.Coproc->name);
skip_this_indent++;
make_command_string_internal (command->value.Coproc->command);
*** ../bash-5.2/patchlevel.h2020-06-22 14:51:03.0 -0400
--- patchlevel.h2020-10-01 11:01:28.0 -0400
***
*** 26,30
looks for to find the patch level (for the sccs version string). */
! #define PATCHLEVEL 31
#endif /* _PATCHLEVEL_H_ */
--- 26,30
looks for to find the patch level (for the sccs version string). */
! #define PATCHLEVEL 32
#endif /* _PATCHLEVEL_H_ */
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Bash-5.2 Patch 31
BASH PATCH REPORT = Bash-Release: 5.2 Patch-ID: bash52-031 Bug-Reported-by:Grisha Levit Bug-Reference-ID: Bug-Reference-URL: https://lists.gnu.org/archive/html/bug-bash/2023-06/msg00045.html Bug-Description: There is a memory leak in the code that implements the optimized $(http://tiswww.cwru.edu/~chet/
Bash-5.2 Patch 30
BASH PATCH REPORT
=
Bash-Release: 5.2
Patch-ID: bash52-030
Bug-Reported-by:Steven Pelley
Bug-Reference-ID:
Bug-Reference-URL:
https://lists.gnu.org/archive/html/bug-bash/2024-01/msg00104.html
Bug-Description:
`wait -n' can fail to return some jobs if they exit due to signals the shell
does not report to the user.
Patch (apply with `patch -p0'):
*** ../bash-5.2-patched/jobs.c Thu Nov 9 14:59:14 2023
--- jobs.c Tue Jul 30 15:27:44 2024
***
*** 4275,4279
((DEADJOB (job) && IS_FOREGROUND (job) == 0) || STOPPED (job)))
continue;
!
/* If job control is disabled, don't print the status messages.
Mark dead jobs as notified so that they get cleaned up. If
--- 4288,4312
((DEADJOB (job) && IS_FOREGROUND (job) == 0) || STOPPED (job)))
continue;
!
! /* Do the same thing and don't print anything or mark as notified
!for the signals we're not going to report on. This is the opposite
!of the first two cases under case JDEAD below. */
! else if (interactive_shell == 0 && DEADJOB (job) && IS_FOREGROUND
(job) == 0 &&
! WIFSIGNALED (s) && (termsig == SIGINT
! #if defined (DONT_REPORT_SIGTERM)
! || termsig == SIGTERM
! #endif
! #if defined (DONT_REPORT_SIGPIPE)
! || termsig == SIGPIPE
! #endif
! || signal_is_trapped (termsig)))
! continue;
!
! /* hang onto the status if the shell is running -c command */
! else if (startup_state == 2 && subshell_environment == 0 &&
! WIFSIGNALED (s) == 0 &&
! ((DEADJOB (job) && IS_FOREGROUND (job) == 0) || STOPPED (job)))
! continue;
!
/* If job control is disabled, don't print the status messages.
Mark dead jobs as notified so that they get cleaned up. If
***
*** 4298,4302
/* Print info on jobs that are running in the background,
and on foreground jobs that were killed by anything
!except SIGINT (and possibly SIGPIPE). */
switch (JOBSTATE (job))
{
--- 4331,4335
/* Print info on jobs that are running in the background,
and on foreground jobs that were killed by anything
!except SIGINT (and possibly SIGTERM and SIGPIPE). */
switch (JOBSTATE (job))
{
***
*** 4318,4321
--- 4351,4355
else if (IS_FOREGROUND (job))
{
+ /* foreground jobs, interactive and non-interactive shells */
#if !defined (DONT_REPORT_SIGPIPE)
if (termsig && WIFSIGNALED (s) && termsig != SIGINT)
***
*** 4331,4337
fprintf (stderr, "\n");
}
}
! else if (job_control) /* XXX job control test added */
{
if (dir == 0)
dir = current_working_directory ();
--- 4365,4375
fprintf (stderr, "\n");
}
+ /* foreground jobs that exit cleanly */
+ jobs[job]->flags |= J_NOTIFIED;
}
! else if (job_control)
{
+ /* background jobs with job control, interactive and
+non-interactive shells */
if (dir == 0)
dir = current_working_directory ();
***
*** 4342,4346
}
! jobs[job]->flags |= J_NOTIFIED;
break;
--- 4380,4391
}
! /* Interactive shells without job control enabled are handled
!above. */
! /* XXX - this is a catch-all in case we missed a state */
! else
! {
! internal_debug("notify_of_job_status: catch-all setting J_NOTIFIED on job %d
(%d), startup state = %d", job, jobs[job]->flags, startup_state);
! jobs[job]->flags |= J_NOTIFIED;
! }
break;
*** ../bash-5.2/patchlevel.h2020-06-22 14:51:03.0 -0400
--- patchlevel.h2020-10-01 11:01:28.0 -0400
***
*** 26,30
looks for to find the patch level (for the sccs version string). */
! #define PATCHLEVEL 29
#endif /* _PATCHLEVEL_H_ */
--- 26,30
looks for to find the patch level (for the sccs version string). */
! #define PATCHLEVEL 30
#endif /* _PATCHLEVEL_H_ */
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Bash-5.2 Patch 29
BASH PATCH REPORT
=
Bash-Release: 5.2
Patch-ID: bash52-029
Bug-Reported-by:Grisha Levit
Bug-Reference-ID:
Bug-Reference-URL:
https://lists.gnu.org/archive/html/bug-bash/2023-04/msg00072.html
Bug-Description:
There are problems with recovery after parser errors when parsing compound
assignments. For instance, the `local' builtin reports an error but never
cleans up the function context.
Patch (apply with `patch -p0'):
*** ../bash-20230427/parse.yFri Apr 14 11:50:29 2023
--- parse.y Mon May 1 16:25:14 2023
***
*** 6471,6478
{
set_exit_status (EXECUTION_FAILURE);
if (interactive_shell == 0 && posixly_correct)
jump_to_top_level (FORCE_EOF);
else
! jump_to_top_level (DISCARD);
}
--- 6471,6483
{
set_exit_status (EXECUTION_FAILURE);
+ current_token = '\n'; /* XXX */
if (interactive_shell == 0 && posixly_correct)
jump_to_top_level (FORCE_EOF);
else
! {
! if (executing && parse_and_execute_level == 0)
! top_level_cleanup ();
! jump_to_top_level (DISCARD);
! }
}
***
*** 6538,6546
{
set_exit_status (EXECUTION_FAILURE);
! last_read_token = '\n'; /* XXX */
if (interactive_shell == 0 && posixly_correct)
jump_to_top_level (FORCE_EOF);
else
! jump_to_top_level (DISCARD);
}
--- 6543,6555
{
set_exit_status (EXECUTION_FAILURE);
! last_read_token = current_token = '\n'; /* XXX */
if (interactive_shell == 0 && posixly_correct)
jump_to_top_level (FORCE_EOF);
else
! {
! if (executing && parse_and_execute_level == 0)
! top_level_cleanup ();
! jump_to_top_level (DISCARD);
! }
}
*** ../bash-20230427/y.tab.cTue Jul 30 15:19:31 2024
--- y.tab.c Tue Jul 30 15:20:21 2024
***
*** 8786,8793
{
set_exit_status (EXECUTION_FAILURE);
if (interactive_shell == 0 && posixly_correct)
jump_to_top_level (FORCE_EOF);
else
! jump_to_top_level (DISCARD);
}
--- 8786,8798
{
set_exit_status (EXECUTION_FAILURE);
+ current_token = '\n'; /* XXX */
if (interactive_shell == 0 && posixly_correct)
jump_to_top_level (FORCE_EOF);
else
! {
! if (executing && parse_and_execute_level == 0)
! top_level_cleanup ();
! jump_to_top_level (DISCARD);
! }
}
***
*** 8853,8861
{
set_exit_status (EXECUTION_FAILURE);
! last_read_token = '\n'; /* XXX */
if (interactive_shell == 0 && posixly_correct)
jump_to_top_level (FORCE_EOF);
else
! jump_to_top_level (DISCARD);
}
--- 8858,8870
{
set_exit_status (EXECUTION_FAILURE);
! last_read_token = current_token = '\n'; /* XXX */
if (interactive_shell == 0 && posixly_correct)
jump_to_top_level (FORCE_EOF);
else
! {
! if (executing && parse_and_execute_level == 0)
! top_level_cleanup ();
! jump_to_top_level (DISCARD);
! }
}
*** ../bash-5.2/patchlevel.h2020-06-22 14:51:03.0 -0400
--- patchlevel.h2020-10-01 11:01:28.0 -0400
***
*** 26,30
looks for to find the patch level (for the sccs version string). */
! #define PATCHLEVEL 28
#endif /* _PATCHLEVEL_H_ */
--- 26,30
looks for to find the patch level (for the sccs version string). */
! #define PATCHLEVEL 29
#endif /* _PATCHLEVEL_H_ */
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Bash-5.2 Patch 28
BASH PATCH REPORT
=
Bash-Release: 5.2
Patch-ID: bash52-028
Bug-Reported-by:Mark March
Bug-Reference-ID: <834896722.6304071.1718744118...@mail.yahoo.com>
Bug-Reference-URL:
https://lists.gnu.org/archive/html/bug-bash/2024-06/msg00122.html
Bug-Description:
A DEBUG trap in an asynchronous process can steal the controlling terminal
away from the calling shell, causing it to exit.
Patch (apply with `patch -p0'):
*** ../bash-20240609/trap.c Fri May 3 12:12:38 2024
--- trap.c Wed Jun 26 10:41:40 2024
***
*** 1217,1221
restore_pgrp_pipe (save_pipe);
# endif
! if (pipeline_pgrp > 0 && ((subshell_environment &
(SUBSHELL_ASYNC|SUBSHELL_PIPE)) == 0))
give_terminal_to (pipeline_pgrp, 1);
--- 1217,1223
restore_pgrp_pipe (save_pipe);
# endif
! /* If the trap command gave the terminal to another process group,
!restore it. XXX - check running_in_background? */
! if (job_control && pipeline_pgrp > 0 && ((subshell_environment &
(SUBSHELL_ASYNC|SUBSHELL_PIPE)) == 0))
give_terminal_to (pipeline_pgrp, 1);
*** ../bash-5.2/patchlevel.h2020-06-22 14:51:03.0 -0400
--- patchlevel.h2020-10-01 11:01:28.0 -0400
***
*** 26,30
looks for to find the patch level (for the sccs version string). */
! #define PATCHLEVEL 27
#endif /* _PATCHLEVEL_H_ */
--- 26,30
looks for to find the patch level (for the sccs version string). */
! #define PATCHLEVEL 28
#endif /* _PATCHLEVEL_H_ */
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Bash-5.2 Patch 27
BASH PATCH REPORT
=
Bash-Release: 5.2
Patch-ID: bash52-027
Bug-Reported-by:Emanuel Haupt
Bug-Reference-ID: <20221001123841.27e1bfb3bf3ed58ab32ea...@freebsd.org>
Bug-Reference-URL:
https://lists.gnu.org/archive/html/bug-bash/2022-10/msg0.html
Bug-Description:
The configure test for the presence of strtoimax(3) is inverted.
Patch (apply with `patch -p0'):
*** ../bash-5.2-patched/m4/strtoimax.m4 Mon Apr 11 16:31:52 2022
--- m4/strtoimax.m4 Tue Apr 9 11:12:36 2024
***
*** 30,34
])
AC_MSG_RESULT($bash_cv_func_strtoimax)
! if test $bash_cv_func_strtoimax = yes; then
AC_LIBOBJ(strtoimax)
fi
--- 30,34
])
AC_MSG_RESULT($bash_cv_func_strtoimax)
! if test $bash_cv_func_strtoimax = no; then
AC_LIBOBJ(strtoimax)
fi
*** ..//bash-5.2-patched/configure Fri Sep 23 10:13:22 2022
--- configure Tue Apr 9 11:13:21 2024
***
*** 20444,20448
{ printf "%s\n" "$as_me:${as_lineno-$LINENO}: result:
$bash_cv_func_strtoimax" >&5
printf "%s\n" "$bash_cv_func_strtoimax" >&6; }
! if test $bash_cv_func_strtoimax = yes; then
case " $LIBOBJS " in
*" strtoimax.$ac_objext "* ) ;;
--- 20444,20448
{ printf "%s\n" "$as_me:${as_lineno-$LINENO}: result:
$bash_cv_func_strtoimax" >&5
printf "%s\n" "$bash_cv_func_strtoimax" >&6; }
! if test $bash_cv_func_strtoimax = no; then
case " $LIBOBJS " in
*" strtoimax.$ac_objext "* ) ;;
*** ../bash-5.2/patchlevel.h2020-06-22 14:51:03.0 -0400
--- patchlevel.h2020-10-01 11:01:28.0 -0400
***
*** 26,30
looks for to find the patch level (for the sccs version string). */
! #define PATCHLEVEL 26
#endif /* _PATCHLEVEL_H_ */
--- 26,30
looks for to find the patch level (for the sccs version string). */
! #define PATCHLEVEL 27
#endif /* _PATCHLEVEL_H_ */
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
