Date: Thu, 9 Nov 2023 16:55:50 -0500 From: Greg Wooledge <g...@wooledge.org> Message-ID: <zu1vzhrpynqlx...@wooledge.org>
| I believe *nothing* would work in that case; There's no requirement (in fact, it is probably not a good idea) for newlines in the output to be printed literally - whether entered literally or using $'\n'. Bash could always just output $'\n' for a newline. It could use $' instead of ' for everything intended to be quoted (and then escape other non-printing characters as well, so output which might lock the terminal wouldn't appear literally, etc). | the output of "jobs -l" cannot be safely parsed in its current form. It probably isn't a good idea, regardless of processing the output, as jobs -l (when it reports process termination, which it can) is supposed to remove the job from the jobs table, and forget it - which generally isn't what is wanted when the output is being parsed. How that operates when the jobs -l is being executed in a subshell but reporting the status of its parent is less clear (and it most probably simply doesn't happen - but there are no guarantees). That is if the jobs command works that way at all in a particular shell. | but if we're modifying the jobs builtin, we might as well just add | the -i or -j option instead. ash based shells have a jobid builtin, which takes anything which identifies a job, and prints a list of its process ids. The NetBSD variant of that has been extended to be able to instead print job identifiers (%1 etc) the process group id, or the lead process id (what $! would have been). I have just added (not yet committed) the ability to do that for all jobs (or any of a listed set) rather than just for one which used to be the case. This command never alters the jobs table, so is safer to use, and doesn't print anything which needs complex interpretation (not intended for humans). But in general this point is valid - though fixing the output of the command to keep it all on one line would also be a useful thing to do, regardless of anything else. kre