bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 5.3-alpha: less readable output when set -x


From: Kerin Millar
Subject: Re: 5.3-alpha: less readable output when set -x
Date: Wed, 24 Apr 2024 17:19:27 +0100
User-agent: Cyrus-JMAP/3.11.0-alpha0-386-g4cb8e397f9-fm-20240415.001-g4cb8e397

On Wed, 24 Apr 2024, at 4:34 PM, balducci@units.it wrote:
> hello
>
> Apologies if I am missing some blatant point here
>
> I have noticed a difference in behavior of bash-5.2.26 and
> bash-5.3-alpha which isn't a problem of correctness, but may be wasn't
> intentional(?)
>
> Given the scriptlett:
>
> ----8<----
> #!/bin/sh
> set -x
>
> show () {
>     cat <<EOF
> $1
> EOF
>     return 0
> }
>
> show "
> 1
> 2
> 3
> "
> exit 0
> ----8<----
>
> for me the output is different for the 2 versions:
>
>     bash-5.2.26 :                bash-5.3-alpha :                 
>     ----8<----                   ----8<----                     
>     ##> ./scriptlett.sh          ##> ./scriptlett.sh       
>     + show '                     + show $'\n1\n2\n3\n'          
>     1                            + cat                          
>     2                                                           
>     3                            1                              
>     '                            2                              
>     + cat                        3                              
>                                                                
>     1                            + return 0                     
>     2                            + exit 0                       
>     3                            ---->8----                     
>
>     + return 0
>     + exit 0
>     ---->8----
>
> Note the difference in how the argument to the function is
> output.  In the case of bash-5.3-alpha the syntax of the argument is
> correct (ie if I call the show function with $'\n1\n2\n3\n' everything
> works as expected), but is less readable (and this is more so if the
> argument is a long stretch of lines)
>
> For what I seem to understand, this might be related to:
>
>   ----8<----
>   b. Bash does a better job of preserving user-supplied quotes around a word
>      completion, instead of requoting it.
>   ---->8----
> ?

I don't think so. That appears to be referring to the behaviour of readline 
completion in an interactive shell.

>
> Of course, if the "new" behavior is intentional, I guess there will be
> good reasons for it and apologize for the noise

It's an interesting observation. I have noticed lately that bash has started to 
become more consistent in its quoting strategies. For instance, 5.2 changed the 
behaviour of declare -p, such that it sometimes employs a quoting strategy like 
that of the ${param@Q} form of expansion.

$ var1=$'foo\nbar' var2=$'foo\rbar'
$ declare -p BASH_VERSION var1 var2
declare -- BASH_VERSION="5.2.26(1)-release"
declare -- var1=$'foo\nbar'
declare -- var2=$'foo\rbar'

$ var1=$'foo\nbar' var2=$'foo\rbar'
$ declare -p BASH_VERSION var1 var2
declare -- BASH_VERSION="5.1.16(1)-release"
declare -- var1="foo
bar"
bar"are -- var2="foo

In my opinion, that demonstrates that the new approach is obviously superior. 
That is, the output of 5.2 there is vastly more legible to me; to make sense of 
the output of 5.1, I might have to rely on a utility such as od or hexdump. Put 
another way, this style of quoting is tremendously helpful for conveying 
strings that do not exclusively consist of graphemes.

Anyway, it look as though the xtrace mode has been similar adjusted.

-- 
Kerin Millar



reply via email to

[Prev in Thread] Current Thread [Next in Thread]