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

[G. Branden Robinson]

Update of bug #55334 (project groff):

             Assigned to:              bgarrigues => gbranden               
                 Summary: preconv fails when build with libuchardet on
MS-Windows => preconv fails when built with libuchardet on MS-Windows

    _______________________________________________________

Follow-up Comment #20:

Self-reply after 16 months or so.

[comment #14 comment #14:]
> 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.

There's more cement poured over the semantics of "-" as a file name in groff
than I knew about back in 2020.  groff(1), if given it as an argument, passes
it as-is to all of the preprocessors it calls, and all the traditional
preprocessors recognize it.  It doesn't seem like a good idea to me to add
complexity to groff(1) to call preconv(1) differently.

> 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.

This part, after learning about "-" the hard way, I am working on.

> 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 haven't explored this yet.

> 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.

I hadn't documented that yet because I had hopes we'd be able to get by
without the special "-" file name (which Bertrand already implemented
post-1.22.4), but I don't think we can, without excessive complexity cost.

    _______________________________________________________

Reply to this item at:

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

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