View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001071 | 1003.1(2013)/Issue7+TC1 | System Interfaces | public | 2016-08-25 17:17 | 2024-06-11 08:55 |
| Reporter | nick | Assigned To | |||
| Priority | normal | Severity | Comment | Type | Enhancement Request |
| Status | Closed | Resolution | Accepted | ||
| Name | Nick Stoughton | ||||
| Organization | USENIX | ||||
| User Reference | nms | ||||
| Section | 2.2.2 The Name Space | ||||
| Page Number | 473 | ||||
| Line Number | 16061 (TC1) or 16302 (TC2D4) | ||||
| Interp Status | --- | ||||
| Final Accepted Text | |||||
| Summary | 0001071: Name space reservation should move to XBD | ||||
| Description | The current text in XSH 2.2.2 reads:
However, this is in a section that is very C-language specific, and it is desirable to reserve namespace for other things like environment variables, functions in awk scripts, shell long options, etc. and it is unclear if this reservation extends to these. Future versions of this standard need to be able to invent new names where there exists multiple, differing, implementations of something with the same name, or an existing method needs to be enhanced in an incompatible way | ||||
| Desired Action | Create a new section in XBD after section 12 (Utility Conventions) and before section 13 (Headers) called "Namespace and Future Directions".
In XSH 2.2.2 on page 473, change
to
| ||||
| Tags | issue8 | ||||
| related to | 0000901 | Closed | reserve _POSIX* shell option namespace for future use |
|
|
Although we are reserving these namespaces for use by the standards, we realize that there is some existing practice using some names in these namespaces. Since these namespace reservations won't be formal until Issue 8 is adopted and we plan to start using some names in these namespaces in Issue 8, we will attempt not to break existing code while producing Issue 8 of the standard. (We try to avoid name collisions even when there are namespace reservations anyway, but there is always a chance that we will pick a name and not know that the name has been used for some other purpose.) |
|
|
The whole idea of reserving namespaces is fundamentally broken - it was realising that which caused the IETF to drop the "X-" e-mail header convention that had existed in earlier e-mail standards but is now gone. The convention (whatever namesoace is reserved this way) isn't so bad when the authority is one which simply invents new technology of its own volition, then expects that to be implemented. But for standards bodies like the IETF, and here, which expect to standardise what exists in the wild (what has been implemented, and had become common - leaving aside whether that is still true, in any sense, in the IETF) it creates a catch-22. An external implementation cannot implement anything using the reserved namespace, as it is reserved, so they use something else instead. The standards body cannot standardise anything new using the new namespace, as there are no implementations of the new technology using that namespace - they all use something different. For issue8, it would be better to simply drop the whole idea, rather than broadening it. |
|
|
Any implementation in the wild is fundamentally the same whatever names are chosen to implement it. The time for introduction of names using the reserved prefixes is therefore in the proposal for adding it to the standard, where the risk of conflicting usage of the wild names is significant. Platforms using the new names will still have to be recompiled to a new point release simply because POSIX_VERSION will get bumped also; it is up to them to advertise properly applications using the wild version would need refactoring/compiling also to be conforming once a proposal is approved for being in that next release. There is no Catch-22, from this standard's perspective, just a matter of following reasonable procedures. |
|
|
It isn't the platform that matters, but the users' scripts. Take a real example - many shells implement the "pipefail" option, which alters the way the shell determines the exit status of a pipeline. That's now common enough that it could be standardised (maybe there's an issue requesting it - this is not intended to be that - and it doesn't matter for this purpose). If we were to say "that's not a posix reserved name, we would have to call it _posix_pipefail" (or something like it) it would be useless - all the scripts that use it do "set -o pipefail". What's more, changing its name would be dangerous, no shell that currently implements "pipefail" can ever drop support for that name - because the users use it. But if it isn't standardised, they also have no reason to make that option conform to what the standard actually specifies for the new option - they could implement a conforming _posix_pipefail (which nothing uses) and leave the old one being similar, but perhaps slightly different. That's exactly what standardisation is supposed to avoid. The correct route of course would be to simply define what the "pipefail" option is supposed to be (what effect it has) using that name and taking account of what is common between the implementations. Any shell that wants to conform would need to make that option work the posix way (at least in posix mode.) That is how it ought to be. That is, the _posix_* namespace is simply useless, unless something new is to be invented. And that should not happen (except perhaps for some indicator to indicate that some other feature exists - so perhaps a _posix_pipefail variable might get set if the pipefail option exists .. except that would be invention, as no implementation I have seen does that, and as the name is reserved, nor can they while also conforming.) And while (if it worked) namespace divisiion would solve name clashes between posix and the implementations, it doesn't solve the clashes that matter, between different implementations, and between the implementations and the users - they still all use whatever they want (excepting only the _posix_ names) and implementations can clash with each other and with scripts - the world manages to deal with all of that - people don't always like it, but there is no workable better way. This same kind of thing is true of all attempts to divide namespaces between "us" and "them". Unless "we" ("us") are in the business of regularly inventing new stuff, we have no need for new names, and so we have no need of a reserved namespace. If we are just writiing down what others have already invented, we *must* use their names. If that would cause too big of a problem, then whatever it is is not ready to be standardised. ps: Please do not use this note as a trigger for discussions of the pipefail option ... that is just an example for this note. |
|
|
The intention of the posix prefix is to be able to include a feature that has been implemented in a non-unique way in different shells. If such a problems exists, POSIX could chose one of the implementations or a better combination from all existing implementations ans introduce it under the name posix_xxx |
|
|
Re Note 4033 First, before anyone draws any incorrect conclusions from this note, I am very much opposed to creating any rules to attempt to limit future solutions to any problem - each should be considered entirely upon its merits to find the best solution, unencumbered by any "we cannot do this, because we decided..." That said, let's consider a few possibilities for what might happen: First, if multiple implementations (this includes anything, not just features in shells) might implement different things and call it by the same name (a namespace collision). This isn't really a case considered in the note, or the bug report, but is related (kind of) so I am including it here... It isn't (wasn't) considered as it really is a different issue - each of the features would need to be considered independently. If one (functionality, not name) is implemented multiple times, and is worthy of being included, then it should be using a name which one of the other implementations has chosen rather than the one that conflicts (if at all possible). If the function has been implemented multiple times, all with the one name, that happens to have been used elsewhere for something different then it should just be standardised under the common name, and the implementations that used the name for something else need to change (but this should be a last resort.) If several implementations have implemented substantially the same functionality under the same name, then it should just be standardised under that name (with the common parts of the functionality specified, and less common parts either unspecified, or if essential, then as most commonly implemented.) If there are variant implementations of some functionality under the same name, such that the common part is so limited as to be useless, then it is not ready to be standardised, and the implementations should be encouraged to converge upon a more functional common set of features. What should never be done is "a better combination from all existing implementations" - that's invention, and without implementation and use, it is only guesswork as to whether what is specified will actually be useful or not. That we should avoid - always. Simply note the problems, and leave it for the implementations to come up with solutions that work, and once there is something, then it can be included. Included using the name actually used in the implementation(s?) - if that happens to be posix_xxx then fine, otherwise, just xxx. Again, these are nothing more than general principles, not rules, in any particular case, what should be done will depend upon the actual issues, and what implementations actually exist, and how they are actually used. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2016-08-25 17:17 | nick | New Issue | |
| 2016-08-25 17:17 | nick | Name | => Nick Stoughton |
| 2016-08-25 17:17 | nick | Organization | => USENIX |
| 2016-08-25 17:17 | nick | User Reference | => nms |
| 2016-08-25 17:17 | nick | Section | => 2.2.2 The Name Space |
| 2016-08-25 17:17 | nick | Page Number | => 473 |
| 2016-08-25 17:17 | nick | Line Number | => 16061 (TC1) or 16302 (TC2D4) |
| 2016-08-25 17:17 | nick | Interp Status | => --- |
| 2018-01-04 17:09 | nick | View Status | private => public |
| 2018-01-04 17:23 | nick | Relationship added | related to 0000901 |
| 2018-01-04 17:44 | Don Cragun | Note Added: 0003907 | |
| 2018-01-04 17:44 | Don Cragun | Status | New => Resolved |
| 2018-01-04 17:44 | Don Cragun | Resolution | Open => Accepted |
| 2018-01-04 17:44 | Don Cragun | Tag Attached: issue8 | |
| 2018-05-09 11:45 | kre | Note Added: 0004023 | |
| 2018-05-10 14:52 | shware_systems | Note Added: 0004026 | |
| 2018-05-10 14:54 | shware_systems | Note Edited: 0004026 | |
| 2018-05-11 10:06 | kre | Note Added: 0004029 | |
| 2018-05-14 10:59 | joerg | Note Added: 0004033 | |
| 2018-05-15 22:22 | kre | Note Added: 0004035 | |
| 2020-04-21 13:41 | geoffclare | Status | Resolved => Applied |
| 2024-06-11 08:55 | agadmin | Status | Applied => Closed |
