[bug #65980] [troff] diagnose why directory operands can't be opened

[G. Branden Robinson]

Follow-up Comment #3, bug #65980 (group groff):

I recast the Summary because it was a little too vague.

_groff_ has long issued diagnostics when an input file can't be _read_.


$ echo "Hello, Dave." > dave.troff
$ chmod 000 dave.troff
$ nroff dave.troff
troff: fatal error: cannot open 'dave.troff': Permission denied
$ ~/groff-1.22.3/bin/nroff dave.troff
troff: fatal error: can't open `dave.troff': Permission denied


The problem with a directory is that it _can_ be opened with _fopen_(3) for
reading...a legacy hangover of 1970s Unix where you really could open and read
directories as files.  Bell Labs quickly learned the hazards of arbitrary
_writes_ to directories by user, or even inexpertly audited privileged
code...a path that leads swiftly to _fsck_ (which hadn't been invented yet--I
think they had things called _dcheck_ and _clri_?).

Anyway, you get the idea.  The opening of the named file and actually reading
from it are separated in time.  When _troff_ attempts a read from a
successfully opened directory, that read fails and it moves on to the next
operand (if any, or the standard input stream if given the `-i` option).

Since we know by its file type (or "mode" in _stat_(2) parlance) that a read
from a directory will never succeed, we can diagnose it at _fopen_ time, which
is what we now do, at the cost of non-standard-libc calls to inquire about
that file type.

I decided not to foreclose reading from other file types.  There's no inherent
reason one can't read *roff input from a socket, a block device, a character
device (like a terminal, natch), a fifo (named pipe), and so forth. 


    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65980>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/

signature.asc
Description: PGP signature