Re: Bug tracking

[Martin D Kealey]

On Tue, 2 Apr 2024 at 00:31, Chet Ramey  wrote:

> On 3/31/24 8:34 PM, Martin D Kealey wrote:
> > That's a good start, but it seems incomplete, and there's little --
> perhaps
> > no -- overlap with bug reports in this list.
>

And this is still the most fundamental problem; the submission of bug
reports, the discussion around them, and the proposed fixes currently are
split between multiple platforms that don't talk to each other. So *very*
few people actually track everything.


> > Has bashbug always sent email to bug-bash@gnu.org, or was it previously
> fed into Savannah?
> bashbug long predates savannah.
>

We are instructed to submit bug reports via bash-bug, or by posting to this
mailing list, but none of those reports reach Savannah.

When Savannah became the primary repository, bash-bug should have been
updated to post to Savannah, and/or an email receiver should have been
created to inject into Savannah's "support" queue. Likewise, details
entered directly on Savannah should be sent to the mailing list. ("Overdue"
would be an understatement.)

First impressions when I sign into Savannah:

   - There's no "dashboard" or "overview" of stuff that I personally am
   likely to need. In particular, there's no mention of any projects I'm
   trying to engage with. OK I'll try to add some:
   - The sidebar has a (relatively) obvious link "My Groups", taking me to
   "My Group Membership".
   Nope, "You're not a member of any public group".
   - The right panel has "Request for inclusion", which sounds about right.
   OK, let's search for Bash. Yay, found ... oh wait, nope, "Bash Bear Trap"
   is not "Bash".
   - Let's back up, and use the site search in the side bar.
   OK, *this* time I see "The GNU Bourne-Again SHell" (and the Bear Trap
   again, and 13 other projects).
   Let's follow that link and ... yay, found it.

At this point I save a bookmark, because that was the short-and-simple
version of what was actually a much longer and far more tedious process of
discovery.

The summary page says that this project has:

   - 3 mailing lists
   - an SVN repository (which turns out to be empty)
   - a Git repository
   - a "tech support manager" (which turns out to be a general inquiries
   queue)
   - a "patch manager" (which turns out to be a bug-reporting and
   feature-request queue)
   - 3 mailing lists

Initial impression good.
Well okay.
For all of 10 minutes, by which time I've discovered that these facilities
have no mutual integration.

It seems like the "support" queue is intended for interactions with users
and the "patches" queue is for interactions between designers, developers
and Q/A reviewers. That arrangement could have some benefits, but
unfortunately:

   - The support and patch queues don't talk to each other. Once an actual
   bug is identified from a support request, a separate "patch" issue has to
   be opened, without any automatic cross referencing. And therefore when a
   bug fix finally makes it into a release, there's no automated process to
   close any original support requests.
   - Neither the support queue nor the patches queue has any integration
   with this email list (nor, I suspect, with any others).
   - Any cross-referencing between them is up to project members to perform
   manually.
   - The git repo has a fixed set of branches created by the members; other
   users cannot create their own branches.
   - When it says "patch", it really still means an actual context diff
   text file.
   Anyone used to using a modern source management system (e.g. Piper,
   Perforce, Bitbucket, Gitlab, or GitHub) would expect "patch" to mean a git
   branch or equivalent, which can be amended (with additional commits),
   merged, or rebased, all while being subject to regression testing, and then
   merged into the "master" branch once it has QA approval. (A major effect of
   this lack is that a textual patch can "go stale" while the master branch in
   the git repo moves on, without any tracking of how far out of date it's
   become.)
   But there is no linkage between the patch queue and any git repo, nor is
   there a branch per active patch issue.
   - We cannot use ssh to connect to git.savannah.gnu.org, despite the
   instructions for cloning the repo saying we should use
   @git.savannah.gnu.org:/srv/git/bash.git rather than just
git.savannah.gnu.org:/srv/git/bash.git
   .

This combination of missing features (and outright mis-features) amounts to
the antithesis of how one should design a modern collaborative development
process.

And that's a big part of why a one-man-band running the whole show is the
only feasible support model.

> Savannah seems too simplistic [...]
>
> If you have suggestions for the savannah maintainers, 

Re: [bug #65827] Cross-compilation fails with gcc 14.1.0

[Brett Neumeier]

On 6/3/24 08:30, Chet Ramey wrote:
  On 6/2/24 9:43 AM, Brett Neumeier wrote:
  
./configure --build=x86_64-unknown-linux-gnu --host=aarch64-cbl-linux-gnu
--enable-static-link --without-bash-malloc

I get this failure:

[...]

If I add "#include " to tparam.c, it builds fine.
  
  Thanks for the report.
  
  I'm more interested in why configuring for your cross-compilation
  environment doesn't find any of the curses libraries or headers. Do
  you have them installed?

Hello Mr Ramey and thank you for your email!

In my previous build, I didn't have ncurses set as a dependency of bash, so 
bash was getting built first -- and then there was no ncurses for it to find.

I made sure ncurses was already available and the initial problem went away. 
When I configured ncurses (6.5) using the default settings, including wide 
character support, I got a different failure:

aarch64-cbl-linux-gnu-gcc -L./builtins -L./lib/readline -L./lib/readline 
-L./lib/glob -L./lib/tilde  -L./lib/sh  
-L/home/lbl/work/sysroot/scaffolding/lib -rdynamic -I/home/lbl/work/sy
sroot/scaffolding/include  -static -o bash shell.o eval.o y.tab.o general.o 
make_cmd.o print_cmd.o  dispose_cmd.o execute_cmd.o variables.o copy_cmd.o 
error.o expr.o flags.o jobs.o su
bst.o hashcmd.o hashlib.o mailcheck.o trap.o input.o unwind_prot.o pathexp.o 
sig.o test.o version.o alias.o array.o arrayfunc.o assoc.o braces.o bracecomp.o 
bashhist.o bashline.o  lis
t.o stringlib.o locale.o findcmd.o redir.o pcomplete.o pcomplib.o syntax.o 
xmalloc.o signames.o -lbuiltins -lglob -lsh -lreadline -lhistory -lncurses 
-ltilde 
/home/lbl/work/crosstools/lib/gcc/aarch64-cbl-linux-gnu/14.1.1/../../../../aarch64-cbl-linux-gnu/bin/ld:
 cannot find -lncurses: No such file or directory

I don't quite understand why having widec support caused a problem -- the bash 
config.log shows:

configure:21471: checking for tgetent in -lncurses
configure:21494: aarch64-cbl-linux-gnu-gcc -o conftest 
-I/home/lbl/work/sysroot/scaffolding/include  
-L/home/lbl/work/sysroot/scaffolding/lib conftest.c -lncurses   >&5
/home/lbl/work/crosstools/lib/gcc/aarch64-cbl-linux-gnu/14.1.1/../../../../aarch64-cbl-linux-gnu/bin/ld:
 cannot find -lncurses: No such file or directory

and

configure:21510: checking for tgetent in -lncursesw
configure:21533: aarch64-cbl-linux-gnu-gcc -o conftest -I/home/lbl/work/sysroot/
scaffolding/include  -L/home/lbl/work/sysroot/scaffolding/lib conftest.c -lncurs
esw   >&5
configure:21533: $? = 0
configure:21543: result: yes
configure:21565: checking which library has the termcap functions
configure:21568: result: using libncursesw

so the configure seems to find libncursesw just fine, but then still tries to 
link against libncurses.

When I rebuilt ncurses with `--disable-widec`, the bash build succeeds.

Thank you again for your help!

Cheers,

Brett

Re: [bug #65827] Cross-compilation fails with gcc 14.1.0

[Chet Ramey]

On 6/2/24 9:43 AM, Brett Neumeier wrote:


./configure --build=x86_64-unknown-linux-gnu --host=aarch64-cbl-linux-gnu
--enable-static-link --without-bash-malloc

I get this failure:

---
aarch64-cbl-linux-gnu-gcc -c -I/home/lbl/work/sysroot/scaffolding/include
-DHAVE_CONFIG_H  -I. -I../.. -I../.. -I../../lib -I. tparam.c
tparam.c: In function 'memory_out':
tparam.c:67:3: error: implicit declaration of function 'write'
[-Wimplicit-function-declaration]
67 |   write (2, "virtual memory exhausted\n", 25);
   |   ^
make[1]: *** [Makefile:56: tparam.o] Error 1
make[1]: Leaving directory '/home/lbl/work/build/bash-5.2.26/lib/termcap'
make: *** [Makefile:702: lib/termcap/libtermcap.a] Error 1
---

If I add "#include " to tparam.c, it builds fine.


Thanks for the report.

I'm more interested in why configuring for your cross-compilation
environment doesn't find any of the curses libraries or headers. Do
you have them installed?

What does config.log say about searching for the curses and termcap
libraries?

The ancient termcap library bash includes is the bare minimum to get
a successful link.

--
``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

[bug #65827] Cross-compilation fails with gcc 14.1.0

[Brett Neumeier]

URL:
  

 Summary: Cross-compilation fails with gcc 14.1.0
   Group: The GNU Bourne-Again SHell
   Submitter: bneumeier
   Submitted: Sun 02 Jun 2024 01:43:53 PM UTC
Category: None
Severity: 3 - Normal
  Item Group: None
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any


___

Follow-up Comments:


---
Date: Sun 02 Jun 2024 01:43:53 PM UTC By: Brett Neumeier 
Building binutils 5.2.26 with an x86_64-to-aarch64 gcc 14.1.0, configured
thus:

./configure --build=x86_64-unknown-linux-gnu --host=aarch64-cbl-linux-gnu
--enable-static-link --without-bash-malloc

I get this failure:

---
aarch64-cbl-linux-gnu-gcc -c -I/home/lbl/work/sysroot/scaffolding/include
-DHAVE_CONFIG_H  -I. -I../.. -I../.. -I../../lib -I. tparam.c
tparam.c: In function 'memory_out':
tparam.c:67:3: error: implicit declaration of function 'write'
[-Wimplicit-function-declaration]
   67 |   write (2, "virtual memory exhausted\n", 25);
  |   ^
make[1]: *** [Makefile:56: tparam.o] Error 1
make[1]: Leaving directory '/home/lbl/work/build/bash-5.2.26/lib/termcap'
make: *** [Makefile:702: lib/termcap/libtermcap.a] Error 1
---

If I add "#include " to tparam.c, it builds fine.







___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

Re: yet another $(case ... parse bug

[Chet Ramey]

On 5/24/24 1:43 AM, Oğuz wrote:

While you're at it take a look at this too:

true; for (( ; $? == 0; ${ ! break;} )); do uname; done


The arithmetic for command should probably check for breaking after it
evaluates the loop test. You have to admit this is not something people
are going to write as a matter of course.

--
``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: yet another $(case ... parse bug

[Chet Ramey]

On 5/23/24 1:19 PM, Oğuz wrote:

See:

$ bash -c 'for (( $(case x in x) esac);; )); do :; done'
bash: -c: line 1: syntax error: `;' unexpected
bash: -c: line 1: syntax error: `(( $(case x in x)

 ;;
esac);; ))'


Thanks for the report. This should be a pretty easy fix; just use
extract_command_subst() 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/

Re: yet another $(case ... parse bug

[Oğuz]

While you're at it take a look at this too:

true; for (( ; $? == 0; ${ ! break;} )); do uname; done

Once you run this command bash gets stuck in a state where it prints
the prompt string and reads commands but doesn't execute anything. If
you press Ctrl+C it returns to normal.

Oğuz

yet another $(case ... parse bug

[Oğuz]

See:

$ bash -c 'for (( $(case x in x) esac);; )); do :; done'
bash: -c: line 1: syntax error: `;' unexpected
bash: -c: line 1: syntax error: `(( $(case x in x)

;;
esac);; ))'

This is reproducible on 5.3 alpha too.

Oğuz

Re: bug in bash

[Chet Ramey]

On 5/14/24 11:12 AM, Chet Ramey wrote:

On 5/14/24 10:20 AM, Andreas Schwab wrote:

On Mai 14 2024, Chet Ramey wrote:


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


But leaving it in the process group of the parent shell does not
accomplish that, which is actually the point of this thread. 


It does in two cases: a builtin command, where the process group doesn't
change, and a pipeline, where the process group is already set and the
process substitution doesn't change it.


I should probably have included what I suspect is the most common case:
process substitution that's part of a redirection associated with a simple
command that's not a builtin or function. Since redirections are performed
in the child process, the process substitution inherits the (already-set)
process group of the simple command.

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

[Chet Ramey]

On 5/14/24 10:20 AM, Andreas Schwab wrote:

On Mai 14 2024, Chet Ramey wrote:


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


But leaving it in the process group of the parent shell does not
accomplish that, which is actually the point of this thread. 


It does in two cases: a builtin command, where the process group doesn't
change, and a pipeline, where the process group is already set and the
process substitution doesn't change it.


A process
substitution is similar to a pipeline; it really belongs to the process
group of the command that reads from it.


The problem with this case is that the word expansion is performed before
the child process is created, so there is no "process group of the command
that reads from 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: bug in bash

[Andreas Schwab]

On Mai 14 2024, Chet Ramey wrote:

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

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

-- 
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: bug in bash

[Chet Ramey]

On 5/13/24 3:37 PM, Oğuz wrote:
On Monday, May 13, 2024, Chet Ramey > wrote:


performs the setpgid in the process forked
to run the process substitution).


Yes, this sounds like the easy way. I don't know how else to prevent the 
race in OP. Close stdin/stdout? 


That doesn't change the controlling terminal.


Direct it from /dev/null?


Same issue.

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

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

[Oğuz]

On Monday, May 13, 2024, Chet Ramey  wrote:

> performs the setpgid in the process forked
> to run the process substitution).
>

Yes, this sounds like the easy way. I don't know how else to prevent the
race in OP. Close stdin/stdout? Direct it from /dev/null?


-- 
Oğuz

Re: bug in bash

[Chet Ramey]

On 5/12/24 10:00 AM, Oğuz wrote:

On Sun, May 12, 2024 at 4:33 PM Andreas Schwab  wrote:

Since the redirection fails and the cat command is never started, bash
doesn't switch the terminal process group


It does on my computer:

554   ioctl(255, TIOCSPGRP, [554])  = 0
553   execve("/usr/bin/wc", ["wc", "-l"], 0x55706d7bac10 /* 30 vars */

554   +++ exited with 1 +++

But it doesn't change the process group ID of `wc' to its PID, so it
ends up in the foreground process group with bash.


Command substitutions and process substitutions run in the same process
group as the shell performing the word expansions. This is how ksh93 does
it as well (zsh, by contrast, performs the setpgid in the process forked
to run the process substitution).

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

[Andreas Schwab]

On Mai 12 2024, Greg Wooledge wrote:

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

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

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: bug in bash

[Oğuz]

On Sun, May 12, 2024 at 4:33 PM Andreas Schwab  wrote:
> Since the redirection fails and the cat command is never started, bash
> doesn't switch the terminal process group

It does on my computer:

554   ioctl(255, TIOCSPGRP, [554])  = 0
553   execve("/usr/bin/wc", ["wc", "-l"], 0x55706d7bac10 /* 30 vars */

554   +++ exited with 1 +++

But it doesn't change the process group ID of `wc' to its PID, so it
ends up in the foreground process group with bash. See:

$ cat <(bash -c 'enable setpgid; setpgid $$ $$; wc -l') 

Re: bug in bash

[Greg Wooledge]

On Sun, May 12, 2024 at 03:33:12PM +0200, Andreas Schwab wrote:
> > On Sun, May 12, 2024 at 03:55:21AM +0200, Quốc Trị Đỗ wrote:
> >> I found a bug when i tried with syntax <(cmd). this is an example
> >> cat <(wc -l) < bk

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

Ah... I assumed bk was an existing file.

hobbit:~$ cat <(wc -l) <.bashrc
wc: 'standard input': Input/output error
0
hobbit:~$ 

Re: bug in bash

[Andreas Schwab]

On Mai 12 2024, Greg Wooledge wrote:

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

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

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: bug in bash

[Greg Wooledge]

On Sun, May 12, 2024 at 03:55:21AM +0200, Quốc Trị Đỗ wrote:
> I found a bug when i tried with syntax <(cmd). this is an example
> cat <(wc -l) < bk

What is "wc -l" supposed to read from?  It counts lines of standard input,
until EOF is reached.  But its standard input is a terminal.  And you're
running it as a background process.

I would *expect* this command to fail with an error message of some
kind, because a background process shouldn't be allowed to read
input from a terminal.

> How to fix it? It doesn't last that long. After a while, it will show "wc:
> stdin: read: Input/output error". Or we can ctrl C.

Sounds appropriate.

What's the "bug in bash" supposed to be?  What did you think this command
would do?

Re: bug in bash

[Kerin Millar]

On Sun, 12 May 2024 03:55:21 +0200
Quốc Trị Đỗ  wrote:

> Hi,
> 
> I found a bug when i tried with syntax <(cmd). this is an example
> cat <(wc -l) < bk
> 
> You can follow this command, then you have bugs. I think because you
> created a fork getting inside in the parenthesis and the main process do <
> bk. They work parallel. Because of that,  yeah.
> At least, I tried this here on this campus, at 42Heilbronn - Germany.
> 

Let's replace wc with ps for a moment.

$ cat <(ps -j)
PIDPGID SID TTY  TIME CMD
   784078407840 pts/000:00:00 bash
   849278407840 pts/000:00:00 ps
   849384937840 pts/000:00:00 cat

There, cat ends up being the sole member of the foreground process group (whose 
PGID happened to be 8493 at the time). It can be seen that ps is not a member 
of that same process group. Were ps to try to read from the standard input - as 
wc does - it would also fail. The reason is that only processes belonging to 
the foreground process group are allowed to read from the controlling terminal.

> How to fix it? It doesn't last that long. After a while, it will show "wc:
> stdin: read: Input/output error". Or we can ctrl C.
> Version 5.2

Though already asked, what were you intending for it to do?

-- 
Kerin Millar

Re: bug in bash

[Andreas Kähäri]

On Sun, May 12, 2024 at 03:55:21AM +0200, Quốc Trị Đỗ wrote:
> Hi,
> 
> I found a bug when i tried with syntax <(cmd). this is an example
> cat <(wc -l) < bk
> 
> You can follow this command, then you have bugs. I think because you
> created a fork getting inside in the parenthesis and the main process do <
> bk. They work parallel. Because of that,  yeah.
> At least, I tried this here on this campus, at 42Heilbronn - Germany.
> 
> How to fix it? It doesn't last that long. After a while, it will show "wc:
> stdin: read: Input/output error". Or we can ctrl C.
> Version 5.2
> 
> Kind regards
> Quoc Tri do

What was it that you intended to do when you composed that command?

-- 
Andreas (Kusalananda) Kähäri
Uppsala, Sweden

.

bug in bash

[Quốc Trị Đỗ]

Hi,

I found a bug when i tried with syntax <(cmd). this is an example
cat <(wc -l) < bk

You can follow this command, then you have bugs. I think because you
created a fork getting inside in the parenthesis and the main process do <
bk. They work parallel. Because of that,  yeah.
At least, I tried this here on this campus, at 42Heilbronn - Germany.

How to fix it? It doesn't last that long. After a while, it will show "wc:
stdin: read: Input/output error". Or we can ctrl C.
Version 5.2

Kind regards
Quoc Tri do

(Just making sure this went through.) Bug: Bash is not memory safe.

[Joshua Brown]

$ bash --version | head -n1
GNU bash, version 5.2.15(1)-release (x86_64-pc-linux-gnu)

$ valgrind --leak-check=full \
 --track-origins=yes \
 --verbose \
 --log-file=valgrind-out-bash.txt \
 /bin/bash



==2762== Memcheck, a memory error detector
==2762== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==2762== Using Valgrind-3.19.0-8d3c8034b8-20220411 and LibVEX; rerun
with -h for copyright info ==2762== Command: /bin/bash
==2762== Parent PID: 2251
==2762== 
--2762-- 
--2762-- Valgrind options:
--2762----leak-check=full
--2762----track-origins=yes
--2762----verbose
--2762----log-file=valgrind-out-bash.txt
--2762-- Contents of /proc/version:
--2762--   Linux version 6.1.0-20-amd64
(debian-ker...@lists.debian.org) (gcc-12 (Debian 12.2.0-14) 12.2.0, GNU
ld (GNU Binutils for Debian) 2.40) #1 SMP PREEMPT_DYNAMIC Debian
6.1.85-1 (2024-04-11) --2762-- --2762-- Arch and hwcaps: AMD64,
LittleEndian,
amd64-cx16-lzcnt-rdtscp-sse3-ssse3-avx-avx2-bmi-f16c-rdrand-rdseed
--2762-- Page sizes: currently 4096, max supported 4096 --2762--
Valgrind library directory: /usr/libexec/valgrind --2762-- Reading syms
from /bin/bash --2762--object doesn't have a symbol table --2762--
Reading syms from /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 --2762--
Considering
/usr/lib/debug/.build-id/80/8ccde0c755608358b0915a6615c19401fe6bf6.debug
.. --2762--   .. build-id is valid --2762-- Reading syms from
/usr/libexec/valgrind/memcheck-amd64-linux --2762--   Considering
/usr/lib/debug/.build-id/82/26c2aa6b808ebd5a6fafb694a7fb3287f33590.debug
.. --2762--   .. build-id is valid --2762--object doesn't have a
dynamic symbol table --2762-- Scheduler: using generic scheduler lock
implementation. --2762-- Reading suppressions file:
/usr/libexec/valgrind/default.supp ==2762== embedded gdbserver: reading
from /tmp/vgdb-pipe-from-vgdb-to-2762-by-user-on-??? ==2762== embedded
gdbserver: writing to   /tmp/vgdb-pipe-to-vgdb-from-2762-by-user-on-???
==2762== embedded gdbserver: shared mem
/tmp/vgdb-pipe-shared-mem-vgdb-2762-by-user-on-??? ==2762== ==2762== TO
CONTROL THIS PROCESS USING vgdb (which you probably ==2762== don't want
to do, unless you know exactly what you're doing, ==2762== or are doing
some strange experiment): ==2762==   /usr/bin/vgdb --pid=2762
...command... ==2762== ==2762== TO DEBUG THIS PROCESS USING GDB: start
GDB like this ==2762==   /path/to/gdb /bin/bash ==2762== and then give
GDB the following command ==2762==   target remote | /usr/bin/vgdb
--pid=2762 ==2762== --pid is optional if only one valgrind process is
running ==2762== 
--2762-- REDIR: 0x40238e0 (ld-linux-x86-64.so.2:strlen) redirected to
0x580bb0e2 (vgPlain_amd64_linux_REDIR_FOR_strlen) --2762-- REDIR:
0x40220c0 (ld-linux-x86-64.so.2:index) redirected to 0x580bb0fc
(vgPlain_amd64_linux_REDIR_FOR_index) --2762-- Reading syms from
/usr/libexec/valgrind/vgpreload_core-amd64-linux.so --2762--
Considering
/usr/lib/debug/.build-id/ad/f1388be4d8781737b0c83fe111a5a9c6e930aa.debug
.. --2762--   .. build-id is valid --2762-- Reading syms from
/usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so --2762--
Considering
/usr/lib/debug/.build-id/d8/ec66cffcb23a75c3f15940674d6028709121f8.debug
.. --2762--   .. build-id is valid ==2762== WARNING: new redirection
conflicts with existing -- ignoring it --2762-- old: 0x040238e0
(strlen  ) R-> (.0) 0x580bb0e2
vgPlain_amd64_linux_REDIR_FOR_strlen --2762-- new: 0x040238e0
(strlen  ) R-> (2007.0) 0x048468a0 strlen --2762-- REDIR:
0x40222e0 (ld-linux-x86-64.so.2:strcmp) redirected to 0x4847780
(strcmp) --2762-- REDIR: 0x4021550 (ld-linux-x86-64.so.2:mempcpy)
redirected to 0x484b1a0 (mempcpy) --2762-- Reading syms from
/usr/lib/x86_64-linux-gnu/libgtk3-nocsd.so.0 --2762--object doesn't
have a symbol table --2762-- Reading syms from
/lib/x86_64-linux-gnu/libtinfo.so.6.4 --2762--object doesn't have a
symbol table --2762-- Reading syms from /lib/x86_64-linux-gnu/libc.so.6
--2762--   Considering
/usr/lib/debug/.build-id/ee/3145ecaaff87a133daea77fbc3eecd458fa0d1.debug
.. --2762--   .. build-id is valid ==2762== WARNING: new redirection
conflicts with existing -- ignoring it --2762-- old: 0x0493b540
(memalign) R-> (1011.0) 0x04845bc0 memalign --2762--
new: 0x0493b540 (memalign) R-> (1017.0) 0x04845b90
aligned_alloc ==2762== WARNING: new redirection conflicts with existing
-- ignoring it --2762-- old: 0x0493b540 (memalign) R->
(1011.0) 0x04845bc0 memalign --2762-- new: 0x0493b540 (memalign
   ) R-> (1017.0) 0x04845b60 aligned_alloc --2762-- Reading syms
from /lib/x86_64-linux-gnu/libdl.so.2 --2762--   Considering
/usr/lib/debug/.build-id/53/eaa845e9ca621f159b0622daae7387cdea1e97.debug
.. --2762--   .. build-id is valid --2762-- Reading syms from
/lib/x86_64-linux-gnu/libpthread.so.0 --2762--   Considering
/usr/lib/debug/.build-id/26/820458adaf5d95718fb502d170fe374ae3ee70.debug
.. 

[bug #65670] Bash is not memory safe.

[anonymous]

URL:
  

 Summary: Bash is not memory safe.
   Group: The GNU Bourne-Again SHell
   Submitter: None
   Submitted: Wed 01 May 2024 11:39:28 PM UTC
Category: None
Severity: 3 - Normal
  Item Group: None
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any


___

Follow-up Comments:


---
Date: Wed 01 May 2024 11:39:28 PM UTC By: Anonymous
$ bash --version | head -n1
GNU bash, version 5.2.15(1)-release (x86_64-pc-linux-gnu)

$ valgrind --leak-check=full \
 --track-origins=yes \
 --verbose \
 --log-file=valgrind-out-bash.txt \
 /bin/bash



==2762== Memcheck, a memory error detector
==2762== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==2762== Using Valgrind-3.19.0-8d3c8034b8-20220411 and LibVEX; rerun with -h
for copyright info
==2762== Command: /bin/bash
==2762== Parent PID: 2251
==2762== 
--2762-- 
--2762-- Valgrind options:
--2762----leak-check=full
--2762----track-origins=yes
--2762----verbose
--2762----log-file=valgrind-out-bash.txt
--2762-- Contents of /proc/version:
--2762--   Linux version 6.1.0-20-amd64 (debian-ker...@lists.debian.org)
(gcc-12 (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1
SMP PREEMPT_DYNAMIC Debian 6.1.85-1 (2024-04-11)
--2762-- 
--2762-- Arch and hwcaps: AMD64, LittleEndian,
amd64-cx16-lzcnt-rdtscp-sse3-ssse3-avx-avx2-bmi-f16c-rdrand-rdseed
--2762-- Page sizes: currently 4096, max supported 4096
--2762-- Valgrind library directory: /usr/libexec/valgrind
--2762-- Reading syms from /bin/bash
--2762--object doesn't have a symbol table
--2762-- Reading syms from /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
--2762--   Considering
/usr/lib/debug/.build-id/80/8ccde0c755608358b0915a6615c19401fe6bf6.debug ..
--2762--   .. build-id is valid
--2762-- Reading syms from /usr/libexec/valgrind/memcheck-amd64-linux
--2762--   Considering
/usr/lib/debug/.build-id/82/26c2aa6b808ebd5a6fafb694a7fb3287f33590.debug ..
--2762--   .. build-id is valid
--2762--object doesn't have a dynamic symbol table
--2762-- Scheduler: using generic scheduler lock implementation.
--2762-- Reading suppressions file: /usr/libexec/valgrind/default.supp
==2762== embedded gdbserver: reading from
/tmp/vgdb-pipe-from-vgdb-to-2762-by-user-on-???
==2762== embedded gdbserver: writing to  
/tmp/vgdb-pipe-to-vgdb-from-2762-by-user-on-???
==2762== embedded gdbserver: shared mem  
/tmp/vgdb-pipe-shared-mem-vgdb-2762-by-user-on-???
==2762== 
==2762== TO CONTROL THIS PROCESS USING vgdb (which you probably
==2762== don't want to do, unless you know exactly what you're doing,
==2762== or are doing some strange experiment):
==2762==   /usr/bin/vgdb --pid=2762 ...command...
==2762== 
==2762== TO DEBUG THIS PROCESS USING GDB: start GDB like this
==2762==   /path/to/gdb /bin/bash
==2762== and then give GDB the following command
==2762==   target remote | /usr/bin/vgdb --pid=2762
==2762== --pid is optional if only one valgrind process is running
==2762== 
--2762-- REDIR: 0x40238e0 (ld-linux-x86-64.so.2:strlen) redirected to
0x580bb0e2 (vgPlain_amd64_linux_REDIR_FOR_strlen)
--2762-- REDIR: 0x40220c0 (ld-linux-x86-64.so.2:index) redirected to
0x580bb0fc (vgPlain_amd64_linux_REDIR_FOR_index)
--2762-- Reading syms from
/usr/libexec/valgrind/vgpreload_core-amd64-linux.so
--2762--   Considering
/usr/lib/debug/.build-id/ad/f1388be4d8781737b0c83fe111a5a9c6e930aa.debug ..
--2762--   .. build-id is valid
--2762-- Reading syms from
/usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so
--2762--   Considering
/usr/lib/debug/.build-id/d8/ec66cffcb23a75c3f15940674d6028709121f8.debug ..
--2762--   .. build-id is valid
==2762== WARNING: new redirection conflicts with existing -- ignoring it
--2762-- old: 0x040238e0 (strlen  ) R-> (.0) 0x580bb0e2
vgPlain_amd64_linux_REDIR_FOR_strlen
--2762-- new: 0x040238e0 (strlen  ) R-> (2007.0) 0x048468a0
strlen
--2762-- REDIR: 0x40222e0 (ld-linux-x86-64.so.2:strcmp) redirected to
0x4847780 (strcmp)
--2762-- REDIR: 0x4021550 (ld-linux-x86-64.so.2:mempcpy) redirected to
0x484b1a0 (mempcpy)
--2762-- Reading syms from /usr/lib/x86_64-linux-gnu/libgtk3-nocsd.so.0
--2762--object doesn't have a symbol table
--2762-- Reading syms from /lib/x86_64-linux-gnu/libtinfo.so.6.4
--2762--object doesn't have a symbol table
--2762-- Reading syms from /lib/x86_64-linux-gnu/libc.so.6
--2762--   Considering
/usr/lib/debug/.build-id/ee/3145ecaaff87a133daea77fbc3eecd458fa0d1.debug ..
--2762--   .. build-id is valid
==2762== WARNING: new redirection conflicts with existing -- ignoring it
--2762-- old: 0x0493b540 (memalign) R-> (1011.0) 0x04845bc0

Re: Bug#1069978: bash: incorrect value of $BASH for login shells

[Chet Ramey]

On 4/28/24 6:18 PM, Gioele Barabucci wrote:

On 28/04/24 22:50, Chet Ramey wrote:

On 4/28/24 3:07 PM, Gioele Barabucci wrote:

 $ su -l $USER -s /bin/bash-static -c 'echo $BASH; readlink 
/proc/$$/exe; head -1z /proc/$$/cmdline; echo'

 /bin/bash
 /usr/bin/bash-static
 -bash-static


So argv[0] == "-bash-static", which causes $0 to be set to -bash-static
and internally sets shell_name to "bash-static" and login_shell to 1
(which notes that bash was executed with argv[0][0] == '-').

Then when you get to setting $BASH, this code gets executed:

   if ((login_shell == 1) && RELPATH(shell_name))
 {
   if (current_user.shell == 0)
 get_current_user_info ();
   name = savestring (current_user.shell);
 }

which has been the way bash has behaved since the bash-1.x days. Is
this enough of an issue to change behavior that dates back that far?


The bash manual defines $BASH as follows:


Expands to the full filename used to invoke this instance of bash.

So, either the code or the manual should be changed.

I see why changing such an old behavior for the sake of correctness may not 
be worth the risk of breaking somebody's workflow. But at the same time it 
is hard to believe that anybody may be relying on "$BASH contains the user 
shell set up in /etc/passwd when read from a login shell".


I think the original intent of this code -- it was a very long time ago --
was that a login shell either came from login/getty/xterm or su. If it came
from su, the name in argv[0] was either "-su" (the traditional behavior of
`su -'/`su -l') or the user's login shell. The Linux-specific business of
specifying the shell to use didn't come along until much later. Non-Linux
systems still put "su"/"-su" in argv[0].

In that light, it's easy to see what's happening. You want to change "-su"
to something reasonable, and the user's login shell is what su always uses.
If it's already the login shell, no loss.

I think we can fix this Linux issue by checking for and changing "-su"/"su"
to the login shell and letting other pathnames through.

--
``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: Bug#1069978: bash: incorrect value of $BASH for login shells

[Gioele Barabucci]

On 28/04/24 22:50, Chet Ramey wrote:

On 4/28/24 3:07 PM, Gioele Barabucci wrote:

 $ su -l $USER -s /bin/bash-static -c 'echo $BASH; readlink 
/proc/$$/exe; head -1z /proc/$$/cmdline; echo'

 /bin/bash
 /usr/bin/bash-static
 -bash-static


So argv[0] == "-bash-static", which causes $0 to be set to -bash-static
and internally sets shell_name to "bash-static" and login_shell to 1
(which notes that bash was executed with argv[0][0] == '-').

Then when you get to setting $BASH, this code gets executed:

   if ((login_shell == 1) && RELPATH(shell_name))
     {
   if (current_user.shell == 0)
     get_current_user_info ();
   name = savestring (current_user.shell);
     }

which has been the way bash has behaved since the bash-1.x days. Is
this enough of an issue to change behavior that dates back that far?


The bash manual defines $BASH as follows:


Expands to the full filename used to invoke this instance of bash.

So, either the code or the manual should be changed.

I see why changing such an old behavior for the sake of correctness may 
not be worth the risk of breaking somebody's workflow. But at the same 
time it is hard to believe that anybody may be relying on "$BASH 
contains the user shell set up in /etc/passwd when read from a login shell".


In my case, I intended to use $BASH to make sure that the right binary 
was picked up by a certain test. I assume I'm not the only one using it 
in that way.


Regards,

--
Gioele Barabucci

Re: Bug#1069978: bash: incorrect value of $BASH for login shells

[Chet Ramey]

On 4/28/24 3:07 PM, Gioele Barabucci wrote:

     $ su -l $USER -s /bin/bash-static -c 'echo $BASH; readlink 
/proc/$$/exe; head -1z /proc/$$/cmdline; echo'

     /bin/bash
     /usr/bin/bash-static
     -bash-static


So argv[0] == "-bash-static", which causes $0 to be set to -bash-static
and internally sets shell_name to "bash-static" and login_shell to 1
(which notes that bash was executed with argv[0][0] == '-').

Then when you get to setting $BASH, this code gets executed:

  if ((login_shell == 1) && RELPATH(shell_name))
{
  if (current_user.shell == 0)
get_current_user_info ();
  name = savestring (current_user.shell);
}

which has been the way bash has behaved since the bash-1.x days. Is
this enough of an issue to change behavior that dates back that far?

--
``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: Bug#1069978: bash: incorrect value of $BASH for login shells

[Gioele Barabucci]

On 28/04/24 20:01, Chet Ramey wrote:

On 4/27/24 6:23 PM, Gioele Barabucci wrote:
bash 5.0 and 5.2 do not set $BASH to the right value when bash is used 
as the login shell:


 $ apt install bash-static
 $ getent passwd $USER | cut -d: -f 7
 /bin/bash

 $ su $USER -s /bin/bash-static -c 'echo $BASH; readlink 
/proc/$$/exe; true'

 /usr/bin/bash-static
 /usr/bin/bash-static

 $ su -l $USER -s /bin/bash-static -c 'echo $BASH; readlink 
/proc/$$/exe; true'

 /bin/bash
 /usr/bin/bash-static

(bash-static is not a link to bash)


What does `su' pass to bash in argv[0]?



$ su $USER -s /bin/bash-static -c 'echo $BASH; readlink 
/proc/$$/exe; head -1z /proc/$$/cmdline; echo'

/usr/bin/bash-static
/usr/bin/bash-static
bash-static

$ su -l $USER -s /bin/bash-static -c 'echo $BASH; readlink 
/proc/$$/exe; head -1z /proc/$$/cmdline; echo'

/bin/bash
/usr/bin/bash-static
-bash-static

Regards,

--
Gioele Barabucci

Re: [bug #65651] argument reference inconsistency

[Chet Ramey]

On 4/28/24 1:10 PM, Lawrence Velázquez wrote:

On Sun, Apr 28, 2024, at 7:59 AM, Emanuele Torre wrote:

I don't know why this savannah ticket has been crossposted to @bug-bash,
but its replies have not been crossposted here: it is very confusing.


Apparently it's not possible to have the replies crossposted:

https://savannah.gnu.org/support/?111046


Anyway, they already got a response on savannah.


OP can't be reached from here anyway, since they were not added to
the CC list.


The OP is anonymous.

--
``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: [bug #65651] argument reference inconsistency

[Chet Ramey]

On 4/28/24 7:59 AM, Emanuele Torre wrote:

I don't know why this savannah ticket has been crossposted to @bug-bash,
but its replies have not been crossposted here: it is very confusing.


Because savannah can't do that.

The original request was to have one place to go to for bug reports. The
best you can do is to have savannah send `notifications' to bug-bash when
an issue is opened. It's not bugzilla; there's no facility to send email
and have it added to an issue as a comment, and follow-up comments on
savannah don't generate notifications.

--
``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: [bug #65651] argument reference inconsistency

[Lawrence Velázquez]

On Sun, Apr 28, 2024, at 7:59 AM, Emanuele Torre wrote:
> I don't know why this savannah ticket has been crossposted to @bug-bash,
> but its replies have not been crossposted here: it is very confusing.

Apparently it's not possible to have the replies crossposted:

https://savannah.gnu.org/support/?111046

> Anyway, they already got a response on savannah.

OP can't be reached from here anyway, since they were not added to
the CC list.

-- 
vq

Re: [bug #65651] argument reference inconsistency

[alex xmb sw ratchev]

On Sun, Apr 28, 2024, 13:59 Emanuele Torre  wrote:

> I don't know why this savannah ticket has been crossposted to @bug-bash,
> but its replies have not been crossposted here: it is very confusing.
>

cool , thanks ... btw got me the link ? thxx && bless

Anyway, they already got a response on savannah.
>
> o/
>  emanuele6
>

Re: [bug #65651] argument reference inconsistency

[Emanuele Torre]

I don't know why this savannah ticket has been crossposted to @bug-bash,
but its replies have not been crossposted here: it is very confusing.

Anyway, they already got a response on savannah.

o/
 emanuele6

Re: [bug #65651] argument reference inconsistency

[alex xmb sw ratchev]

On Sun, Apr 28, 2024, 08:52 anonymous  wrote:

> URL:
>   
>
>  Summary: argument reference inconsistency
>Group: The GNU Bourne-Again SHell
>Submitter: None
>Submitted: Sun 28 Apr 2024 06:51:44 AM UTC
> Category: None
> Severity: 3 - Normal
>   Item Group: None
>   Status: None
>  Privacy: Public
>  Assigned to: None
>  Open/Closed: Open
>  Discussion Lock: Any
>
>
> ___
>
> Follow-up Comments:
>
>
> ---
> Date: Sun 28 Apr 2024 06:51:44 AM UTC By: Anonymous
> Try the following script w/ various sets of arguments and tell me if you
> see
> something weird!
>
> #!/bin/bash
> echo "script has $# arguments"
> echo "cmdline \$* = $*"
> echo "first 3 args: [$1] [$2] [$3]"
>
> for a in $*
> do
>echo "arg: $a"
> done
>

did u mean ${!a}
or for a ; or for a in "$@"

Argument set:
> A)   alpha beta gamma
> B)   "alpha" "beta" "gamma"
> C)   "alp ha" "be ta" "gam ma"
>
>
>
>
>
>
>
> ___
>
> Reply to this item at:
>
>   
>
> ___
> Message sent via Savannah
> https://savannah.gnu.org/
>
>
>

[bug #65651] argument reference inconsistency

[anonymous]

URL:
  

 Summary: argument reference inconsistency
   Group: The GNU Bourne-Again SHell
   Submitter: None
   Submitted: Sun 28 Apr 2024 06:51:44 AM UTC
Category: None
Severity: 3 - Normal
  Item Group: None
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any


___

Follow-up Comments:


---
Date: Sun 28 Apr 2024 06:51:44 AM UTC By: Anonymous
Try the following script w/ various sets of arguments and tell me if you see
something weird!

#!/bin/bash
echo "script has $# arguments"
echo "cmdline \$* = $*"
echo "first 3 args: [$1] [$2] [$3]"

for a in $*
do
   echo "arg: $a"
done

Argument set:
A)   alpha beta gamma
B)   "alpha" "beta" "gamma"
C)   "alp ha" "be ta" "gam ma"







___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

Bug#1069978: bash: incorrect value of $BASH for login shells

[Gioele Barabucci]

Package: bash
Version: 5.2.21-2
X-Debbugs-CC: bug-bash@gnu.org

Hi,

bash 5.0 and 5.2 do not set $BASH to the right value when bash is used 
as the login shell:


$ apt install bash-static
$ getent passwd $USER | cut -d: -f 7
/bin/bash

$ su $USER -s /bin/bash-static -c 'echo $BASH; readlink 
/proc/$$/exe; true'

/usr/bin/bash-static
/usr/bin/bash-static

$ su -l $USER -s /bin/bash-static -c 'echo $BASH; readlink 
/proc/$$/exe; true'

/bin/bash
/usr/bin/bash-static

(bash-static is not a link to bash)

Bash also uses the value in /etc/passwd when in login mode, although the 
documentation says


> BASH   Expands to the full filename used to invoke this instance of bash.

"full filename" could be interpreted both as "an absolute filename" as 
well as "the canonical absolute path".


$ su $USER -s /bin/bash -c 'echo $BASH; readlink /proc/$$/exe; true'
/usr/bin/bash
/usr/bin/bash

$ su -l $USER -s /bin/bash -c 'echo $BASH; readlink /proc/$$/exe; true'
/bin/bash
/usr/bin/bash

Regards,

--
Gioele Barabucci

[bug #65638] Make error: two or more data types in declaration specifiers

[anonymous]

URL:
  

 Summary: Make error: two or more data types in declaration
specifiers
   Group: The GNU Bourne-Again SHell
   Submitter: None
   Submitted: Wed 24 Apr 2024 07:32:32 PM UTC
Category: None
Severity: 3 - Normal
  Item Group: None
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any


___

Follow-up Comments:


---
Date: Wed 24 Apr 2024 07:32:32 PM UTC By: Anonymous
When attempting to compile BASH 5.2.21, after running the following configure
command (on ArchLinux):

./configure --host=i686-w64-mingw32 --disable-win32-registry --disable-rpath
--enable-threads=windows

When I run make I get the following error (followed by other similar errors):

In file included from ./mksyntax.c:23:
./config.h:328:15: error: two or more data types in declaration specifiers
  328 | #define u_int unsigned int









___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

Bug#973620: bash: overflow on integer variables greater than 9223372036854775807

[Gioele Barabucci]

Control: found -1 5.2.21-2
Control: tags -1 upstream
X-Debbugs-CC: bug-bash@gnu.org

On Mon, 2 Nov 2020 16:46:14 +0100 Antonio  wrote:

Dear Maintainer,
recently while I was running some tests, I ran into this strange overflow:

$ declare -i n=9223372036854775800; for((i=0; i<15; ++i)); do echo "$i -> $n";
n+=1; done

0 -> 9223372036854775800
1 -> 9223372036854775801
2 -> 9223372036854775802
3 -> 9223372036854775803
4 -> 9223372036854775804
5 -> 9223372036854775805
6 -> 9223372036854775806
7 -> 9223372036854775807
8 -> -9223372036854775808
9 -> -9223372036854775807
10 -> -9223372036854775806
11 -> -9223372036854775805
12 -> -9223372036854775804
13 -> -9223372036854775803
14 -> -9223372036854775802

The integer handled by bash is obviously very large, but I believe
that in the event of an overflow it would be better to reset the
variable and issue an error flow warning, rather than remain silent.


Bash 5.2.21 is affected by this issue:

$ declare -i n=$((2**63 - 2))
$ for i in {1..4}; do echo "$i -> $n"; n+=1; done
1 -> 9223372036854775806
2 -> 9223372036854775807
3 -> -9223372036854775808
4 -> -9223372036854775807

$ declare -i n=36893488147419103234; echo $?
0
$ echo $n
2

Would it be possible to detect this overflow (or non-representable 
numbers, like in the second case) and warn about it?


Regards,

--
Gioele Barabucci

Bug#306043: bash executable completion doesn't work if there is a space in the executable path

[Gioele Barabucci]

Control: found -1 5.2.21-2
Control: tags -1 upstream
X-Debbugs-CC: bug-bash@gnu.org

On Sat, 23 Apr 2005 15:20:19 -0700 Frederik Eaton  wrote:

Bash executable completion doesn't work if there is a space in the
executable path.


This issue is still partially present in current version of Bash.

The most basic case has been fixed:

$ touch "cmd with spaces"
$ chmod +x "cmd with spaces"
$ PATH=$PWD:$PATH
$ cmd
$ cmd\ with\ spaces

However there seems to be a linger issue that appears when multiple 
commands with spaces match a given prefix:


$ touch "myfoo "{a,b,c}" command"
$ chmod +x "myfoo "{a,b,c}" command"
$ ls myfo*
'myfoo a command'  'myfoo b command'  'myfoo c command'
$ PATH=$PWD:$PATH
$ myf
$ myfoo\ 
$ myfoo\

No suggestions are shown after the double tab. Instead, double tabbing 
should show all available commands matching the "myfoo " prefix:


$ myfoo\ 
myfoo a command  myfoo b command  myfoo c command

Regards,

--
Gioele Barabucci

Re: Bug tracking

[Chet Ramey]

On 4/1/24 5:30 AM, Koichi Murase wrote:


Perhaps bug tracking could be migrated to a more modern system?


I think a more realistic solution for GNU is to improve Savane, which
is also an open-source project:
https://savannah.nongnu.org/projects/administration/


That is a GNU project decision, and needs people to work on 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: Bug tracking

[Chet Ramey]

On 3/31/24 8:34 PM, Martin D Kealey wrote:


On Mon, 11 Dec 2023, 05:19 Chet Ramey, <mailto:chet.ra...@case.edu>> wrote:


On 11/30/23 5:18 AM, Martin D Kealey wrote:

 > If there's a bug tracking system beyond "threads in a mailing list",
I'd
 > like to know how I can get access to it.

https://savannah.gnu.org/support/?group=bash
<https://savannah.gnu.org/support/?group=bash>


That's a good start, but it seems incomplete, and there's little -- perhaps 
no -- overlap with bug reports in this list.


Has bashbug always sent email to bug-bash@gnu.org 
<mailto:bug-bash@gnu.org>, or was it previously fed into Savannah?


bashbug long predates savannah.



Savannah seems too simplistic, as it ignores what happens after code is 
written, and fails to distinguish other important steps. (Among other 
things: it lacks a field for "intended release" and lacks numerous status 
options including "awaiting design review", "awaiting code review", "ready 
for release", & "release scheduled"; there's no link between bug reports 
and the source repo (so management of pull requests); and it doesn't have 
any form of continuous testing or integration.) And of course, it's 
disconnected from this mailing list.


If you have suggestions for the savannah maintainers, I'm sure they would
be receptive.



Perhaps bug tracking could be migrated to a more modern system? I know that 
(for good reason) GNU projects won't use proprietary services like 
Bitbucket or Github, but perhaps Bugtraq or Gitlab would be acceptable, or 
maybe some other project management tool?


That's a GNU community decision. GNU projects use GNU tools.



Aside from the shortcomings of Savannah itself, I'm concerned that bug 
reports in Savannah can only be assigned to three people, two of whom have 
been inactive for years. (I'm guessing they're the same people who can 
update bugs.) Are we building a cathedral with gatekeepers, or a bazaar 
where the masses can contribute?


What about savannah is keeping the masses from contributing? If you want to
work on a bug, work on 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: Bug tracking

[Koichi Murase]

2024年4月1日(月) 9:35 Martin D Kealey :
> On Mon, 11 Dec 2023, 05:19 Chet Ramey,  wrote:
> > On 11/30/23 5:18 AM, Martin D Kealey wrote:
> > > If there's a bug tracking system beyond "threads in a mailing list", I'd
> > > like to know how I can get access to it.
> >
> > https://savannah.gnu.org/support/?group=bash
>
> That's a good start, but it seems incomplete, and there's little -- perhaps
> no -- overlap with bug reports in this list.
>
> Has bashbug always sent email to bug-bash@gnu.org, or was it previously fed
> into Savannah?

I have been also wondering how to subscribe to the bug-tracking system
of Bash on Savannah (through e-mail notifications, etc.). I created an
account on savannah.gnu.org in the past but could not find a way.

> Perhaps bug tracking could be migrated to a more modern system?

I think a more realistic solution for GNU is to improve Savane, which
is also an open-source project:
https://savannah.nongnu.org/projects/administration/

Re: Bug tracking

[Oğuz]

On Monday, April 1, 2024, Martin D Kealey  wrote:

> On Mon, 11 Dec 2023, 05:19 Chet Ramey,  wrote:
>  Are we building a cathedral with gatekeepers, or a bazaar
> where the masses can contribute?
>

What's stopping masses from contributing now? All you need is an email
address.

And why this non-stop nagging? If you want maintainership ask for it, or is
your plan boring us all to death first?


-- 
Oğuz

Bug tracking

[Martin D Kealey]

On Mon, 11 Dec 2023, 05:19 Chet Ramey,  wrote:

> On 11/30/23 5:18 AM, Martin D Kealey wrote:
>
> > If there's a bug tracking system beyond "threads in a mailing list", I'd
> > like to know how I can get access to it.
>
> https://savannah.gnu.org/support/?group=bash


That's a good start, but it seems incomplete, and there's little -- perhaps
no -- overlap with bug reports in this list.

Has bashbug always sent email to bug-bash@gnu.org, or was it previously fed
into Savannah?

Savannah seems too simplistic, as it ignores what happens after code is
written, and fails to distinguish other important steps. (Among other
things: it lacks a field for "intended release" and lacks numerous status
options including "awaiting design review", "awaiting code review", "ready
for release", & "release scheduled"; there's no link between bug reports
and the source repo (so management of pull requests); and it doesn't have
any form of continuous testing or integration.) And of course, it's
disconnected from this mailing list.

Perhaps bug tracking could be migrated to a more modern system? I know that
(for good reason) GNU projects won't use proprietary services like
Bitbucket or Github, but perhaps Bugtraq or Gitlab would be acceptable, or
maybe some other project management tool?

Aside from the shortcomings of Savannah itself, I'm concerned that bug
reports in Savannah can only be assigned to three people, two of whom have
been inactive for years. (I'm guessing they're the same people who can
update bugs.) Are we building a cathedral with gatekeepers, or a bazaar
where the masses can contribute?

-Martin

PS: bashbug announces «Bashbug is used to send mail to the Bash
maintainers», and then addresses the message to *this* mailing list. I read
that as "this list is only for maintainers". (And yes, I distinguish
between subscribers, who receive messages from the list, and submitters,
who send messages to the list.)

Somewhere along the line this list has ceased to fulfil that role, instead
becoming an informal bash testers list, while the actual
bash-test...@cwru.edu list doesn't rate a mention here, and moreover
attempting to subscribe by sending to bash-testers-requ...@cwru.edu bounces
(550 5.1.1 User unknown). If the testers list is elsewhere, bashbug needs
updating.

Debian bug #929178: wrong trap displayed inside functions

[Oğuz]

On Tuesday, March 26, 2024, Martin D Kealey  wrote:
>
> When forwarding incoming HTML to a text-only list, most mailing list
> servers will put the hyperlinks in a footnote, so that that long links
> won't obscure the text they apply to. (The better ones only do this when
> text text and its hyperlink differ; if the text and its hyperlink match
> (like when you have XX for any XX) then nothing is gained
> by duplicating it. That would appear to be the case with this mailing
> list.)
>
> Some mail receivers (e.g. Gmail) will convert bare text that looks like a
> hyperlink back into a hyperlink, which is how you get clickable links in
> the footnote.
>

They don't actually type those brackets then. Thanks


-- 
Oğuz

Re: Debian bug #929178: wrong trap displayed inside functions

[Martin D Kealey]

On Tue, 26 Mar 2024 at 04:05, Oğuz  wrote:

> On Mon, Mar 25, 2024 at 8:38 PM G. Branden Robinson
>  wrote:
> > [1]
> > [1] http...
>
> I keep seeing this. Why don't you guys just paste the link?
>

When forwarding incoming HTML to a text-only list, most mailing list
servers will put the hyperlinks in a footnote, so that that long links
won't obscure the text they apply to. (The better ones only do this when
text text and its hyperlink differ; if the text and its hyperlink match
(like when you have XX for any XX) then nothing is gained
by duplicating it. That would appear to be the case with this mailing list.)

Some mail receivers (e.g. Gmail) will convert bare text that looks like a
hyperlink back into a hyperlink, which is how you get clickable links in
the footnote.

-Martin

Re: Debian bug #929178: wrong trap displayed inside functions

[Chet Ramey]

On 3/25/24 3:47 PM, Gioele Barabucci wrote:

On 25/03/24 18:13, Oğuz wrote:
On Mon, Mar 25, 2024 at 7:18 PM Gioele Barabucci > wrote:
 > Just for reference, neither dash nor busybox sh preserve the caller's 
trap:


I don't know why you think they are relevant.


Because they are two very commonly used /bin/sh, and thus important when it 
comes to understanding what the current consensus among implementers is?


There are varying implementations, and POSIX allows them all.

You can behave like bash, the NetBSD sh and yash, and preserve the trap
strings in the child until it changes them. You can behave like dash and
mksh, and kill the trap strings immediately upon starting the subshell.
Or you can behave in a hybrid fashion, like the FreeBSD sh, and check for
a subshell where the only command is trap, and preserve the trap strings
only in that case.

This is kind of like subshells keeping the jobs list around just long
enough to make j=$(jobs) 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: Debian bug #929178: wrong trap displayed inside functions

[Chet Ramey]

On 3/25/24 11:45 AM, Gioele Barabucci wrote:
Hi, I'm forwarding a minor issue originally reported in 
.


If a function does not set a trap, `trap` will output the command set by 
the caller. This is just a cosmetic issue, the right trap will be run at 
runtime.


POSIX allows this behavior:

"When a subshell is entered, traps that are not being ignored shall be set
to the default actions, except in the case of a command substitution
containing only a single trap command, when the traps need not be altered.
Implementations may check for this case using only lexical analysis; for
example, if `trap` and $( trap -- ) do not alter the traps in the subshell,
cases such as assigning var=trap and then using $($var) may still alter
them. This does not imply that the trap command cannot be used within the
subshell to set new traps."

and bash implements it. Other shells that aim for POSIX conformance do as
well.


--
``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: Debian bug #929178: wrong trap displayed inside functions

[Gioele Barabucci]

On 25/03/24 18:13, Oğuz wrote:
On Mon, Mar 25, 2024 at 7:18 PM Gioele Barabucci > wrote:
 > Just for reference, neither dash nor busybox sh preserve the caller's 
trap:


I don't know why you think they are relevant.


Because they are two very commonly used /bin/sh, and thus important when 
it comes to understanding what the current consensus among implementers is?


For what is worth, also mksh behaves like dash and busybox sh.

--
Gioele Barabucci

Re: Debian bug #929178: wrong trap displayed inside functions

[G. Branden Robinson]

At 2024-03-25T21:05:02+0300, Oğuz wrote:
> On Mon, Mar 25, 2024 at 8:38 PM G. Branden Robinson
>  wrote:
> > [1]
> > [1] http...
> 
> I keep seeing this. Why don't you guys just paste the link?

I believe I am.

https://lists.gnu.org/archive/html/bug-bash/2024-03/msg00207.html

And if that gets munched too...

https:
lists.gnu.org
archive
html
bug-bash
2024-03
msg00207.html

Reconstruct with appropriately placed slashes.

Maybe your MUA or other email provider is, uh, "protecting" you.

(Granted, that link I shared earlier should be handled with lead-lined
gloves.  It's entirely _too_ safe for work.)

Regards,
Branden


signature.asc
Description: PGP signature

Re: Debian bug #929178: wrong trap displayed inside functions

[Oğuz]

On Mon, Mar 25, 2024 at 8:38 PM G. Branden Robinson
 wrote:
> [1]
> [1] http...

I keep seeing this. Why don't you guys just paste the link?

Re: Debian bug #929178: wrong trap displayed inside functions

[G. Branden Robinson]

At 2024-03-25T19:13:39+0200, Oğuz wrote:
> On Mon, Mar 25, 2024 at 7:18 PM Gioele Barabucci  wrote:
> > Just for reference, neither dash nor busybox sh preserve the
> > caller's trap:
> 
> I don't know why you think they are relevant. dash doesn't even support
> `x=$(trap)', which is mandated by POSIX to work;

It would seem to be relevant to its _maintainers_...

dash(1):

DESCRIPTION
 dash is the standard command interpreter for the system.  The
 current version of dash is in the process of being changed to
 conform with the POSIX 1003.2 and 1003.2a specifications for the
 shell.

Maybe they would accept patches for better conformance.

> and busybox sh is a bare-bones shell for small, embedded systems.

True, but if you want a shell for embedded systems with a real luster to
it, you've gotta grab Toybox, which, whatever its technical merits (or
lack thereof), glistens with 0BSD true freedom.  We can't be tying the
hands of America's entreprenurial innovators, like whoever's running
Google these days, with worries about liability for copyright
infrigement--not while they have intellectual property rights that they
vigorously safeguard from the chiseling proles, parasites one and all.

Remember, Big Business is America's most persecuted minority.[1]

Regards,
Branden

[1] https://courses.aynrand.org/works/americas-persecuted-minority-big-business/


signature.asc
Description: PGP signature

Debian bug #929178: wrong trap displayed inside functions

[Oğuz]

On Mon, Mar 25, 2024 at 7:18 PM Gioele Barabucci  wrote:
> Just for reference, neither dash nor busybox sh preserve the caller's
trap:

I don't know why you think they are relevant. dash doesn't even support
`x=$(trap)', which is mandated by POSIX to work; and busybox sh is a
bare-bones shell for small, embedded systems.


-- 
Oğuz

Re: Debian bug #929178: wrong trap displayed inside functions

[Gioele Barabucci]

On 25/03/24 17:12, Oğuz wrote:
On Monday, March 25, 2024, Gioele Barabucci > wrote:


If a function does not set a trap, `trap` will output the command
set by the caller. This is just a cosmetic issue, the right trap
will be run at runtime.


Doesn't POSIX allow this? How else do you propose we save the trap set 
for an event into a variable if `x=$(trap)' stops working?


Just for reference, neither dash nor busybox sh preserve the caller's trap:

trap in f1:
f1 output: <>
trap in f2 (initial):
trap in f2 (final):
f2 output: 
main

Regards,

--
Gioele Barabucci

Debian bug #929178: wrong trap displayed inside functions

[Oğuz]

On Monday, March 25, 2024, Gioele Barabucci  wrote:
>
> If a function does not set a trap, `trap` will output the command set by
> the caller. This is just a cosmetic issue, the right trap will be run at
> runtime.
>

Doesn't POSIX allow this? How else do you propose we save the trap set for
an event into a variable if `x=$(trap)' stops working?


-- 
Oğuz

Debian bug #929178: wrong trap displayed inside functions

[Gioele Barabucci]

Hi, I'm forwarding a minor issue originally reported in 
.


If a function does not set a trap, `trap` will output the command set by 
the caller. This is just a cosmetic issue, the right trap will be run at 
runtime.


To reproduce this issue:

#!/bin/bash

f1() { echo "trap in f1: $(trap)" >&2 ; }

f2() {
echo "trap in f2 (initial): $(trap)" >&2
trap "/bin/echo f2" EXIT
echo "trap in f2 (final): $(trap)" >&2
}

trap "/bin/echo main" EXIT

echo "f1 output: <$(f1)>"
echo "f2 output: <$(f2)>"

Output:

trap in f1: trap -- '/bin/echo main' EXIT
f1 output: <>
trap in f2 (initial): trap -- '/bin/echo main' EXIT
trap in f2 (final): trap -- '/bin/echo f2' EXIT
f2 output: 
main

Regards,

--
Gioele Barabucci

Re: Debian bug #822605: SIGPIPE not handled in "echo >", terminates shell

[Chet Ramey]

On 3/22/24 2:02 AM, Gioele Barabucci wrote:

For various reasons. First of all, because it confuses users (there are 
various bug reports in Debian for this specific issue).


More technically, because non-builtin commands are treated differently, 
for example /bin/echo (from <https://bugs.debian.org/423207>):


There's been a fair amount of (inconclusive) discussion on the POSIX
mailing list about this issue at various points, but not enough reason
to change the way bash has always behaved.


Dear Chet, thanks you for your reply. Do you have a link or two to these 
discussions that I can add to the Debian bug reports to explain why they 
will be marked as "wontfix"?


The one I can find looking quickly is 
https://www.austingroupbugs.net/view.php?id=789; that one lasted for years.


which is a discussion about `pipefail' but includes comments about setting
SIGPIPE to SIG_IGN with trap if you don't want it to affect the exit
status.

There was also a May, 2016 discussion, but I don't know where the austin-
group mail archives are kept. That one was inconclusive, but did note that
there are a number of pieces of state that can cause differing behavior
when a builtin is executed (e.g., resource limits).

If you want to insulate a script against this, there are various ways to
discover whether or not a utility is a builtin (e.g., type) and to make
sure you always run something external (e.g., full pathnames or enable
to disable the builtin).




For example, there is plenty of code that expects the shell to exit when
you hit it with, say, a SIGHUP while it's executing a builtin, or if you
hit a non-interactive shell with a SIGTERM during a builtin, because that's
how shells have always behaved.


I'd argue (but I assume it has already been done in the aforementioned 
discussions) that the SIGPIPE comes from a command being run in a pipeline 
provided by the user, while these other signals come from an "external" 
source (the user? other programs?).


There's no real difference. The shell gets a signal and either handles it
or does not. From the script's perspective, it doesn't matter what
originates 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: Debian bug #822605: SIGPIPE not handled in "echo >", terminates shell

[Gioele Barabucci]

On 21/03/24 22:54, Chet Ramey wrote:

On 3/21/24 1:43 PM, Gioele Barabucci wrote:

On 21/03/24 18:08, Oğuz wrote:
On Thu, Mar 21, 2024 at 7:13 PM Gioele Barabucci  
wrote:

Regardless of the reason for the SIGPIPE, the reporter expects the loop
to carry on indefinitely (`while true; ...`).


Then he should do `trap '' PIPE' before the loop.


it is incorrect that > SIGPIPE terminates the subshell.


Why?


For various reasons. First of all, because it confuses users (there 
are various bug reports in Debian for this specific issue).


More technically, because non-builtin commands are treated 
differently, for example /bin/echo (from 
<https://bugs.debian.org/423207>):


There's been a fair amount of (inconclusive) discussion on the POSIX
mailing list about this issue at various points, but not enough reason
to change the way bash has always behaved.


Dear Chet, thanks you for your reply. Do you have a link or two to these 
discussions that I can add to the Debian bug reports to explain why they 
will be marked as "wontfix"?



For example, there is plenty of code that expects the shell to exit when
you hit it with, say, a SIGHUP while it's executing a builtin, or if you
hit a non-interactive shell with a SIGTERM during a builtin, because that's
how shells have always behaved.


I'd argue (but I assume it has already been done in the aforementioned 
discussions) that the SIGPIPE comes from a command being run in a 
pipeline provided by the user, while these other signals come from an 
"external" source (the user? other programs?). So in this regard it 
makes sense to handle SIGPIPE differently (i.e., catching it).


Regards,

--
Gioele Barabucci

Re: Debian bug #822605: SIGPIPE not handled in "echo >", terminates shell

[Chet Ramey]

On 3/21/24 1:43 PM, Gioele Barabucci wrote:

On 21/03/24 18:08, Oğuz wrote:

On Thu, Mar 21, 2024 at 7:13 PM Gioele Barabucci  wrote:

Regardless of the reason for the SIGPIPE, the reporter expects the loop
to carry on indefinitely (`while true; ...`).


Then he should do `trap '' PIPE' before the loop.


it is incorrect that > SIGPIPE terminates the subshell.


Why?


For various reasons. First of all, because it confuses users (there are 
various bug reports in Debian for this specific issue).


More technically, because non-builtin commands are treated differently, for 
example /bin/echo (from <https://bugs.debian.org/423207>):


There's been a fair amount of (inconclusive) discussion on the POSIX
mailing list about this issue at various points, but not enough reason
to change the way bash has always behaved.

For example, there is plenty of code that expects the shell to exit when
you hit it with, say, a SIGHUP while it's executing a builtin, or if you
hit a non-interactive shell with a SIGTERM during a builtin, because that's
how shells have always behaved.

--
``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: Debian bug #822605: SIGPIPE not handled in "echo >", terminates shell

[Chet Ramey]

On 3/21/24 12:13 PM, Gioele Barabucci wrote:


When bash runs a builtin command without forking, it should install
a SIGPIPE handler that will cause that signal to abort the command
but not terminate the shell.
If this behavior is desired and not considered a bug, then the bash manual 
should describe it in the SIGNALS section.


It's described in the COMMAND EXECUTION section. The execution environment
for shell builtins and functions is the same as the shell environment: it
has none of the changes described in the "simple command other than a
builtin or shell function" execution environment. In particular, the signal
handlers and trapped signals are identical to the calling 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/



OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Debian bug #822605: SIGPIPE not handled in "echo >", terminates shell

[Gioele Barabucci]

On 21/03/24 18:08, Oğuz wrote:

On Thu, Mar 21, 2024 at 7:13 PM Gioele Barabucci  wrote:

Regardless of the reason for the SIGPIPE, the reporter expects the loop
to carry on indefinitely (`while true; ...`).


Then he should do `trap '' PIPE' before the loop.


it is incorrect that > SIGPIPE terminates the subshell.


Why?


For various reasons. First of all, because it confuses users (there are 
various bug reports in Debian for this specific issue).


More technically, because non-builtin commands are treated differently, 
for example /bin/echo (from <https://bugs.debian.org/423207>):


$ rm -f /tmp/f && mkfifo /tmp/f
$ true /tmp/f
$ bash -c 'exec >&3; exit 42'; echo $?
42
$ bash -c 'exec >&3; echo hi; exit 42'; echo $?
141
$ bash -c 'exec >&3; /bin/echo hi; exit 42'; echo $?
42

...and because under the right conditions it may seemingly randomly 
close the interactive shell of the user:


$ rm -f /tmp/f && mkfifo /tmp/f
$ true /tmp/f
$ exec >&3
$ echo
$ echo hi
* shell exits *

Regards,

--
Gioele Barabucci

Re: Debian bug #822605: SIGPIPE not handled in "echo >", terminates shell

[Oğuz]

On Thu, Mar 21, 2024 at 7:13 PM Gioele Barabucci  wrote:
> The command in the first shell will exit after a random number of
> iterations with "terminated with exit status 141".

That's what every other shell does.

> Regardless of the reason for the SIGPIPE, the reporter expects the loop
> to carry on indefinitely (`while true; ...`).

Then he should do `trap '' PIPE' before the loop.

> > it is incorrect that > SIGPIPE terminates the subshell.

Why?

Debian bug #822605: SIGPIPE not handled in "echo >", terminates shell

[Gioele Barabucci]

Hi, I'm forwarding a bug report originally reported in 
<https://bugs.debian.org/822605>.


When a builtin function like echo fails to write to a named pipe, bash 
will receive a SIGPIPE that will terminate the whole shell.


To reproduce this issue:

In shell 1:

$ rm -f /tmp/f && mkfifo /tmp/f && \
(i=0; while true; do echo $((i=i+1)) > /tmp/f; done); \
echo "terminated with exit status $?"

In shell 2:

$ while true; do echo $(< /tmp/f); done

The command in the first shell will exit after a random number of 
iterations with "terminated with exit status 141".


The reason for the SIGPIPE is a race condition illustrated in [1].

Regardless of the reason for the SIGPIPE, the reporter expects the loop 
to carry on indefinitely (`while true; ...`).


One possible solution suggested in [1] is:


it is incorrect that > SIGPIPE terminates the subshell.

When bash runs a builtin command without forking, it should install
a SIGPIPE handler that will cause that signal to abort the command
but not terminate the shell.
If this behavior is desired and not considered a bug, then the bash 
manual should describe it in the SIGNALS section.


Regards,

[1] https://bugs.debian.org/822605#26

--
Gioele Barabucci

Re: Documentation Bug: ‘of’ should be ‘or’

[Chet Ramey]

On 3/17/24 1:24 AM, Abigail Read wrote:

As of
Reference Documentation for Bash Edition 5.2, for Bash Version 5.2.
September 2022

In 3.1.2.5 Locale-Specific Translation
Quoting from the first paragraph of this section:
If the current locale is C or POSIX, if there are no translations available, of 
if the string is not translated, the dollar sign is ignored.

This sentence should read:
If the current locale is C or POSIX, if there are no translations available, or 
if the string is not translated, the dollar sign is ignored.


Good catch, 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: Documentation Bug: ‘of’ should be ‘or’

[alex xmb sw ratchev]

+1

On Sun, Mar 17, 2024, 15:04 Abigail Read  wrote:

> As of
> Reference Documentation for Bash Edition 5.2, for Bash Version 5.2.
> September 2022
>
> In 3.1.2.5 Locale-Specific Translation
> Quoting from the first paragraph of this section:
> If the current locale is C or POSIX, if there are no translations
> available, of if the string is not translated, the dollar sign is ignored.
>
> This sentence should read:
> If the current locale is C or POSIX, if there are no translations
> available, or if the string is not translated, the dollar sign is ignored.

Documentation Bug: ‘of’ should be ‘or’

[Abigail Read]

As of 
Reference Documentation for Bash Edition 5.2, for Bash Version 5.2.
September 2022

In 3.1.2.5 Locale-Specific Translation
Quoting from the first paragraph of this section:
If the current locale is C or POSIX, if there are no translations available, of 
if the string is not translated, the dollar sign is ignored.

This sentence should read:
If the current locale is C or POSIX, if there are no translations available, or 
if the string is not translated, the dollar sign is ignored.

Re: Bug report for pretty-printing coprocesses with simple commands

[Chet Ramey]

On 2/27/24 7:25 PM, Seth Sabar wrote:

Hi,

I'd like to report a bug with the *--pretty-print* feature of bash. When I
run the following script:

*coproc sleep 5*

the pretty-printed result is

*coproc COPROC* sleep 5


Thanks for the report. This issue was fixed back in December as the
result of

https://lists.gnu.org/archive/html/bug-bash/2023-12/msg00047.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

Bug report for pretty-printing coprocesses with simple commands

[Seth Sabar]

Hi,

I'd like to report a bug with the *--pretty-print* feature of bash. When I
run the following script:

*coproc sleep 5*

the pretty-printed result is

*coproc COPROC* sleep 5

The reason this happens is because within Bash's AST every *coproc* is
given a name regardless of whether the user specifies one and the default
is *COPROC*. However, per the bash manual only *coproc*s followed
*compound-command*s may have names. I believe this issue can be fixed in
*make_command_string_internal* in the case handling *cm_coproc* there
should be different cases based on what type of *command* it contains.

I discovered this issue via *coproc.tests* in *bash-5.2/tests/*.

Best,
Seth

Re: Bug: Ligatures are removed as one character

[Chet Ramey]

On 2/25/24 5:37 AM, Martin D Kealey wrote:


Unicode has categories for "modifiers" (especially "modifier letters") and
for "combining characters". Note that each symbol can be in multiple
categories.

Modifiers change how another character is displayed. They may or may not be
considered to have their own separate semantic meaning. In the simple cases
they simply over-print an additional mark, but more complex adjustments are
possible. They don't normally change the overall size of the modified
character, so wcwidth(ch) will report zero.


Not quite, as I understand it in the sense Unicode uses them.

Unicode modifier characters are base characters in their own right, are
not combining characters, and do not change the graphical representation
of the base character they modify.

Combining marks are more or less as you describe: they may or may not have
a graphical representation; they may or may not, but usually do, change
the graphical representation of the base character they follow; they are
usually, but not always, zero-width. These are the characters you can
determine are combining characters by testing whether or not they are zero-
width.



What matters is that "combining characters" do not have stand-alone semantic
meaning; they should be erased along with the principal character. Accents
in European languages (and Thai) tend to be in this category.


This is how readline behaves, and the behavior the OP was reporting as
a bug.



To a first approximation, backspace should skip over the latter but not the
former. However if you've just removed a zero-width element, it would be
advisable to either re-render the whole line, or backspace over the last
full glyph, erase it, and re-render it with all its (remaining) modifiers.


If the difference between the old line and the new line is a zero-width
character, readline redisplays the base character, but the readline
character operations always skip over zero-width combining characters
and operate on the base character+combining characters.



On systems that need to dynamically load a shared library (linunicode.so?)
to support this, I suggest delaying doing so until it's needed -- after
setlocale("something.UTF-8") returns success, or some equivalent test. (I
hope there's a check that can be done against the already-loaded locale,
rather than inspecting the locale name as a string.)


The original report used C.UTF-8 as the locale; there's not a lot you can
tell from that about the semantic properties of characters.

--
``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: Bug: Ligatures are removed as one character

[Martin D Kealey]

n Fri, 23 Feb 2024, Chet Ramey wrote:
> On 2/19/24 9:26 PM, Avid Seeker wrote:
> > When pressing backspace on Arabic ligatures (including characters with
> > diacritics), they are removed as if they are one character.
>
> As you might guess, readline doesn't know much about Arabic, per se. In a
> UTF-8 locale, for example, it knows base characters and combining
> characters.
>
> The idea is simple: when moving backwards, move one multibyte character at
> a time, ignoring combining characters, until you get to a character for
> which wcwidth(x) > 0, and move point there. The algorithm for moving
> forward is similar.
>
> How should this be modified to support Arabic in a portable way?

Unicode has categories for "modifiers" (especially "modifier letters") and
for "combining characters". Note that each symbol can be in multiple
categories.

Modifiers change how another character is displayed. They may or may not be
considered to have their own separate semantic meaning. In the simple cases
they simply over-print an additional mark, but more complex adjustments are
possible. They don't normally change the overall size of the modified
character, so wcwidth(ch) will report zero.

What matters is that "combining characters" do not have stand-alone semantic
meaning; they should be erased along with the principal character. Accents
in European languages (and Thai) tend to be in this category.

To a first approximation, backspace should skip over the latter but not the
former. However if you've just removed a zero-width element, it would be
advisable to either re-render the whole line, or backspace over the last
full glyph, erase it, and re-render it with all its (remaining) modifiers.

https://stackoverflow.com/questions/54450823/what-is-the-difference-between-combining-characters-and-modifier-letters

On systems that need to dynamically load a shared library (linunicode.so?)
to support this, I suggest delaying doing so until it's needed -- after
setlocale("something.UTF-8") returns success, or some equivalent test. (I
hope there's a check that can be done against the already-loaded locale,
rather than inspecting the locale name as a string.)

-Martin

Re: Bug: Ligatures are removed as one character

[Chet Ramey]

On 2/19/24 9:26 PM, Avid Seeker wrote:

When pressing backspace on Arabic ligatures (including characters with
diacritics), they are removed as if they are one character.


As you might guess, readline doesn't know much about Arabic, per se. In a
UTF-8 locale, for example, it knows base characters and combining
characters.

The idea is simple: when moving backwards, move one multibyte character at
a time, ignoring combining characters, until you get to a character for
which wcwidth(x) > 0, and move point there. The algorithm for moving
forward is similar.

How should this be modified to support Arabic in a portable way?

--
``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: Bug: Ligatures are removed as one character

[Avid Seeker]

$ locale
LANG=C.UTF-8
LC_CTYPE="C.UTF-8"
LC_NUMERIC="C.UTF-8"
LC_TIME="C.UTF-8"
LC_COLLATE="C.UTF-8"
LC_MONETARY="C.UTF-8"
LC_MESSAGES="C.UTF-8"
LC_PAPER="C.UTF-8"
LC_NAME="C.UTF-8"
LC_ADDRESS="C.UTF-8"
LC_TELEPHONE="C.UTF-8"
LC_MEASUREMENT="C.UTF-8"
LC_IDENTIFICATION="C.UTF-8"
LC_ALL=

But it's the same behavior even if bash is launched with:
$ LANG=ar_EG.UTF-8 bash

On Wednesday, February 21st, 2024 at 16:23, Chet Ramey  
wrote:

> On 2/19/24 9:26 PM, Avid Seeker wrote:
> 
> > When pressing backspace on Arabic ligatures (including characters with
> > diacritics), they are removed as if they are one character.
> 
> 
> What's your locale? (Not that I guarantee having it installed.)
> 
> --
> `The lyf so short, the craft so long to lerne.'' - Chaucer` Ars longa, vita 
> brevis'' - Hippocrates
> Chet Ramey, UTech, CWRU c...@case.edu http://tiswww.cwru.edu/~chet/

Re: Bug: Ligatures are removed as one character

[Chet Ramey]

On 2/19/24 9:26 PM, Avid Seeker wrote:

When pressing backspace on Arabic ligatures (including characters with
diacritics), they are removed as if they are one character.


What's your locale? (Not that I guarantee having it installed.)

--
``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: Ligatures are removed as one character

[Martin D Kealey]

It's been a long time since I looked into Unicode, but this is what I
remember.

Depending on the Unicode normalisation level, backspace is *supposed* to
remove a letter and all its associated combining marks.

The root problem seems to be that some Arabic letters change from
"non-combining" to "combining" depending on the language in which they're
used. Unicode also has a problem distinguishing a combining letter (vowel
points in Arabic or Hebrew) from a combining diacritic (accents in Latin
script).

If you think that's a bug in Unicode, you're not alone; the Unicode
consortium has been struggling with this for at least ten years - see
https://unicode.org/L2/L2014/14109-inline-chars.pdf

There's been some progress; Unicode version 12 has at least admitted
there's a problem (https://www.unicode.org/versions/Unicode12.1.0/ch07.pdf
chapter 7.9 page 327).

I'll leave it to others to survey the current state of play with Unicode,
but historically it's been a mess.

-Martin


On Tue, 20 Feb 2024 at 12:26, Avid Seeker 
wrote:

> When pressing backspace on Arabic ligatures (including characters with
> diacritics), they are removed as if they are one character.
>
> Example:
>
> السَّلامُ
>
> Pressing 3 backspaces leaves the word at ال. It removed لا which is a
> ligature
> combining "ل" and "ا", and removed "م" with diacritics. Compare this with
> the
> behavior of zsh.
>
> For non-Arabic speakers, this is like typing: fi (U+0046 U+0049), but when
> pressing backspace it removed it as the character: fi (U+FB01).
>
>

Bug: Ligatures are removed as one character

[Avid Seeker]

When pressing backspace on Arabic ligatures (including characters with
diacritics), they are removed as if they are one character.

Example:

السَّلامُ

Pressing 3 backspaces leaves the word at ال. It removed لا which is a ligature
combining "ل" and "ا", and removed "م" with diacritics. Compare this with the
behavior of zsh.

For non-Arabic speakers, this is like typing: fi (U+0046 U+0049), but when
pressing backspace it removed it as the character: fi (U+FB01).

Re: possible bash bug bringing job. to foreground

[alex xmb sw ratchev]

On Sat, Feb 17, 2024, 20:54 Greg Wooledge  wrote:

> On Sat, Feb 17, 2024 at 07:41:43PM +, John Larew wrote:
> > After further examination, the examples with "fg $$" and "fg $!" clearly
> do not bring the subshell into the foreground, as they are evaluated prior
> to the subshells background execution.
> > I'm trying to bring the subshell to the foreground to perform an exit,
> after a delay.
> > Ultimately, it will be used as part of a terminal emulator inactivity
> timeout.
>
> Bash already has a TMOUT variable which will cause an interactive shell
> to exit after a specified length of inactivity.  Is that sufficient?
> If not, how does your desired solution need to differ from TMOUT?
>

i never heard of TMOUT before , too

>

Re: possible bash bug bringing job. to foreground

[John Larew]

I was unaware of TMOUT. Now I have a backup as well. Thanks for tolerating my 
inexperience.
 
 
  On Sat, Feb 17, 2024 at 2:54 PM, Greg Wooledge wrote:   On 
Sat, Feb 17, 2024 at 07:41:43PM +, John Larew wrote:
> After further examination, the examples with "fg $$" and "fg $!" clearly do 
> not bring the subshell into the foreground, as they are evaluated prior to 
> the subshells background execution.
> I'm trying to bring the subshell to the foreground to perform an exit, after 
> a delay.
> Ultimately, it will be used as part of a terminal emulator inactivity timeout.

Bash already has a TMOUT variable which will cause an interactive shell
to exit after a specified length of inactivity.  Is that sufficient?
If not, how does your desired solution need to differ from TMOUT?
  

Re: possible bash bug bringing job. to foreground

[Greg Wooledge]

On Sat, Feb 17, 2024 at 07:41:43PM +, John Larew wrote:
> After further examination, the examples with "fg $$" and "fg $!" clearly do 
> not bring the subshell into the foreground, as they are evaluated prior to 
> the subshells background execution.
> I'm trying to bring the subshell to the foreground to perform an exit, after 
> a delay.
> Ultimately, it will be used as part of a terminal emulator inactivity timeout.

Bash already has a TMOUT variable which will cause an interactive shell
to exit after a specified length of inactivity.  Is that sufficient?
If not, how does your desired solution need to differ from TMOUT?

Re: possible bash bug bringing job. to foreground

[John Larew]

After further examination, the examples with "fg $$" and "fg $!" clearly do not 
bring the subshell into the foreground, as they are evaluated prior to the 
subshells background execution.
I'm trying to bring the subshell to the foreground to perform an exit, after a 
delay.
Ultimately, it will be used as part of a terminal emulator inactivity timeout.
I suspected there are advantages to exiting the emulator vs. killing the 
process.
Clearly, I misunderstood. Thanks again.

Re: Possible bug Bash v5.22.6/5.1.16

[Chet Ramey]

On 2/17/24 6:40 AM, John Larew wrote:

This is a portion of a script that appears to be problematic. Each of these 
attempts appear to be valid; none of them work.
The issue is apparent with bash in both termux v0.118.0/5.22.6 and Ubuntu 
v22.04.3 LTS/5.1.16  (see attached).


The clue is in the error message (and its subsequent variants):

fg: current: no such job

which means that there are no background jobs in the execution environment
where `fg' is executed.

The background job in constructs like

( sleep 15s; set -m; fg %+; exit) &
( sleep 15s; set -m; fg %%; exit) &

is in the parent shell's execution environment; the subshell has no
background jobs of its own.

In constructs like

( sleep 15s; set -m; fg $$; exit) &
( sleep 15s; set -m; fg $!; exit) &

`fg' doesn't take PID arguments. (The reason you get the `current' in the
error message is that $! expands to nothing if there haven't been any
background jobs created, and `fg' without arguments defaults to the current
job.)

--
``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: possible bash bug bringing job. to foreground

[Greg Wooledge]

On Sat, Feb 17, 2024 at 01:30:00PM +, John Larew wrote:
> Repeat-By:  1: (sleep 15s; set -m; fg %%; exit ) & 2: (sleep 15s; set -m; fg 
> %+; exit ) & 

You're using %% or %+ inside a shell where there have NOT been any
background jobs created yet.  The sleep 15s runs in the foreground,
because it doesn't have a & after it.

> Fix: (sleep 15s; set -m; kill $PPID) &     Not a preferred solution; I prefer 
> a smaller hammer.

It's not clear to me what you're trying to do in the first examples.
Did you think that the subshell would somehow "take over" the terminal
and become the interactive shell, after the 15 second delay?  And what
would that achieve, if it worked?

In the "Fix" example, you're killing the main shell's parent, which
is most likely a terminal emulator.  Did you want to kill the main
shell instead of the terminal?  If so, you can get its PID with
the $$ variable.  Even inside a subshell, $$ always refers to the main
shell's PID.  If you want the subshell's PID, use BASHPID instead.

What exactly is it about the "Fix" example that you don't prefer?
What goal are you trying to achieve?

possible bash bug bringing job. to foreground

[John Larew]

Configuration Information [Automatically generated, do not change]:Machine: 
x86_64OS: linux-gnuCompiler: gccCompilation CFLAGS: -g -O2 -flto=auto 
-ffat-lto-objects -flto=auto -ffat-lto-objects -fstack-protector-strong 
-Wformat -Werror=format-security -Wall uname output: Linux 
HP-ProBook-6450b-500GB 5.15.133.1-microsoft-standard-WSL2 #1 SMP Thu Oct 5 
21:02:42 UTC 2023 x86_64 x86_64 x86_64 GNU/LinuxMachine Type: 
x86_64-pc-linux-gnu
Bash Version: 5.1Patch Level: 16Release Status: release
Description: This is an attempted portion of a larger script I am writing. All 
these attempts appear valid; none works.
 BTW, also fails on termux 0.118.0/bash v5.22.6 (HOSTTYPE=aarch64, 
MACHTYPE=aarch64-unknown-linux-android)
Repeat-By:  1: (sleep 15s; set -m; fg %%; exit ) & 2: (sleep 15s; set -m; fg 
%+; exit ) & 
Fix: (sleep 15s; set -m; kill $PPID) &     Not a preferred solution; I prefer a 
smaller hammer.

[PATCH 03/18] doc/bash.1: fix latent bug in `QN` macro

[G. Branden Robinson]

Whether it arises will depend on word placement and line length.

*roff has a simplistic notion of what a "word" is.

groff_man_style(7):
 ... The formatter troff(1) collects words from the input and fills
 output lines with as many as will fit.  Words are separated by
 spaces and newlines.  A transition to a new output line is called a
 break.  When formatted, a word may be broken at hyphens, at \% or
 \: escape sequences (see subsection “Portability” below), or at
 predetermined locations if automatic hyphenation is enabled (see
 the -rHY option in section “Options” below). ...

The input

.  if t \%``\%\\$1''\\$2

...tells the formatter that a hyphenation break is permitted after the
opening double quotation mark, like “‐
this”.  A hyphenation control escape sequence at the _beginning_ of a
word is treated specially.

groff_man_style(7):
 \%Control hyphenation.  The location of this escape
   sequence within a word marks a hyphenation point,
   supplementing groff’s automatic hyphenation patterns.  At
   the beginning of a word, it suppresses any hyphenation
   breaks within except those specified with \%.
---
 doc/bash.1 | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/doc/bash.1 b/doc/bash.1
index 1c495378..9562d830 100644
--- a/doc/bash.1
+++ b/doc/bash.1
@@ -41,7 +41,8 @@
 .\"
 .\" File Name macro.  This used to be `.PN', for Path Name,
 .\" but Sun doesn't seem to like that very much.
-.\" The \% is to prevent the filename from hyphenation.
+.\"
+.\" \% at the beginning of a word protects it from hyphenation.
 .\"
 .de FN
 \%\fI\|\\$1\|\fP
@@ -57,11 +58,12 @@
 .  if n "\\$1"\\$2
 .\}
 ..
+.\" As Q, but don't permit automatic hyphenation of contents.
 .de QN
 .ie \n(.g \%\(lq\\$1\(rq\\$2
 .el \{\
-.  if t \%``\%\\$1''\\$2
-.  if n \%"\%\\$1"\\$2
+.  if t \%``\\$1''\\$2
+.  if n \%"\\$1"\\$2
 .\}
 ..
 .SH NAME
-- 
2.30.2



signature.asc
Description: PGP signature

[PATCH 02/18] doc/bash.1: fix bug in new `Q` macro

[G. Branden Robinson]

I didn't pay close enough attention to Documenter's Workbench 3.3 troff
output when submitting the original version of this macro.  Add a
necessary backslash to escape the newline at the beginning of a
conditional block.  This omission was causing DWB to put a blank line on
the output every time it hit a "Q" macro call.  This did not delete any
text from the output, but it was surely ugly.

Diff of rendering (DWB):
- one with the highest index) is
-
- "main".  This variable exists only when a shell func-
- tion is executing.  Assignments to FUNCNAME have no
- effect.  If FUNCNAME is unset, it loses its special
- properties, even if it is subsequently reset.
+ one with the highest index) is "main".  This variable
+ exists only when a shell function is executing.
+ Assignments to FUNCNAME have no effect.  If FUNCNAME is
+ unset, it loses its special properties, even if it is
+ subsequently reset.
---
 doc/bash.1 | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/doc/bash.1 b/doc/bash.1
index b02e7527..1c495378 100644
--- a/doc/bash.1
+++ b/doc/bash.1
@@ -52,14 +52,14 @@
 .\"
 .de Q
 .ie \n(.g \(lq\\$1\(rq\\$2
-.el \{
+.el \{\
 .  if t ``\\$1''\\$2
 .  if n "\\$1"\\$2
 .\}
 ..
 .de QN
 .ie \n(.g \%\(lq\\$1\(rq\\$2
-.el \{
+.el \{\
 .  if t \%``\%\\$1''\\$2
 .  if n \%"\%\\$1"\\$2
 .\}
-- 
2.30.2



signature.asc
Description: PGP signature

Re: BUG: Here-doc delimiter: unclosed quotes

[Chet Ramey]

On 1/18/24 9:16 AM, Dastan Abdygali wrote:


Bash Version: 5.2
Patch Level: 0
Release Status: release

Description:
 If unclosed single quotes or unclosed double quotes are used as a
delimiter in here-doc, bash lets the user finish the quote on
 the next lines. As a result delimiter contains \newline character.
Which even if pasted does not trigger the
 here-doc to be concluded.


A here-document delimiter containing a newline can never work: the
delimiter has to appear on a line by itself, immediately followed by a
newline, to be recognized. Some of the ash-based shells accept delimiters
with embedded newlines, but bash never has.

I've considered adding a warning for this or making it a fatal syntax
error like yash, but never done 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

BUG: Here-doc delimiter: unclosed quotes

[Dastan Abdygali]

Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: darwin19.6.0
Compiler: gcc
Compilation CFLAGS: -g -O2
uname output: Darwin lab1r2s10.42abudhabi.ae 19.6.0 Darwin Kernel Version
19.6.0: Thu Oct 29 22:56:45 PDT 2020; root:xnu-6153.$
Machine Type: x86_64-apple-darwin19.6.0

Bash Version: 5.2
Patch Level: 0
Release Status: release

Description:
If unclosed single quotes or unclosed double quotes are used as a
delimiter in here-doc, bash lets the user finish the quote on
the next lines. As a result delimiter contains \newline character.
Which even if pasted does not trigger the
here-doc to be concluded.

Repeat-By:
Just try the following command and try to execute:
cat <

Re: Bash Bug - Incorrect Printing of Escaped Characters

[Seth Sabar]

   Hi Grisha,

   I didn’t know to look there (I’m still pretty new to the Bash source).
   Thanks, this is exciting!

   Best,

   Seth

 On Jan 16, 2024, at 12:18 PM, Grisha Levit 
 wrote:

   
   On Tue, Jan 16, 2024, 11:01 Seth Sabar <[1]sethsa...@gmail.com> wrote:

 Are you planning on releasing a patch for this? If you'd like me to
 try to
 prepare a patch, I'd appreciate some guidance around the various
 dequote_... functions in subst.c. Thanks!

   Hi Seth,
   Chet has committed a fix for this in the devel branch here:
   [2]https://git.savannah.gnu.org/cgit/bash.git/commit/?h=devel=fa0b00
   29

References

   1. mailto:sethsa...@gmail.com
   2. https://git.savannah.gnu.org/cgit/bash.git/commit/?h=devel=fa0b0029

Re: [Bug][Bash Posix] Inquiry about Contributing to the Project

[Chet Ramey]

On 1/16/24 7:11 PM, Emre Ulusoy wrote:

Dear Bash Maintainers,

I hope this message finds you well. I am writing to inquire about the 
possibility of contributing to your project.

Recently, I discovered a potential bug in the 'bash --posix' terminal and I 
believe I have a fix that could resolve this issue. Before proceeding, I wanted 
to confirm if this is an open-source project where external contributions via 
pull requests are welcomed.


If you believe you have found a bug in bash, you are welcome to report it
right 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/

Re: [Bug][Bash Posix] Inquiry about Contributing to the Project

[Lawrence Velázquez]

On Tue, Jan 16, 2024, at 7:11 PM, Emre Ulusoy wrote:
> Recently, I discovered a potential bug in the 'bash --posix' terminal 
> and I believe I have a fix that could resolve this issue. Before 
> proceeding, I wanted to confirm if this is an open-source project where 
> external contributions via pull requests are welcomed.

Yes, contributions are welcome, although this project does not use
pull requests.

https://git.savannah.gnu.org/cgit/bash.git/tree/README?h=bash-5.2#n51

-- 
vq

[Bug][Bash Posix] Inquiry about Contributing to the Project

[Emre Ulusoy]

Dear Bash Maintainers,

I hope this message finds you well. I am writing to inquire about the 
possibility of contributing to your project.

Recently, I discovered a potential bug in the 'bash --posix' terminal and I 
believe I have a fix that could resolve this issue. Before proceeding, I wanted 
to confirm if this is an open-source project where external contributions via 
pull requests are welcomed.

I am eager to contribute to the improvement of this project and would 
appreciate any guidance you could provide on how to proceed.

Thank you for your time and consideration. I look forward to your response.

Best regards,
Emre ULUSOY
EPITA Student

Re: Bash Bug - Incorrect Printing of Escaped Characters

[Grisha Levit]

On Tue, Jan 16, 2024, 11:01 Seth Sabar  wrote:

> Are you planning on releasing a patch for this? If you'd like me to try to
> prepare a patch, I'd appreciate some guidance around the various
> dequote_... functions in subst.c. Thanks!
>

Hi Seth,
Chet has committed a fix for this in the devel branch here:
https://git.savannah.gnu.org/cgit/bash.git/commit/?h=devel=fa0b0029

>

Re: Bash Bug - Incorrect Printing of Escaped Characters

[Seth Sabar]

Are you planning on releasing a patch for this? If you'd like me to try to
prepare a patch, I'd appreciate some guidance around the various
dequote_... functions in subst.c. Thanks!

Best,
Seth

On Wed, Dec 27, 2023 at 1:03 PM Chet Ramey  wrote:

> On 12/25/23 5:00 PM, Seth Sabar wrote:
> > Hi all,
> >
> > I'm reaching out to report what I believe to be a bug with the
> > *--pretty-print* feature in bash-5.2. From what I can tell, Bash uses the
> > utf-8 character */001* as an escape character. However, when using the
> > pretty-print feature in Bash, this doesn't seem to be considered. So, for
> > example, in a bash script with character */001* the AST representation
> > will contain */001/001*, however, when it's printed via the pretty print
> > feature, this isn't un-escaped.
>
> Thanks for the report. This affects word lists, the word in a case
> command, and shell function names. The fix is to dequote those words when
> in pretty-printing mode. You could do that for the name in a select
> command, too, but that's an invalid identifier to begin with.
>
> 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-bash] Bash-5.2 Patch 22

[Chet Ramey]

On 1/16/24 10:09 AM, Dr. Werner Fink wrote:

On 2024/01/16 09:27:19 -0500, Chet Ramey wrote:

On 1/16/24 4:00 AM, Dr. Werner Fink wrote:


what is with the readline82-008, readline82-009, and readline82-010
patches?


What about them?


Should those be part also of trhe bash52 patches as well?


Bash-5.2 doesn't have prototypes either, so patch 8 doesn't really matter.
That will all get cleaned up in the next release. Patch 9 doesn't apply
since bash uses the directory rewrite hook and directory completion hook.
Patch 10 will be part of the next set of bash patches.

--
``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-bash] Bash-5.2 Patch 22

[Dr. Werner Fink]

On 2024/01/16 09:27:19 -0500, Chet Ramey wrote:
> On 1/16/24 4:00 AM, Dr. Werner Fink wrote:
> 
> > what is with the readline82-008, readline82-009, and readline82-010
> > patches?
> 
> What about them?

Should those be part also of trhe bash52 patches as well?

-- 
  "Having a smoking section in a restaurant is like having
  a peeing section in a swimming pool." -- Edward Burr


signature.asc
Description: PGP signature

Re: [bug-bash] Bash-5.2 Patch 22

[Chet Ramey]

On 1/16/24 4:00 AM, Dr. Werner Fink wrote:


what is with the readline82-008, readline82-009, and readline82-010
patches?


What about them?

--
``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-bash] Bash-5.2 Patch 22

[Dr. Werner Fink]

On 2024/01/14 13:34:06 -0500, Chet Ramey wrote:
>BASH PATCH REPORT
>=
> 
> Bash-Release: 5.2
> Patch-ID: bash52-022
> 
> Bug-Reported-by:  srobert...@peratonlabs.com
> Bug-Reference-ID:
> Bug-Reference-URL:
> https://lists.gnu.org/archive/html/bug-bash/2022-09/msg00049.html
> 
> Bug-Description:
> 
> It's possible for readline to try to zero out a line that's not null-
> terminated, leading to a memory fault.
> 
> Patch (apply with `patch -p0'):
> 
> *** ../bash-5.2-patched/lib/readline/display.c2022-04-05 
> 10:47:31.0 -0400
> --- lib/readline/display.c2022-12-13 13:11:22.0 -0500
> ***
> *** 2684,2692 
>   
> if (visible_line)
> ! {
> !   temp = visible_line;
> !   while (*temp)
> ! *temp++ = '\0';
> ! }
> rl_on_new_line ();
> forced_display++;
> --- 2735,2740 
>   
> if (visible_line)
> ! memset (visible_line, 0, line_size);
> ! 
> rl_on_new_line ();
> forced_display++;
> 
> *** ../bash-5.2/patchlevel.h  2020-06-22 14:51:03.0 -0400
> --- patchlevel.h  2020-10-01 11:01:28.0 -0400
> ***
> *** 26,30 
>  looks for to find the patch level (for the sccs version string). */
>   
> ! #define PATCHLEVEL 21
>   
>   #endif /* _PATCHLEVEL_H_ */
> --- 26,30 
>  looks for to find the patch level (for the sccs version string). */
>   
> ! #define PATCHLEVEL 22
>   
>   #endif /* _PATCHLEVEL_H_ */
> 

Hi,

what is with the readline82-008, readline82-009, and readline82-010
patches?

Werner

-- 
  "Having a smoking section in a restaurant is like having
  a peeing section in a swimming pool." -- Edward Burr


signature.asc
Description: PGP signature

Re: A possible bug?

[Chet Ramey]

On 12/27/23 4:33 PM, George R Goffe wrote:

Chet,

Thanks for your response.

Is this clone NOT a dev branch? I'm thinking you're saying that it is not.


It is not. The default (master) branch is for releases.


My objective in using the clone is to get as close to a "release" as possible... a beta 
branch(?) for daily use to identify possible bugs (experimental GCC, bash itself, other software 
that uses bash). Is there a "better" branch that I could use for this purpose?


http://git.savannah.gnu.org/cgit/bash.git/log/?h=devel

It may be enough for you to checkout the devel branch in your clone.

I appreciate people checking over the code in the devel branch.

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: A possible bug?

[George R Goffe]

Chet,

Thanks for your response.

Is this clone NOT a dev branch? I'm thinking you're saying that it is not.

My objective in using the clone is to get as close to a "release" as 
possible... a beta branch(?) for daily use to identify possible bugs 
(experimental GCC, bash itself, other software that uses bash). Is there a 
"better" branch that I could use for this purpose?

Best regards and "see you next year",

George...
 






On Wednesday, December 27, 2023 at 10:10:56 AM PST, Chet Ramey 
 wrote: 





On 12/26/23 1:06 PM, George R Goffe wrote:

> Hi,
> 
> I'm building bash with the bash at " git clone 
> https://git.savannah.gnu.org/git/bash.git; and am seeing the following 
> messages:
> 
> make depend
> bash ./support/mkdep -c gcc --  -DPROGRAM='"bash"' 


The make depend support is only intended for the devel branch; the releases
should have complete dependencies included. If they don't, it's a bug. The
idea is to have as few dependencies (no pun intended) in the releases as
possible. I suppose I could make the depend target conditional on the
release status, but I've never done it.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
        ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    c...@case.edu    http://tiswww.cwru.edu/~chet/

Re: A possible bug?

[Chet Ramey]

On 12/26/23 1:06 PM, George R Goffe wrote:

Hi,

I'm building bash with the bash at " git clone 
https://git.savannah.gnu.org/git/bash.git; and am seeing the following messages:

make depend
bash ./support/mkdep -c gcc --  -DPROGRAM='"bash"' 


The make depend support is only intended for the devel branch; the releases
should have complete dependencies included. If they don't, it's a bug. The
idea is to have as few dependencies (no pun intended) in the releases as
possible. I suppose I could make the depend target conditional on the
release status, but I've never done 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: Bash Bug - Incorrect Printing of Escaped Characters

[Chet Ramey]

On 12/25/23 5:00 PM, Seth Sabar wrote:

Hi all,

I'm reaching out to report what I believe to be a bug with the
*--pretty-print* feature in bash-5.2. From what I can tell, Bash uses the
utf-8 character */001* as an escape character. However, when using the
pretty-print feature in Bash, this doesn't seem to be considered. So, for
example, in a bash script with character */001* the AST representation
will contain */001/001*, however, when it's printed via the pretty print
feature, this isn't un-escaped.


Thanks for the report. This affects word lists, the word in a case
command, and shell function names. The fix is to dequote those words when
in pretty-printing mode. You could do that for the name in a select
command, too, but that's an invalid identifier to begin with.

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