bugGNU roff - Bugs: bug #61070, [troff] want to drop default...

 
 

bug #61070: [troff] want to drop default "User Abort." text from .ab request

Submitter:  G. Branden Robinson <gbranden>
Submitted:  Mon 23 Aug 2021 01:21:39 AM UTC
   
 
Category:  Core Severity:  1 - Wish
Item Group:  Feature change Status:  Fixed
Privacy:  Public Assigned to:  gbranden
Open/Closed:  Closed Planned Release:  1.23.0
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Sat 11 Sep 2021 08:24:52 PM UTC, comment #7: 


commit e266961202e32db22a94fa15ababddfc12771166
Author: G. Branden Robinson <g.branden.robinson@gmail.com>
Date:   Tue Sep 7 07:16:20 2021 +1000

    [troff]: Quieten `.ab` if given no arguments.

    [troff]: Make `ab` request quiet if given no arguments.  The `tm`, and
    `tm1` and `tmc` requests provide ample flexibility for constructing
    diagnostic messages prior to an error exit, and it's convenient to make
    `ab` itself quiet instead of saying "User Abort." as Unix Version 7
    troff did.  Further, there is no standardization across troffs regarding
    what `ab` should emit if arguments are absent.

    * src/roff/troff/input.cpp (abort_request): Do it.

    * src/roff/groff/tests/ab_works.sh:
    * src/roff/groff/groff.am (groff_TESTS): Test it.

    * doc/groff.texi (Debugging, Implementation Differences):
    * man/groff.7.man (Requests/Request short reference):
    * man/groff_diff.7.man (Implementation differences): Document it.

    Fixes <https://savannah.gnu.org/bugs/?61070>.  Thanks to Dave Kemper for
    the discussion.


G. Branden Robinson <gbranden>
Group administrator
Tue 07 Sep 2021 01:49:42 AM UTC, comment #6: 

comment #5:

> (shame!  SHAME!)


I dunno -- since the original docs never specified a nonzero exit value, and the original implementation exited with 0, this has every indication of being intentional, and groff the one that changed behavior here, probably to mirror the behavior of the similarly named abort() system call.  Worth pointing out in groff_diff(7) at least.

Dave <barx>
Group Member
Mon 06 Sep 2021 08:46:29 PM UTC, comment #5: 

Unix Version 7 nroff said exactly "User Abort." if .ab was given no arguments, and exited with status zero  (shame!  SHAME!).


PDP-11 simulator V3.8-1
sim> set cpu 11/45
Disabling XQ
sim> set tto 7b
sim> att rl unix_v7_rl.dsk
sim> boot rl
@boot
New Boot, known devices are hp ht rk rl rp tm vt
: rl(0,0)rl2unix
mem = 177856
# Restricted rights: Use, duplication, or disclosure
is subject to restrictions stated in your contract with
Western Electric Company, Inc.
Thu Sep 22 06:42:34 EDT 1988

login: dmr
$ nroff
.ab
User Abort.
$ echo $?
0
$ nroff
.ab foo
foo
$ echo $?
0


G. Branden Robinson <gbranden>
Group administrator
Thu 26 Aug 2021 02:00:46 PM UTC, comment #4: 

comment #3:

> > (though it also exits with a 0 status).
>
> Yikes!


I thought that was weird too, but I looked up .ab in CSTR #54, and it says nothing about the exit value.  So it may be canonically undefined.

Dave <barx>
Group Member
Mon 23 Aug 2021 09:58:22 AM UTC, comment #3: 


comment #2:

> Even in its most back-compatible mode (-x0), Heirloom troff gives some useful information when .ab is called with no argument


Yes, quite a bit of it.

> (though it also exits with a 0 status).


Yikes!
 

> Whether that's evidence that AT&T troff's bare .ab was a bit more chatty,


Version 7 Unix troff definitely was not.

https://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/src/cmd/troff/n5.c

(You'll have to search the text, as minnie doesn't show line numbers.)

> or that Heirloom's implementers didn't consider historical .ab output sacrosanct, I cannot say


I think it's clear that they didn't.  V10 Research Unix didn't change much, possibly taking off the period.

https://minnie.tuhs.org/cgi-bin/utree.pl?file=V10/cmd/troff/n5.c

DWB 3.3 troff is unchanged in this respect from V10.

https://github.com/n-t-roff/DWB3.3/blob/master/text/troff/n5.c#L435

> -- but I think either one makes the case that we needn't be married to the output groff's .ab currently offers.


So it seems.

> So "make groff stderr output match Heirloom's" could be yet another option, maybe D1.


Yeah, but I'm leaning away from it.  I kind of want an .ab that is quiet by default.

> B1 and B2 are my least favorites: they add a new request that offers no real new functionality, just tweaks functionality offered by an existing request; and the request they add will be interpreted by strictly conforming historical implementations as ".ab" with the argument "ort" anyway.


Good point.

> But that's all on purely theoretical grounds; I've never had occasion to use .ab in real life, so I don't have any strong opinion about how it works.


I was going to say that it shows up with some frequency in groff's macro packages, but most or all of the cases I see, I had a hand in writing.  Oops.

G. Branden Robinson <gbranden>
Group administrator
Mon 23 Aug 2021 09:42:59 AM UTC, comment #2: 

Even in its most back-compatible mode (-x0), Heirloom troff gives some useful information when .ab is called with no argument (though it also exits with a 0 status).


$ troff -x0 <<< '.ab'
troff: User Abort; line 1, file <standard input>

$ echo $?
0


Whether that's evidence that AT&T troff's bare .ab was a bit more chatty, or that Heirloom's implementers didn't consider historical .ab output sacrosanct, I cannot say -- but I think either one makes the case that we needn't be married to the output groff's .ab currently offers.

So "make groff stderr output match Heirloom's" could be yet another option, maybe D1.

B1 and B2 are my least favorites: they add a new request that offers no real new functionality, just tweaks functionality offered by an existing request; and the request they add will be interpreted by strictly conforming historical implementations as ".ab" with the argument "ort" anyway.

But that's all on purely theoretical grounds; I've never had occasion to use .ab in real life, so I don't have any strong opinion about how it works.

Dave <barx>
Group Member
Mon 23 Aug 2021 01:26:23 AM UTC, comment #1: 

original submission:

> C3. Modify the .ex request to accept an optional argument to define the exit status.


The above should have been numbered C1.

> My preference is for A1, because I have doubt that anyone parses or is wedded to the precise string "User Abort.", which communicates almost nothing that troff's own exit status does not.


On further thought that "almost" might be a "complete", because there is nothing to stop an input file from doing this.


...
.tm User Abort.
...


...carrying on merrily and eventually exiting normally, perhaps without producing any further output to the standard error stream.

G. Branden Robinson <gbranden>
Group administrator
Mon 23 Aug 2021 01:21:39 AM UTC, original submission:  

The default text emitted to the standard error stream by the .ab request when it is given no arguments feels like a relic to me.

1. It is idiosyncratically capitalized.
2. It is not a complete sentence, yet ends with a period.
3. It does not identify the program that is aborting.
4. It combines poorly with user leverage of the .tm family of requests.  The .tm1 and .tmc variants offer great control over the formatting of diagnostic output, enough that one doesn't really need .ab to do anything except exit (without the write to stderr).

A few solutions are possible.

A1. Change .ab to stop writing this default message.  This is the solution least (slavishly) compatible with AT&T troff.
A2. Change .ab to stop writing this default message only outside of compatibility mode.
B1. Add a new .abort request that implements the semantics I desire.
B2. Add a new .abort request that accepts an optional initial argument to define the exit status (before the optional message arguments).
C3. Modify the .ex request to accept an optional argument to define the exit status.

My preference is for A1, because I have doubt that anyone parses or is wedded to the precise string "User Abort.", which communicates almost nothing that troff's own exit status does not.

G. Branden Robinson <gbranden>
Group administrator

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by barx (Posted a comment)
  • -email is unavailable- added by gbranden (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2022-01-22 gbranden Item GroupNone Feature change
    2021-09-11 gbranden StatusIn Progress Fixed
        Open/ClosedOpen Closed
        Planned ReleaseNone 1.23.0
    2021-09-06 gbranden StatusNeed Info In Progress

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code