Re: [PATCH] printf: add %#s alias to %b

[Robert Elz]

Date:Thu, 7 Sep 2023 13:46:08 -0500
From:Eric Blake 
Message-ID:  


  | Right now, both bash and coreutils' 'printf %hhd 257' outputs "257",

ok, not unexpected.   I'm not sure its useful either.

  | but printf("%hhd", 257) in C outputs 1.

Yes.

  | I would LOVE to have a mode
  | (possibly spelled 'printf -C %hhd 257') where I can ensure that width
  | modifiers are applied to the integer value obtained from the correct
  | subsequent argument to printf.

Actually, I doubt you would, not really.  C has all kinds of fixed
bit width data types, and needs lots of infrastructure to deal
with that - the constants that give the max/min values, size
modifiers, so that either all the necessary bits can be fetched
from the arg, or we can pretend we only received the fewer number
we should have gotten, if only it weren't for the C arg data type
promotion rules.

The C example above is really an example of poor coding - not
incorrect, but relying on quirks that exist for other reasons.
The arg to %hhd should be an int8_t in which case it cannot be
257.  Having printf doing value masking in such a case is really
just to undo any unwanted effects from the promotion rules which
would apply if it really was an int8_t variable instead of a
consant.

Using those modifiers because you're too lazy to write the code
to mask the value yourself is just bad.

Printf(1) has none of all of that - apart from the single max
number of supported bits that applies, there are no magic
fixed bit width fields, no reason to specially bless 8, 16,
32 bit widths as more important than any other number.

Further the shell has most of the same arith capabilities as C
does, you can just as easily write your own masking expression
so you can pretend to have 19 bit wide ints if that were to
turn out to be useful.

The size modifiers aren't necessary, and aren't really useful
for the printf command, and just like C23's %b, aren't really
general enough.   We have enough non-portable sh level code
already, we don't need new added mechanisms that add to it.

  | And given that, I prefer naming such an extension option
  | -C or -c (implying C-like), rather than your suggestion of -b
  | (implying binary, but where the implication only benefits %b) 

That implication was actually exactly the point - I still subscribe
to the 'do one thing, and do it well' philosophy.  That is, no
catch-all flags which enable a zillion different modifications,
all with one flag.  -b just for %b, -? (don't know what) for
size mod8fiers (just how many bits does (or would) %zu print
in printf(1), and why?)   Etc.

Neither are really likely to be needed, IMO.

kre

Re: [PATCH] printf: add %#s alias to %b

[Pádraig Brady]

On 07/09/2023 19:46, Eric Blake wrote:

On Thu, Sep 07, 2023 at 11:53:54PM +0700, Robert Elz wrote:

And for those who have been following this issue, the new text for
the forthcoming POSIX version has removed any mention of obsoleting
%b from printf(1) - instead it will simply note that there is will be
a difference between printf(1) and printf(3) once the latter gets its
version of %b specified (in C23, and in POSIX, in the next major version
that follows the coming one, almost certainly) - and to encourage
implementors to consider possible solutions.

I've considered, and I don't see a problem needing solving, so I'm
intending to do precisely nothing, unless someone actually finds a
need for binary output from printf(1), which seems unlikely to
ever happen to me (I mean a real need, not just to be the same as printf(3)
"just because").

So, we can all go back to sleep now - and Chet, I'd undo $#s before it
appears in a release, there's no need, and having it might eventually
just cause more backward compat issues.


Indeed, at this point, even though I proposed a patch for %#s in
coreutils, I'm inclined to NOT apply it there.


Agreed.


The ksh extension of %..2d to output in binary does sound worth
replicating; I wonder if glibc would consider putting that in their
printf(3); and I could see adding it to Coreutils (whether or not bash
adds it - because ksh already has it).


This does seem useful as there is prior art, and it's quite general.
FWIW there is related functionality in coreutils currently through `basenc 
--base2msbf`

cheers,
Pádraig

Re: [PATCH] printf: add %#s alias to %b

[Zachary Santer]

On Thu, Sep 7, 2023 at 12:55 PM Robert Elz  wrote:

> There are none, printf(3) belongs to the C committee, and they can make
> use of anything they like, at any time they like.
>
> The best we can do is use formats that make no sense for printf(1) to
> support
>

That's still assuming the goal of minimizing the discrepancies between
printf(1) and printf(3) format specifiers. As you point out, that isn't
particularly useful, and these things diverging further is now a foregone
conclusion. The only benefit, from my perspective, is allowing the
printf(1) man page to simply reference the printf(3) man page for
everything that printf(1) attempts to replicate.

Zack

Re: [PATCH] printf: add %#s alias to %b

[Eric Blake]

On Thu, Sep 07, 2023 at 02:42:16PM +0700, Robert Elz wrote:
> Date:Wed, 6 Sep 2023 11:32:32 -0500
> From:Eric Blake 
> Message-ID:  
> 
> 
>   | You (anyone reading this, not just kre) are welcome to join tomorrow's
>   | Austin Group meeting
> 
> Thanks, but I don't expect its time of day will coincide with
> mine this week, at best I would be a half asleep zombie.
> 
>   |  it is a Zoom call
> 
> As best I understand it, zoom does not support NetBSD - which
> is the only platform I use, which has been true for decades now
> (previously I also used SunOS (not Solaris) and Ultrix).
> 
> While probably works on android (ie: phone)  meeting use that
> way would not be convenient for anyone - certainly not for me
> staring at it all the time, and assuming that it works with
> video enabled, not for anyone else with an image moving around
> randomly... (my phone has no stand, I haven't been able to
> find one which fits it).

The meeting is now over, but for clarification, the Austin Group does
audio-only meetings.  Some weeks we use Zoom, some we use Webex
(depends on who is available to run the meeting), but no one is
on-screen, so a POT dialin always works at no disadvantage to someone
unable/unwilling to run Zoom software (whether that be for reasons of
not yet having port available, or for Zoom not releasing their
software under a license acceptable to your liking).  Speak up if you
think the Austin Group is ever unfairly crippling someone's right to
participate by limiting the participation behind a paywall.

> 
>   | Or you can add comments to the bug directly.
> 
> I have done that already, and probably will add one more.
> 
>   | Of course, the gamble is easier to win if we have multiple independent
>   | implementations that have all coordinated to do it the same way, so we
>   | can push back on WG14 to tell them they would be foolish to commandeer
>   | %#s for anything other than what existing practice has.
> 
> Which worked how well with %b ?

As Geoff commented on 1771, if someone had raised the issue about %b
conflicting 6 months sooner, and pointed out the ksh extension of
%..d as an alternative, we may have had time to do so.
https://austingroupbugs.net/view.php?id=1771#c6453

But because the Austin Group learned about the conflict so late in the
game, we were already too late to push back on C2x at the time,
putting us instead into the camp of seeing what consensus we could get
from shell developers.  This thread (and others like it) have been
helpful - we DID get consensus (namely, that printf(1) and printf(3)
have always diverged, so diverging further on %b is okay), and today's
Austin Group meeting we updated what will go into Issue 8 based on
that feedback.

I consider that to be a successful outcome, even if you may have felt
heartburn through the intermediate stages of it all.

> 
> Further, upon reflection, I think a better use of %#s in printf(1)
> (no point in printf(3)) would be to explicity output a string of
> bytes (what %s used to do, before it was reinterpreted to output
> characters instead).   While the two might seem to be mostly the
> same, that depends upon the implementation - if an implementation
> treats strings of characters as arrays of wchar_t, and converts
> from byte encoding to wchar_t on input, there's no guarantee that
> the output (converted back from wchar_t to byte encoding) will be
> identical to the input string.   Sometimes that might not be
> desirable and a method to simply copy the input string to the
> output, as uninterpreted bytes might be useful to have.  To me
> that is a better use of %#s than as a %b clone - particularly
> as %b needs the same kind of variant (%#b).   This also deals
> with the precision issue, %.1s is 1 character fr9m the arg
> string, %#.1s is one byte instead.

That is indeed a cool idea, but one for the libc folks to take up.  At
any rate, I agree that burning %#s to be a synonym for %b precludes
this useful idea (and it may be even more important in shell contexts,
now that Issue 8 has taken efforts to make it clear that sometimes the
shell deals with characters, and sometimes with bytes; in particular,
environment variables can hold bytes that need not always form
characters in the current locale).

> 
> If there were to be anything worthy of announcing as deprecated
> from posix printf(1) it would be %c - then we could make %c be
> compat with its printf(3) meaning, where it takes a codepoint
> as an int (just 8 bits in printf(3) but we don't neet to retain
> that restriction) and outputs the associated character, rather
> than just being an (almost) alias for %.1s -- where the almost
> is because given '' as the arg string, %c is permitted to output
> \0 or nothing, where %.1s is required to output nothing.  Because
> it is unspecified which happens with %c, portable applications
> cannot rely upon either behaviour, so %.1s is a much safer and
> more portable format to use for the purpose.   

Re: [PATCH] printf: add %#s alias to %b

[Eric Blake]

On Thu, Sep 07, 2023 at 11:53:54PM +0700, Robert Elz wrote:
> And for those who have been following this issue, the new text for
> the forthcoming POSIX version has removed any mention of obsoleting
> %b from printf(1) - instead it will simply note that there is will be
> a difference between printf(1) and printf(3) once the latter gets its
> version of %b specified (in C23, and in POSIX, in the next major version
> that follows the coming one, almost certainly) - and to encourage
> implementors to consider possible solutions.
> 
> I've considered, and I don't see a problem needing solving, so I'm
> intending to do precisely nothing, unless someone actually finds a
> need for binary output from printf(1), which seems unlikely to
> ever happen to me (I mean a real need, not just to be the same as printf(3)
> "just because").
> 
> So, we can all go back to sleep now - and Chet, I'd undo $#s before it
> appears in a release, there's no need, and having it might eventually
> just cause more backward compat issues.

Indeed, at this point, even though I proposed a patch for %#s in
coreutils, I'm inclined to NOT apply it there.

The ksh extension of %..2d to output in binary does sound worth
replicating; I wonder if glibc would consider putting that in their
printf(3); and I could see adding it to Coreutils (whether or not bash
adds it - because ksh already has it).

And thanks for pointing out the existing discrepancy with %c; that was
really helpful in today's Austin Group meeting in realizing that
conflicts in Issue 9 regarding %b is not covering new ground.

> 
> And wrt:
>   | I don't know what potential uppercase/lowercase pairs of format specifiers
>   | are free from use in any existing POSIX-like shell, but my suggestion 
> would
> 
> There are none, printf(3) belongs to the C committee, and they can make
> use of anything they like, at any time they like.
> 
> The best we can do is use formats that make no sense for printf(1) to
> support (like %p, which in printf(3) prints a pointer value, but in
> printf(1) there are no (meaningful) pointers that it could ever make
> sense to print, so %p is useless for its printf(3) purpose in printf(1).
> 
> Similarly all the size modifier chars are meaningless for printf(1), as
> all the numeric values it is passed are actually strings - what internal
> format they're converted into is unrelated to anything the printf(1) user
> can control, so none of those size modifiers mean anything to printf(1)
> either (but it seems that many of those have been usurped by various
> printf(1) implementations already, so finding something free that everyone
> could use, isn't easy).

Here, I slightly disagree with you.

Right now, both bash and coreutils' 'printf %hhd 257' outputs "257",
but printf("%hhd", 257) in C outputs 1.  I would LOVE to have a mode
(possibly spelled 'printf -C %hhd 257') where I can ensure that width
modifiers are applied to the integer value obtained from the correct
subsequent argument to printf.

[Side note: since bash also supports 'printf a%n b >/dev/null' as a
convoluted way of accomplishing 'b=1', I wonder if it would be
possible to port https://github.com/carlini/printf-tac-toe which
performs an interactive game of tic-tac-toe in a single printf(3)
statement invoked in a while loop into a single printf(1) command line
invocation. The lack of %hhd implicitly masking with 256 makes it
harder]

That is, if we are thinking about adding 'printf -c' or 'printf -C' as
a way to say "treat my format string as closely to C as possible", we
would be addressing MULTIPLE things at once: %b, %c, %hhd, and any
other (useful) conversion specifier in C.  And given that, I prefer
naming such an extension option -C or -c (implying C-like), rather
than your suggestion of -b (implying binary, but where the implication
only benefits %b) as a better option name for such a printf extension
option.

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

Re: [PATCH] printf: add %#s alias to %b

[Robert Elz]

And for those who have been following this issue, the new text for
the forthcoming POSIX version has removed any mention of obsoleting
%b from printf(1) - instead it will simply note that there is will be
a difference between printf(1) and printf(3) once the latter gets its
version of %b specified (in C23, and in POSIX, in the next major version
that follows the coming one, almost certainly) - and to encourage
implementors to consider possible solutions.

I've considered, and I don't see a problem needing solving, so I'm
intending to do precisely nothing, unless someone actually finds a
need for binary output from printf(1), which seems unlikely to
ever happen to me (I mean a real need, not just to be the same as printf(3)
"just because").

So, we can all go back to sleep now - and Chet, I'd undo $#s before it
appears in a release, there's no need, and having it might eventually
just cause more backward compat issues.

And wrt:
  | I don't know what potential uppercase/lowercase pairs of format specifiers
  | are free from use in any existing POSIX-like shell, but my suggestion would

There are none, printf(3) belongs to the C committee, and they can make
use of anything they like, at any time they like.

The best we can do is use formats that make no sense for printf(1) to
support (like %p, which in printf(3) prints a pointer value, but in
printf(1) there are no (meaningful) pointers that it could ever make
sense to print, so %p is useless for its printf(3) purpose in printf(1).

Similarly all the size modifier chars are meaningless for printf(1), as
all the numeric values it is passed are actually strings - what internal
format they're converted into is unrelated to anything the printf(1) user
can control, so none of those size modifiers mean anything to printf(1)
either (but it seems that many of those have been usurped by various
printf(1) implementations already, so finding something free that everyone
could use, isn't easy).

kre

Re: Prompt messed up if PS1 contains ANSI escape sequences

[alex xmb ratchev]

On Thu, Sep 7, 2023, 17:41 Kerin Millar  wrote:

> On Thu, 7 Sep 2023 17:33:45 +0200
> alex xmb ratchev  wrote:
>
> > On Thu, Sep 7, 2023, 16:51 Kerin Millar  wrote:
> >
> > > On Thu, 7 Sep 2023 15:53:03 +0200
> > > alex xmb ratchev  wrote:
> > >
> > > > On Thu, Sep 7, 2023, 15:46 Gioele Barabucci 
> wrote:
> > > >
> > > > > On 07/09/23 15:00, alex xmb ratchev wrote:
> > > > > > u have to \[ esc-seq \]
> > > > > > eg inside \[ and \]
> > > > > >
> > > > > > PS1=$'\u\[\e[1m\]\h\[\e[0m- '
> > > > > >
> > > > > > should display hostname bold
> > > > >
> > > > > Thanks for the suggestion, but adding \] does not really fix the
> > > > > problem, it just masks it in many cases (better than nothing).
> > > > >
> > > > > Try:
> > > > >
> > > > > $ long_name="$(printf 'abcdef0123456789/%.0s' {0..20})"
> > > > > $ mkdir -p /tmp/$long_name
> > > > > $ cd /tmp/$long_name
> > > > > $ PS1='\n\[\e[1m\]\w\[\e[m\] \$ '
> > > > >
> > > >
> > > > foo=$' .. '
> > > > not
> > > > foo=' .. '
> > >
> > > $'' quoting is not required for that particular definition of PS1.
> > >
> >
> > o cause \e gets expanded .. ? didnt know ..
>
> Yes. \n also.
>

n was clear e was new
.. thxx .. greets ..

-- 
> Kerin Millar
>

Re: Prompt messed up if PS1 contains ANSI escape sequences

[Kerin Millar]

On Thu, 7 Sep 2023 17:33:45 +0200
alex xmb ratchev  wrote:

> On Thu, Sep 7, 2023, 16:51 Kerin Millar  wrote:
> 
> > On Thu, 7 Sep 2023 15:53:03 +0200
> > alex xmb ratchev  wrote:
> >
> > > On Thu, Sep 7, 2023, 15:46 Gioele Barabucci  wrote:
> > >
> > > > On 07/09/23 15:00, alex xmb ratchev wrote:
> > > > > u have to \[ esc-seq \]
> > > > > eg inside \[ and \]
> > > > >
> > > > > PS1=$'\u\[\e[1m\]\h\[\e[0m- '
> > > > >
> > > > > should display hostname bold
> > > >
> > > > Thanks for the suggestion, but adding \] does not really fix the
> > > > problem, it just masks it in many cases (better than nothing).
> > > >
> > > > Try:
> > > >
> > > > $ long_name="$(printf 'abcdef0123456789/%.0s' {0..20})"
> > > > $ mkdir -p /tmp/$long_name
> > > > $ cd /tmp/$long_name
> > > > $ PS1='\n\[\e[1m\]\w\[\e[m\] \$ '
> > > >
> > >
> > > foo=$' .. '
> > > not
> > > foo=' .. '
> >
> > $'' quoting is not required for that particular definition of PS1.
> >
> 
> o cause \e gets expanded .. ? didnt know ..

Yes. \n also.

-- 
Kerin Millar

Re: Prompt messed up if PS1 contains ANSI escape sequences

[alex xmb ratchev]

On Thu, Sep 7, 2023, 16:51 Kerin Millar  wrote:

> On Thu, 7 Sep 2023 15:53:03 +0200
> alex xmb ratchev  wrote:
>
> > On Thu, Sep 7, 2023, 15:46 Gioele Barabucci  wrote:
> >
> > > On 07/09/23 15:00, alex xmb ratchev wrote:
> > > > u have to \[ esc-seq \]
> > > > eg inside \[ and \]
> > > >
> > > > PS1=$'\u\[\e[1m\]\h\[\e[0m- '
> > > >
> > > > should display hostname bold
> > >
> > > Thanks for the suggestion, but adding \] does not really fix the
> > > problem, it just masks it in many cases (better than nothing).
> > >
> > > Try:
> > >
> > > $ long_name="$(printf 'abcdef0123456789/%.0s' {0..20})"
> > > $ mkdir -p /tmp/$long_name
> > > $ cd /tmp/$long_name
> > > $ PS1='\n\[\e[1m\]\w\[\e[m\] \$ '
> > >
> >
> > foo=$' .. '
> > not
> > foo=' .. '
>
> $'' quoting is not required for that particular definition of PS1.
>

o cause \e gets expanded .. ? didnt know ..

cheers

-- 
> Kerin Millar
>

Re: key "x" doesn't print out the "x", only "CTRL-V x" does.

[Chet Ramey]

On 9/7/23 8:17 AM, detlef.bier...@posteo.de wrote:


Bash Version: 5.1
Patch Level: 16
Release Status: release

Description:

When pressing the "x" key, no letter appears, with the combination "CTRL-v x" the 
"x" appears.
The key only works in bash, in sh, in the X server as well, in all graphic 
applications as well, as well as in the editors nano, joe, etc.
If this works, please send me the instructions. THANKS!


You have `x' bound to a readline command other than self-insert, or you
have it bound to one of the stty special characters.

Check the first by looking at the output of

bind -p | grep '^\"x"';

check the second by looking at the output of `stty -a'.

--
``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: command substitution when timing grouped commands fails

[Kerin Millar]

On Thu, 07 Sep 2023 05:50:49 -0700
hacke...@member.fsf.org wrote:

> Configuration Information [Automatically generated, do not change]:
> Machine: x86_64
> OS: linux-gnu
> Compiler: gcc
> Compilation CFLAGS: -g -O2 -fstack-protector-strong -Wformat 
> -Werror=format-security -Wall
> uname output: Linux abyssal 6.4.0-3-amd64 #1 SMP PREEMPT_DYNAMIC Debian 
> 6.4.11-1 (2023-08-17) x86_64 GNU/Linux
> Machine Type: x86_64-pc-linux-gnu
> 
> Bash Version: 5.2
> Patch Level: 15
> Release Status: release
> 
> Description:
> 
>   Bash gives a syntax error when using the $(...) form of
>   command substitution and timing grouped commands.
> 
>   However, Bash works correctly when using the `...` form of
>   command substitution.
> 
> 
> Repeat-By:
> 
>   The 'time' built-in command can measure a group of commands
>   run in a subshell, for example:
> 
>   $ time (date; sleep 1)
>   Thu Sep  7 05:19:21 AM PDT 2023
> 
>   real0m1.005s
>   user0m0.003s
>   sys 0m0.001s
> 
>   Attempting to save the output of time to a variable fails when
>   using $(...) command substitution. For example,
> 
>   $ x=$( time ( date; sleep 1 ) 2>&1 )
>   -bash: syntax error near unexpected token `date'
> 
>   However, old versions of bash (~2016) used to work correctly.
>   And, indeed, even the current version of bash works if one
>   uses backticks for command substitution.
> 
>   $ x=` time ( date; sleep 1 ) 2>&1 `
>   $   # no error
> 
>   There should be no difference between $(...) and `...`.

This issue, which affects 5.2, was previously reported here:

https://lists.gnu.org/archive/html/bug-bash/2023-08/msg00124.html

It was fixed in the devel branch in the fashion described by:

https://lists.gnu.org/archive/html/bug-bash/2023-09/msg00013.html

The issue has not yet been addressed by any available 5.2 patchlevel. Should 
you wish to patch 5.2 yourself - as I did - apply the above-mentioned change 
while ignoring the addition of "case DOLBRACE:".

-- 
Kerin Millar

Re: give_terminal_to() / maybe_give_terminal_to() race

[Earl Chew]

On 2023-09-05 08:46, Chet Ramey wrote:

Such as? If the parent doesn't need to change the terminal process group,
synchronizes with the pipeline via waitpid(), and doesn't attempt to change
the terminal process group back until all children in that process group
have stopped or exited, what consequences are of concern?


I think the only other side-effects relate to IO (eg SIGTTIN, SIGTTOU),
but as far as I can tell these are not of concern since the parent stays
quiet until the foreground job either stops or completes.


Given that the children must synchronise before exec(), there is no
issue if all configure the terminal though it is sufficient
if only the first child does so.


Not true; ...


You're right, I have that backwards. If only one child configures the
terminal, then the siblings must wait until that child has completed
doing so before they invoke exec(). Rather than do that, given that
subsequent invocations of give_terminal_to() (ie tcsetpgrp()) by siblings
will find the foreground group already configured, it makes sense to
simply let every sibling do so.

Earl

Re: Prompt messed up if PS1 contains ANSI escape sequences

[Kerin Millar]

On Thu, 7 Sep 2023 15:53:03 +0200
alex xmb ratchev  wrote:

> On Thu, Sep 7, 2023, 15:46 Gioele Barabucci  wrote:
> 
> > On 07/09/23 15:00, alex xmb ratchev wrote:
> > > u have to \[ esc-seq \]
> > > eg inside \[ and \]
> > >
> > > PS1=$'\u\[\e[1m\]\h\[\e[0m- '
> > >
> > > should display hostname bold
> >
> > Thanks for the suggestion, but adding \] does not really fix the
> > problem, it just masks it in many cases (better than nothing).
> >
> > Try:
> >
> > $ long_name="$(printf 'abcdef0123456789/%.0s' {0..20})"
> > $ mkdir -p /tmp/$long_name
> > $ cd /tmp/$long_name
> > $ PS1='\n\[\e[1m\]\w\[\e[m\] \$ '
> >
> 
> foo=$' .. '
> not
> foo=' .. '

$'' quoting is not required for that particular definition of PS1.

-- 
Kerin Millar

Re: Prompt messed up if PS1 contains ANSI escape sequences

[Gioele Barabucci]

On 07/09/23 16:24, Gioele Barabucci wrote:

On 07/09/23 16:15, Greg Wooledge wrote:

On Thu, Sep 07, 2023 at 04:03:39PM +0200, Gioele Barabucci wrote:
The following snippet shows that, even with the final \], Bash 
produces the
same erroneous output and miscalculates the cursor position (it just 
needs a

longer prompt):

 $ long_name="$(printf 'abcdef0123456789/%.0s' {0..20})"
 $ mkdir -p /tmp/$long_name
 $ cd /tmp/$long_name
 $ PS1=$'\n\[\e[1m\]\w\[\e[m\] \$ '

 Now press the up arrow, then the down arrow)


Have you tried testing with several different terminal emulators? 


Yes. I tried with xterm, gnome-terminal and the native Linux VT. They 
all show the same problem.


In the heat of the testing I mistakenly used bash 5.0, not bash 5.2.

Bash 5.2.12 does not show this problem.

Regards,

--
Gioele Barabucci

Re: Prompt messed up if PS1 contains ANSI escape sequences

[alex xmb ratchev]

On Thu, Sep 7, 2023, 16:26 Andreas Kähäri  wrote:

> On Thu, Sep 07, 2023 at 04:03:39PM +0200, Gioele Barabucci wrote:
> > On 07/09/23 15:50, Greg Wooledge wrote:
> > > On Thu, Sep 07, 2023 at 03:46:23PM +0200, Gioele Barabucci wrote:
> > > > On 07/09/23 15:00, alex xmb ratchev wrote:
> > > > > u have to \[ esc-seq \]
> > > > > eg inside \[ and \]
> > > > >
> > > > > PS1=$'\u\[\e[1m\]\h\[\e[0m- '
> > > > >
> > > > > should display hostname bold
> > > >
> > > > Thanks for the suggestion, but adding \] does not really fix the
> problem, it
> > > > just masks it in many cases (better than nothing).
> > >
> > > The \[ \] wrappings are required.  They're not "masking" the problem.
> > > Your prompt is literally set incorrectly without them.
> >
> > Agreed that \] is required. With "masking" I mean that the use of \]
> > prevents the problem I'm referring to from showing up easily. But the
> > problem is still there even when \] is used.
> >
> > The following snippet shows that, even with the final \], Bash produces
> the
> > same erroneous output and miscalculates the cursor position (it just
> needs a
> > longer prompt):
> >
> > $ long_name="$(printf 'abcdef0123456789/%.0s' {0..20})"
> > $ mkdir -p /tmp/$long_name
> > $ cd /tmp/$long_name
> > $ PS1=$'\n\[\e[1m\]\w\[\e[m\] \$ '
> >
> > Now press the up arrow, then the down arrow)
> >
> > Regards,
> >
> > --
> > Gioele Barabucci
>
> I can't really reproduce the issue that you are seeing, but isn't the \n
> (the newline) also a non-printable character that should be wrapped in
> \[ \], since it has no width?
>

just from my past trying with multiline prompts , no , only esc seq
bash may parse \n there specially , for internal use .. displayment

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

Re: Prompt messed up if PS1 contains ANSI escape sequences

[Andreas Kähäri]

On Thu, Sep 07, 2023 at 04:03:39PM +0200, Gioele Barabucci wrote:
> On 07/09/23 15:50, Greg Wooledge wrote:
> > On Thu, Sep 07, 2023 at 03:46:23PM +0200, Gioele Barabucci wrote:
> > > On 07/09/23 15:00, alex xmb ratchev wrote:
> > > > u have to \[ esc-seq \]
> > > > eg inside \[ and \]
> > > > 
> > > > PS1=$'\u\[\e[1m\]\h\[\e[0m- '
> > > > 
> > > > should display hostname bold
> > > 
> > > Thanks for the suggestion, but adding \] does not really fix the problem, 
> > > it
> > > just masks it in many cases (better than nothing).
> > 
> > The \[ \] wrappings are required.  They're not "masking" the problem.
> > Your prompt is literally set incorrectly without them.
> 
> Agreed that \] is required. With "masking" I mean that the use of \]
> prevents the problem I'm referring to from showing up easily. But the
> problem is still there even when \] is used.
> 
> The following snippet shows that, even with the final \], Bash produces the
> same erroneous output and miscalculates the cursor position (it just needs a
> longer prompt):
> 
> $ long_name="$(printf 'abcdef0123456789/%.0s' {0..20})"
> $ mkdir -p /tmp/$long_name
> $ cd /tmp/$long_name
> $ PS1=$'\n\[\e[1m\]\w\[\e[m\] \$ '
> 
> Now press the up arrow, then the down arrow)
> 
> Regards,
> 
> -- 
> Gioele Barabucci

I can't really reproduce the issue that you are seeing, but isn't the \n
(the newline) also a non-printable character that should be wrapped in
\[ \], since it has no width?

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

.

Re: Prompt messed up if PS1 contains ANSI escape sequences

[Gioele Barabucci]

On 07/09/23 16:15, Greg Wooledge wrote:

On Thu, Sep 07, 2023 at 04:03:39PM +0200, Gioele Barabucci wrote:

The following snippet shows that, even with the final \], Bash produces the
same erroneous output and miscalculates the cursor position (it just needs a
longer prompt):

 $ long_name="$(printf 'abcdef0123456789/%.0s' {0..20})"
 $ mkdir -p /tmp/$long_name
 $ cd /tmp/$long_name
 $ PS1=$'\n\[\e[1m\]\w\[\e[m\] \$ '

 Now press the up arrow, then the down arrow)


Have you tried testing with several different terminal emulators? 


Yes. I tried with xterm, gnome-terminal and the native Linux VT. They 
all show the same problem.


--
Gioele Barabucci

Re: Prompt messed up if PS1 contains ANSI escape sequences

[Greg Wooledge]

On Thu, Sep 07, 2023 at 04:03:39PM +0200, Gioele Barabucci wrote:
> The following snippet shows that, even with the final \], Bash produces the
> same erroneous output and miscalculates the cursor position (it just needs a
> longer prompt):
> 
> $ long_name="$(printf 'abcdef0123456789/%.0s' {0..20})"
> $ mkdir -p /tmp/$long_name
> $ cd /tmp/$long_name
> $ PS1=$'\n\[\e[1m\]\w\[\e[m\] \$ '
> 
> Now press the up arrow, then the down arrow)

I did this in bash 5.2.15 (Debian 12 package version 5.2.15-2+b2) in
rxvt-unicode (Debian 12 package version 9.30-2+b4), and I can't see
whatever problem you're reporting.  Typing a long command (one which
goes past the 80th column and scrolls the terminal's text upward) and
then backspacing all of it acts as expected.  As does pressing up arrow
until a sufficiently long command is recalled from history.

Have you tried testing with several different terminal emulators?  Be
sure to include xterm among them, as that one tends to be extremely
well-behaved in situations where the big fancy ones are not.  I'm a fan
of rxvt or rxvt-unicode, which have both been kind to me, but good old
xterm should always be considered.

Re: Prompt messed up if PS1 contains ANSI escape sequences

[Gioele Barabucci]

On 07/09/23 15:50, Greg Wooledge wrote:

On Thu, Sep 07, 2023 at 03:46:23PM +0200, Gioele Barabucci wrote:

On 07/09/23 15:00, alex xmb ratchev wrote:

u have to \[ esc-seq \]
eg inside \[ and \]

PS1=$'\u\[\e[1m\]\h\[\e[0m- '

should display hostname bold


Thanks for the suggestion, but adding \] does not really fix the problem, it
just masks it in many cases (better than nothing).


The \[ \] wrappings are required.  They're not "masking" the problem.
Your prompt is literally set incorrectly without them.


Agreed that \] is required. With "masking" I mean that the use of \] 
prevents the problem I'm referring to from showing up easily. But the 
problem is still there even when \] is used.


The following snippet shows that, even with the final \], Bash produces 
the same erroneous output and miscalculates the cursor position (it just 
needs a longer prompt):


$ long_name="$(printf 'abcdef0123456789/%.0s' {0..20})"
$ mkdir -p /tmp/$long_name
$ cd /tmp/$long_name
$ PS1=$'\n\[\e[1m\]\w\[\e[m\] \$ '

Now press the up arrow, then the down arrow)

Regards,

--
Gioele Barabucci

Re: Prompt messed up if PS1 contains ANSI escape sequences

[alex xmb ratchev]

On Thu, Sep 7, 2023, 15:46 Gioele Barabucci  wrote:

> On 07/09/23 15:00, alex xmb ratchev wrote:
> > u have to \[ esc-seq \]
> > eg inside \[ and \]
> >
> > PS1=$'\u\[\e[1m\]\h\[\e[0m- '
> >
> > should display hostname bold
>
> Thanks for the suggestion, but adding \] does not really fix the
> problem, it just masks it in many cases (better than nothing).
>
> Try:
>
> $ long_name="$(printf 'abcdef0123456789/%.0s' {0..20})"
> $ mkdir -p /tmp/$long_name
> $ cd /tmp/$long_name
> $ PS1='\n\[\e[1m\]\w\[\e[m\] \$ '
>

foo=$' .. '
not
foo=' .. '

(Adapted from .)
>
> Now press up to recall the last command and press down to go back to an
> empty command line. Various stray characters will still be visible and
> the cursor will be in the wrong place.
>
> Also try to type any command (say `echo`) and you will notice that "cho"
> ends up displayed in the wrong line.
>
> Regards,
>
> --
> Gioele Barabucci
>

Re: Prompt messed up if PS1 contains ANSI escape sequences

[Greg Wooledge]

On Thu, Sep 07, 2023 at 03:46:23PM +0200, Gioele Barabucci wrote:
> On 07/09/23 15:00, alex xmb ratchev wrote:
> > u have to \[ esc-seq \]
> > eg inside \[ and \]
> > 
> > PS1=$'\u\[\e[1m\]\h\[\e[0m- '
> > 
> > should display hostname bold
> 
> Thanks for the suggestion, but adding \] does not really fix the problem, it
> just masks it in many cases (better than nothing).

The \[ \] wrappings are required.  They're not "masking" the problem.
Your prompt is literally set incorrectly without them.

>From the man page:

PROMPTING
[...]
  \[ begin  a sequence of non-printing characters, which could
 be used to embed a terminal  control  sequence  into  the
 prompt
  \] end a sequence of non-printing characters

See also  for more details.

Re: Prompt messed up if PS1 contains ANSI escape sequences

[Gioele Barabucci]

On 07/09/23 15:00, alex xmb ratchev wrote:

u have to \[ esc-seq \]
eg inside \[ and \]

PS1=$'\u\[\e[1m\]\h\[\e[0m- '

should display hostname bold


Thanks for the suggestion, but adding \] does not really fix the 
problem, it just masks it in many cases (better than nothing).


Try:

$ long_name="$(printf 'abcdef0123456789/%.0s' {0..20})"
$ mkdir -p /tmp/$long_name
$ cd /tmp/$long_name
$ PS1='\n\[\e[1m\]\w\[\e[m\] \$ '

(Adapted from .)

Now press up to recall the last command and press down to go back to an 
empty command line. Various stray characters will still be visible and 
the cursor will be in the wrong place.


Also try to type any command (say `echo`) and you will notice that "cho" 
ends up displayed in the wrong line.


Regards,

--
Gioele Barabucci

Re: [PATCH] printf: add %#s alias to %b

[Zachary Santer]

The trouble with using an option flag to printf(1) to toggle the meaning of
%b is that you can't then mix format specifiers for binary literals and
backslash escape expansion within the same format string. You'd just have
to call printf(1) multiple times, which largely defeats the purpose of a
format string.

I don't know what potential uppercase/lowercase pairs of format specifiers
are free from use in any existing POSIX-like shell, but my suggestion would
be settling on one of those to take on the meaning of C2x's %b. They'd
still print '0b' or '0B' in the resulting binary literal when given the #
flag, which might be a little confusing, but this seems like the safest way
to go. It obviously still represents a divergence from C2x's printf(3), but
I think the consensus is that that's going to happen regardless.

ksh's format specifiers for arbitrary-base integer representation sound
really slick, and I'd love to see that in Bash, too, actually.

Zack

command substitution when timing grouped commands fails

[hackerb9]

Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -g -O2 -fstack-protector-strong -Wformat 
-Werror=format-security -Wall
uname output: Linux abyssal 6.4.0-3-amd64 #1 SMP PREEMPT_DYNAMIC Debian 
6.4.11-1 (2023-08-17) x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu

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

Description:

Bash gives a syntax error when using the $(...) form of
command substitution and timing grouped commands.

However, Bash works correctly when using the `...` form of
command substitution.


Repeat-By:

The 'time' built-in command can measure a group of commands
run in a subshell, for example:

$ time (date; sleep 1)
Thu Sep  7 05:19:21 AM PDT 2023

real0m1.005s
user0m0.003s
sys 0m0.001s

Attempting to save the output of time to a variable fails when
using $(...) command substitution. For example,

$ x=$( time ( date; sleep 1 ) 2>&1 )
-bash: syntax error near unexpected token `date'

However, old versions of bash (~2016) used to work correctly.
And, indeed, even the current version of bash works if one
uses backticks for command substitution.

$ x=` time ( date; sleep 1 ) 2>&1 `
$   # no error

There should be no difference between $(...) and `...`.

Re: Prompt messed up if PS1 contains ANSI escape sequences

[alex xmb ratchev]

sorry \] missing bug

PS1=$'\u\[\e[1m\]\h\[\e[0m\]- '

On Thu, Sep 7, 2023, 15:00 alex xmb ratchev  wrote:

> u have to \[ esc-seq \]
> eg inside \[ and \]
>
> PS1=$'\u\[\e[1m\]\h\[\e[0m- '
>
> should display hostname bold
>
> On Thu, Sep 7, 2023, 14:55 Gioele Barabucci  wrote:
>
>> Bash 5.2.15 (Debian 12) will produce erroneous output when PS1 contains
>> escape sequences. It will also misplace the cursor and corrupt the state
>> of the current line.
>>
>> To replicate this issue:
>>
>> 1. Modify PS1 to contain one or more ANSI escape sequences, for example
>> "\e[45m" (tput setab 5, changes the background color to purple) or
>> "\e(B\e[m" (tput sgr0, reset for xterm terminals):
>>
>>  $ PS1="x$(printf '\e(B\e[m') \\\$ "
>>
>> 2. Press the up arrow to recall the last command. The command line will
>> now show [■ indicates the position of the cursor]:
>>
>>  x $ PS1="x$(printf '\e(B\e[m') \\\$ "■
>>
>> 3. Press the down arrow to go back to the empty prompt.
>>
>> What one should see at this point is just the prompt
>>
>>  x $ ■
>>
>> Instead, left-overs from the recalled line will be visible and the
>> cursor will be placed in the wrong spot:
>>
>>  x $ PS1="x■
>>
>> The amount of garbage left on the prompt is proportional to the number
>> of escape sequences:
>>
>> PS1="x$(printf '\e(B\e[m')\\\$ " => 6 left-over chars
>> PS1="x$(printf '\e(B\e[m%.0s' {1..2})\\\$ " => 12 left-over chars
>> PS1="x$(printf '\e(B\e[m%.0s' {1..4})\\\$ " => 24 left-over chars
>>
>> Tested with TERM = linux, xterm, xterm-256color.
>>
>> Regards,
>>
>> (This bug has also been reported at .)
>>
>> --
>> Gioele Barabucci
>>
>>

Re: Prompt messed up if PS1 contains ANSI escape sequences

[alex xmb ratchev]

u have to \[ esc-seq \]
eg inside \[ and \]

PS1=$'\u\[\e[1m\]\h\[\e[0m- '

should display hostname bold

On Thu, Sep 7, 2023, 14:55 Gioele Barabucci  wrote:

> Bash 5.2.15 (Debian 12) will produce erroneous output when PS1 contains
> escape sequences. It will also misplace the cursor and corrupt the state
> of the current line.
>
> To replicate this issue:
>
> 1. Modify PS1 to contain one or more ANSI escape sequences, for example
> "\e[45m" (tput setab 5, changes the background color to purple) or
> "\e(B\e[m" (tput sgr0, reset for xterm terminals):
>
>  $ PS1="x$(printf '\e(B\e[m') \\\$ "
>
> 2. Press the up arrow to recall the last command. The command line will
> now show [■ indicates the position of the cursor]:
>
>  x $ PS1="x$(printf '\e(B\e[m') \\\$ "■
>
> 3. Press the down arrow to go back to the empty prompt.
>
> What one should see at this point is just the prompt
>
>  x $ ■
>
> Instead, left-overs from the recalled line will be visible and the
> cursor will be placed in the wrong spot:
>
>  x $ PS1="x■
>
> The amount of garbage left on the prompt is proportional to the number
> of escape sequences:
>
> PS1="x$(printf '\e(B\e[m')\\\$ " => 6 left-over chars
> PS1="x$(printf '\e(B\e[m%.0s' {1..2})\\\$ " => 12 left-over chars
> PS1="x$(printf '\e(B\e[m%.0s' {1..4})\\\$ " => 24 left-over chars
>
> Tested with TERM = linux, xterm, xterm-256color.
>
> Regards,
>
> (This bug has also been reported at .)
>
> --
> Gioele Barabucci
>
>

Prompt messed up if PS1 contains ANSI escape sequences

[Gioele Barabucci]

Bash 5.2.15 (Debian 12) will produce erroneous output when PS1 contains 
escape sequences. It will also misplace the cursor and corrupt the state 
of the current line.


To replicate this issue:

1. Modify PS1 to contain one or more ANSI escape sequences, for example 
"\e[45m" (tput setab 5, changes the background color to purple) or 
"\e(B\e[m" (tput sgr0, reset for xterm terminals):


$ PS1="x$(printf '\e(B\e[m') \\\$ "

2. Press the up arrow to recall the last command. The command line will 
now show [■ indicates the position of the cursor]:


x $ PS1="x$(printf '\e(B\e[m') \\\$ "■

3. Press the down arrow to go back to the empty prompt.

What one should see at this point is just the prompt

x $ ■

Instead, left-overs from the recalled line will be visible and the 
cursor will be placed in the wrong spot:


x $ PS1="x■

The amount of garbage left on the prompt is proportional to the number 
of escape sequences:


PS1="x$(printf '\e(B\e[m')\\\$ " => 6 left-over chars
PS1="x$(printf '\e(B\e[m%.0s' {1..2})\\\$ " => 12 left-over chars
PS1="x$(printf '\e(B\e[m%.0s' {1..4})\\\$ " => 24 left-over chars

Tested with TERM = linux, xterm, xterm-256color.

Regards,

(This bug has also been reported at .)

--
Gioele Barabucci

key "x" doesn't print out the "x", only "CTRL-V x" does.

[detlef . bieritz]

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 db2 5.15.0-83-generic #92-Ubuntu SMP Mon Aug 14 09:30:42 
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:

When pressing the "x" key, no letter appears, with the combination "CTRL-v x" 
the "x" appears.
The key only works in bash, in sh, in the X server as well, in all graphic 
applications as well, as well as in the editors nano, joe, etc.
If this works, please send me the instructions. THANKS!

(translation by google)

Re: [PATCH] printf: add %#s alias to %b

[Robert Elz]

Date:Wed, 6 Sep 2023 11:03:25 -0500
From:Eric Blake 
Message-ID:  


  | If we do nothing now for Issue 8, then Issue 9 WILL have a conflict
  | between printf(1) and printf(3).

Yes.

  | If we reach out to all developers now, we can start the discussion,

That would be reasonable, but shoving wording in the draft standard,
more or less at the last minute, is not the way to accomplish that.

  | - Do nothing; printf(1) and printf(3) have incompatible %b

Since that is the only sane outcome here (one caveat below excepted)
and doesn't require I8 to list %b as deprecated to do it, seems like
it would be better not to do that.

  | - Declare that %b has implementation-defined behavior (shell authors
  |   have the choice on whether %b has old or new behavior)

That's a horrid suggestion, no-one would (should) support that.

  | - Declare that %b is no longer standardized (but implementations can
  |   still provide it as an extension, using their choice of behavior)

We could do that, but what would be the point - just avoiding having
a "conflict" in the standard between printf(1) and printf(3).   Who cares?
We already have one of those with %c and no-one seems to mind (but should,
as fixing that one would actually be useful).

  | - Standardize %#s to do the same thing as %b used to do

We could do that in I9, but that doesn't require deprecating %b.
Of course, if %b remains, there's no point, and it isn't really a
good idea anyway.

  | - Standardize 'printf -c %b 1' which parses its format string
  |   according to C23 rules (output "0b1"), while 'printf %b 1' remains
  |   the old way (output "1")

That one is actually a reasonable suggestion, for any implementation
which feels like it should have a way to make %b output binary numbers
(if someone has an actual need for that, and there isn't a better way
in the meantime).   Any implementation can do that at any time, and it
could be added in I9 if there's support for it (actual implementations
doing it) - and doesn't need %b (the old one) to be deprecated.   This
is just new functionality - initially outside the realm of the standard,
as -c isn't a defined option flag, so implementations can use that to
change the operation any way they like - and it is simply new functionality
for posix if it is deemed worth of incorporation into I9 (or something later).


The only rational one of you options for what to do, which seems fairly
comprehensive, which requires is the one which simply remove

  | But for that work, Issue 8 has to do something - it marks %b
  | obsolescent, merely so that we have the option (not the mandate) to
  | change its behavior in the future.

The only rational one of you options for what to do, which seems fairly
comprehensive, which requires %b listed as obsolescent is the one which
simply removes %b from the standard.

Should that ever happen, you can expect a bug report asking for %b to be
added to the standard the next day (in the form it currently has) - as it
is universally supported (all implementations), and widely used by
applications - it meets all of the requirements for a new feature to be
added.   So you can remove it in D1 of I9, but it will just be back again
in D2.   What would be the point?

  | It may turn out that there is
  | enough resistance that the answer is no change to behavior,

That has already happened, no-one is going to remove %b as it now is.
That means, that apart from the possibility of adding an option to
alter its meaning (like your -c suggestion - though I'd probably suggest
-b for binary 'b' rather than linking it to C printf(3)) there is no
point at all making %b obsolete in I8.   It is already clear that is
never going to happen.

  | Adding %#s as a synonym to %b seems easy enough to do,

It is, but it is not really safe, and as I indicated in the previous message,
there is a better use for %#s we could invent (perhaps) if we're willing
to either gamble that the C people won't define a meaning for it, or
without having any idea what that meaning might be, we're willing in
advance to ignore their definition (assuming there is one someday) and
go our own way.   I don't think that's a good idea, so I have decided
I won't be doing that.   If I though there might be a reason to make
an alias for %b (which I don't), I'd use %p instead, that one is safe.

  | what Issue 9 decides to do to %b, so the Austin Group mentioned that
  | as a non-normative idea in the wording for Issue 8.

I wouldn't even hint at it in the standard.

kre

Re: [PATCH] printf: add %#s alias to %b

[Robert Elz]

Date:Wed, 6 Sep 2023 11:32:32 -0500
From:Eric Blake 
Message-ID:  


  | You (anyone reading this, not just kre) are welcome to join tomorrow's
  | Austin Group meeting

Thanks, but I don't expect its time of day will coincide with
mine this week, at best I would be a half asleep zombie.

  |  it is a Zoom call

As best I understand it, zoom does not support NetBSD - which
is the only platform I use, which has been true for decades now
(previously I also used SunOS (not Solaris) and Ultrix).

While probably works on android (ie: phone)  meeting use that
way would not be convenient for anyone - certainly not for me
staring at it all the time, and assuming that it works with
video enabled, not for anyone else with an image moving around
randomly... (my phone has no stand, I haven't been able to
find one which fits it).

  | Or you can add comments to the bug directly.

I have done that already, and probably will add one more.

  | Of course, the gamble is easier to win if we have multiple independent
  | implementations that have all coordinated to do it the same way, so we
  | can push back on WG14 to tell them they would be foolish to commandeer
  | %#s for anything other than what existing practice has.

Which worked how well with %b ?

Further, upon reflection, I think a better use of %#s in printf(1)
(no point in printf(3)) would be to explicity output a string of
bytes (what %s used to do, before it was reinterpreted to output
characters instead).   While the two might seem to be mostly the
same, that depends upon the implementation - if an implementation
treats strings of characters as arrays of wchar_t, and converts
from byte encoding to wchar_t on input, there's no guarantee that
the output (converted back from wchar_t to byte encoding) will be
identical to the input string.   Sometimes that might not be
desirable and a method to simply copy the input string to the
output, as uninterpreted bytes might be useful to have.  To me
that is a better use of %#s than as a %b clone - particularly
as %b needs the same kind of variant (%#b).   This also deals
with the precision issue, %.1s is 1 character fr9m the arg
string, %#.1s is one byte instead.

If there were to be anything worthy of announcing as deprecated
from posix printf(1) it would be %c - then we could make %c be
compat with its printf(3) meaning, where it takes a codepoint
as an int (just 8 bits in printf(3) but we don't neet to retain
that restriction) and outputs the associated character, rather
than just being an (almost) alias for %.1s -- where the almost
is because given '' as the arg string, %c is permitted to output
\0 or nothing, where %.1s is required to output nothing.  Because
it is unspecified which happens with %c, portable applications
cannot rely upon either behaviour, so %.1s is a much safer and
more portable format to use for the purpose.   If %c were
(eventually) altered to take an int (codepoint) as its arg,
rather than a string, we could also stop needing to tell people
they have to use the bizarre printf \\$(printf %o val) nonsense
method to do such a simple operation, which only works for
8 bit codepoints.

kre

Re: set -x vs. n=($@)

[Dan Jacobson]

OK. That's well and good. But my main problem now is that that fact is
not documented anywhere.

(Also here it is again, so as to remove any confusion about "compound
assignment" (some readers might think it meant two ='s on the same line.)

$ bash -c 'set a b c; set -x; m=$@; n=($@)'
+ m='a b c'
+ n=($@)

)
> "CR" == Chet Ramey  writes:
CR> On 9/3/23 6:08 AM, Dan Jacobson wrote:
>> It's not fair:
>> set -x a b c
>> m=$@ n=($@)
>> == gives ==
>> + m='a b c'
>> + n=($@)

CR> It's because the compound assignment forces the expansion to be deferred.
CR> You have to figure out what kind of array you're dealing with, for example,
CR> and what kind of compound assignment, and bash figures all that out after
CR> the `we're performing a variable assignment with xtrace enabled, print the
CR> rhs' code runs.