Enclosed are the minutes from last weeks call

Minutes of the 29th November 2018 Teleconference     Austin-895 Page 1 of 1
Submitted by Andrew Josey, The Open Group. 4th December 2018

    Nick Stoughton, USENIX, ISO/IEC JTC 1/SC 22 OR
    Joerg Schilling, FOKUS Fraunhofer
    Eric Blake, Red Hat
    Don Cragun, IEEE PASC OR
    Geoff Clare, The Open Group
    Andrew Josey, The Open Group
    Mike Crowe, (BrightSign)
    Martin Rehak, Oracle, The Open Group OR
    Mark Ziegast, SHware Systems (Etherpad only)

* General news 


* Outstanding actions

(Please note that this section has been flushed to shorten the minutes -
to locate the previous set of outstanding actions, look to the minutes
from 9 March 2018 and earlier)

Bug 1077: Recommend support for wide-character regcomp and regexec and/or 
specify multi-byte behavior OPEN

Andrew has completed the action to ping his Apple contact and is
awaiting a reply.

Bug 1122: POSIX should include gettext() and friends  OPEN
Left open as an action is still in progress to flesh out a complete proposal.

* Current Business

Bug 1134: Add getentropy interface         OPEN

Action: Andrew to add boilerplate response regarding a proposal for
new interface, and also to ask The Open Group OR if they would
sponsor this addition.
Both Actions now Completed.
(update 19 Oct 2018)
There has been no reaction from the Base Working Group and the period for 
comments has ended now.

Bug 1138: Add strsignal(), sig2str() and str2sig() to the standard. OPEN

Martin has completed his action.  Andrew took an action to chase
the Base Working group members for sponsorship of the two interfaces.
Update: The action on Andrew is still open.

Bug 1216: Adding clockid parameter to functions that accept absolute struct 
timespec timeouts OPEN 

There is strong sentiment in favor of this proposal, but it needs
more work fleshing out the editing instructions and details. This
may help get the proposed interfaces into glibc, therefore providing
a reference implementation. Once that happens, it should be easier
to find a sponsor.

Things to consider, based on points made during the discussion:

     Look at how openat() is defined in terms of open() and copy
     that style in writing a new page for each new function. In
     particular, be sure to include things like ERRORS where you
     call out all of the same errors as the older function, plus
     the additional errors of EINVAL for unknown clock, ENOTSUP for
     clock that can't be used, ...  APPLICATION_USAGE should mention
     that some clocks (like CLOCK_CPUTIME) may not be suitable
     (precisely because the clock doesn't increment while the
     interface is blocked) Also, directions to the editor on page/line
     numbers against the pdf for where to insert other references
     (such as the new signature for pthread_cond_clockwait() in
     <pthread.h>, in addition to the new page for the documentation
     of pthread_cond_clockwait() itself) If some functions in the
     set are difficult to implement, it's okay to document the
     signature in FUTURE DIRECTIONS, while focusing on condvar as
     the main one to standardize now Pointing to the glibc mailing
     list threads with patch proposals matching the POSIX wording
     proposal will help show that there is existing practice (even
     if glibc hasn't incorporated the patches yet, the fact that
     the patches are in the public will count towards an existing
     practice claim) - the URLs do not have to be part of the
     proposed normative text additions, but having the cross-link
     trail in the bug page will help

Bug 1145: compound-list does not required a terminating semicolon even in 
compound commands, which is contradictory with implementations.

Closed, Rejected:
The command:

until a do b; done

is not accepted by the grammar because in the grammar do_group
requires a "do" keyword to be present, and this command does not
have one. (The word "do" in this command is an ordinary word to be
passed as an argument to "a"; it is not recognised as a keyword.)

This appears to be the same misinterpretation of the shell grammar
rules as was made in 0001046.

Update: this bug was discussed in the Nov 29, 2018 teleconference
and is being rejected for the reason given above.

Bug 1146: "total" line in ls -l output Accepted as marked.

An interpretation required. This is tagged with the TC3-2008 tag

Interpretation response:

The standard states that ls lists the space requirements for all
files in a directory, and conforming implementations must conform
to this. However, concerns have been raised about this which are
being referred to the sponsor.

This is not (and never has been) existing practice.

Notes to the Editor (not part of this interpretation):

On page 2928 line 96855 section ls, change:
    ... each list of files within the directory shall be preceded
    by a status line indicating the number of file system blocks
    occupied by files in the directory ...
    ... each list of files within a directory shall be preceded by
    a status line indicating the number of file system blocks
    occupied by the listed files for that directory ...

Add to Application Usage on p2930 after line 96908:
    The <tt>total</tt> number provided when using ls -l does not
    necessarily correspond to the space that would be reclaimed if
    all the listed files were removed, because of hard links (and
    symbolic links if -L is present). The space for each listed
    file is counted in the total regardless of any relationship
    between the files.

Bug 1147: ls -l -F/-p and symlinks OPEN

Discussion started on this item and will continue on the next call.

Next Steps 

The next call is on December 6th 2018 (Thursday).

Calls are anchored on US time. (8am Pacific) 
This call will be for the regular 90 minutes.

An etherpad is usually up for the meeting, with a URL using the date format as 
username=posix password=2115756#

Andrew Josey                    The Open Group
Austin Group Chair          
Apex Plaza, Forbury Road,Reading,Berks.RG1 1AX,England
Tel:+44 118 9023044

To learn how we maintain your privacy, please review The Open Group Privacy 
Statement at
To unsubscribe/opt-out from this mailing list login to The Open Group 
collaboration portal at

Reply via email to