Date: Thu, 17 Sep 2020 14:40:04 -0400
From: Chet Ramey <chet.ra...@case.edu>
Message-ID: <b9f7a89c-f65a-e5f2-c5a6-daeb6b601...@case.edu>
| That's why I find yash so interesting to test against. It's written by
| someone with almost no contact with the standards community, yet attempts
| to implement the letter of POSIX.
Yes. I've had a few discussions with Yuki about various issues,
at least one of which led to a posix bug report.
| I don't have list-specific email configs.
Are there any lists for which you want to direct replies to yourself
rather than the list? And aside from me, do you encounter almost anyone
whose MUA actually implements Reply-To properly, and replies only to you?
(Except when manually overridden, which I usually remember to do.)
| Because that's where the incentives are. Nobody cares if you implement
| "what is right" if you fail a standards conformance test.
I guess that depends upon your objectives. I don't care in the
slightest about conformance tests, or their results - which is why
I won't implement "cd -L" and why NetBSD refuses to supply exec'able
forms of "cd" "umask" ...
When there are two options, neither of which looks better than the other,
and the standard has picked one, I'll do the same. When one is clearly
a better result (which involves both what happens and why, and also how
whatever it is is actually being used in the wild) then I'll do that one,
regardless of what the standard says should happen.
| The shell implementation still has to do something, even if the user is
| supposed to ensure it,
Of course.
| and that something really should try to reflect what
| the user intends (determining that is always a tricky business).
When possible, yes. But in something like "${foo:-abc"def}" it is
kind of hard to guess any intent. An error would make sense, but so
would expanding to abc"def (if foo is unset or null) just as if that
string had been single quoted, if that was possible there - just for the
purpose of the " of course, any $ expansion in it would still be processed.
| Then the standard needs to be clarified, doesn't it?
Yes, we were kind of at that point earlier ... and we know the result
can only be "unspecified" which isn't really very helpful.
It would be nicer if before that happens we could just agree on what
is the better result, and do that, and try to get mksh and ksh93 to
do the same. Then perhaps the standard would not need to say "unspecified".
kre
