Add error numbers to the exit codes so that readers can decode them without having to use a separate utility. Organize exits by error code. Mark up the error constants with the error constant macro, even though this is really not very helpful because people will search for the error code, the macro is explicitly for the constants and not the codes. While where, align and alphabetize the options list as well, fix misaligned padding in an example, and a one-sentance-per-line error. Reported by: Antranig Vartanian <antranigv@freebsd.am> MFC after: 3 days
Details
- Reviewers
carlavilla mhorne kevans - Group Reviewers
manpages
Diff Detail
- Repository
- rG FreeBSD src repository
- Lint
Lint Skipped - Unit
Tests Skipped - Build Status
Buildable 71044 Build 67927: arc lint + arc unit
Event Timeline
Revert s/Dv/Sy/g, I did that to align with sysexits(3), however this was
a mistake as I think apropos Dv=EX_USAGE is an outstanding workflow. I
now believe that error messages should always be Dv.
Use Er to markup error constants according to mdoc(7), and use
Dv to markup the exit numbers to enable apropos Dv=64.
| usr.bin/lockf/lockf.1 | ||
|---|---|---|
| 216 | Okay, now I see where you were coming from with D48619... It seems clear to me that apropos Er=EX_USAGE should lead to this page. But I am not sure that apropos Dv=64 needs to. If the status code I am investigating comes from lockf(1), then I surely know which man page to check, no? | |
| 222–223 | .Po/.Pc save some headaches here. | |
Honestly, IMHO what would be best is Er=$actual_returned_number, but mandoc isn't written that way. The workflow for Er is actually purely imagined for me at this point since it doesn't exist yet for anything I've checked, which is normally completely unacceptable, but my rationale is that confirming to the standard will create allowance for the workflow.
One idea for Dv contributed by kevans@ is debugging complex shell scripts with $?, which I think would be reinforcing design consistency.
redo this commit without using Dvs. I think that organizing this page
and fufilling the requested error numbers is valuable and systemic
deficiencies in marking up error constants vs codes is not something
i can do anything about right now.