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

[Koichi Murase]

2023年2月13日(月) 13:29 Martin D Kealey <martin@kurahaupo.gen.nz>:
> The contorted rules for reporting the state of the parent shell suggest
> that maybe the entire approach needs re-thinking.

Yeah, maybe we can rethink the approach and find an ideal shell
design. But even when we found it, we would need to continue to
maintain the current behavior along with the new one. With the new
approach, fewer users would (be supposed to) be confused, but the
subtleties with `builtin jobs' etc, would still remain unless we work
on it.

> Several approaches come to mind.
>
> 1. Create a built-in “parent” command where “parent ulimit” or “parent
> trap” answers based on the parent shell rather than the subshell itself.
> (Obviously it would be the snapshot taken when the processes forked, rather
> than the parent's *current* state, unless we want to get really fancy with
> some kind of IPC. I suspect this would not play well with the current
> "longjmp" implementation of subshells.)
>
> 2. Extend all the commands that report on the shell's internal state
> analogously to printf: take a '-v VAR' argument to which they write what
> would normally be their output, so there's no need for a subshell, and
> therefore doubt about which shell they're reporting on.
>
> 3. Provide tracking variables so that it's not necessary to use commands at
> all. e.g. "${BASH_ULIMIT[core]}" would report the maximum size of core dump
> (and "${BASH_ULIMIT[hard-core]}" would report the maximum value that the
> former can be set to), while "${BASH_TRAP[HUP]}" would match the command
> string from trap -p HUP (and [[ -v BASH_TRAP[HUP] ]] would tell you whether
> its unset or just empty).
>
> 4. For "jobs" only, always report the viewpoint of the nearest shell that
> has functioning job control - the one that actually uses setpgrp(). "fg",
> "bg", and any other command used with a job-spec should recognize that
> they're in the "wrong shell" and complain rather than simply being silent.

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.

[1] https://lists.gnu.org/archive/html/help-bash/2020-05/msg00077.html

In the above reply, Chet told us,
> if someone wants to take a shot at implementing it
> before I get to looking at it, I'd be happy to merge it in.

----

> I wonder how "job control enabled" should be reported in subshells. A
> simple reading of POSIX suggests that $- must contain 'm' in subshells of a
> session shell that has job control enabled, even though they don't actually
> do job control themselves. Maybe there should be an 'M' in $- when job
> control is actually active (in the top level session shell). What do others
> think about this?

Maybe I miss the point, but how can we use the "job control enabled"
state for the present issue? Or is it actually an independent
discussion?

I haven't checked what POSIX says about the jobs in subshells, but at
least Bash maintains a separate "job list" of a subshell (which is
accessible from the built-in command `jobs') regardless of whether the
"job control" is turned on or not. For example,

$ sleep 2023 & sleep 2024 &
[1] 2929313
[2] 2929314
$ jobs
[1]-  Running                 sleep 2023 &
[2]+  Running                 sleep 2024 &
$ (sleep 2025 & sleep 2026 & jobs)
[1]-  Running                 sleep 2025 &
[2]+  Running                 sleep 2026 &
$ jobs
[1]-  Running                 sleep 2023 &
[2]+  Running                 sleep 2024 &

Or non-interactive shells without job control can also have a job list:

$ LANG=C bash -c 'echo $-; sleep 10 & jobs'
hBc
[1]+  Running                 sleep 10 &

This makes your suggestion 4 (report for the nearest shell with active
job control) non-trivial.

--
Koichi