Austin Group Defect Tracker

Aardvark Mark IV

Viewing Issue Simple Details Jump to Notes ] Issue History ] Print ]
ID Category Severity Type Date Submitted Last Update
0001075 [1003.1(2013)/Issue7+TC1] Shell and Utilities Objection Omission 2016-09-08 20:08 2019-10-28 10:36
Reporter Don Cragun View Status public  
Assigned To
Priority normal Resolution Accepted As Marked  
Status Applied  
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 Note: 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.

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
Attached Files

- Relationships

-  Notes
kre (reporter)
2018-03-08 21:42
edited on: 2018-03-08 21:45

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

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).

geoffclare (manager)
2018-03-09 11:06

Reopening as we need to address kre's comment.
joerg (reporter)
2018-03-09 11:23

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.
kre (reporter)
2018-03-09 13:05

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

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.
joerg (reporter)
2018-03-09 13:20

What I wanted to say is that Don may have looked at the Bourne Shell sources when writing his proposal.
geoffclare (manager)
2018-03-15 15:56

On P 2395, L76342 (1st paragraph of unset DESCRIPTION section) change:
Each variable or function specified by name shall be unset.

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).
hvd (reporter)
2018-04-21 08:01

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.

- Issue History
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 => Note: 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

Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker