[Groff] Re: pre-grohtml fails with SIGPIPE on command line invocation

[MARSHALL Keith]

Gaius Mulley <address@hidden> wrote:
> MARSHALL Keith <address@hidden> writes a very detailed
> explanation: -)
> 
>> There are, I think, three options here:
>> 
>>   1. Modify 'run_output_filter', so that SIGPIPE is ignored;  (this is
>>      easy, but I am reluctant to do it, since I do not believe it to
>>      be the most appropriate action).
> 
> ok..
> 
>> 
>>   2. Declare that 'pre-grohtml' should *always* process 'stdin', and
>>      *never* files specified as command line arguments;  modify the
>>      text displayed by the 'usage' function, and the parsing of
>>      command line arguments accordingly, such that 'pre-grohtml' will
>>      abort with a syntax error message, if file arguments are
>>      specified;  (this is probably also fairly easy, but likely to
>>      require a bit more effort than 1).
> 
> indeed, I think this the most appropriate course of action as users
> should never directly invoke pre-grohtml. All input files are
> soelim'ed and piped into pre-grohtml (by groff), then the input is
> buffered and sent to the postscript and html device drivers by
> pre-grohtml.
> 
>> 
>>   3. Modify the operation of 'pre-grohtml', such that files specified
>>      on the command line are processed appropriately.  Modification of
>>      the argument parsing code will also be required; at the very
>>      least, it will be necessary to eliminate such file names from the
>>      argument lists passed to 'do_image' and 'do_html';  (perhaps this
>>      should be the ultimate goal, but is likely to require
>>      significantly more effort than either 1 or 2).
>> 
>> What do you think?
> 
> this could be done, but only if it makes sense to developers/debuggers
> as this is the only audience I believe.. and then it is probably
> easier to redirect an input file into the gdb debuggee for testing?
> 
> My preference would be to go for (2), but I do hope I've not missed
> anything?

Thanks for this feedback, Gaius.

Option 2 is also my preference -- since option 3 would only be of
value to developers, the additional effort required to implement it is
unlikely to be justified.

If Werner is also in agreement, I will progress an implementation of
option 2.

Best regards,
Keith.