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

[Chet Ramey]

On 2/11/23 8:15 PM, Robert Elz wrote:
>      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.

`command jobs' works (I had to remind myself that it does). It's
another implementation artifact; it happened separately from the
`jobs_hack'. It's because `command' runs the rest of the words through
the execution path again, while `builtin' simply looks up and invokes
a shell builtin directly.


>    | 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".

"Special builtin" is not a particularly useful concept, but bash embraces
it in posix mode.


> Chet can decide if making bash handle more cases than it currently does is
> worth it or not for bash and its users.

I think handling it in `jobs' and `command jobs' is enough for now.

--
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/