View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001075 | 1003.1(2013)/Issue7+TC1 | Shell and Utilities | public | 2016-09-08 20:08 | 2024-06-11 08:55 |
| Reporter | Don Cragun | Assigned To | |||
| Priority | normal | Severity | Objection | Type | Omission |
| Status | Closed | Resolution | Accepted As Marked | ||
| Name | Donald Cragun | ||||
| Organization | Self | ||||
| User Reference | |||||
| Section | 2.14 Special Built-in Utilities -- unset | ||||
| Page Number | 2395 | ||||
| Line Number | 76338-76355 | ||||
| Interp Status | --- | ||||
| Final Accepted Text | 0001075:0003937 | ||||
| Summary | 0001075: The unset utility's NAME section mentions values and attributes, but the DESCRIPTION doesn't mention attributes. | ||||
| Description | The unset special built-in utility's NAME section is:unset — unset values and attributes of variables and functions and traditional implementations of unset do indeed unset variables and remove the export attribute from variables that are unset. But the DESCRIPTION, OPTIONS, OPERANDS, EXTENDED DESCRIPTION, APPLICATION USAGE, EXAMPLE, and RATIONALE sections do not mention attributes. The standard does not provide any mechanism to export a function definition nor to make a function definition read-only, but the function definition command rationale mentions that some shells allow functions to be exported as an extension. | ||||
| Desired Action | On P 2395, L76342 (1st paragraph of unset DESCRIPTION section) change:Each variable or function specified by name shall be unset. to: The unset utility shall unset each variable or function definition specified by name and unset any attributes that have been given to name (see section 2.14 export and readonly). | ||||
| Tags | tc3-2008 | ||||
|
|
I had not seen this issue earlier... I do not much like the resolution approved, as it suggests that "unset" can undo the readonly attribute, which has never been one of its functions. The text does say that Read-only variables cannot be unset. but it does not say (explicitly) that the readonly attribute cannot be removed - and if the text is now to say and unset any attributes that have been given to name (see section 2.14 export and readonly). It reads to me as if it is saying that unset should be able to unset the readonly attribute, and there is nothing that counters that. The text as it currently exists (in TC2) says ... If -v is specified, name refers to a variable name and the shell shall unset it and remove it from the environment. I have always interpreted "remove it from the environment" as including "delete the export attribute" as if that were not to happen, the variable would simply reappear in the environment when it is set again, and that is not what any shell has ever done. I agree that this section is not well written, and needs clarification (particularly in that if -v is not specified, all it says is that the variable should be unset - which could allow an implementation to leave the value in the environment while deleting it from the current shell, which is also not what should happen.) So, I would suggest that the text should say something more like If -f is set, each name refers to a function, and affects the named functions. If -v is set, each name refers to a variable, and affects the named variables. If both -f and -v are set, then both variables and functions are affected. If neither -f nor -v is specified, name refers to a variable; if a variable by that name does not exist, it is unspecified whether a function by that name, if any, is affected. Each variable to be operated upon by this command shall be unset, removed from the environment, and have its export attribute (see the export command in section 2.14) removed. Read-only variables (see the readonly command in section 2.14) cannot be unset, and are not altered in any way. Each function to be operated upon by this command shall have its definition deleted (the function shall be unset) so that no function of that name continues to exist in the current execution environment. Unsetting a variable or function that was not previously set shall not be considered an error and does not cause the shell to abort. (and the rest that currently follows the previous sentence, which is unchanged.) There should probably be something added related to attempts to unset readonly variables causing an error (at least exit status 1, and a diagnostic to stderr). |
|
|
Reopening as we need to address kre's comment. |
|
|
Well the Bourne Shell uses this algorithm since more than 35 years: The unset C function in the shell resets all attributes (including the readonly attribute) when it does the actual unset. It however first checks whether a variable is readonly and fails in this case before doing something with the variable. |
|
|
Joerg - you mean it resets the readonly attribute that it already knows is not set? And the only other attribute that exists is "exported" right? So in practice, "resets all attributes" means "resets the exported attribute, if set". I prefer to be explicit about what happens. Where it makes a difference is for shells that have added more attributes (not the one I work on I might add here). If "unset" claims that "all" attributes are reset, then that would mean that some attribute that most of us have never heard of (the "null on weekends" attribute) must be reset by the "unset" command - yet the shell that invented that attribute might not act that way, and perhaps for good reason. We should specify what happens for attributes defined by the standard. There are, as best I recall anyway, just 2 - exported and readonly. Unset never resets readonly, so let's just be accurate and say that it unsets the export attribute (and the value of course), and leave it at that. Whether attributes that other shells have are also unset is for the documentation of those shells to specify. If any such attribute is ever added to posix, then we would need to ammend this section, to indicate whether it is cleared, or not, by the unset command. |
|
|
What I wanted to say is that Don may have looked at the Bourne Shell sources when writing his proposal. |
|
|
On P 2395, L76342 (1st paragraph of unset DESCRIPTION section) change: Each variable or function specified by name shall be unset. to: The unset utility shall unset each variable or function definition specified by name that does not have the readonly attribute and remove any attributes other than readonly that have been given to name (see section 2.14 export and readonly). |
|
|
I believe the currently accepted text would mean that it is no longer an error to attempt to unset a readonly unexported variable: unset is specified to simply do nothing in that case, which cannot fail. I believe the currently accepted text is unclear on whether it would be an error to attempt to unset a readonly exported variable: unset is specified to only remove the export attribute, but is silent on whether that attempt will succeed. (Note: this is similar to the question of whether the export attribute can be added to a readonly variable. Implementations vary, and in those that allow it, there is further variance in whether extensions such as typeset +x allow the attribute to subsequently be removed.) Shells do treat both of these as an error and should continue to do so. I think the originally proposed wording was on the right track for handling that, but the failure to unset a variable should imply that its attributes will not be modified, in which case it does not matter whether unset is specified to unset the readonly attribute. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2016-09-08 20:08 | Don Cragun | New Issue | |
| 2016-09-08 20:08 | Don Cragun | Name | => Donald Cragun |
| 2016-09-08 20:08 | Don Cragun | Organization | => Self |
| 2016-09-08 20:08 | Don Cragun | Section | => 2.14 Special Built-in Utilities -- unset |
| 2016-09-08 20:08 | Don Cragun | Page Number | => 2395 |
| 2016-09-08 20:08 | Don Cragun | Line Number | => 76338-76355 |
| 2016-09-08 20:08 | Don Cragun | Interp Status | => --- |
| 2018-03-08 16:20 | geoffclare | Status | New => Resolved |
| 2018-03-08 16:20 | geoffclare | Resolution | Open => Accepted |
| 2018-03-08 16:20 | geoffclare | Tag Attached: tc3-2008 | |
| 2018-03-08 21:42 | kre | Note Added: 0003931 | |
| 2018-03-08 21:45 | kre | Note Edited: 0003931 | |
| 2018-03-09 11:06 | geoffclare | Note Added: 0003932 | |
| 2018-03-09 11:06 | geoffclare | Status | Resolved => Under Review |
| 2018-03-09 11:06 | geoffclare | Resolution | Accepted => Reopened |
| 2018-03-09 11:23 | joerg | Note Added: 0003933 | |
| 2018-03-09 13:05 | kre | Note Added: 0003934 | |
| 2018-03-09 13:20 | joerg | Note Added: 0003935 | |
| 2018-03-15 15:56 | geoffclare | Note Added: 0003937 | |
| 2018-03-15 15:57 | geoffclare | Final Accepted Text | => 0001075:0003937 |
| 2018-03-15 15:57 | geoffclare | Status | Under Review => Resolved |
| 2018-03-15 15:57 | geoffclare | Resolution | Reopened => Accepted As Marked |
| 2018-04-21 08:01 | hvd | Note Added: 0003988 | |
| 2019-10-28 10:36 | geoffclare | Status | Resolved => Applied |
| 2024-06-11 08:55 | agadmin | Status | Applied => Closed |
