Austin Group Defect Tracker

Aardvark Mark IV

Main | My View | View Issues | Change Log | Docs
  

Viewing Issue Simple Details [ Jump to Notes ] [ Issue History ] [ Print ]
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 2022-07-25 15:25
Reporter joerg View Status public  
Assigned To
Priority normal Resolution Rejected  
Status Closed  
Name Jörg Schilling
Organization
User Reference
Section set
Page Number 2380
Line Number 75979-75999
Interp Status ---
Final Accepted Text
Summary 0001025: set description contains counterproductive claims
Description 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.
Desired Action 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.
Attached Files

- Relationships
related to 0000767Closedajosey 1003.1(2008)/Issue 7 Add built-in "local" 

-  Notes
(0003049)
stephane (reporter)
2016-01-28 12:16
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:

vars=$(set)
....
eval "$vars"

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").
(0003050)
joerg (reporter)
2016-01-28 13:21
edited on: 2016-01-28 13:41

 The official and documented way to save and restore shell settings is
to catch the output from

set +o

and to later execute the saved output. With this attempt, ksh93
is non-POSIX...

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.
(0003051)
shware_systems (reporter)
2016-01-28 15:00

 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.
(0003052)
joerg (reporter)
2016-01-28 15:35

 While unset may be a bit counter-intuitive, it looks like a useful
proposal.

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:
http://schillix.sourceforge.net/man/man1/bosh.1.html [^]
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.
(0003053)
shware_systems (reporter)
2016-01-28 15:59

 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.
(0003064)
joerg (reporter)
2016-02-01 13:09
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.
(0003508)
joerg (reporter)
2016-12-01 16:26
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

http://schillix.sourceforge.net/man/man1/bosh.1.html [^]

that today (December 1 2016) has this information at the bottom of page 60.
(0005909)
Don Cragun (manager)
2022-07-25 15:23

 This feature is not implemented in most conforming shells. Therefore, this bug is rejected.


If other shells do implement this feature, please resubmit this bug for inclusion in a future revision of the standard. If this does happen, we suggest something like adding a -F option to type.

- Issue History
Date Modified Username Field Change
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
2022-07-25 15:23 Don Cragun Note Added: 0005909
2022-07-25 15:25 Don Cragun Interp Status => ---
2022-07-25 15:25 Don Cragun Status New => Closed
2022-07-25 15:25 Don Cragun Resolution Open => Rejected

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