[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

Re: A possible bug?

[Kerin Millar]

On Tue, 26 Dec 2023, at 6: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"' 
> -DCONF_HOSTTYPE='"x86_64"' -DCONF_OSTYPE='"linux-gnu"' 
> -DCONF_MACHTYPE='"x86_64-pc-linux-gnu"' -DCONF_VENDOR='"pc"' 
> -DLOCALEDIR='"/usr/lsd/Linux/share/locale"' -DPACKAGE='"bash"' -DSHELL 
> -DHAVE_CONFIG_H   -I.  -I. -I./include -I./lib -I./lib/intl 
> -I/tools/bash/bash/lib/intl   -g -O2 -Wno-parentheses 
> -Wno-format-security shell.c eval.c parse.y general.c make_cmd.c 
> print_cmd.c y.tab.c dispose_cmd.c execute_cmd.c variables.c  version.c 
> expr.c copy_cmd.c flags.c subst.c hashcmd.c hashlib.c mailcheck.c 
> test.c trap.c alias.c jobs.c nojobs.c  braces.c input.c bashhist.c 
> array.c arrayfunc.c assoc.c sig.c pathexp.c unwind_prot.c siglist.c 
> bashline.c bracecomp.c error.c list.c stringlib.c locale.c findcmd.c 
> redir.c pcomplete.c pcomplib.c syntax.c xmalloc.c
> bash: ./support/mkdep: No such file or directory
> make: *** [Makefile:978: depends] Error 127
>
>
>
> I do have a full log if you need/want it. I don't see mkdep anywhere in 
> the build tree. Is this a "bug" or a mistake on my part?

As far as I can tell, it exists only in the devel branch. However, mkdep should 
not be used - at least, not for GNU make. Which commands were issued on your 
part?

-- 
Kerin Millar

A possible bug?

[George R Goffe]

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"' -DCONF_HOSTTYPE='"x86_64"' 
-DCONF_OSTYPE='"linux-gnu"' -DCONF_MACHTYPE='"x86_64-pc-linux-gnu"' 
-DCONF_VENDOR='"pc"' -DLOCALEDIR='"/usr/lsd/Linux/share/locale"' 
-DPACKAGE='"bash"' -DSHELL -DHAVE_CONFIG_H   -I.  -I. -I./include -I./lib 
-I./lib/intl -I/tools/bash/bash/lib/intl   -g -O2 -Wno-parentheses 
-Wno-format-security shell.c eval.c parse.y general.c make_cmd.c print_cmd.c 
y.tab.c dispose_cmd.c execute_cmd.c variables.c  version.c expr.c copy_cmd.c 
flags.c subst.c hashcmd.c hashlib.c mailcheck.c test.c trap.c alias.c jobs.c 
nojobs.c  braces.c input.c bashhist.c array.c arrayfunc.c assoc.c sig.c 
pathexp.c unwind_prot.c siglist.c bashline.c bracecomp.c error.c list.c 
stringlib.c locale.c findcmd.c redir.c pcomplete.c pcomplib.c syntax.c xmalloc.c
bash: ./support/mkdep: No such file or directory
make: *** [Makefile:978: depends] Error 127



I do have a full log if you need/want it. I don't see mkdep anywhere in the 
build tree. Is this a "bug" or a mistake on my part?

Best regards and happy hollidays.

George...

Re: Bash Bug - Incorrect Printing of Escaped Characters

[Eric Pruitt]

On Mon, Dec 25, 2023 at 05:00:37PM -0500, Seth Sabar wrote:
> I'm reaching out to report what I believe to be a bug with the
> *--pretty-print* feature in bash-5.2.

Tangentially, this option doesn't seem to be documented outside of "bash
--help":

$ git clone https://git.savannah.gnu.org/git/bash.git
Cloning into 'bash'...
remote: Counting objects: 41221, done.
remote: Compressing objects: 100% (5024/5024), done.
remote: Total 41221 (delta 36225), reused 41045 (delta 36106)
Receiving objects: 100% (41221/41221), 259.98 MiB | 15.65 MiB/s, done.
Resolving deltas: 100% (36225/36225), done.
$ cd bash/doc/
doc$ fgrep -r pretty
texinfo.tex:% above.  But it's pretty close.
texinfo.tex:  % and a tt hyphen is pretty tiny.  @code also disables ?` !`.
doc$

Eric

Bash Bug - Incorrect Printing of Escaped Characters

[Seth Sabar]

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.

Steps to reproduce:

Download the following version of bash (this is the latest version of
bash-5.2 as of sending this email):
https://git.savannah.gnu.org/cgit/bash.git/commit/?id=4b0f8ba28449c60d6b3436d0c98b14e016b232c2

After extracting the tar file run the *configure* script and *make clean
all* as usual to prepare the bash executable.

Copy the attached *test.sh* into the bash directory.

Run the following command: ./bash --pretty-print test.sh > test2.sh
Then run: ./bash --pretty-print test2.sh > test3.sh

Observe the exponential growth of the escape character */001* in the bash
files.

I believe the following files in the *tests* directory in the bash source
directory may also be used to reproduce this issue:

case2.sub,
nquote3.sub,
dollar-star6.sub,
nquote5.sub,
exp6.sub,
exp7.sub,
quote4.sub,
cond-regexp1.sub,
iquote1.sub,
exp1.sub,
rhs-exp1.sub,
cond-regexp3.sub,
glob8.sub,
posixexp6.sub,
new-exp6.sub,
dollar-at-star10.sub,
dollar-at-star4.sub

Additional Information:

My computer: 2020 13-inch Macbook Pro on MacOS 14.1.2

However, I should note that I was able to reproduce this issue on Linux.

Thanks all and Merry Christmas,
Seth
var1=$'\001'

Re: Sv: TAB completion bug

[Chet Ramey]

On 12/10/23 7:23 PM, Ole Tange wrote:

*Fra:* Chet Ramey 

On 12/5/23 6:46 PM, Ole Tange via Bug reports for the GNU Bourne Again

SHell wrote:


  For the (admitedly weirdly named) dirs below TAB completion does not work 
correctly.



Thanks for the report. Where did you encounter these directory names?


Test purposes.


Fair enough.

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

Sv: TAB completion bug

[Ole Tange via Bug reports for the GNU Bourne Again SHell]

Fra: Chet Ramey 

>On 12/5/23 6:46 PM, Ole Tange via Bug reports for the GNU Bourne Again
SHell wrote:

>>  For the (admitedly weirdly named) dirs below TAB completion does not 
>> work correctly.

>Thanks for the report. Where did you encounter these directory names?

Test purposes.

GNU Parallel uses $TMPDIR, and had a bug where \n in $TMPDIR would cause it to 
fail.

To guard against bugs like that all testing is now done with $TMPDIR containing 
\n, `cmd` and other special shell chars.


/Ole

Re: TAB completion bug

[Chet Ramey]

On 12/5/23 6:46 PM, Ole Tange via Bug reports for the GNU Bourne Again 
SHell wrote:



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

Description:
 Tested on git (2023-12-06).

 For the (admitedly weirdly named) dirs below TAB completion does not work 
correctly.


Thanks for the report. Where did you encounter these directory names?


--
``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: TAB completion bug

[Chet Ramey]

On 12/6/23 1:38 AM, Grisha Levit wrote:

The problem seems to be not treating a single quote that follows a
backslash as the end of a single-quoted string.


Thanks for the patch; this is indeed a problem.

--
``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: TAB completion bug

[Grisha Levit]

The problem seems to be not treating a single quote that follows a
backslash as the end of a single-quoted string.
diff --git a/bashline.c b/bashline.c
index 774f813f..b1837d43 100644
--- a/bashline.c
+++ b/bashline.c
@@ -4077,15 +4077,13 @@ bash_dequote_filename (char *text, int quote_char)
   ret = (char *)xmalloc (l + 1);
   for (quoted = quote_char, p = text, r = ret; p && *p; p++)
 {
-  /* Allow backslash-escaped characters to pass through unscathed. */
-  if (*p == '\\')
+  /* Allow backslash-escaped characters to pass through unscathed,
+ unless in single quotes */
+  if (quoted != '\'' && *p == '\\')
 	{
-	  /* Backslashes are preserved within single quotes. */
-	  if (quoted == '\'')
-	*r++ = *p;
 	  /* Backslashes are preserved within double quotes unless the
 	 character is one that is defined to be escaped */
-	  else if (quoted == '"' && ((sh_syntaxtab[(unsigned char)p[1]] & CBSDQUOTE) == 0))
+	  if (quoted == '"' && ((sh_syntaxtab[(unsigned char)p[1]] & CBSDQUOTE) == 0))
 	*r++ = *p;
 
 	  *r++ = *++p;

Re: TAB completion bug

[Kerin Millar]

On Wed, 6 Dec 2023 05:43:43 +
Kerin Millar  wrote:

> On Tue, 5 Dec 2023 23:46:51 +
> Ole Tange via Bug reports for the GNU Bourne Again SHell  
> wrote:
> 
> > Configuration Information [Automatically generated, do not change]:
> > Machine: x86_64
> > OS: linux-gnu
> > Compiler: gcc
> > Compilation CFLAGS: -g -O2
> > uname output: Linux aspire 5.15.0-88-generic #98-Ubuntu SMP Mon Oct 2 
> > 15:18:56 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
> > Machine Type: x86_64-pc-linux-gnu
> > 
> > Bash Version: 5.2
> > Patch Level: 21
> > Release Status: release
> > 
> > Description:
> > Tested on git (2023-12-06).
> > 
> > For the (admitedly weirdly named) dirs below TAB completion does not 
> > work correctly.
> > 
> > Repeat-By:
> > #!/bin/bash
> > 
> > # TAB works
> > # $ ls -l ta
> > # 
> > # Tab completes but is escaped wrongly:
> > # $ ls -l ta
> > # 
> 
> I can confirm this for both 5.2.21 and the development branch. The backticks 
> are not quoted as they ought to be, resulting in a command substitution.
> 
> > 
> > mkdir -p 'tab/
> > `/tmp/trip`>/tmp/tripwire;
> > '"'"'@ > 
> > # These give the same
> > # $ ls -l tw
> > # $ ls -l tw
> > # But the last should include tmp
> 
> I was not able to reproduce this, however.

Apologies. I had overlooked the presence of the second mkdir command entirely. 
Indeed, it does not complete.

-- 
Kerin Millar

Re: TAB completion bug

[Kerin Millar]

On Tue, 5 Dec 2023 23:46:51 +
Ole Tange via Bug reports for the GNU Bourne Again SHell  
wrote:

> Configuration Information [Automatically generated, do not change]:
> Machine: x86_64
> OS: linux-gnu
> Compiler: gcc
> Compilation CFLAGS: -g -O2
> uname output: Linux aspire 5.15.0-88-generic #98-Ubuntu SMP Mon Oct 2 
> 15:18:56 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
> Machine Type: x86_64-pc-linux-gnu
> 
> Bash Version: 5.2
> Patch Level: 21
> Release Status: release
> 
> Description:
> Tested on git (2023-12-06).
> 
> For the (admitedly weirdly named) dirs below TAB completion does not work 
> correctly.
> 
> Repeat-By:
> #!/bin/bash
> 
> # TAB works
> # $ ls -l ta
> # 
> # Tab completes but is escaped wrongly:
> # $ ls -l ta
> # 

I can confirm this for both 5.2.21 and the development branch. The backticks 
are not quoted as they ought to be, resulting in a command substitution.

> 
> mkdir -p 'tab/
> `/tmp/trip`>/tmp/tripwire;
> '"'"'@ 
> # These give the same
> # $ ls -l tw
> # $ ls -l tw
> # But the last should include tmp

I was not able to reproduce this, however.

$ cd ta
$ echo "${PWD@Q}"
$'/home/kerin/tange/tab/\n`/tmp/trip`>'
$ cd ../../../..
$ cd ta
$ echo "${PWD@Q}"
$'/home/kerin/tange/tab/\n`/tmp/trip`>/tmp'

That was with programmable completion disabled (shopt -u progcomp) and the 
following directory structure in place.

$ LC_ALL=C find . -mindepth 1 -exec ls -1d --quoting-style=c {} +
"./tab"
"./tab/\n`"
"./tab/\n`/tmp"
"./tab/\n`/tmp/trip`>"
"./tab/\n`/tmp/trip`>/tmp"
"./tab/\n`/tmp/trip`>/tmp/tripwire;\n'@/tmp/tripwire;\n'@

TAB completion bug

[Ole Tange via Bug reports for the GNU Bourne Again SHell]

Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -g -O2
uname output: Linux aspire 5.15.0-88-generic #98-Ubuntu SMP Mon Oct 2 15:18:56 
UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu

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

Description:
Tested on git (2023-12-06).

For the (admitedly weirdly named) dirs below TAB completion does not work 
correctly.

Repeat-By:
#!/bin/bash

# TAB works
# $ ls -l ta
# 
# Tab completes but is escaped wrongly:
# $ ls -l ta
# 

mkdir -p 'tab/
`/tmp/trip`>/tmp/tripwire;
'"'"'@
# $ ls -l tw
# But the last should include tmp

mkdir -p 'two/
>/tmp/tripwire;
'"'"'@

Re: Bug in readline when readline-colored-completion-prefix is set

[Chet Ramey]

On 11/29/23 11:32 AM, raphaal wrote:

Hi all,

My version of bash is:
GNU bash, version 5.2.15(1)-release (x86_64-pc-linux-gnu)

When the .inputrc contains:
 > colored-completion-prefix on

and LS_COLORS="*.readline-colored-completion-prefix=01;30"

then readline ignores the setting and uses default CYAN color.


Thanks for the report. This was fixed several months ago in the bash and
readline devel branches. It's patch 3 to readline-8.2 but there's no
corresponding bash patch yet.

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

Bug in readline when readline-colored-completion-prefix is set

[raphaal]

Hi all,

My version of bash is:
GNU bash, version 5.2.15(1)-release (x86_64-pc-linux-gnu)

When the .inputrc contains:
> colored-completion-prefix on

and LS_COLORS="*.readline-colored-completion-prefix=01;30"

then readline ignores the setting and uses default CYAN color.

After a session of debugging the issue I noticed that there is a 
difference between readline in bash and main readline library:


https://git.savannah.gnu.org/cgit/bash.git/tree/lib/readline/colors.c#n76
#define RL_COLOR_PREFIX_EXTENSION   "readline-colored-completion-prefix"

https://git.savannah.gnu.org/cgit/readline.git/tree/colors.c#n76
#define RL_COLOR_PREFIX_EXTENSION   ".readline-colored-completion-prefix"

(missing dot at the beginning)

It shall be easy to fix

Raphaal

Re: BUG: Colorize background of whitespace

[Oğuz]

On Thursday, October 26, 2023, Phi Debian  wrote:

> On Wed, Oct 25, 2023 at 5:01 PM Greg Wooledge  wrote:
>
> >
> > Ahh.  That wasn't clear to me.  Thanks.
> >
> >
> Ouch got caught the same way. This can be reduced to
>
> $ clear
> $ echo "\e[36;44;4m\nsome colored\ttext with\ttabs\e[m\n"
> $  # Recall and run prev command
> repeat the later until top lines scroll out.
>
> I added ;4 in the first \e i.e Underline to show that doing  output is
> just a cursor movement (not a char painting) as would do any other cursor
> positioning esc seq.
>
> Doing so we see that on  both the color and the underline are not
> decorated, on top lines, this is normal
>
> When the scroll out occurs, the underline is never painted, as expected,
> yet the BG color of the 'tab' is decorated.
>
> This is because there is a bogus \n right after the SGR sequence
> \e[36;44;4m\n this later \n say we open and SGR attribute, and \n will
> preserve it on scroll out, BUT colors at not completly SGR as stated here
>
> https://invisible-island.net/xterm/ctlseqs/ctlseqs.html search for
> *"ANSI X3.64-1979"*
>
>
> *When we remove the bogus \n all is normal*
>
> $ clear
> $ echo "\e[36;44;4m\some colored\ttext with\ttabs\e[m\n"
> 
> many time.
>
>
> Generally speaking it is not good to leave an open SGR sequence before a
> \n, when emitting SGR before the \n it is wise to have a closing sequence
> \n[m\n
>

I can reproduce this behavior on all the terminals I have access to except
xterm on Solaris 10, it never paints the background of a tab, which is at
least consistent. I wonder what changed...


-- 
Oğuz

Re: BUG: Colorize background of whitespace

[Phi Debian]

On Wed, Oct 25, 2023 at 5:01 PM Greg Wooledge  wrote:

>
> Ahh.  That wasn't clear to me.  Thanks.
>
>
Ouch got caught the same way. This can be reduced to

$ clear
$ echo "\e[36;44;4m\nsome colored\ttext with\ttabs\e[m\n"
$  # Recall and run prev command
repeat the later until top lines scroll out.

I added ;4 in the first \e i.e Underline to show that doing  output is
just a cursor movement (not a char painting) as would do any other cursor
positioning esc seq.

Doing so we see that on  both the color and the underline are not
decorated, on top lines, this is normal

When the scroll out occurs, the underline is never painted, as expected,
yet the BG color of the 'tab' is decorated.

This is because there is a bogus \n right after the SGR sequence
\e[36;44;4m\n this later \n say we open and SGR attribute, and \n will
preserve it on scroll out, BUT colors at not completly SGR as stated here

https://invisible-island.net/xterm/ctlseqs/ctlseqs.html search for
*"ANSI X3.64-1979"*


*When we remove the bogus \n all is normal*

$ clear
$ echo "\e[36;44;4m\some colored\ttext with\ttabs\e[m\n"

many time.


Generally speaking it is not good to leave an open SGR sequence before a
\n, when emitting SGR before the \n it is wise to have a closing sequence
\n[m\n

Re: BUG: Colorize background of whitespace

[Greg Wooledge]

On Wed, Oct 25, 2023 at 02:48:20PM +, David wrote:
> On Wed, 25 Oct 2023 at 11:51, Greg Wooledge  wrote:
> > On Wed, Oct 25, 2023 at 10:29:32AM +0200, Holger Klene wrote:
> > > Repeat-By:
> > > run the following command line:
> > > clear; seq 50; printf '\e[36;44m\nsome colored\ttext with\ttabs\e[m\n'
> > > Play with the parameter to seq, to keep the line within the first screen 
> > > or move it offscreen.

> The bug being reported is that the '\t' characters have a black background
> if the 'seq' argument is low enough that its lines 1 and 2 remain
> visible when run.
> But if the 'seq' argument is changed to be bigger, so that (at least)
> lines 1 and 2 both
> scroll off the top of the terminal window so that they are not visible, then 
> the
> '\t' characters then get the expected blue background.

Ahh.  That wasn't clear to me.  Thanks.

In an 80x24 rxvt-unicode or xterm terminal, "seq 22" shows the reported
problem, and "seq 23" does not.

Re: BUG: Colorize background of whitespace

[Chet Ramey]

On 10/25/23 10:48 AM, David wrote:


The bug being reported is that the '\t' characters have a black background
if the 'seq' argument is low enough that its lines 1 and 2 remain
visible when run.


Bash and readline don't do anything with terminal foreground colors and
background colors except under certain circumstances like bracketed-paste.
If you're pasting the above command into the terminal, that pasted text
will be colored according to active-region-start-color and
active-region-end-color (bash-5.2) or terminal standout mode (bash-5.1).
Otherwise, readline redisplay just outputs terminal sequences to move the
cursor and the characters in the line.

--
``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: Colorize background of whitespace

[David]

On Wed, 25 Oct 2023 at 11:51, Greg Wooledge  wrote:
> On Wed, Oct 25, 2023 at 10:29:32AM +0200, Holger Klene wrote:

> > Description:
> > The initial bash background is hardcoded to some default (e.g. black) and 
> > cannot be colorized by printing "transparent" tabs/newlines with 
> > ANSI-ESC-codes.
> > Only after a vertical scrollbar appears, the whitespace beyond the window 
> > hight will get the proper background color.
>
> Terminals have colors (foreground and background).  Bash does not.  Bash
> is just a command shell.
>
> > Repeat-By:
> > run the following command line:
> > clear; seq 50; printf '\e[36;44m\nsome colored\ttext with\ttabs\e[m\n'
> > Play with the parameter to seq, to keep the line within the first screen or 
> > move it offscreen.
> >
> > Reproduced in:
> > - in Konsole on Kubuntu 23.04
> > - in the git bash for windows mintty 3.6.1
> > - in WSL cmd window on Windows 11
>
> I ran this command in xterm (version 379) and rxvt-unicode (9.30) on
> Debian, but I'm not sure what I'm supposed to be seeing.

The bug being reported is that the '\t' characters have a black background
if the 'seq' argument is low enough that its lines 1 and 2 remain
visible when run.
But if the 'seq' argument is changed to be bigger, so that (at least)
lines 1 and 2 both
scroll off the top of the terminal window so that they are not visible, then the
'\t' characters then get the expected blue background.

I see this in Debian 11, both in 'lxterminal' under LXDE, and in the
virtual consoles,
[david@kablamm ~]$ echo $BASH_VERSION
5.1.4(1)-release
[david@kablamm ~]$ cat /etc/debian_version
11.8

Re: BUG: Colorize background of whitespace

[Greg Wooledge]

On Wed, Oct 25, 2023 at 10:29:32AM +0200, Holger Klene wrote:
> Description:
> The initial bash background is hardcoded to some default (e.g. black) and 
> cannot be colorized by printing "transparent" tabs/newlines with 
> ANSI-ESC-codes.
> Only after a vertical scrollbar appears, the whitespace beyond the window 
> hight will get the proper background color.

Terminals have colors (foreground and background).  Bash does not.  Bash
is just a command shell.

> Repeat-By:
> run the following command line:
> clear; seq 50; printf '\e[36;44m\nsome colored\ttext with\ttabs\e[m\n'
> Play with the parameter to seq, to keep the line within the first screen or 
> move it offscreen.
> 
> Reproduced in:
> - in Konsole on Kubuntu 23.04
> - in the git bash for windows mintty 3.6.1
> - in WSL cmd window on Windows 11

I ran this command in xterm (version 379) and rxvt-unicode (9.30) on
Debian, but I'm not sure what I'm supposed to be seeing.

In my case, the terminals are 80x24, and xterm has a default black
background, while rxvt has a default white background.  In both cases,
the expected rows of numbers are printed by seq, and then there's
a blank line, and then there's a line of dark blue background which
extends all the way across the terminal, containing "some colored" and
"text with" and "tabs" in a greenish foreground color.

Hitting Enter to scroll the text upward doesn't do anything surprising,
and neither does scrolling the terminal with Shift-PageUp or with
the mouse.

What are *you* seeing which surprises you?

In any case, this has nothing to do with bash.  It's strictly a terminal
issue, whatever the issue may be.

Re: BUG: Colorize background of whitespace

[Phi Debian]

On Wed, Oct 25, 2023 at 11:09 AM Holger Klene  wrote:

> Configuration Information [Automatically generated, do not change]:
> Machine: x86_64
> OS: linux-gnu
> Compiler: gcc
> Compilation CFLAGS: -g -O2 -flto=auto -ffat-lto-objects -flto=auto
> -ffat-lto-objects -fstack-protector-strong -Wformat -Werror=format-security
> -Wall
> uname output: Linux BX-NB-015 5.15.90.1-microsoft-standard-WSL2 #1 SMP Fri
> Jan 27 02:56:13 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
> Machine Type: x86_64-pc-linux-gnu
> Bash Version: 5.1
> Patch Level: 16
> Release Status: release
>
> Description:
> The initial bash background is hardcoded to some default (e.g. black) and
> cannot be colorized by printing "transparent" tabs/newlines with
> ANSI-ESC-codes.
> Only after a vertical scrollbar appears, the whitespace beyond the window
> hight will get the proper background color.
>
> Repeat-By:
> run the following command line:
> clear; seq 50; printf '\e[36;44m\nsome colored\ttext with\ttabs\e[m\n'
> Play with the parameter to seq, to keep the line within the first screen
> or move it offscreen.
>
> Reproduced in:
> - in Konsole on Kubuntu 23.04
> - in the git bash for windows mintty 3.6.1
> - in WSL cmd window on Windows 11
>
>
I guess this is the way terminal emulator works, and I guess as well they
are doing what real terminals use to do, though I have no such term at hand
to prove :-)

Worth to consider
 $ clear; seq 50; printf '\e[36;44m\nsome colored\ttext with\ttabs\e[m\n' |
expand

BUG: Colorize background of whitespace

[Holger Klene]

Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -g -O2 -flto=auto -ffat-lto-objects -flto=auto 
-ffat-lto-objects -fstack-protector-strong -Wformat -Werror=format-security 
-Wall
uname output: Linux BX-NB-015 5.15.90.1-microsoft-standard-WSL2 #1 SMP Fri Jan 
27 02:56:13 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu
Bash Version: 5.1
Patch Level: 16
Release Status: release

Description:
The initial bash background is hardcoded to some default (e.g. black) and 
cannot be colorized by printing "transparent" tabs/newlines with ANSI-ESC-codes.
Only after a vertical scrollbar appears, the whitespace beyond the window hight 
will get the proper background color.

Repeat-By:
run the following command line:
clear; seq 50; printf '\e[36;44m\nsome colored\ttext with\ttabs\e[m\n'
Play with the parameter to seq, to keep the line within the first screen or 
move it offscreen.

Reproduced in:
- in Konsole on Kubuntu 23.04
- in the git bash for windows mintty 3.6.1
- in WSL cmd window on Windows 11

Re: bug in bashbug script shipped with bash 5.2.15

[Chet Ramey]

On 10/9/23 1:18 PM, Ti Strga wrote:

The bug likely got checked in earlier than 5.2.15, that's just what I
happened to be running when I ran into this.


Thanks, it's already been fixed 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/

bug in bashbug script shipped with bash 5.2.15

[Ti Strga]

The bug likely got checked in earlier than 5.2.15, that's just what I
happened to be running when I ran into this.

$ declare -p BASH_VERSINFO
declare -ar BASH_VERSINFO=([0]="5" [1]="2" [2]="15" [3]="3"
[4]="release" [5]="x86_64-pc-cygwin")

$ bashbug
/usr/bin/bashbug: line 135: [: missing `]'
/usr/bin/bashbug: line 137: [: missing `]'

{at this point I'm inside my $EDITOR, and exited without making changes}

/usr/bin/bashbug: You have not changed the subject from the default.
/usr/bin/bashbug: Please use a more descriptive subject header.
/usr/bin/bashbug: Type `y' to give up, and lose your bug report;
/usr/bin/bashbug: type `n' to re-enter the editor.
/usr/bin/bashbug: Do you want to give up? y
$


The relevant lines are in a series of tests trying to find the correct
editor executable:

.
elif [ -x /usr/bin/xemacs ]; then
DEFEDITOR=xemacs
elif [ -x /usr/bin/vim; then <
DEFEDITOR=vim
elif [ -x /usr/bin/gvim; then <
DEFEDITOR=gvim
elif [ -x /usr/bin/nano ]; then
.

Re: bug:

[Greg Wooledge]

On Tue, Oct 03, 2023 at 12:54:45PM +, queency jones via Bug reports for the 
GNU Bourne Again SHell wrote:
> BASH_VERSION='5.1.4(1)-release'PRETTY_NAME="Debian GNU/Linux 11 (bullseye)"no 
> compile needed
> i made a fifo file by typing: mkfifo gdbout.fifo
> i coded a resource file named  : command.bashthe file code is :aa(){ gdb 
> ./hello_wordl.out > gdbout.fifo & }
> i loaded the resource file by typing in bash shell:       .com.bash
> then run the function aa
> when i typed: ps i got 2 bash jobs instead of 1 bash and 1 gdb !

Your function runs a background subshell which opens a named pipe before
executing gdb.  Opening a named pipe will block, until the named pipe is
opened a *second* time in the opposite direction.  (Since your function
opens it for writing, you need a second process to open it for reading.)

Once the named pipe is opened a second time, the background subshell
will be able to continue, to execute gdb.  Until then, however, it's
still a bash process.

bug:

[queency jones via Bug reports for the GNU Bourne Again SHell]

BASH_VERSION='5.1.4(1)-release'PRETTY_NAME="Debian GNU/Linux 11 (bullseye)"no 
compile needed
i made a fifo file by typing: mkfifo gdbout.fifo
i coded a resource file named  : command.bashthe file code is :aa(){ gdb 
./hello_wordl.out > gdbout.fifo & }
i loaded the resource file by typing in bash shell:       .com.bash
then run the function aa
when i typed: ps i got 2 bash jobs instead of 1 bash and 1 gdb !

thank you for your time 

Re: bug#65659: RFC: changing printf(1) behavior on %b

[Steffen Nurpmeso]

Stephane Chazelas wrote in
 <20230902084912.vdfedsgbnat2w...@chazelas.org>:
 |2023-09-01 23:28:50 +0200, Steffen Nurpmeso via austin-group-l at The \
 |Open Group:
 ...
 |>|FWIW, a "printf %b" github shell code search returns ~ 29k
 |>|entries
 |>|(https://github.com/search?q=printf+%25b+language%3AShell=code=Sh\
 |>|ell)
 ...
 |> Actually this returns a huge amount of false positives where
 |> printf(1) and %b are not on the same line, let alone the same
 ...
 |Apparently, we can also search with regexps and searching for
 |printf.*%b
 |(https://github.com/search?q=%2Fprintf.*%25b%2F+language%3AShell=code)
 |It's probably a lot more accurate. It returns ~ 19k.
 ...
 |> Furthermore it shows a huge amount of false use cases like
 ...
 |Yes, I also see a lot of echo -e stuff that should have been
 |echo -E stuff (or echo alone in those (many) implementations
 |that don't expand by default or use the more reliable printf
 |with %s (not %b)).
 |
 |> It seems people think you need this to get colours mostly, which
 ...
 |Incidentally, ANSI terminal colour escape sequences are somewhat
 |connecting those two %b's as they are RGB (well BGR) in binary
 |(white is 7 = 0b111, red 0b001, green 0b010, blue 0b100), with:
 |
 |R=0 G=1 B=1
 |printf '%bcyan%b\n' "\033[3$(( 2#$B$G$R ))m" '\033[m'
 |
 |(with Korn-like shells, also $(( 0b$B$G$R )) in zsh though zsh
 |has builtin colour output support including RGB-based).

..and, off-topic, but in my opinion that is also false usage, one
should use tput(1) instead, and then simply printf(1) (or echo(1)
(or cat(1))) the output, something like, fwiw :),

  color_init() {
  [ -n "${NO_COLOUR}" ] && return
  # We do not want color for "make test > .LOG"!
  if [ -t 1 ] && command -v tput >/dev/null 2>&1; then
  { sgr0=$(tput sgr0); } 2>/dev/null
  [ $? -eq 0 ] || return
  { saf1=$(tput setaf 1); } 2>/dev/null
  [ $? -eq 0 ] || return
  { saf2=$(tput setaf 2); } 2>/dev/null
  [ $? -eq 0 ] || return
  { saf3=$(tput setaf 3); } 2>/dev/null
  [ $? -eq 0 ] || return
  { saf5=$(tput setaf 5); } 2>/dev/null
  [ $? -eq 0 ] || return
  { b=$(tput bold); } 2>/dev/null
  [ $? -eq 0 ] || return

  COLOR_ERR_ON=${saf1}${b} COLOR_ERR_OFF=${sgr0}
  COLOR_DBGERR_ON=${saf5} COLOR_DBGERR_OFF=${sgr0}
  COLOR_WARN_ON=${saf3}${b} COLOR_WARN_OFF=${sgr0}
  COLOR_OK_ON=${saf2} COLOR_OK_OFF=${sgr0}
  unset saf1 saf2 saf3 b
  fi
  }

  ...

  printf '%s%s%s' "${COLOR_WARN_ON}" "$SOME_MSG" "${COLOR_WARN_OFF}"

Of course this is also only ANSI via sgr0 (:-|

 |Speaking of stackexchange, on the June data dump of
 |unix.stackexchange.com:
 |
 |stackexchange/unix.stackexchange.com$ xml2 < Posts.xml | grep -c 'printf\
 |.*%b'
 |494
 |
 |(FWIW)
 |
 |Compared with %d (though that will have entries for printf(3) as well):
 |
 |stackexchange/unix.stackexchange.com$ xml2 < Posts.xml | grep -c 'printf\
 |.*%d'
 |3444

I am totally stunned by the ratio.  I myself have never used %b
(like this, aka for printf).

 --End of <20230902084912.vdfedsgbnat2w...@chazelas.org>

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: bug#65659: RFC: changing printf(1) behavior on %b

[Léa Gris]

Le 02/09/2023 à 07:46, Phi Debian écrivait :

On Fri, Sep 1, 2023 at 8:10 PM Stephane Chazelas 
wrote:


2023-09-01 07:54:02 -0500, Eric Blake via austin-group-l at The Open Group:


FWIW, a "printf %b" github shell code search returns ~ 29k
entries
(
https://github.com/search?q=printf+%25b+language%3AShell=code=Shell
)



Ha super, at least some numbers :-), I didn't knew we could make this kind
of request... thanx for that.


18k results on 



Those actual numbers vary a lot depending on request accuracy. Because 
there is no Regex replacement for a shell language parser; it cannot 
match all syntactically valid use cases, even with a carefully crafted 
Regex.


--
Léa Gris

Re: bug#65659: RFC: changing printf(1) behavior on %b

[Stephane Chazelas]

2023-09-01 23:28:50 +0200, Steffen Nurpmeso via austin-group-l at The Open 
Group:
[...]
>  |FWIW, a "printf %b" github shell code search returns ~ 29k
>  |entries
>  |(https://github.com/search?q=printf+%25b+language%3AShell=code=Sh\
>  |ell)
>  |
>  |That likely returns only a small subset of the code that uses
>  |printf with %b inside the format and probably a few false
>  |positives, but that gives many examples of how printf %b is used
>  |in practice.
> 
> Actually this returns a huge amount of false positives where
> printf(1) and %b are not on the same line, let alone the same
> command, if you just scroll down a bit it starts like neovim match
[...]

You're right, I only looked at the first few results and saw
that already gave interesting ones.

Apparently, we can also search with regexps and searching for
printf.*%b
(https://github.com/search?q=%2Fprintf.*%25b%2F+language%3AShell=code)
It's probably a lot more accurate. It returns ~ 19k.

(still FWIW, that's still just a sample of random code on the
internet)

[...]
> Furthermore it shows a huge amount of false use cases like
> 
>  printf >&2 "%b\n" "The following warnings and non-fatal errors were 
> encountered during the installation process:"
[...]

Yes, I also see a lot of echo -e stuff that should have been
echo -E stuff (or echo alone in those (many) implementations
that don't expand by default or use the more reliable printf
with %s (not %b)).

> It seems people think you need this to get colours mostly, which
> then, it has to be said, is also practically mislead.  (To the
> best of *my* knowledge that is.)
[...]

Incidentally, ANSI terminal colour escape sequences are somewhat
connecting those two %b's as they are RGB (well BGR) in binary
(white is 7 = 0b111, red 0b001, green 0b010, blue 0b100), with:

R=0 G=1 B=1
printf '%bcyan%b\n' "\033[3$(( 2#$B$G$R ))m" '\033[m'

(with Korn-like shells, also $(( 0b$B$G$R )) in zsh though zsh
has builtin colour output support including RGB-based).

Speaking of stackexchange, on the June data dump of
unix.stackexchange.com:

stackexchange/unix.stackexchange.com$ xml2 < Posts.xml | grep -c 'printf.*%b'
494

(FWIW)

Compared with %d (though that will have entries for printf(3) as well):

stackexchange/unix.stackexchange.com$ xml2 < Posts.xml | grep -c 'printf.*%d'
3444

-- 
Stephane

Re: bug#65659: RFC: changing printf(1) behavior on %b

[Phi Debian]

On Fri, Sep 1, 2023 at 8:10 PM Stephane Chazelas 
wrote:

> 2023-09-01 07:54:02 -0500, Eric Blake via austin-group-l at The Open Group:
>
>
> FWIW, a "printf %b" github shell code search returns ~ 29k
> entries
> (
> https://github.com/search?q=printf+%25b+language%3AShell=code=Shell
> )
>
>
Ha super, at least some numbers :-), I didn't knew we could make this kind
of request... thanx for that.

Re: bug#65659: RFC: changing printf(1) behavior on %b

[Steffen Nurpmeso]

Stephane Chazelas via austin-group-l at The Open Group wrote in
 <20230901181024.pwx4plwclz7ij...@chazelas.org>:
 |2023-09-01 07:54:02 -0500, Eric Blake via austin-group-l at The Open Group:
 ...
 |> How many scripts in the wild actually use %b, though?  And if there
 |> are such scripts, anything we can do to make it easy to do a drop-in
 |> replacement that still preserves the old behavior (such as changing %b
 |> to %#s) is going to be easier to audit than the only other
 |> currently-portable alternative of actually analyzing the string to see
 |> if it uses any octal or \c escapes that have to be re-written to
 |> portably function as a printf format argument.
 |[...]
 |
 |FWIW, a "printf %b" github shell code search returns ~ 29k
 |entries
 |(https://github.com/search?q=printf+%25b+language%3AShell=code=Sh\
 |ell)
 |
 |That likely returns only a small subset of the code that uses
 |printf with %b inside the format and probably a few false
 |positives, but that gives many examples of how printf %b is used
 |in practice.

Actually this returns a huge amount of false positives where
printf(1) and %b are not on the same line, let alone the same
command, if you just scroll down a bit it starts like neovim match

 pr_title="${pr_title// /,}" # Replace spaces with commas.
 pr_title="$(printf 'vim-patch:%s' "${pr_title#,}")"

(bash only btw).
Furthermore it shows a huge amount of false use cases like

 printf >&2 "%b\n" "The following warnings and non-fatal errors were 
encountered during the installation process:"

This is only the first result page.
It seems people think you need this to get colours mostly, which
then, it has to be said, is also practically mislead.  (To the
best of *my* knowledge that is.)

Ah it is a copy world, and for one Stephane at stackoverflow
there are 99 that fool and mislead you, or do not know for sure
themselves, but also copy and paste!

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: bug#65659: RFC: changing printf(1) behavior on %b

[Stephane Chazelas]

2023-09-01 07:54:02 -0500, Eric Blake via austin-group-l at The Open Group:
[...]
> > Well in all case %b can not change semantic in the bash script, since it is
> > there for so long, even if it depart from python, perl, libc, it is
> > unfortunate but that's the way it is, nobody want a semantic change, and on
> > next routers update, see the all internet falling appart :-)
> 
> How many scripts in the wild actually use %b, though?  And if there
> are such scripts, anything we can do to make it easy to do a drop-in
> replacement that still preserves the old behavior (such as changing %b
> to %#s) is going to be easier to audit than the only other
> currently-portable alternative of actually analyzing the string to see
> if it uses any octal or \c escapes that have to be re-written to
> portably function as a printf format argument.
[...]

FWIW, a "printf %b" github shell code search returns ~ 29k
entries
(https://github.com/search?q=printf+%25b+language%3AShell=code=Shell)

That likely returns only a small subset of the code that uses
printf with %b inside the format and probably a few false
positives, but that gives many examples of how printf %b is used
in practice.

printf %b is also what all serious literature about shell
scripting has been recommending to use in place of the
unportable echo -e (or XSI echo, or print without -r). That
includes the POSIX standard which has been recommending using
printf instead of the non-portable echo for 30 years.

So that change will also invalidate all those. It will take a
while before %#s is supported widely enough that %b can be
safely replaced with %#s

-- 
Stephane

Re: bug#65659: RFC: changing printf(1) behavior on %b

[Stephane Chazelas]

2023-09-01 07:15:14 -0500, Eric Blake:
[...]
> > Note that in bash, you need both
> > 
> > shopt -s xpg_echo
> > set -o posix
> > 
> > To get a XSI echo. Without the latter, options are still
> > recognised. You can get a XSI echo without those options with:
> > 
> > xsi_echo() {
> >   local IFS=' ' -
> >   set +o posix
> >   echo -e "$*\n\c"
> > }
> > 
> > The addition of those \n\c (noop) avoids arguments being treated as
> > options if they start with -.
> 
> As an extension, Bash (and Coreutils) happen to honor \c always, and
> not just for %b.  But POSIX only requires \c handling for %b.
> 
> And while Issue 8 has taken steps to allow implementations to support
> 'echo -e', it is still not standardized behavior; so your xsi_echo()
> is bash-specific (which is not necessarily a problem, as long as you
> are aware it is not portable).
[...]

Yes, none of local (from ash I believe), the posix option
(several shells have an option called posix all used to improve
POSIX conformance, bash may have been the first) nor -e (from
Research Unix v8) are standard, that part was about bash
specifically (as the thread is also posted on gnu.bash.bug).

BTW, that xsi_echo is not strictly equivalent to a XSI echo in
the case where the last character of the last argument is an unescaped
backslash or a character whose encoding ends in the same byte as
the encoding of backslash.

-- 
Stephane

Re: bug#65659: RFC: changing printf(1) behavior on %b

[Eric Blake]

On Fri, Sep 01, 2023 at 07:19:13AM +0200, Phi Debian wrote:
> Well after reading yet another thread regarding libc_printf() I got to
> admit that even %B is crossed out, (Yet already choosen by ksh93)
> 
> The other thread also speak about libc_printf() documentting %# as
> undefined for things other than  a, A, e, E, f, F, g, and G, yet the same
> thread also talk about a A comming late (citing C99) in the dance, meaning
> what is undefined today become defined tomorow, so %#b is no safer.
>

Caution: The proposal here is for %#s (an alternative string), not %#b
(which C2x wants to be similar to %#x, in that it outputs a '0b'
prefix for all values except bare '0').

Yes, there is a slight risk that C may decide to define %#s.  But as
the Austin Group includes a member of WG14, we are able to advise the
C committee that such an addition is not wise.

> My guess is that printf(1) is now doomed to follow its route, keep its old
> format exception, and then may be implement something like c_printf like
> printf but the format string follow libc semantic, or may be a -C option to
> printf(1)...

Adding an option to printf is also a possibility, if there is
wide-spread implementation practice to standardize.  If someone wants
to implement 'printf -C' right now, that could help feed such a future
standardization.  But it is somewhat orthogonal to the request in this
thread, which is how to allow users to still access the old %b
behavior even if %b gets repurposed in the future; if we can get
multiple implementations to add a %#s alias now, it makes the future
decisions easier (even if it is too late for Issue 8 to add any new
features, or for that matter, to make any normative changes other than
marking %b obsolescent as a way to be able to revisit it in the future
for Issue 9).


> 
> Well in all case %b can not change semantic in the bash script, since it is
> there for so long, even if it depart from python, perl, libc, it is
> unfortunate but that's the way it is, nobody want a semantic change, and on
> next routers update, see the all internet falling appart :-)

How many scripts in the wild actually use %b, though?  And if there
are such scripts, anything we can do to make it easy to do a drop-in
replacement that still preserves the old behavior (such as changing %b
to %#s) is going to be easier to audit than the only other
currently-portable alternative of actually analyzing the string to see
if it uses any octal or \c escapes that have to be re-written to
portably function as a printf format argument.

POSIX is not mandating %#s at this time, so much as suggesting that if
implementations are willing to implement it now, it will make Issue 9
easier to reason about.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.
Virtualization:  qemu.org | libguestfs.org

Re: bug#65659: RFC: changing printf(1) behavior on %b

[Eric Blake]

On Fri, Sep 01, 2023 at 08:59:19AM +0100, Stephane Chazelas wrote:
> 2023-08-31 15:02:22 -0500, Eric Blake via austin-group-l at The Open Group:
> [...]
> > The current POSIX says that %b was added so that on a non-XSI
> > system, you could do:
> > 
> > my_echo() {
> >   printf %b\\n "$*"
> > }
> 
> That is dependant on the current value of $IFS. You'd need:
> 
> xsi_echo() (
>   IFS=' '
>   printf '%b\n' "$*"
> )

Let's read the standard in context (Issue 8 draft 3 page 2793 line 92595):

"
The printf utility can be used portably to emulate any of the traditional 
behaviors of the echo
utility as follows (assuming that IFS has its standard value or is unset):
• The historic System V echo and the requirements on XSI implementations in 
this volume of
  POSIX.1-202x are equivalent to:
printf "%b\n" "$*"
"

So yes, the standard does mention the requirement to have a sane IFS,
and I failed to include that in my one-off implementation of
my_echo().  Thank you for pointing out a more robust version.

> 
> Or the other alternatives listed at
> https://unix.stackexchange.com/questions/65803/why-is-printf-better-than-echo/65819#65819
> 
> [...]
> > Bash already has shopt -s xpg_echo
> 
> Note that in bash, you need both
> 
> shopt -s xpg_echo
> set -o posix
> 
> To get a XSI echo. Without the latter, options are still
> recognised. You can get a XSI echo without those options with:
> 
> xsi_echo() {
>   local IFS=' ' -
>   set +o posix
>   echo -e "$*\n\c"
> }
> 
> The addition of those \n\c (noop) avoids arguments being treated as
> options if they start with -.

As an extension, Bash (and Coreutils) happen to honor \c always, and
not just for %b.  But POSIX only requires \c handling for %b.

And while Issue 8 has taken steps to allow implementations to support
'echo -e', it is still not standardized behavior; so your xsi_echo()
is bash-specific (which is not necessarily a problem, as long as you
are aware it is not portable).

> [...]
> > The Austin Group also felt that standardizing bash's behavior of %q/%Q
> > for outputting quoted text, while too late for Issue 8, has a good
> > chance of success, even though C says %q is reserved for
> > standardization by C. Our reasoning there is that lots of libc over
> > the years have used %qi as a synonym for %lli, and C would be foolish
> > to burn %q for anything that does not match those semantics at the C
> > language level; which means it will likely never be claimed by C and
> > thus free for use by shell in the way that bash has already done.
> [...]
> 
> Note that %q is from ksh93, not bash and is not portable across
> implementations and with most including bash's gives an output
> that is not safe for reinput in arbitrary locales (as it uses
> $'...' in some cases), not sure  it's a good idea to add it to
> the standard, or at least it should come with fat warnings about
> the risk in using it.

%q is NOT being added to Issue 8, but $'...' is.  Bug 1771 asked if %q
could be added to Issue 8, but it came it past the deadline for
feature requests, so the best we could do is add a FUTURE DIRECTIONS
blurb that mentions the idea.  But since FUTURE DIRECTIONS is
non-normative, we can always change our mind in Issue 9 and delete
that text if it turns out we can't get consensus to standardize some
form of %q/%Q after all.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.
Virtualization:  qemu.org | libguestfs.org

Re: bug#65659: RFC: changing printf(1) behavior on %b

[Stephane Chazelas]

2023-08-31 15:02:22 -0500, Eric Blake via austin-group-l at The Open Group:
[...]
> The current POSIX says that %b was added so that on a non-XSI
> system, you could do:
> 
> my_echo() {
>   printf %b\\n "$*"
> }

That is dependant on the current value of $IFS. You'd need:

xsi_echo() (
  IFS=' '
  printf '%b\n' "$*"
)

Or the other alternatives listed at
https://unix.stackexchange.com/questions/65803/why-is-printf-better-than-echo/65819#65819

[...]
> Bash already has shopt -s xpg_echo

Note that in bash, you need both

shopt -s xpg_echo
set -o posix

To get a XSI echo. Without the latter, options are still
recognised. You can get a XSI echo without those options with:

xsi_echo() {
  local IFS=' ' -
  set +o posix
  echo -e "$*\n\c"
}

The addition of those \n\c (noop) avoids arguments being treated as
options if they start with -.


[...]
> The Austin Group also felt that standardizing bash's behavior of %q/%Q
> for outputting quoted text, while too late for Issue 8, has a good
> chance of success, even though C says %q is reserved for
> standardization by C. Our reasoning there is that lots of libc over
> the years have used %qi as a synonym for %lli, and C would be foolish
> to burn %q for anything that does not match those semantics at the C
> language level; which means it will likely never be claimed by C and
> thus free for use by shell in the way that bash has already done.
[...]

Note that %q is from ksh93, not bash and is not portable across
implementations and with most including bash's gives an output
that is not safe for reinput in arbitrary locales (as it uses
$'...' in some cases), not sure  it's a good idea to add it to
the standard, or at least it should come with fat warnings about
the risk in using it.

See also:

https://unix.stackexchange.com/questions/379181/escape-a-variable-for-use-as-content-of-another-script/600214#600214

-- 
Stephane