Date: Thu, 14 Apr 2022 09:42:37 +0100
From: "Geoff Clare via austin-group-l at The Open Group"
<[email protected]>
Message-ID: <20220414084237.GA15370@localhost>
| That is how things are at present. The suggested changes just make it
| explicit.
Yes, I know, but that's what I am suggesting that we not do in this one case.
| Do you have an alternative proposal?
Only to the extent of "do nothing". I am certainly not suggesting that
we attempt to solve the problem.
Except perhaps it might be worth adding something to the Rationale (but
about what, ie: where there, I have no idea) along the lines of:
It is often unclear whether a string is to be interpreted as
characters in some locale, or as an arbitrary byte string.
While it would have been possible to arbitrarily make the various
cases more explicit, or explicitly unspecifried, it was considered
better, in this version of <however the doc refers to itself> to
make no changes, as it is believed that much additional work is
required to enable a standards-worthy specification possible.
This work is beyond the scope of this standard.
The problem I see, is that any specification at all of any of this,
allows implementors to just say "that is what posix requires" and do
nothing at all, where we really need some innovation, by someone who
actually understands the issues and how to deal with them in a rational
way - or at least who can come up with some kind of plan, and without
any possibility of being considered a non-conformant implementation
because of it.
| The application can document that it requires pathnames to be in the
| same encoding as the user's locale.
That's not sufficient. Try encoding a find command to look for pathnames
containing currency symbols. It should be just a simple find -name '*[ABCD]*'
type operation, with appropriate substitutions for the ABCD chars.
No problem if not all the world's currency symbols are encoded, if we find
one that has been forgotten, it can simply be added. Currency symbols are
things like the $ sign, British pound, Euro, Yen, Baht, ... (there are a
whole bunch of them). If there were a [:currency:] class, it would be easy
(and I'd need to come up with a different example). But there isn't.
If we cannot do something this simple, and expect it to work reliably,
everywhere, then what we have is useless, and needs to be replaced or
reworked. That's not a standards' body type task. But we should be
doing nothing to interfere with the production of a solution.
| The C locale is specified as containing 256 single-byte characters.
| Thus in the C locale all pathnames are valid character strings.
Sure, understood.
| > Even worse perhaps, ???.doc which should match 7 char
| > names that end in ".doc" (or is that 7 byte names?) (not counting the \0).
|
| It would match 7-byte names.
Yes, in the C locale it would. But do you believe that is what the user
would have intended? Are they to be required to work out how many bytes
their local filenames are encoded as, and enter the appropriate number of '?'
chars?
kre
