Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Janis Papanagnou Newsgroups: comp.unix.shell Subject: Re: (bash) How (really!) does the "current job" get determined? Date: Mon, 7 Oct 2024 04:50:31 +0200 Organization: A noiseless patient Spider Lines: 42 Message-ID: References: <20241003170607.397@kylheku.com> <20241004070133.515@kylheku.com> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Injection-Date: Mon, 07 Oct 2024 04:50:32 +0200 (CEST) Injection-Info: dont-email.me; posting-host="5f5acbc78a353cdf8f36934af485fb2c"; logging-data="1661904"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/8KyBtX3bQR/Y4q52fhq26" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 Cancel-Lock: sha1:mYWgW9iQWlaoI33/fuhMBFTp72s= In-Reply-To: X-Enigmail-Draft-Status: N1110 Bytes: 2973 On 05.10.2024 00:48, Christian Weisgerber wrote: > On 2024-10-04, Janis Papanagnou wrote: > >>>> What? Scripting should not go anywhere near POSIX job control, which is >>>> an interactive feature that requires a terminal session. >>> >>> Well, there _is_ set -m. >> >> And how will that devaluate what Kaz has said? Please elaborate. > > Job control does not require an interactive shell or a terminal > session. It can be used in scripting. That's the facts. Yes, but for one that doesn't explain why you emphasized 'set -m', and your example below - certainly reasonable for discussion! - I don't find convincing. In contrast to '$!' that you get and work with there's no (no easy?) way to obtain the job number that the shell assigns! And (for concerning your question below) you have alway 'wait' available, for both, PIDs or job numbers (at least in Kornshell; don't know about Bash or what POSIX says about it). Janis > >> or if you know of any useful and sensible application contexts >> for non-interactive usages I'd certainly be curious to know.[*] > > I'm curious myself. That said, here's something I stumbled across > recently: > > background job & > ... > kill %1 # clean up > > What happens if the background job has already terminated on its > own accord before we reach the kill(1)? Not much, because with job > control, the shell knows that no such job exists. If you do this > with "kill $!", you signal that PID, which no longer refers to the > intended process and may in fact have been reused for a different > process. >