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
