[bug #65108] [troff] support construction of general file name request arguments

[Dave]

Follow-up Comment #13, bug #65108 (group groff):

[comment #12 comment #12:]
> I feel like we're saying the same thing, or compatible things.

Quite possibly.

> A file named "résumé1.ms" might be stored on the file system
> using either character encoding,

...or, as my example attempted to illustrate, _two_ files might be stored,
each using a different encoding.

Similar to the contents of a file, a filename is just a string of bytes.  What
characters those bytes _mean_ is defined by the encoding.

A file can contain metadata to indicate its encoding; if not, there's often
enough context for tools like preconv (or even the system's "file" command) to
correctly guess it.

The settings of one's terminal and LC_CTYPE environment variable affect how
the string of bytes in a filename is interpreted.  There may not be enough
context to guess.  There's no metadata (that I'm aware of, though I'd be happy
to be wrong) to make the name's encoding definitive.

> That's why I want to be able to support:
> 

> $ grep -F .so résumé.ms
> .so r\[u00E9]sum\[u00E9]1.ms
> .so r\[u00E9]sum\[u00E9]2.ms
> .so r\[u00E9]sum\[u00E9]3.ms


Agreed, but I think it's ambiguous which of the two files I created in comment
#11 a construction like this refers to.  They both, from some viewpoint, have
the base filename "résumé".  They can both coexist on the same file system,
even in the same directory.


    _______________________________________________________

Reply to this item at:

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

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

signature.asc
Description: PGP signature