On 12/18/24 4:56 PM, Kaz Kylheku wrote:
(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
On 12/18/24 4:38 PM, Kaz Kylheku wrote:
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 i
Date:Wed, 18 Dec 2024 13:56:48 -0800
From:Kaz Kylheku
Message-ID:
| The $$ parameter is expanded to a decimal numeric word
| *before* the while command is executed,
No it isn't.
| so the background process is referencing the correct PID of the parent.
But th
were my wrong assumptations .. sry .. peace ..
On Wed, Dec 18, 2024, 10:57 PM Kaz Kylheku wrote:
> 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
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
On Wed, Dec 18, 2024, 10:40 PM Kaz Kylheku wrote:
> 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 ta
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.
>
> Somethin
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.
L
i made smth with reserved line for some chat ..
On Wed, Dec 18, 2024, 8:18 PM Kaz Kylheku wrote:
> 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/
>
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/
post ur code for review , if u want ..
On Wed, Dec 18, 2024, 7:28 PM Kaz Kylheku wrote:
> 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
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 -
On 12/15/24 2:16 AM, Kaz Kylheku wrote:
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
Then something about the execu
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
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
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 d
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 S
17 matches
Mail list logo
