The amount of sheer invention swirling around this issue is amazing.
The question "Does POSIX / WG15 / OpenGroup create new interfaces out of whole
cloth" was settled more than two decades ago. I was in the room when it
happened. The answer to that question is "No". In the POSIX/WG15/OpenGroup
world, a "Sane Standard" documents what implementations do, not what some
collection of individuals believe they ought to do.
There are no implementations that have a "globskipdot" option or anything like
it. The fact that the standard does not document such a (non-existent in any
real implementation) option cannot be regarded as an error to be corrected;
this is invention.
If the MOA which governs the behavior of the IEEE POSIX standards committee,
JTC1/SC21/WG15, and The Open Group with respect to IEEE 1003 and ISO/IEC 9945
has been altered to allow or encourage invention, it's news to me. And should
this committee decide to go there, I can promise an avalanche of sheer
invention will arrive within the next year, if I have to spend vacation time to
dream it up and find a half-dozen sock puppets with whom I can forge consensus
with regard to "need" and "sanity".
This door was slammed shut and welded closed. That's not how POSIX changes
anymore, for better or worse.
You want to make this change? Show me two mainstream implementations that
address the issue. Even if they need harmonization, that's a place to start.
The old TCOS-SS SEC PAR Evaluation Criteria didn't have a hard and fast rule
for just how "mainstream" it had to be, but 0.1% of the installed base of
recent releases of UNIX (and now Linux) wouldn't have met the bar. But without
real world implementations to examine, without a pool of real-world experience
with the proposed feature to draw on, this is inappropriate for consideration
for the POSIX standard.
What was the old rule of thumb? "If it's not boring, it's not ripe for
standardization." The amount of argument in this thread alone demonstrates that
"boring" doesn't apply here.
Implementations drive the standard into new content. The standard does not
drive implementations into new code.
Jason Zions
-----Original Message-----
From: Andreas Grapentin <[email protected]>
Sent: Tuesday, June 4, 2019 6:12 AM
To: Joerg Schilling <[email protected]>
Cc: [email protected]; [email protected]; [email protected];
[email protected]
Subject: Re: Bug 1228: allow shells to exclude "." and ".." from pathname
expansions
This discussion seems to currently spiral into conflicting opinions about
whether sane shell globbing of .*/ should include `../' and `./'.
However, the originally discussed issue was whether the introduction of an
option to control the globbing behaviour of the shell should be specified in
the standard or not.
I would personally offer the opinion that any `sane' or `expected'
behavior must depend on the use case. Situations can be constructed where each
of the two possible behaviours can be desirable:
# should probably not include ../
$ rm -r .*/
# should probably include ../
$ grep '#include' .*/*.{c,h}
As such, I would agree that it seems to make sense to specify a globskipdot
option in the shell and require consistent behaviour from readdir across
filesystems. Especially since for the application an argument produced by a
glob expansion is indistinguishable from one typed explicitly.
The next question to answer though, would then be what the default setting for
the option should be... :)
Best,
Andreas
--
------------------------------------------------------------------------------
my GPG Public Key: https://files.grapentin.org/.gpg/public.key
------------------------------------------------------------------------------
