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

[Koichi Murase]

2023年2月13日(月) 22:00 Oğuz İsmail Uysal <oguzismailuysal@gmail.com>:
> On 2/13/23 2:43 PM, Koichi Murase wrote:
> > I guess just the support for ksh's ${ list; } [1] would make
> > everything simple and clear. One can simply call ${ jobs; }, ${ trap
> > -p; }, etc. without thinking about subshells.
> I don't see what difference that'd make.

Right, it doesn't change anything in the behavior, but I think that is
what Martin tried to think about, i.e., an alternative approach that
does the *same* thing but that can be understood more easily by users
without knowing the special rule of $(trap), $(jobs), etc.

Even though it is specified in the standard, that special rule is not
so natural that the users without knowledge can guess it. Compared to
that, the behaviors of ${ trap; }, ${ jobs; }, etc. would be naturally
understood without knowing the special rule as far as the user knows
what is ${ list; }.

> I think `builtin' should be fixed and the rest left alone.

I actually agree with it personally. It might not be so user-friendly
for general users, but the shells have behaved in this way, and the
rule is already in the standard. I don't think it is usuful to add
additional rules or builtins to handle it in an even different way.

Nevertheless, even if we forget about trap, jobs, etc., ${ list; }
alone is very useful as it's free from the fork cost and also can
affect the parent shell context when it wants to. I think it instead
needs to create a temporary file in the internal implementation, but
the file creation is much faster than the subshell fork usually. An
easy-to-understand idiom ${ jobs; } would be just a bonus of the
general ${ list; }.

--
Koichi