bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Idea: jobs(1) -i to print only :%ID:s


From: Robert Elz
Subject: Re: Idea: jobs(1) -i to print only :%ID:s
Date: Fri, 10 Nov 2023 05:33:50 +0700

    Date:        Thu, 9 Nov 2023 16:55:50 -0500
    From:        Greg Wooledge <greg@wooledge.org>
    Message-ID:  <ZU1VZhrPyNQlxuBN@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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]