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.
