Except for the addition of that final sentence, I prefer the original.

Same comment as for bg.

Same comment as for bg and fg.

The options were previously ordered lexicographically, as they should. Why are you changing that?

gratuitous change

this list is out of order

Please don't mark up random words just because they happen to match the title of a related page.

As above.

gratuitous change

Please don't mark up random parts of sentences that just happen to match the title of a section.

des is right, my recommendation introduces a regression when rendered in plain text. The way you had it the first time was better. Sorry about that!

Now I understand, thank you. So does it mean I should turn all these references to manpages and section titles, which des is talking about, into 'See (...)'-like references?

Yeah I think so. I personally think they're better with a comma rather than a parentheses.

I would guess it's better to use parentheses just for consistency with style of this particular page.

There is no reason to capitalize this.

I would move the parenthesis to right before the comma to avoid breaking up the lemma.

Redundant article. I would perhaps rewrite to “The job control facility allows users”

Perhaps “Additionally, the following built-in commands accept a job ID as an argument:” would be better

either “see the <title> section below” or just “see <title> below”

remove the final “the” here because Ar signal acts as a proper noun.

I know that Oxford commas are controversial but the FDP mandates them (section 12).

“for additional information on the meanings of these signals”

Move the parenthesis to the end of the sentence, and perhaps switch to the shorter formulation that you used above.

If there is substantial text copied from POSIX after all review changes, please add a notice like in share/examples/mdoc/POSIX-copyright.

Might want to mention here how this can be done: Ctrl+Z (if not adjusted using stty(1)).

Nit: I think this sentence "At most one job can be identified with it." can be removed since "Identifies the job" above already implies it.

Nit: I think this sentence "At most one job can be identified with it." can be removed since "Identifies the job" above already implies it.

I think the "expressed as a decimal number" part is appropriate for a standards document but a little too verbose for a manual page. That the number is decimal would be what a normal person expects, so there is no need to mention it. (If it were hexadecimal, that would need to be mentioned.)

Perhaps add something like "This is typically because Ctrl+Z was pressed."

Unfortunately, these messages are messier than that. As can be found in lib/libc/gen/siglist.c, they are Suspended (signal), Stopped (tty input) and Stopped (tty output), for SIGSTOP, SIGTTIN and SIGTTOU respectively.

Then I guess we would also need to mention how to 'continue their execution at a later point' and 'run them in the foreground or in the background'? I.e. for some reason we explained 'selectively suspend the execution of processes', but forgot about other actions in this list...

Will this sentence better be put in parenthesis after '(see ...)', or just as a standalone sentence?

Indeed, thanks for that! Will it be ok if we list all of this messages (including 'Suspended') as separate .It items first and below write a single description, where names of the signal, which interrupted the process, will be listed in the same order as their messages?

That would be using the bg and fg builtins.

I'd say a standalone sentence would be good enough.

SIGTTIN could be described as "This is typically because the command attempted to read from the terminal while in the background." and SIGTTOU could be described as "This is typically because the command attempted to change terminal settings or (if stty tostop is in effect) write to the terminal while in the background."

SIGSTOP can be described as a signal since it does not have common ways of generation other than kill.

Sure, but just to be sure that I understood what you mean right: we put this additional info in the parenthesis after every statement about these features in this sentence?

You didn't test this, you can't use Ao/Ac here.

I didn't know that - as I can see, it renders fine. Is there a semantic issue here? Shall we instead use just '<space>'?

it renders fine.

Sorry, my mistake! How are you rendering and viewing it?

How are you rendering and viewing it?

Just simply man bin/sh/sh.1. It is displayed like this: ⟨space⟩. This is in xterm.

Are there other ways to render and view the manpage? Isn't man sufficient?

For long and content-saturated man pages, I find it often useful to render into ps/pdf and read like an article, instead of the terminal rendering. Either

mandoc bin/sh/sh.1 >/tmp/sh.1.pdf

or, if groff is installed (if not installed, better install and check with groff as well)

groff -Tpdf -mdoc bin/sh/sh.1 >/tmp/sh.1.pdf

mandoc bin/sh/sh.1 >/tmp/sh.1.pdf

I guess mandoc -T pdf bin/sh/sh.1 >/tmp/sh.1.pdf was meant. Thank you!

I tested with both mandoc and groff and in both cases <space> renders good.

You can actually write it a little neater like this