#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
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
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,
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
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
escribe it in the SIGNALS section.
Regards,
[1] https://bugs.debian.org/822605#26
--
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
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
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
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
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
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
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
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
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
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
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
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
`.
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
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
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
rd colors (white on
black, in my case).
Tested with xterm and gnome-termimal, using TERM=xterm-256color.
Regards,
--
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
e
Regards,
--
Gioele Barabucci
24 matches
Mail list logo
