View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
00007741003.1(2013)/Issue7+TC1Shell and Utilitiespublic2013-10-19 22:022013-12-14 00:59
Reportersteffen Assigned To 
PrioritynormalSeverityEditorialTypeEnhancement Request
Status ClosedResolutionRejected 
NameSteffen Nurpmeso
Organization
User Reference
SectionVol 3: 2.5.3, 4.sh(1)
Page Number2326, 3192
Line Number73826, 106854
Interp Status---
Final Accepted TextSee 0000774:0002073.
Summary0000774: Addition of a POSIX_VERSION shell variable
DescriptionToday it is hard to write portable shell scripts because even on systems which state that they are POSIX compliant there are shells which do not comply to the set of features that POSIX describes for its sh(1).

To be able to at least produce correct error messages you find, in fact, yourself writing code "like the following", or similar:

  ( eval '[ "$(echo bticks)" = bticks ]' ) && echo ok || echo sorry

Many modern shells instead offer special version macros (KSH_VERSION, .sh.version, BASH_VERSINFO), which can instead be checked easily by shell programmers in order to act accordingly.
Desired ActionAt the mentioned addresses, add:

POSIX_VERSION
  This variable shall expand to the numeric value of the POSIX version that this shell complies to (in the format of the _POSIX_VERSION system interface symbolic constant [REFERENCE]).
  It shall be ensured that this variable is removed from the environment of subprocesses created by the shell.
TagsNo tags attached.

Activities

ranjit

2013-10-21 21:27

reporter   bugnote:0001940

You want getconf:
on_posix=$(command -p getconf _POSIX_VERSION 2>/dev/null) || on_posix=0

Don Cragun

2013-12-14 00:58

manager   bugnote:0002073

Last edited: 2013-12-14 01:12

 This was discussed at length during the December 5, 2013 Austin Group conference call. This request is rejected for several reasons (including but not limited to the following):
1. A given shell may comply to more than one version of the standard. (For example, on Solaris Systems, /usr/xpg4/bin/sh meets the requirements for what this request would specify to be 199309, 199506, and several others before this type of version numbering was included in the POSIX standards. How would the shell know which one of several choices it should report? (Be careful. If you say it should report the latest standard to which it conforms, all of the scripts that depended on it being an earlier value could stop working.) Note that an increasing version number doesn't guarantee additional features; obsolescent features that a script might be depending on can disappear in later versions.)

2. If you want to know about certain features provided by a shell, the version of the standard might not be a good indicator. Whether or not a particular version of the shell conforms to a particular version says nothing about what extensions to the standard might or might not be supported by that shell. And, the example trying to determine whether or not back quotes can be used for command substitution is strange since every version of the POSIX Shell and Utilities Standards have required both $( command ) and `command` to work.

3. Having a shell claim that it conforms to a version of a standard is frequently meaningless unless the utilities that will be found when using the current setting of $PATH conform to the same version of the standard. Using getconf POSIX_VERSION gives you a good idea of the environment you have available, IF you are using a system that conforms to the standard. If you are using a system (e.g., Linux systems) that does not verify that it conforms to the standards, there is no reason to believe that any particular feature of any particular utility will conform to POSIX requirements. (Most GNU utilities do conform to most POSIX requirements, but there can be a huge difference between "most" and "all" when the trivial requirement you want to use in your attempt to write a portable script because doing what POSIX requires is sometimes, hard or slower than doing it "another" or "better" way.)

4. The standard says nothing about how various alternative shells work. It only describes the behavior of a program named sh that can be found with command -p sh. Unfortunately, the current descriptions of getconf and command have a chicken and egg problem; you have to read the documentation to find the path to the command command and the getconf command to get the right one for a particular version of the standards. (I am working on a bug report to add a new requirement to the next revision of the standards to make it easier to find a version of getconf that will give you a way to get the proper settings to set up an environment for any standard supported by that implementation (even if there are multiple versions of getconf on the system), but it hasn't been submitted yet.)

Issue History

Date Modified Username Field Change
2013-10-19 22:02 steffen New Issue
2013-10-19 22:02 steffen Name => Steffen Nurpmeso
2013-10-19 22:02 steffen Section => Vol 3: 2.5.3, 4.sh(1)
2013-10-19 22:02 steffen Page Number => 2326, 3192
2013-10-19 22:02 steffen Line Number => 73826, 106854
2013-10-21 21:27 ranjit Note Added: 0001940
2013-12-14 00:58 Don Cragun Note Added: 0002073
2013-12-14 00:59 Don Cragun Interp Status => ---
2013-12-14 00:59 Don Cragun Final Accepted Text => See 0000774:0002073.
2013-12-14 00:59 Don Cragun Status New => Closed
2013-12-14 00:59 Don Cragun Resolution Open => Rejected
2013-12-14 01:10 Don Cragun Note Edited: 0002073
2013-12-14 01:11 Don Cragun Note Edited: 0002073
2013-12-14 01:12 Don Cragun Note Edited: 0002073