Re: Incorrect positioning when long prompt contains ANSI escape sequences + UTF-8 LANG

2024-08-10 Thread Gioele Barabucci
e Regards, -- Gioele Barabucci

Incorrect positioning when long prompt contains ANSI escape sequences + UTF-8 LANG

2024-08-08 Thread Gioele Barabucci
(type anything; text ends up in the wrong place) $ unset LANG (press up arrow) (type anything; text is displayed correctly) Extracted from https://bugs.debian.org/1018851 Regards, -- Gioele Barabucci

Prompt color reset after using arrow keys

2024-08-07 Thread Gioele Barabucci
rd colors (white on black, in my case). Tested with xterm and gnome-termimal, using TERM=xterm-256color. Regards, -- Gioele Barabucci

Re: «run_pending_traps: bad value in trap_list» when `jobs` is run a trap

2024-07-03 Thread Gioele Barabucci
On 03/07/24 15:33, Chet Ramey wrote: On 7/1/24 4:45 PM, Gioele Barabucci wrote: the following script (reduced from <https://bugs.debian.org/417946>) #!/bin/bash childfinished () { echo "jobs: $(jobs)"; } trap childfinished SIGCHLD sleep 1 & wait c

«run_pending_traps: bad value in trap_list» when `jobs` is run a trap

2024-07-01 Thread Gioele Barabucci
ps: bad value in trap_list[17]: 0x5625e6fa43d0 Does this warning hint at something like a dangling reference that should be fixed, or can it be safely ignored? Modifying the trap to call `jobs` directly instead of in a subshell makes the warning go away. Regards, -- Gioele Barabucci

--rcfile and non existing files

2024-06-24 Thread Gioele Barabucci
`. https://bugs.debian.org/1042394 reports that this happen for `--init-file` as well. Should the manpage be reworded to avoid stating "will force bash to read..."? Or should passing a non existing file to `--rcfile` turned into an error? Regards, -- Gioele Barabucci

printf, binary data, leading single quote and non ASCII codesets

2024-06-24 Thread Gioele Barabucci
printf "%d %q\n" "'$c" "$c"; done; } 195 $'\303' 255 $'\277' 190 $'\276' Should the manpage be changed? Or the code modified to always use ASCII as the reference codeset? Regards, -- Gioele Barabucci

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

2024-04-28 Thread Gioele Barabucci
On 28/04/24 22:50, Chet Ramey wrote: On 4/28/24 3:07 PM, Gioele Barabucci wrote: $ su -l $USER -s /bin/bash-static -c 'echo $BASH; readlink /proc/$$/exe; head -1z /proc/$$/cmdline; echo' /bin/bash /usr/bin/bash-static -bash-static So argv[0] == "-bash

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

2024-04-28 Thread Gioele Barabucci
On 28/04/24 20:01, Chet Ramey wrote: On 4/27/24 6:23 PM, Gioele Barabucci wrote: bash 5.0 and 5.2 do not set $BASH to the right value when bash is used as the login shell: $ apt install bash-static $ getent passwd $USER | cut -d: -f 7 /bin/bash $ su $USER -s /bin/bash

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

2024-04-27 Thread Gioele Barabucci
ER -s /bin/bash -c 'echo $BASH; readlink /proc/$$/exe; true' /usr/bin/bash /usr/bin/bash $ su -l $USER -s /bin/bash -c 'echo $BASH; readlink /proc/$$/exe; true' /bin/bash /usr/bin/bash Regards, -- Gioele Barabucci

Re: bash: ":?xxx" filename broken on autocomplete

2024-04-27 Thread Gioele Barabucci
can finish completion by entering "aa", but then "rm" rejects this name. In bash 5.2.21(1) the filename is now fully completed, but the stray ":" at the beginning is still produced: $ mkdir ':?aa' $ rmdir : $ rmdir :\:\?aa/ Regards, -- Gioele Barabucci

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

2024-04-15 Thread Gioele Barabucci
036854775808 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

2024-04-05 Thread Gioele Barabucci
hown 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: Debian bug #929178: wrong trap displayed inside functions

2024-03-25 Thread Gioele Barabucci
On 25/03/24 18:13, Oğuz wrote: On Mon, Mar 25, 2024 at 7:18 PM Gioele Barabucci <mailto:gio...@svario.it>> 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 comm

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

2024-03-25 Thread Gioele Barabucci
On 25/03/24 17:12, Oğuz wrote: On Monday, March 25, 2024, Gioele Barabucci <mailto:gio...@svario.it>> 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. Does

Debian bug #929178: wrong trap displayed inside functions

2024-03-25 Thread Gioele Barabucci
in" 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

2024-03-21 Thread 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

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

2024-03-21 Thread 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

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

2024-03-21 Thread Gioele Barabucci
escribe it in the SIGNALS section. Regards, [1] https://bugs.debian.org/822605#26 -- Gioele Barabucci

Re: Prompt messed up if PS1 contains ANSI escape sequences

2023-09-07 Thread 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

Re: Prompt messed up if PS1 contains ANSI escape sequences

2023-09-07 Thread 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

Re: Prompt messed up if PS1 contains ANSI escape sequences

2023-09-07 Thread 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,

Re: Prompt messed up if PS1 contains ANSI escape sequences

2023-09-07 Thread Gioele Barabucci
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

Prompt messed up if PS1 contains ANSI escape sequences

2023-09-07 Thread Gioele Barabucci
#x27;\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 <https://bugs.debian.org/1051388>.) -- Gioele Barabucci