Re: "builtin jobs" does not output to stdout.

[Robert Elz]

    Date:        Sun, 12 Feb 2023 01:14:12 +0900
    From:        Koichi Murase <myoga.murase@gmail.com>
    Message-ID:  
<CAFLRLk_-GgzATBf-zgS7g3i+HNRn1uttg__6Q6x1hThCBX38SA@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