From ajosey@rdg.opengroup.org Thu Apr 17 10:10:52 1997 Received: from mailgate.rdg.opengroup.org (mailgate.rdg.opengroup.org [192.153.166.4]) by dkuug.dk (8.6.12/8.6.12) with SMTP id KAA26119 for ; Thu, 17 Apr 1997 10:10:46 +0200 Received: by mailgate.rdg.opengroup.org; id AA04991; Thu, 17 Apr 1997 09:10:57 GMT Message-Id: <9704170910.AA04991@mailgate.rdg.opengroup.org> Received: by mailhome.rdg.opengroup.org (1.36.108.10/16.2) id AA01767; Thu, 17 Apr 1997 09:07:51 +0100 From: ajosey@rdg.opengroup.org (Andrew Josey) Date: Thu, 17 Apr 1997 09:07:50 +0100 In-Reply-To: Andrew Josey's message as of Apr 17, 9:04am. Reply-To: ajosey@rdg.opengroup.org (Andrew Josey) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: sc22wg15@dkuug.dk Subject: 1003.2-1992 Finalised PASC Interps Attached are the finalised PASC 1003.2-1992 interpretations since October 1996. These are being circulated in accordance with Action 9610-60 . regards Andrew ----- Andrew Josey PASC Functional Chair Interpretations The Open Group Apex Plaza,Forbury Road, Reading,Berks.RG1 1AX,England Tel: +44 118 9508311 ext 2250 Fax: +44 118 9500110 Email: a.josey@opengroup.org #--------------------------------CUT HERE------------------------------------- #! /bin/sh # # This is a shell archive. Save this into a file, edit it # and delete all lines above this comment. Then give this # file to sh by executing the command "sh file". The files # will be extracted into the current directory owned by # you with default permissions. # # The files contained herein are: # # -rw-r--r-- 1 ajosey other 6146 Jan 3 11:52 pasc-1003.2-148.html # -rw-r--r-- 1 ajosey other 4239 Jan 3 11:52 pasc-1003.2-149.html # -rw-r--r-- 1 ajosey other 3441 Jan 3 11:52 pasc-1003.2-143.html # echo 'x - pasc-1003.2-148.html' if test -f pasc-1003.2-148.html; then echo 'shar: not overwriting pasc-1003.2-148.html'; else sed 's/^X//' << '________This_Is_The_END________' > pasc-1003.2-148.html X X X[Ref: pasc-1003.2-148] Topic: ar command X X X

XPASC Interpretation Ref: pasc-1003.2-148
Topic: ar command X

X

X

XThis is an unapproved interpretation of PASC P1003.2-1992. X

XUse of the information contained in this unapproved document is at your Xown risk. X

XLast update: 03 January,1997 X

X
X								1003.2-92  #148
X
X _____________________________________________________________________________
X
X
X	Interpretation Number:	148
X	Topic:			ar command
X	Relevant Sections:	6.1.6.1
X	Classification:		Ambiguous
X
XInterpretation Request:
X-----------------------
X
X	From fredz@pacific-89 
X	Fri Jul 12 13:23 PDT 1996
X
XDear Interpretations Committee,
X
XI would like to request an official binding interpretation of IEEE
XStd 1003.2-1992 (POSIX.2).  This request deals with the format
Xof the standard output of the "ar" utility.  This format is specified
Xin POSIX.2 subclause 6.1.6.1, and the item for which I request an
Xinterpretation is on lines 127-146. These lines read:
X
X    If the -t option is used with the -v option, the standard output
X    format shall be
X
X	"%s %u/%u %u %s %d %d:%d:%d %d %s\n", <member mode>,
X	<user ID>, <group ID>, <number of bytes in member>,
X	<abbreviated month>, <day-of-month>, <hour>, <minute>,
X	<year>, <file>
X
X    where
X
X	file		shall be the operand specified on the
X			command line, if file operands were specified,
X			or the name of the file in the archive if they
X			were not.
X
X	<member mode>	shall be formatted the same as the <file mode>
X			string defined in 4.39.6.1, except that the
X			first character, the <entry type>, is not used;
X			the string represents the file mode of the archive
X			member at the time it was added to, or replaced in,
X			the archive.
X
X    The following represent the last-modification time of a file when it
X    was most recently added to or replaced in the archive:
X
X	<abbreviated month>	Equivalent to the %b format in date
X				(see 4.15).
X
X	<day-of-month>		Equivalent to the %e format in date.
X
X	<hour>			Equivalent to the %H format in date.
X
X	<minute>		Equivalent to the %M format in date.
X
X	<year>			Equivalent to the %Y format in date.
X
XMy question is: in the day-of-month, hour, minute and year fields,
Xunder what conditions (if any) is a value in the range 0-9 printed with
Xa leading zero?
X
XMy reading of this description is that the different numeric fields in
Xthe archive member's modification time are (logically, at least)
Xformatted in a two-step process: first strings are created using
Xformats from the date utility, and then the output is formed from these
Xstrings using the standard output formatting conventions of POSIX.2 as
Xspecified in subclause 2.12 (File Format Notation).  The %d format from
Xsubclause 2.12 is used for all four fields in question.  With no precision
Xspecifier, a default of 1 is assumed (2.12 lines 4104-4105), and thus no
Xleading zeroes should be printed for values > 0.  Under this reading,
Xa modification time of June 4 at 3:05:13 am would be printed as
X
X	Jun 4  3:5:13
X
XThis does not agree with any of the historical formats, which would
Xgive either
X
X	Jun 04 03:05:13
X
Xor
X
X	Jun  4 03:05:13
X
XThe use of the %e, %H, %M and %Y formats leads me to suspect that the
Xintent of the standard was for the use of the latter format (with possibly
Xdifferent white space).  However, I do not believe that this is what the
Xstandard actually calls for.  Could you please clarify the normative
Xrequirements imposed on the ar utility by this portion of the standard.
X
XThank you for your attention to this matter.
X
XFred Zlotnick
Xfred.zlotnick@eng.sun.com
X
XIEEE Interpretation for 1003.2-1992 
X-----------------------------------
X
XThe standard is ambiguous on this issue and no conformance
Xdistinction can be made between alternative implementations
Xbased on this.  This is being referred to the sponsor.
X           
X
XRationale for Interpretation:
X-----------------------------
XNone.
X
X
X
XEditorial note for future revision of standard (not part of this interpretation)
X-------------------------------------------------------------------------------
XA proposed change to the section 6.1.6.1 ar Command is as follows:
X
XPage 664, line 128:
XFrom:
X	"%s %u/%u %u %s %d %d:%d %d %s\n", <member mode>,
XTo:
X	"%s %u/%u %u %s %s\n", <member mode>,
X
XPage 664, line 130:
XFrom:
X	<abbreviated month>, <day-of-month>, <hour>, <minute>, <year>,
X	<file>
XTo:
X	<date and time>, <file>
X
XPage 664, lines 140-149:
XFrom:
X	The following represent the last-modification time of a file when
X	it was most recently added to or replaced in the archive:
X
X	<abbreviated month>	Equivalent to the %b format in date (see 4.15).
X	<day-of-month>		Equivalent to the %e format in date.
X	<hour>			Equivalent to the %H format in date.
X	<minute>		Equivalent to the %M format in date.
X	<year>			Equivalent to the %Y format in date.
X
X	When LC_TIME does not specify the POSIX Locale, a different format
X	and order of presentation of these fields relative to each other
X	may be used in a format appropriate in the specified locale.
XTo:
X	The <date and time> field shall contain the last-modification date
X	and time of the file as of when it was most recently added to or
X	replaced in the archive.  In the POSIX Locale, the field shall be
X	the equivalent of the output of the following date command (see
X	4.15):
X
X		date "+%b %e %H:%M %Y"
X
X	However, the final <newline> produced by date shall not be included
X	and the output shall be as if the date command were executed at
X	the time of the last-modification date of the file as described
X	above rather than the current time.  When the LC_TIME locale
X	category is not set to the POSIX Locale, a different format and
X	order of presentation of this field may be used.
X	
XNOTE: There is no certainty that these comments will apply to any
Xrevision of IEEE Std 1003.2-1992.
X
XFinalised:  3rd Jan 1997
X
X ________This_Is_The_END________ if test `wc -l < pasc-1003.2-148.html` -ne 182; then echo 'shar: pasc-1003.2-148.html was damaged during transit (should have been 182 bytes)' fi fi ; : end of overwriting check echo 'x - pasc-1003.2-149.html' if test -f pasc-1003.2-149.html; then echo 'shar: not overwriting pasc-1003.2-149.html'; else sed 's/^X//' << '________This_Is_The_END________' > pasc-1003.2-149.html X X X[Ref: pasc-1003.2-149] Topic: sh and SIGTERM X X X

XPASC Interpretation Ref: pasc-1003.2-149
Topic: sh and SIGTERM X

X

X

XThis is an unapproved interpretation of PASC P1003.2-1992. X

XUse of the information contained in this unapproved document is at your Xown risk. X

XLast update: 03 January,1997 X

X
X								1003.2-92  #149
X
X _____________________________________________________________________________
X
X
X	Interpretation Number:	xxxx
X	Topic:			sh and SIGTERM
X	Relevant Sections:	6.1.6.1
X
XInterpretation Request:
X-----------------------
X
X	From: ajosey@xopen.org (Andrew Josey)
X	Date: Thu, 8 Aug 1996 15:25:34 +0100
X
XI wish to ask for an interpretation request of the Shell and
XUtilities standard, IEEE Std 1003.2-1992 (ISO/IEC 9945-2:1993)
Xrelated to signal handling by the shell. This issue
Xhas been raised due to a test for a POSIX.2 test assertion.
X
XTo operate correctly, historically the shell has ignored SIGTERM for
Xshells that are deemed an interactive shell.  
X
XAlthough POSIX.2 does not seem to discuss this issue, all shells we 
Xcould check (ksh88, Bourne shell, ksh93, csh) are documented to 
Xignore SIGTERM when they are interactive shells so that the 
Xcommand "kill 0" will not kill the login shell. We believe this
Xis valid for the POSIX shell as well.
X	
XTo allow the "kill 0" for process group to have the desired
Xfunctionality a newly invoked utility needs to reset the disposition of
XSIGTERM at startup and so introduces a race condition which is being hit
Xby this test case on systems which are fast (typically those with shells
Xthat implement many common utilities by builtins).
X
XThe test suite assumes that a shell is interactive  - based on the 
Xpage 414 of POSIX.2 lines 8852-8854:
X
X	"if the -i option is present, or if there are no operands and the
X	shell's standard input and standard error are attached to a terminal,
X	the shell is considered to be interactive"
X
XThe test does not allow for the possibility of a race condition.
XThis problem can usually be duplicated by issuing the following
Xcommands from an interactive shell:
X
X        sleep 20 & kill %1
X
XThe "kill %1" doesn't terminate the "sleep 20" if the kill is
Xperformed before the signal handlers are reset in the subshell
Xinvoking the sleep.  
X
XThis may not work 100% of the time, because of the race for the child to start
Xand reset the disposition of SIGTERM before kill sends the signal; 
Xshells with builtin kill commands should demonstrate this most easily.
X
XThe actual test does the following:
X
Xsleep 300 & bg 2>/dev/null >/dev/null; cat - ; kill %1 2>/dev/null >/dev/null;
X
XThe following points are the important issues
X
X1) all interactive shells need to handle/ignore SIGTERM.
X
X2) jobs started by these interactive shells must reset the
Xdisposition of SIGTERM at startup.
X
X3) there is a race condition where the jobs may receive SIGTERM
Xafter they are created but before they have had time to reset
XSIGTERM's disposition.
X
X4) VSC bg-17 test can hit that race condition, especially when the
Xshell is very fast with respect to "bg" and "cat", both of
Xwhich are builtins in our shell.
X	   
XDoes a conforming shell have to delay continued processing
Xin the parent shell until the signal handlers in the asynchronous
Xlist have been reset? 
X	   
X	
XInterpretation response
X------------------------
XThe standard clearly states the requirement sof execution
Xof asynchronous lists and conforming implementations
Xmust conform to this.
X
XThe description of asynchronous lists in section 3.9.3.1 says that
Xthe command terminated by the control operator & shall be executed
Xin a subshell. We believe that this means that the command runs
Xasynchronously with the parent shell, but not the creation of the
Xsubshell, therefore the standard requires the sleep to be killed
Xin the example given.
X
XIf the phrase in 3.9.3.1 had stated that a subshell was created
Xasynchronously to execute the command the behaviour suggested would
Xbe ok.
X
XRationale
X-------------
XNone.
X
XForwarded to Interpretations group: Aug 9 1996
XForward for 30 day review: 22 Oct 1996
XFinalised: 24 Nov 1996
X
X ________This_Is_The_END________ if test `wc -l < pasc-1003.2-149.html` -ne 124; then echo 'shar: pasc-1003.2-149.html was damaged during transit (should have been 124 bytes)' fi fi ; : end of overwriting check echo 'x - pasc-1003.2-143.html' if test -f pasc-1003.2-143.html; then echo 'shar: not overwriting pasc-1003.2-143.html'; else sed 's/^X//' << '________This_Is_The_END________' > pasc-1003.2-143.html X X X[Ref: pasc-1003.2-143] Topic: c89 X X X

XPASC Interpretation Ref: pasc-1003.2-143
Topic: c89 X

X

X

XThis is an unapproved interpretation of PASC P1003.2-1992. X

XUse of the information contained in this unapproved document is at your Xown risk. X

XLast update: 03 January,1997 X

X
X								1003.2-92  #143
X
X _____________________________________________________________________________
X
X
X	Interpretation Number:	xxxx
X	Topic:			c89
X	Relevant Sections:	2.9.1.4 and A.1.2
X
XInterpretation Request:
X-----------------------
X
X        From: Andre Bellotti <aab@unx.dec.com>
X	Date: Sun, 10 Dec 1995 11:30:00 - 0800
X
XDear Standards Board,
X
X    I would like to request a formal interpretation concerning 
Xthe following point in IEEE Std 1003.2-1992 (POSIX.2).
X
XContrary to historical practice, the Standard is ambiguous as to 
Xwhether or not the execute permissions will be set on the file 
Xcreated by the c89 compiler if a file of the same name already 
Xexists without execute permissions.
X
X
XIn section A.1.2, page 688, lines 27 through 31 it states:
X
X   "The executable file shall be created as specified in 2.9.1.4, 
X    except that the file permissions shall be set to
X
X	    S_IRWXO|S_IRWXG|S_IRWXU
X
X   (see 6.6.1.2 in POSIX.1 {8}) and that the bits specified by 
X    the umask of the process shall be cleared."
X
XThis would indicate that in all cases that the file should be 
Xcreated with the permissions as specified.  As this is obviously 
Xthe action desired from an executable file created by a compiler 
Xthis should be definitive.  However an ambiguity arises in the 
Xcase of an existing file that is being overwritten by the output 
Xof the compiler.  
X
XIn section 2.9.1.4, page 93, lines 3390 and 3391 the specification
Xstates that:
X
X     "When a file that does not exist is created, the following 
X      POSIX.1 {8} features shall apply unless the utility or 
X      function description states otherwise:"
X
XUnfortunately in the case of an existing file the modifying language
Xallowing the utility to override the section 2.9.1.4 does not exist;
Xpage 93, lines 3404 and 3405 read:
X
X     "When an attempt is made to create a file that already exists, 
X      the action shall depend on the file type:"
X
XWithout the modifying language the intent of the explicit permissions
Xin the c89 description becomes ambiguous to apply.
X
XAs it is obvious that the rules that were being referred to by the
Xreference to section 2.9.1.4 were those dealing with files other than
Xregular text files we would recommend that section 2.9.1.4, page 93,
Xline 3409 be changed to read
X
X" (2) For regular files, unless the utility or function description
X  states otherwise:"
X
XThis would eliminate any ambiguity of application of explicit
Xpermissions upon existing files that are being overwritten. 
X
X
XThank you for your attention to this matter.
X
XInterpretation response
X------------------------
X
XThe standard clearly states the behavior for setting permissions on a file's
Xcreation and conforming implementations must conform to this.  The exception
Xstated on Page 688 applies to both cases of a file existing and not existing.
XIt is not limited to either case.
X
X
XRationale
X-------------
XNone.
XForwarded to Interpretations group: Dec 28 1995
XCommence 30 day review: Mar 8 1996
XFinalised: Oct 28 1996
X
X
X
X ________This_Is_The_END________ if test `wc -l < pasc-1003.2-143.html` -ne 111; then echo 'shar: pasc-1003.2-143.html was damaged during transit (should have been 111 bytes)' fi fi ; : end of overwriting check exit 0