|Anonymous | Login||2020-08-04 08:14 UTC|
|Main | My View | View Issues | Change Log | Docs|
|Viewing Issue Simple Details|
|ID||Category||Severity||Type||Date Submitted||Last Update|
|0001025||[1003.1(2013)/Issue7+TC1] Shell and Utilities||Editorial||Clarification Requested||2016-01-28 11:47||2016-12-01 16:51|
|Final Accepted Text|
|Summary||0001025: set description contains counterproductive claims|
The set command text only permits to list shell variables when set is
called without arguments.
Given that POSIX does not include the ksh builtin "typeset", this
prevents POSIX shells from being able to list all defined functions
using only POSIX methods.
Either permit "set" to list functions as well or introduce a new POSIX
method to list functions. It seems to be inapropriate for other reasons
to just add the ksh builtin "typeset" to POSIX.
|Tags||No tags attached.|
edited on: 2016-01-28 12:19
Changing the "set" output would be a non-backward-compatible change of API.
At the moment, one can do:
to restore variable contents as stored in $vars (without affecting function definitions). The suggested change of allowing "set" to output function definitions would break that usage pattern.
So, to dump the function definitions, we'd want a separate API like an option to "set" ("set -F", "set +F" like we have "set -o" and "set +o" for options and zsh has "set -A", "set +A" for arrays) or a separate utility (`ksh` and `zsh` already have `functions` (as an alias to "typeset -f").
edited on: 2016-01-28 13:41
The official and documented way to save and restore shell settings is
to catch the output from
and to later execute the saved output. With this attempt, ksh93
But you seem to refer to the state of the variables. For this
attempt, please note that one of the variables may have been set
read-only, so your example may cause an unexpected exit status != 0.
I agree this is nominally a deficiency, and brings to mind there are others, but am unaware of any existing practice aside from typeset. set +o and -o wouldn't report function names, just variables.
As invention, to leverage existing functionality, it appears that adding a -l(ist) flag to unset rather than set might be easiest, as it has to access the function name space already.
Suggested usage, if some shell wants to add it:
unset -l [name...]
list function names defined at shell invocation time to stdout,
one per line, with no arguments.
With a single name argument returns 0 as exit code if name is
not a function or variable, 2 if a variable, 3 if readonly variable,
+4 if also a function name.
With multiple names, 0 as exit code indicates none used as
function or variable name, a 1 exit code that stdout has a space
separated string of digit characters indicating the usage per
name written to it, followed by a newline.
unset -lf [name...]
list functions defined by the current script or interactively,
or exit code as above, 0 or 4, if name in use by a function.
unset -lv [name...]
list non-readonly variables, i.e. those that can be unset
(differs from set, which lists all names), or 0, 2, or 3 if name
is in use.
The current usage of -f, -v, and no flags would be unchanged, so no backwards compatibility concerns unless an implementation is using -l for another purpose as an extension. The description changes from 'undefine function or variable' to 'list usage or undefine function or variable names'. If the implementation considers inherited/built-in function names as read only, bit 3 of code, or a +8, can indicate that usage.
While unset may be a bit counter-intuitive, it looks like a useful
Note that there are several problems with backwards compatibility
caused by the POSIX standard:
Some of them already have been implemented in recent versions of the
Bourne Shell, see:
section COMPATIBILITY that currently starts on page 67.
The other known backwards compatibility issues are in the area
of function handling, function/variable name space and the "set"
problem mentioned in this bug.
|yes, set complex enough, imo. That was off the top of my head, but limiting it to 'what is or isn't set', and usage type if it is keeps things simpler. A flag for usage and contents like set output is unneeded, imo. History or reexecuting a script using dot covers it already for functions. This is for 'does a name desired to be used conflict with another use' testing only.|
edited on: 2016-05-10 10:37
How about "command -F name" or "command -F"?
The first would be similar to "command -V name" for a function but otherwise behave like "type name" where the named function definition is listed.
The second could list all function definitions.
Given that 0000854 Note: 0002495 list "type" already as a "shell intrinsic",
it may be a good idea to use "type -F" to list all functions and
"type -f name..." to list specific functions.
edited on: 2016-12-01 16:47
Since August 7, the Bourne Shell implements "type -F" to list all defined functions.
See the recent Bourne Shell man page at
that today (December 1 2016) has this information at the bottom of page 60.
|2016-01-28 11:47||joerg||New Issue|
|2016-01-28 11:47||joerg||Name||=> Jörg Schilling|
|2016-01-28 11:47||joerg||Section||=> set|
|2016-01-28 11:47||joerg||Page Number||=> 2380|
|2016-01-28 11:47||joerg||Line Number||=> 75979-75999|
|2016-01-28 12:16||stephane||Note Added: 0003049|
|2016-01-28 12:17||stephane||Note Edited: 0003049|
|2016-01-28 12:18||stephane||Note Edited: 0003049|
|2016-01-28 12:19||stephane||Note Edited: 0003049|
|2016-01-28 13:21||joerg||Note Added: 0003050|
|2016-01-28 13:33||joerg||Note Edited: 0003050|
|2016-01-28 13:34||joerg||Note Edited: 0003050|
|2016-01-28 13:34||joerg||Note Edited: 0003050|
|2016-01-28 13:38||joerg||Note Edited: 0003050|
|2016-01-28 13:39||joerg||Note Edited: 0003050|
|2016-01-28 13:41||joerg||Note Edited: 0003050|
|2016-01-28 15:00||shware_systems||Note Added: 0003051|
|2016-01-28 15:35||joerg||Note Added: 0003052|
|2016-01-28 15:59||shware_systems||Note Added: 0003053|
|2016-02-01 13:09||joerg||Note Added: 0003064|
|2016-05-10 10:37||joerg||Note Edited: 0003064|
|2016-12-01 16:26||joerg||Note Added: 0003508|
|2016-12-01 16:47||joerg||Note Edited: 0003508|
|2016-12-01 16:51||eblake||Relationship added||related to 0000767|
|Mantis 1.1.6[^] Copyright © 2000 - 2008 Mantis Group|