any current standing point of 'ipc can not be done' alike whatsoever
wont be standing for too long in any case, just a question of time
On Sun, Oct 10, 2021 at 2:06 PM Alex fxmbsw7 Ratchev wrote:
>
> maybe the same way to implent here a fix may do IPC between bashes ?
> a meta database of stuff u
maybe the same way to implent here a fix may do IPC between bashes ?
a meta database of stuff used in scripts, then if exec reset meta'ly
to none ( undo em maybe .. i have to figure such for my bashlinker
project too ) and if that fails restore em back
the same meta db can be used in IPC somehowly.
>I'll look at changing that
Thank you. I agree, making traps behave the same after an exec failure as after
any other failed builtin is a better course of action. It will make the trap
facility stronger. execve failures are not that uncommon, and are hard to
predict in advance. execve(2) man pa
On 10/1/21 2:16 PM, Mark March wrote:
Ok, thank you for clarifying. There is nothing in the documentation about this
behavior as far as I can tell. I would suggest adding a line about traps
getting reset after a failed exec to the paragraph on 'execfail'.
I think it will be a cleaner fix, and
Ok, thank you for clarifying. There is nothing in the documentation about this
behavior as far as I can tell. I would suggest adding a line about traps
getting reset after a failed exec to the paragraph on 'execfail'.
-Mark
On Friday, October 1, 2021, 07:02:34 AM PDT, Chet Ramey
wrote:
Date:Fri, 1 Oct 2021 09:59:44 -0400
From:Chet Ramey
Message-ID:
| Yes. When the shell runs `exec', it assumes the execed program will overlay
| the shell process. To make that happen transparently, it has to undo things
| it has done: it ends job control and re
On 9/30/21 7:24 PM, Mark March wrote:
If execfail is set, a failed exec does not cause a non-interactive shell to
exit, but it seems to reset the EXIT trap:
Yes. When the shell runs `exec', it assumes the execed program will overlay
the shell process. To make that happen transparently, it has
>then no more continued code
man bash(1) says the following for the execfail option:
execfail
If set, a non-interactive shell will not exit if it can‐
not execute the file specified as an argument to the
exec builtin comma
> On Fri, Oct 1, 2021, 01:25 Mark March wrote:
>
> > If execfail is set, a failed exec does not cause a non-interactive shell
> > to exit, but it seems to reset the EXIT trap:
It also appears to reset the EXIT trap in an interactive shell.
unicorn:~$ shopt -s execfail
unicorn:~$ trap 'echo exit
i think its not a bug but normal runtime
as ive understood, exec 'replaces' itself with , then no
more continued code
well error checking could maybe be better
On Fri, Oct 1, 2021, 01:25 Mark March wrote:
> If execfail is set, a failed exec does not cause a non-interactive shell
> to exit, but
10 matches
Mail list logo
