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

Update of bug #55334 (project groff): Severity: 5 - Blocker => 3 - Normal ___ Follow-up Comment #18: The original problem, which Ingo gave a severity of 5, was fixed in the commit mentioned in

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

Update of bug #55334 (project groff): Open/Closed: Closed => Open ___ Follow-up Comment #17: Setting this bug back to Open to reflect the Status being set back to "In Progress."

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

Update of bug #55334 (project groff): Status: Fixed => In Progress ___ Follow-up Comment #16: I will work on it, but I'll first make the 1.23.0.rc1

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

Follow-up Comment #15, bug #55334 (project groff): Re comment #14: All makes sense to me. Branden, do you want to write the required patch to avoid guessing from the filename and instead use fseek(3) and check for errors, as i suggested? And test it? I don't really want to work on it because

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

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

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

Follow-up Comment #13, bug #55334 (project groff): Thanks for fixing this! I would like to raise a minor concern, maybe you can tweak your solution. Comparing the filename to "-" seems fragile. There may be other ways to get a non-seekable file descriptor, for example someone passing

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

Update of bug #55334 (project groff): Open/Closed:Open => Closed ___ Reply to this item at: ___

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

Update of bug #55334 (project groff): Status: Confirmed => Fixed ___ Follow-up Comment #12: I've pushed (c30821d767974c0a5e7220c0e5a65dc963785dc5) a little fix to not use uchardet if the

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

Follow-up Comment #11, bug #55334 (project groff): I was thinking of the final call to groff done by pdfmom: groff -Tpdf -mom $preconv - $cmdstring" it passes the standard input from the previous calls (from what I understand, to generate the table of contents) plus the input file; however

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

Follow-up Comment #10, bug #55334 (project groff): If pdfmom is used in a pipeline, or given a filename of "-", it uses a temporary file to store the contents of stdin, so it is unlikely to cause a problem for preconv. ___ Reply to this

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

Follow-up Comment #9, bug #55334 (project groff): It was not my intention to give up the correct handling of stdin, but I'd like first to commit the easy fix I mentioned so that -me examples are correctly rendered on Windows. Then we can open another bug to think about a proper fix on stdin. I

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

Follow-up Comment #8, bug #55334 (project groff): Sorry for missing your point. As for the solution: I would suggest to explore better ways of saving stdin on a temporary file, before concluding we have no other way than punt. For example, how about using tmpfile? It should be portable, and is

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

Follow-up Comment #7, bug #55334 (project groff): My comment was probably not clear but when I wrote "But of course if 'groff' takes its own input from stdin 'preconv' will also have its input from stdin. [...]The difference is that (in 'doc/doc.am') the input .me is piped into groff" I was

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

Follow-up Comment #6, bug #55334 (project groff): > groff' always runs 'preconv' before any other pre-processors, and he always pass the input file as an argument to preconv That's not always true, and in particular the way the Groff build produces meintro.ps etc. is this: $ LANG=C LC_ALL=C

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

Follow-up Comment #5, bug #55334 (project groff): Whoa, the code in GNU make-4.2.1/output.c is also somewhat broken. It does correctly use open(O_CREAT|O_EXCL), but it only tries once (except for EINTR retries), which is vulnerable to denial of service. Even worse, lacking fdopen(3), it falls

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

Follow-up Comment #4, bug #55334 (project groff): 'groff' always runs 'preconv' before any other pre-processors, and he always pass the input file as an argument to preconv, e.g: groff -k foo triggers: preconv foo | troff -Tps | grops But of course if 'groff' takes its own input from

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

Follow-up Comment #3, bug #55334 (project groff): Btw, there's "prior art" to doing this kind of thing: that's what GNU Make does when invoked with a "-f -" command-line option. ___ Reply to this item at:

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

Follow-up Comment #2, bug #55334 (project groff): Relax, I cannot commit anything anyway, since I don't have write access to the Groff tree. And I'm all for finding a better way of doing this if it exists. Your proposal to read just part of the input is not necessarily a better solution, IMO:

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

Update of bug #55334 (project groff): Severity: 3 - Normal => 5 - Blocker Status:None => Confirmed Assigned to:None => bgarrigues Planned Release:

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

URL: Summary: preconv fails when build with libuchardet on MS-Windows Project: GNU troff Submitted by: eliz Submitted on: Sun 30 Dec 2018 05:44:25 PM IST Category: Preprocessor