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