Date: Sun, 12 Feb 2023 01:14:12 +0900 From: Koichi Murase <myoga.mur...@gmail.com> Message-ID: <caflrlk_-ggzatbf-zgs7g3i+hnrn1uttg__6q6x1hthcbx3...@mail.gmail.com>
| `jobs' can be overwritten by a shell function. For example, when a | user wants to modify the behavior of `jobs' for interactive uses, a | typical solution is to override `jobs' with a shell function and call | `builtin jobs' in the overriding function. The standard way to do that would be to use "command jobs" - but in either of those cases, it is possible that the way that the shell recognises the special case that allows the command in a sub-shell to output information from the parent shell, rather than the sub-shell's information may not be met. The same applies to the "trap" command which has similar issues. | I guessed you have asked this because `jobs' would be specified as a | special built-in utility [XCU 2.14], which cannot be hidden by a | shell-function name, but it doesn't seem to be the case actually; bash has very little belief in the concept of "special bui8lt-in". | POSIX also states that the results are unspecified when the command name | matches `builtin' according to [XCU 2.9.1 / Command Search and Execution / | rule 1b]. Yes, that's the same issue as with select [[ and more ... POSIX knows that there are shells (like bash) which treat those differently than just being normal commands, and so warns applications not to expect them to work as normal commands. There are no precise rules for when a shell should switch from parent shell data to sub-shell data for commands like "trap" and "jobs" - the actual expectation is very limited indeed, but shells can widen that, and allow more cases through. Eg: if one does j=jobs $j | wc -l then it is not required that shells give special treatment to the jobs command that is run, it might report only the sub-shell's jobs in that case (ie: here, none). That is, the shell can look at the text of the command string when creating the sub-shell to decide what do do. But it is allowed to do more - the NetBSD sh here doesn't make decisions about things like this until the command is about to be run, after all expansions, even after function calls, so for us mjjobs() { jobs "$@" ; } myjobs | wc -l will still count the number of lines in the jobs output from the parent shell, as "jobs" is the first simple command run by the sub-shell, and that is what counts (for us). Other shells are likely to be more restricted. Chet can decide if making bash handle more cases than it currently does is worth it or not for bash and its users. kre