Re: [Bug Report] The Unexpected Behavior When Using ANSI Escape Code
@Andreas Have it solved by following that manual page and using "\[ ... \]" combination. Thanks for the hint! By the way, apparently the content about "non-printing characters" in that man page has not been modified across the several versions of Bash, for example in my machine, "3.2.57(1)-release" and "5.1.0(1)-release" share nearly the same document for section "PROMPTING", and both of them have not mentioned about the necessity to wrap around the non-printing characters with "\[...\]". While using non-printing characters without "\[...\]" proves to be fine in versions prior to 5.x.x (e.g., many suggestions from some online forums have suggested "PS1=\e[0m" for using ANSI escape code in the prompt), the same configuration in 5.x.x is not as stable as the previous versions(i.e., "PS1=\[\e[0m\]" should be used instead of "PS1=\e[0m", otherwise the unexpected behavior(STEP7) will happen). This might not be a bug for the current release of Bash, but we, as long-term users, indeed needs to add some extra configurations to Bash5 make things work as normal as the versions prior to 5.x. According to my limited tests, "Using standard ANSI escape code in prompt variable PS1" is exactly the case. I think it would be better to document it in man page/manual, or at least give a hint/warning for using non-printing characters. Nevertheless, Bash Long Live! On Sun, Mar 20, 2022 at 10:43 PM Andreas Schwab wrote: > On Mär 20 2022, Michaelll Lee wrote: > > > 1) $ PS1='---Test \\ \e[0m ---\\$ ' > > Read the manual about non-printing characters in the prompt. > > > https://www.gnu.org/software/bash/manual/html_node/Controlling-the-Prompt.html > > -- > Andreas Schwab, sch...@linux-m68k.org > GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 > "And now for something completely different." >
Re: for loop over parameter expansion of array can miss resulted empty list
i solve this by shopt -s nullglob
On Sun, Mar 20, 2022, 22:07 Alexey via Bug reports for the GNU Bourne Again
SHell wrote:
> Hello.
>
> Machine: x86_64
> OS: linux-gnu
> Compiler: gcc
> Compilation CFLAGS: -g -O2 -fstack-protector-strong -Wformat
> -Werror=format-security -Wall
> uname output: Linux alex 5.16.0-3-amd64 #1 SMP PREEMPT Debian 5.16.11-1
> (2022-02-25) x86_64 GNU/Linux
> Machine Type: x86_64-pc-linux-gnu
>
> Bash Version: 5.1
> Patch Level: 16
> Release Status: release
>
> Description:
>If use 'Parameter Expansion', for example 'Remove matching suffix
> pattern', on array and try to iterate over expansion result with for
> loop, may occur that loop body will not be executed at all.
>
> Repeat-By:
>Code: x=("/"); for i in "${x[@]%/}"; do echo "i is '$i'"; done
>Result: none
>Expected result: i is ''
>
> Expected behavior:
>like for an array with empty element
>Code: x=(""); for i in "${x[@]}"; do echo "i is '$i'"; done
>Result: i is ''
>
>another example, show that problems occurs only with empty resulted
> list
>Code: x=("/" "//"); for i in "${x[@]%/}"; do echo "i is '$i'"; done
>Result: i is ''
>i is '/'
>
>
> Regards,
> Alexey
>
>
Re: for loop over parameter expansion of array can miss resulted empty list
nullglob is not applicable in this situation, because no 'Pathname
Expansion' is occur.
On 2022-03-21 14:40, Alex fxmbsw7 Ratchev wrote:
i solve this by shopt -s nullglob
On Sun, Mar 20, 2022, 22:07 Alexey via Bug reports for the GNU Bourne
Again SHell wrote:
Hello.
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -g -O2 -fstack-protector-strong -Wformat
-Werror=format-security -Wall
uname output: Linux alex 5.16.0-3-amd64 #1 SMP PREEMPT Debian
5.16.11-1
(2022-02-25) x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu
Bash Version: 5.1
Patch Level: 16
Release Status: release
Description:
If use 'Parameter Expansion', for example 'Remove matching suffix
pattern', on array and try to iterate over expansion result with for
loop, may occur that loop body will not be executed at all.
Repeat-By:
Code: x=("/"); for i in "${x[@]%/}"; do echo "i is '$i'"; done
Result: none
Expected result: i is ''
Expected behavior:
like for an array with empty element
Code: x=(""); for i in "${x[@]}"; do echo "i is '$i'"; done
Result: i is ''
another example, show that problems occurs only with empty resulted
list
Code: x=("/" "//"); for i in "${x[@]%/}"; do echo "i is '$i'"; done
Result: i is ''
i is '/'
Regards,
Alexey
Re: [Bug Report] The Unexpected Behavior When Using ANSI Escape Code
On Mon, Mar 21, 2022 at 05:00:29PM +0800, Michaelll Lee wrote: > By the way, apparently the content about "non-printing characters" in that > man page has not been modified across the several versions of Bash, for > example in my machine, "3.2.57(1)-release" and "5.1.0(1)-release" share > nearly the same document for section "PROMPTING", and both of them have not > mentioned about the necessity to wrap around the non-printing characters > with "\[...\]". It's in the list of backslash-escaped special characters: abled. Bash allows these prompt strings to be customized by inserting a number of backslash-escaped special characters that are decoded as follows: \a an ASCII bell character (07) \d the date in "Weekday Month Date" format (e.g., "Tue May 26") [...] \\ a backslash \[ 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 Remember also that the manual (either the texinfo version or the man page) is written as a reference, not a tutorial. All of the information that you need is in there, but it's not necessarily laid out in the way that's best for learning it from a newcomer's point of view.
Re: for loop over parameter expansion of array can miss resulted empty list
Stop. Posting. Upside-down.
> > On Sun, Mar 20, 2022, 22:07 Alexey via Bug reports for the GNU Bourne
> > > Repeat-By:
> > > Code: x=("/"); for i in "${x[@]%/}"; do echo "i is '$i'"; done
> > > Result: none
> > > Expected result: i is ''
> On 2022-03-21 14:40, Alex fxmbsw7 Ratchev wrote:
> > i solve this by shopt -s nullglob
On Mon, Mar 21, 2022 at 02:51:14PM +0400, Alexey via Bug reports for the GNU
Bourne Again SHell wrote:
> nullglob is not applicable in this situation, because no 'Pathname
> Expansion' is occur.
I can confirm that Alexey's example produces the unexpected result
on my system (bash 5.1), and that "shopt -s nullglob" has no effect
on it.
unicorn:~$ bash
unicorn:~$ x=("/"); for i in "${x[@]%/}"; do echo "i is '$i'"; done
unicorn:~$ shopt -s nullglob
unicorn:~$ x=("/"); for i in "${x[@]%/}"; do echo "i is '$i'"; done
unicorn:~$
parameter expansion null check fails for arrays when [*] or [@] is used
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-redhat-linux-gnu'
-DCONF_VENDOR='redhat' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL
-DHAVE_CONFIG_H -I. -I. -I./include -I./lib -D_GNU_SOURCE -DRECYCLES_PIDS
-DDEFAULT_PATH_VALUE='/usr/local/bin:/usr/bin' -DSYSLOG_HISTORY -O2 -g -pipe
-Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS
-fexceptions -fstack-protector-strong -grecord-gcc-switches
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection
-Wno-parentheses -Wno-format-security
uname output: Linux tst-rocky85.innovative-navigation.de
4.18.0-348.el8.0.2.x86_64 #1 SMP Sun Nov 14 00:51:12 UTC 2021 x86_64 x86_64
x86_64 GNU/Linux
Machine Type: x86_64-redhat-linux-gnu
Bash Version: 4.4
Patch Level: 20
Release Status: release
Description:
Bash fails to correctly test for parameter to be unset or null when the
parameter is an array reference [*] or [@].
Repeat-By:
myvar[0]=
echo "${myvar[0]:+nonnull}"
-> OK
echo "${myvar[*]:+nonnull}"
nunnull -> not OK, because "${myvar[*]}" is null
echo "${myvar[@]:+nonnull}"
nunnull -> likewise not OK, because "${myvar[@]}" is null
--
Andreas Luik
Leiter Systemintegration & IT / Head of System Integration & IT
in-innovative navigation GmbH
Leibnizstr. 11
D-70806 Kornwestheim
tel: +49 7154 807171 | fax: +49 7154 807154
email: andreas.l...@innovative-navigation.de
www.innovative-navigation.de
in-innovative navigation GmbH is ISO 9001:2015 certified.
Geschäftsführer: Dr. Thomas Gern, Dr. Reinhard Zimmermann, Uwe Vögele
Kreissparkasse Esslingen
BIC: ESSL DE 66 | IBAN: DE51 6115 0020 0008 5986 55 | SWIFT: ESSL DE 66
Handelsregister: Stuttgart HRB 205770 | Steuer-Nr.71330/00796 |
Umsatzsteuer-ID: DE201463746
Re: for loop over parameter expansion of array can miss resulted empty list
I can add one more example, which change array size while it's not
expected behavior:
x=("/"); y=("${x[@]%/}"); echo "x size: ${#x[@]}, y size: ${#y[@]}"
Goal of this example show that it is not only for loop issue.
Re: BASH_COMMAND should be set before PS0
On 3/19/22 1:07 PM, Taqras via Bug reports for the GNU Bourne Again SHell wrote: Bash Version: 5.1 Patch Level: 16 Release Status: release Description: PS0: The value of this parameter is expanded like PS1 and displayed by interactive shells after reading a command and before the command is executed. BASH_COMMAND: The command currently being executed or about to be executed, unless the shell is executing a command as the result of a trap, in which case it is the command executing at the time of the trap. If BASH_COMMAND is unset, it loses its special properties, even if it is subsequently reset. PROBLEM: By the time PS0 is displayed, BASH_COMMAND is still set to the previous command, not the command about to be executed. These two events take place at different points in command processing. PS0 is displayed immediately after the shell reads a command. BASH_COMMAND is set after assignment statements and redirections are processed as part of command execution. You can't reconcile these two things. -- ``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 Report] The Unexpected Behavior When Using ANSI Escape Code
On Mon, Mar 21, 2022 at 4:01 AM Michaelll Lee wrote: > . . . > While using non-printing characters without "\[...\]" proves to be fine in > versions prior to 5.x.x (e.g., many suggestions from some online forums > have suggested "PS1=\e[0m" for using ANSI escape code in the prompt), the > same configuration in 5.x.x is not as stable as the previous versions(i.e., > "PS1=\[\e[0m\]" should be used instead of "PS1=\e[0m", otherwise the > unexpected behavior(STEP7) will happen). > . . . Note that the difference you see in Bash 5 is due to new paste behavior. However, prior versions are *not* fine without the escaped brackets. Bash loses track of the position of the cursor if there are unbracketed non-printing sequences. This is visible when stepping back through commands in history and a long command wraps, for an example. https://mywiki.wooledge.org/BashFAQ/053
Re: [Bug Report] The Unexpected Behavior When Using ANSI Escape Code
On 3/21/22 5:00 AM, Michaelll Lee wrote: While using non-printing characters without "\[...\]" proves to be fine in versions prior to 5.x.x (e.g., many suggestions from some online forums have suggested "PS1=\e[0m" for using ANSI escape code in the prompt), the same configuration in 5.x.x is not as stable as the previous versions(i.e., "PS1=\[\e[0m\]" should be used instead of "PS1=\e[0m", otherwise the unexpected behavior(STEP7) will happen). This has never been true. Readline's display relies on knowing the physical cursor position. Unless told otherwise, it assumes that every character it outputs contributes to that physical cursor position. Eventually, the incorrect value that results from non-printing characters will mess up redisplay. -- ``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: for loop over parameter expansion of array can miss resulted empty list
On Mon, Mar 21, 2022, at 8:50 AM, Alexey via Bug reports for the GNU Bourne
Again SHell wrote:
> I can add one more example, which change array size while it's not
> expected behavior:
> x=("/"); y=("${x[@]%/}"); echo "x size: ${#x[@]}, y size: ${#y[@]}"
This discrepancy seems to have been introduced some ways back.
3# echo "$BASH_VERSION"; x=("/"); y=("${x[@]%/}"); echo "x ${#x[@]}, y
${#y[@]}"
3.2.48(1)-release
x 1, y 1
42# echo "$BASH_VERSION"; x=("/"); y=("${x[@]%/}"); echo "x ${#x[@]},
y ${#y[@]}"
4.2.45(1)-release
x 1, y 0
--
vq
5.2-alpha prompt broken on next line
After setting PS1 to the following value and resizing window to 90 or 89 columns, display of then typed characters becomes broken. PS1=$'f \\[\E[0;1;37m\\]\\$\\[\E[0m\\] ' It may or may not need backspace to be typed to be triggered. I can't reproduce it with 5.1.4 and 5.1.16. All tested versions have their bundled readlines compiled with them. -- konsolebox
Re: for loop over parameter expansion of array can miss resulted empty list
On Mon, Mar 21, 2022 at 02:47:12PM -0400, Lawrence Velázquez wrote:
> On Mon, Mar 21, 2022, at 8:50 AM, Alexey via Bug reports for the GNU Bourne
> Again SHell wrote:
> > I can add one more example, which change array size while it's not
> > expected behavior:
> > x=("/"); y=("${x[@]%/}"); echo "x size: ${#x[@]}, y size: ${#y[@]}"
>
> This discrepancy seems to have been introduced some ways back.
>
> 3# echo "$BASH_VERSION"; x=("/"); y=("${x[@]%/}"); echo "x ${#x[@]},
> y ${#y[@]}"
> 3.2.48(1)-release
> x 1, y 1
> 42# echo "$BASH_VERSION"; x=("/"); y=("${x[@]%/}"); echo "x
> ${#x[@]}, y ${#y[@]}"
> 4.2.45(1)-release
> x 1, y 0
Good point. The behavior definitely changed between 4.1 and 4.2.
unicorn:~$ bash-3.2 -c 'x=("/"); for i in "${x[@]%/}"; do echo "i is [$i]";
done'
i is []
unicorn:~$ bash-4.0 -c 'x=("/"); for i in "${x[@]%/}"; do echo "i is [$i]";
done'
i is []
unicorn:~$ bash-4.1 -c 'x=("/"); for i in "${x[@]%/}"; do echo "i is [$i]";
done'
i is []
unicorn:~$ bash-4.2 -c 'x=("/"); for i in "${x[@]%/}"; do echo "i is [$i]";
done'
unicorn:~$
Re: 5.2-alpha prompt broken on next line
On 3/21/22 2:49 PM, konsolebox wrote: After setting PS1 to the following value and resizing window to 90 or 89 columns, display of then typed characters becomes broken. PS1=$'f \\[\E[0;1;37m\\]\\$\\[\E[0m\\] ' It may or may not need backspace to be typed to be triggered. I can't reproduce it with 5.1.4 and 5.1.16. All tested versions have their bundled readlines compiled with them. Isn't this the same as https://lists.gnu.org/archive/html/bug-readline/2022-02/msg00038.html ? That's already fixed. -- ``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/
Request for new 5.2 alpha?
Hi, Is there a plan for a 2nd 5.2 alpha? A number of reported bugs have been addressed since and it may help resolve duplicates. Best, sam signature.asc Description: Message signed with OpenPGP
Re: Request for new 5.2 alpha?
On 3/21/22 3:14 PM, Sam James wrote: Hi, Is there a plan for a 2nd 5.2 alpha? A number of reported bugs have been addressed since and it may help resolve duplicates. The next release will be 5.2-beta. You can always use the devel branch for the latest code. -- ``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: 5.2-alpha prompt broken on next line
On Mon, Mar 21, 2022 at 7:11 PM Chet Ramey wrote: > Isn't this the same as > > https://lists.gnu.org/archive/html/bug-readline/2022-02/msg00038.html ? > > That's already fixed. I'm sorry I didn't check. Yes it's already fixed. -- konsolebox
Re: 5.2-alpha completion script source crash
On Sat, Feb 19, 2022 at 9:34 PM Chet Ramey wrote: > Thanks for the report. This is the result of needing to clean up parser > state before recursively calling it to parse the command substitution. Just tested devel. This one's fixed as well. -- konsolebox
Re: [Bug Report] The Unexpected Behavior When Using ANSI Escape Code
On Mar 21, 2022, 9:47 PM Chet Ramey wrote: > Unless told otherwise, it assumes that every character it outputs contributes > to that physical cursor position. Thank you Sir, for pointing out this clearly, and now I think my previous thoughts would be my misunderstanding. On Mon, Mar 21, 2022 at 9:47 PM Chet Ramey wrote: > > On 3/21/22 5:00 AM, Michaelll Lee wrote: > > > While using non-printing characters without "\[...\]" proves to be fine in > > versions prior to 5.x.x (e.g., many suggestions from some online forums > > have suggested "PS1=\e[0m" for using ANSI escape code in the prompt), the > > same configuration in 5.x.x is not as stable as the previous versions(i.e., > > "PS1=\[\e[0m\]" should be used instead of "PS1=\e[0m", otherwise the > > unexpected behavior(STEP7) will happen). > > This has never been true. > > Readline's display relies on knowing the physical cursor position. Unless > told otherwise, it assumes that every character it outputs contributes to > that physical cursor position. Eventually, the incorrect value that results > from non-printing characters will mess up redisplay. > > -- > ``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 Report] The Unexpected Behavior When Using ANSI Escape Code
On Mar 21, 2022, 9:39 PM Dennis Williamson wrote: > > Note that the difference you see in Bash 5 is due to new paste behavior. >From the perspective from users, would be more appropriate to see a hint for this new kind of behavior in man page/manual. Anyway, thanks for the clarification. On Mon, Mar 21, 2022 at 9:39 PM Dennis Williamson < dennistwilliam...@gmail.com> wrote: > > > On Mon, Mar 21, 2022 at 4:01 AM Michaelll Lee wrote: > >> . . . >> While using non-printing characters without "\[...\]" proves to be fine in >> versions prior to 5.x.x (e.g., many suggestions from some online forums >> have suggested "PS1=\e[0m" for using ANSI escape code in the prompt), the >> same configuration in 5.x.x is not as stable as the previous >> versions(i.e., >> "PS1=\[\e[0m\]" should be used instead of "PS1=\e[0m", otherwise the >> unexpected behavior(STEP7) will happen). >> . . . > > > Note that the difference you see in Bash 5 is due to new paste behavior. > However, prior versions are *not* fine without the escaped brackets. Bash > loses track of the position of the cursor if there are unbracketed > non-printing sequences. This is visible when stepping back through commands > in history and a long command wraps, for an example. > https://mywiki.wooledge.org/BashFAQ/053 > >
