Re: [Groff] Strange error messages from Groff 1.22.3

[Keith Marshall]

On 11/11/14 19:20, Ralph Corderoy wrote:
> Hi Eli,
> 
> Thanks for the explanation.
> 
>>> Am I right in thinking that Windows' API is as happy with a/b/c as
>>> a\b\c
>>
>> That's correct.
>>
>>> and so wrappers around the code that's cooking up the a\b\c in the
>>> first place could transliterate there without caring where the a/b/c
>>> is later to be used?
>>
>> The problem with this approach is that these file names are not cooked
>> by Groff code, they come from the command-line arguments typed by the
>> user, see above.  And AFAIK the (very cool, IMO) feature of
>> controlling how the user types the command line is not yet in Groff
>> ;-).
> 
> Hmm, does that mean the argv[] processing in groff's code is a place to
> transliterate when it's known to be a filename?

How can that possibly be known?  When argv[] processing is performed,
all we see is a sequence of strings; they have no semantic meaning.

> No problem if not, of if it's no better than what's been done.  I'm just
> wondering if .lf won't end up being the only place that matters and so
> changing it on input rather than output might be better, if that's
> identifiable.

Perhaps Eli's explanation is overly simplistic.  In reality, cmd.exe
doesn't process those directory separators, no matter whether they are
specified as slashes, (as POSIX and $DEITY mandate), or reversed
slashes, (as Microsoft recommend); that is actually the responsibility
of the application which is invoked.  Thus, the file (or path) name
*could* have been specified to groff, using proper slashes up front,
when the user entered the command line.

The real problem here is that Windows users tend to be hung-up on the
(bogus) notion that they must use reversed slashes, and will tend to do
so; thus groff needs to be prepared to handle this scenario.  Eli's
proposed solution does just that, at the point where the semantic notion
that the argument represents a path name has been established.