Re: Bash spews bracketed-paste escape sequences when handling signal.
On 2024-12-14 11:36, Chet Ramey wrote: > On 12/14/24 12:40 PM, Kaz Kylheku wrote: >> Hi! >> >> I first ran into this issue on MacOS using the Homebrew build of Bash 5 >> (BASH_VERSION "5.2.37(1)-release"). >> >> When a trap is installed for a signal, and delivered, Bash sends characters >> to the terminal which move the cursor. > > It does not; readline does. This turns out to make a difference. Yes; and that is consistent with the issue having a readline config workaround. Pretend I wrote "bash process" not "code in the bash executable itself". >> If you do not have "trap : ALRM" then this doesn't happen. > > Because SIGALRM is a terminating signal that kills the shell. But no; I mean the shell keeps running in that case. Try it: $ kill -ALRM $$ $ # didn't die For some other signals like VTALRM or USR1, it does terminate as you say. Furthermore, if the Bash trap for ALRM is not installed, then the readline behavior in question (emission of terminal sequences) doesn't occur. Since "trap : ALRM" is a Bash feature and not a readline feature, it's hard to escape the conclusion that Bash is somehow acting as an enabler for the behavior. The right fix may be to stay away from SIGALRM, since readline clearly uses it for something. Disabling bracketed paste is probably a bad workaround; what if some Basta user wants that to work? With signals other than SIGALRM, the code has to be careful; if it ever happens that the signal is delivered without the trap being in place, Bash will die.
Re: Bash spews bracketed-paste escape sequences when handling signal.
On 2024-12-14 23:16, Kaz Kylheku wrote: > The right fix may be to stay away from SIGALRM, since readline > clearly uses it for something. Nope! It turns out that by dumb luck, I had picked the winning signal. The hack used in Basta will not work with signals other than SIGALRM. (No, not even ones like SIGBUS; I tried). It looks as if when Bash is sitting in the call to readline to edit the command line, it's not able to receive external signals like SIGUSR1. SIGALRM likely works because readline keeps it unblocked and handles it. (Without looking at code, I can only hypothesize that the Bash trap for ALRM is executed because readline keeps track of the previous handler and chains to it out of its own handler. Furthermore, it could be that when readline sees that there /is/ such a prior handler, then in that case it does the thing with the escape sequences sent to the terminal.)
Re: Bash spews bracketed-paste escape sequences when handling signal.
On 2024-12-18 13:46, microsuxxor wrote: > try > > p=$$ ; while sleep 1 ; do kill -USR1 "$p" ; done & That's not necessary; my existing repro steps successfully show a difference between two signals, that being the only difference between them. The $$ parameter is expanded to a decimal numeric word *before* the while command is executed, so the background process is referencing the correct PID of the parent. There is no need to smuggle the PID through a variable. $$ in the while command will not refer to the child process' (That would be an issue if we had used eval: eval 'command ... $$ ...' & now we backgrounded the eval, which then in the background process parses the shell syntax and does all the expanding. Now $$ is the PID of the background process, not that of the shell which launched it.) > try also trap - USR1 in the new process ( the while loop ) We don't want that at all. The new process is just a helper to generate the signal to our main process. It doesn't receive the signal itself.
Re: Bash spews bracketed-paste escape sequences when handling signal.
On 2024-12-18 06:58, Chet Ramey wrote: >> With signals other than SIGALRM, the code has to be careful; if it >> ever happens that the signal is delivered without the trap being >> in place, Bash will die. > > Same with SIGALRM, too. OK, that is my mistake. These steps do terminate Bash: trap - ALRM # make sure we have no trap for SIGALRM kill -ALRM $$ Sorry for contributing to the despicable spread of misinformation. What remains is the question why I somehow cannot get my stuff to work with a different signal like SIGUSR1 or SIGVTALRM. Bash will not take them while it's sitting in the call to readline. It will act on pending signals once the command line is submitted. However, an ALRM trap can go off during readline operation. This is how the clock display in Basta is kept up-to-date even when you're just sitting at the prompt doing nothing.
Re: Bash spews bracketed-paste escape sequences when handling signal.
On 2024-12-18 12:48, Chet Ramey wrote: > On 12/18/24 1:27 PM, Kaz Kylheku wrote: > >> What remains is the question why I somehow cannot get my >> stuff to work with a different signal like SIGUSR1 or SIGVTALRM. >> >> Bash will not take them while it's sitting in the call to readline. > > Something is indeed messed up in your execution environment. > > Let's try killing an interactive shell sitting in readline() from another > terminal: > > $ echo $BASH_VERSION > 5.2.37(6)-release > $ trap > $ echo $$ > 30762 > User defined signal 1: 30 > > [shell terminates] > > Now let's try killing an interactive shell that's not sitting in readline() > with the same fatal signal: > > $ echo $BASH_VERSION > 5.2.37(6)-release > $ trap > $ kill -USR1 $$ > User defined signal 1: 30 > > [shell terminates]. Right; I didn't make the wrong claim that SIGUSR1 isn't fatal. I made that wrong claim only about SIGALRM, and retracted that already. The real issue is this: Let's work with SIGUSR1 first: $ trap 'echo USR1' USR1 $ kill -USR1 $$ USR1 $ kill -USR1 $$ USR1 So far, so good! Now let's sit at the prompt, while sending the signal from a background process: $ while sleep 1; do kill -USR1 $$; done & [1] 22261 $ fg USR1 while sleep 1; do kill -USR1 $$; done ^C USR1 I waited 20 seconds before typing "fg". Nothing! Now, let's try it with SIGALRM: $ trap 'echo ALRM' ALRM $ while sleep 1; do kill -ALRM $$; done & [1] 21882 $ ALRM ALRM ALRM ALRM ALRM ALRM ALRM ALRM ALRM The "echo ALRM" commands go off like clockwork, every second. Most likely because of the way Readline treats signals, SIGARLRM ends up "blessed" for this purpose. By dumb luck, I had picked the winning signal; it was the first one I reached for. I understand that Bash will die if you send a SIGUSR1, and it has no trap set up for it; but when it does have a handler set up, it seems that Readline may be blocking the signal (perhaps via the sigprocmask or whatever). I probably won't be digging into it more.
Re: Bash spews bracketed-paste escape sequences when handling signal.
On 2024-12-18 11:02, microsuxxor wrote: > post ur code for review , if u want .. It's BSD-licensed freeware: https://www.kylheku.com/cgit/basta/about/
Bash spews bracketed-paste escape sequences when handling signal.
Hi! I first ran into this issue on MacOS using the Homebrew build of Bash 5 (BASH_VERSION "5.2.37(1)-release"). When a trap is installed for a signal, and delivered, Bash sends characters to the terminal which move the cursor. Steps to repro: 1. Register the simplest possible trap for the SIGALRM signal: trap : ALRM 2. In the background, start a loop which delivers the signal to the shell while sleep 1; do kill -ALRM $$ ; done & 3. Every time the signal is delivered, observe Bash spewing the escape sequences for disabling and enabling bracketed paste, with a carriage return in between them that moves the cursor. (One way to capture the output is to do the above steps under the "script" command; then find the characters in the typescript transcript file.) If you do not have "trap : ALRM" then this doesn't happen. The expected behavior is that no output should be produced. Bash should just handle the signal and execute the trap without TTY interaction. See this question on the "Ask Different" Stack Exchange site: https://apple.stackexchange.com/questions/477385/why-am-i-having-an-issue-with-restoring-cursor-position-when-using-basta-on-maco Cheers ...
Re: Possible bug for nested curly brace expansion
On 2025-03-06 11:58, Lawrence Velázquez wrote:
> On Thu, Mar 6, 2025, at 1:48 PM, microsuxx wrote:
>> {0} is no expansion
>> {0,} is
>> it must be 2+
>
> And this is documented. It is not a bug.
>
> A correctly-formed brace expansion must contain unquoted
> opening and closing braces, and at least one unquoted comma
> or a valid sequence expression. Any incorrectly formed
> brace expansion is left unchanged.
>
> https://www.gnu.org/software/bash/manual/html_node/Brace-Expansion.html
Note that glibc's glob function also allows {abc} to produce abc.
But Bash cannot do this. The reason is that brace expansion is already
a deviation from POSIX.
In POSIX, the {} word has a special role: in the arguments of the
-exec predicate of the find utility, it denotes a character sequence
to be replaced with the path name being visited.
Even if {abc} were to denote abc, {} would continue to have to be a special
case denoting [}.
Or else Bash would need a flag to enable the behavior whereby {abc} is
abc and {} expands to nothing. Scripts turning on that flag would
have to carefully quote {} when using the find utility.
Degenerate case in brace expansion.
Hi all,
$ echo {a..zz}
{a..zz}
Right; the sequence is not well-formed according, and so this is not brace
syntax; the syntax stays intact as verbatim text, braces and all.
But:
$ echo {a..{z,y}}
a..z a..y
Is this documented? I would expect it to produce
{a..z} {a..y}
on the hypothesis that the outer brace is not well-formed, and
therefore literal, but the inner brace is active, like any
valid brace in the middle of literal text. I.e. we have
"alpha{brace}omega", where alpha is "{a.." and omega is "}".
If we strip the braces, that means we have recognized the syntax
for special processing, but then it is not evident in the
a..z a..y output how it relates to sequence expansion.
I came across this because the recent discussion in this list prompted
me to go looking into my own brace expansion implementation, which
I recently extended into supporting sequences.
It has the expected behavior:
1> (sys:brace-expand "{a..{z,y}}")
("{a..z}" "{a..y}")
I was just "comparing notes" on some exotic cases like this against
Bash, and noticed this.
(An interesting way to treat this case would be to allow the inner
element expansion to produce multiple sequence expansions,
which are then processed; i.e. as if we took the resulting
{a..z} and {a..y} shown in my implementation, and then "activated"
the braces.)
Cheers ...
Cosmetic issue in job control display of suspsended "command" command.
Hi All,
Consider this trivial wrapper:
wrapper()
{
command "$@"
}
Under an older bash like 4.4.20, when we suspend this with Ctrl-Z we get this:
$ wrapper cat
^Z
[1]+ Stopped cat
But under a newer bash, like 5.2.37:
$ wrapper cat
^Z
[1]+ Stopped command "$@"
The job control listing of the suspended "command" command shows the
unexpanded syntax now.
Maybe there was a good reason why this was done, but it's not working
in a situation like this.
Based on the job contro listing alone, the user has no idea what
actual program was interrupted, and has no access
to the context in which "$@" expands to "cat". The listing conveys
no useful information.
Cheers ...
