On Fri, 3 Feb 2023 at 07:17, Chet Ramey <chet.ra...@case.edu> wrote: > On 1/28/23 5:56 AM, Martin D Kealey wrote: > > Firstly, let's just leave aside "POSIX requires this" for a bit. > Be that as it may, POSIX exists and this is a requirement. It's also how > other shells behave. >
Of course. I'm only contemplating making changes in extended mode, not POSIX mode. > > I contend that it's inconsistent for the actions of "nohup" and "&" to > NOT > > be fully orthogonal. > > Maybe, but their historical behavior has always differed: `nohup' ignores > SIGHUP, and background processes ignore SIGINT/SIGQUIT. You could say those > are "fully orthogonal," setting aside the sometimes-confusing manipulation > of input and output FDs. Is the latter what you mean by orthogonality? > Sorry, nohup was a terrible way to illustrate this, since conflates other things that I wasn't considering; rather I meant something more along the lines of "some hypothetical command structured like nohup but which affects SIGINT & SIGQUIT instead of SIGHUP, and which doesn't redirect stdio" (and which doesn't make the job automatically backgrounded, though that already applies to nohup). By orthogonal, I meant these things should ideally be managed by separate controls: 1. ignoring signals (or not) 2. redirecting filedescriptors 3. immediately waiting on the process (or not) 4. creating new process groups 5. sending a signal to about-to-be orphaned children when the shell exits The problem, as I see it, is that there's no shell syntax that *only* does #3. Yes one could write a shell function, but it'd be pretty contorted, and waste a lot of effort for things that would be undone when using other features at the same time, leading to a situation where people would only bother to use it when they're *not *going to give explicit signal dispositions; so it's still not *practically* orthogonal. > In the meantime, « shopt -s background_without_magic » (*2) gets my vote, > > I don't see any advantage over the mechanism above. > The value proposition in making changes isn't that "this can't already be done *somehow*", but rather the unorthogonality of the current features is suboptimal language design, and poor for user understanding. Rather than a global shopt setting that stops "&" from blocking SIGINT & SIGQUIT, which I'll grant is a hard sell, perhaps an entirely new notation would be possible, using some combination of "&" with other punctuation that isn't already defined, such as "&;" or "&|". > along with incorporating « nohup » as a built-in (so that Bash can > > guarantee its behaviour, and add options to improve its internal > > orthogonality.). > > What guarantees would you like? I put those the wrong way round. To add extensions, and guarantee that they're available to every Bash script, nohup would have to be a built-in. In particular I'm thinking of options along the lines of: nohup --no-redir --[block/default/keep]=[INT,QUIT,HUP,...] (exact names not important; hopefully --long-options are self-explanatory) > *1: I have very occasionally had interactive single-user shell running on > > /dev/console, which doesn't appear to count as a tty because it doesn't > > respond to tcsetpgrp. > > Try running something in a Docker container; that doesn't guarantee a > controlling terminal. > That's a very good point, and I suspect it's for the same underlying reason: that inside the container, the "top" process has pid 1 or pgrp 0 or somesuch, and somewhere this is interpreted as "set the terminal so that it has no pgrp". -Martin
