[bug #55334] preconv fails when build with libuchardet on MS-Windows

[G. Branden Robinson]

Follow-up Comment #14, bug #55334 (project groff):

I second Ingo on this.

'-' was always a hack.

As I understand it, it was developed in the days before there were such things
as /dev/stdin and /dev/stdout.  A way was needed for some programs to be told
via the shell to read or write file descriptors 0 or 1 and the shell had no
semantics for this (for _redirections_, yes--to denote a command operand as a
request to re-use fds 0 or 1 instead of opening a new file, no).

Even if /dev/std{in,out} _had_ existed, I get the feeling Thompson wouldn't
have used them because that would have been too much typing.  

'-' has no _standard_ system-wide semantics, only a set of command-specific
conventions.  Many groff programs replicate those conventions for the sake of
AT&T compatibility.  But we're not required to extend that pattern to preconv
and I don't think we should.

Strictly speaking, the seekability of a file stream should be independent of
whether it's one of the "standard" ones or not.  So if I understand the
applied patch correctly, this would cause a spurious defeat of uchardet
usage:


$ preconv - < foobar


The above is uneconomical, like the famous "useless uses of cat" frequently
contrived by Unix novices, but it shouldn't force any conclusions to be drawn
about the seekability of standard input.

By contrast,


$ cat foobar | preconv
$ cat foobar | preconv /dev/stdin


...both would be ways to render preconv's input un-seekable.

As a side note, if I run preconv with no arguments, I have to enter CTRL-D on
a line by itself _twice_ before it will exit.  Is that a bug?

I also note, more to myself as the man page guy, that preconv(1) doesn't
explicitly say what it does if it is given no file arguments, and it should.

Corrections welcome on any of the above.

    _______________________________________________________

Reply to this item at:

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

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