Quote:
I took a look at ksh93 defect pointed by you... it might be this same, but I'm not sure - I think some research in source of ksh93 would be needed.
Let me paste the script again, now a bit modified.
[code]
....
bzk
in linux when read (bash builtin) executes,(read() starts to waiting for reading data on the fd,or receive a signal eg.usr2 or defined others),process is blocked with `rt_sigprocmask(SIG_BLOCK, [USR1], [USR1],...)` so USR1 signal is blocked.Before this changed to default action with `rt_sigaction(SIGUSR1..`) by bash and also ksh(only linux not sunos)
in linux when read(ksh/ksh93 builtin) executes,(select() starts to waiting for input..)
select returns ERESTARTNOHAND for restart to listening/waiting its own fd(s) after receive the usr1 signal.so it is basically ignored.select will continue reads.
in solaris bash exhibits the same behavior like linux.so firsty, read() returns error with EINTR(call was interrupted by a signal (this is usr1 and prints "Received signal #16, SIGUSR1, in read() [caught]"),, but it resumes from memory with setcontext()..so read() will be continue..
but in
solaris ksh,when you send the sigusr1/sigusr2 to any process (without internal signal handlers for this or even if it can be kill/terminate process as in
default action), process terminated with this messg to screen "Received signal #16/#17, SIGUSR1, in read()..", as can be seen here,in solaris even if process on the read() syscall can be terminated without blocking signals..
regards
ygemici