Re: compound-list

Date:Tue, 13 Jun 2017 00:02:34 +0200 From:Jilles Tjoelker Message-ID: <20170612220234.ga26...@stack.nl> | I think this is supposed to be handled by rule 1 in the first (non-yacc) | part of 2.10.2 Shell Grammar Rules, but the text is not clear to

Re: Differences between versions of the standard

On Mon, 12 Jun 2017, shwares...@aol.com wrote: > This would be the XRAT volume, and Change History in individual entries... > This is only exhaustive in coverage from when the POSIX Group was formed, > it appears, not for earlier IEEE and OpenGroup versions. There is a table XPG5, PDF

Re: compound-list

2017-06-12 20:05:49 +, Yann Régis-Gianas: > Dear members of the Opengroup, > > the shell grammar is defining the non terminal for compound_list as follows: > > compound_list : linebreak term | linebreak term separator ; > > and this non terminal is used in compound_commands like

Re: Differences between versions of the standard

This would be the XRAT volume, and Change History in individual entries... This is only exhaustive in coverage from when the POSIX Group was formed, it appears, not for earlier IEEE and OpenGroup versions. There is a table of when various interfaces became part of the standard that A.Josey

Differences between versions of the standard

Dear members of the opengroup, is there a document, some kind of ChangeLog, that would summarize the differences between the issues of the specification? Best regards, -- Yann Régis-Gianas

Re: Quoting the POSIX specification

Le ven. 9 juin 2017 à 18:07, Wheeler, David A a écrit : > I believe copyright laws typically allow quotations, since otherwise it'd > be impossible to have any kind of scientific work. Under US law, this is > part of "fair use". > > I'm not as familiar with French law, but I

Re: Quoting the POSIX specification

Le ven. 9 juin 2017 à 16:32, Joerg Schilling < joerg.schill...@fokus.fraunhofer.de> a écrit : > Yann Régis-Gianas wrote: > If you plan to use the BNF grammar for the shell that is in the standard, > then it may be of interest that this is most likely not correct.

Re: readdir and d_ino of mount points (Was: rm -rf ./ ../)

2017-06-12 09:58:30 +0100, Geoff Clare: [...] > > - In the second case (the one in FreeBSD, Linux and Solaris at > > least), that's the inode number of a file we > > cannot access by that path (and again, applications using > > d_inos to detect hard links could be fooled). [...] > You say

[1003.1(2016)/Issue7+TC2 0001142]: pread(2) and pwrite(2) should be async-signal-safe

A NOTE has been added to this issue. == http://austingroupbugs.net/view.php?id=1142 == Reported By:dancol Assigned To:

Re: request for clarification on Open Group Base Specifications Issue 7: Canc...

Hi Alexander, thanks for your response. On 06/12/17 09:39, Alexander Terekhov wrote: > Hi, > > > but return ETIMEDOUT and leave the cancellation state pending. > > so that you can call pthread_testcancel() upon ETIMEDOUT return (if > cancel > is more important too you than a timeout). Yes, I

Re: request for clarification on Open Group Base Specifications Issue 7: Canc...

Hi, > but return ETIMEDOUT and leave the cancellation state pending. so that you can call pthread_testcancel() upon ETIMEDOUT return (if cancel is more important too you than a timeout). I don't see what is wrong here. regards, alexander. From: Dimitri Staessens

Re: readdir and d_ino of mount points (Was: rm -rf ./ ../)

Stephane Chazelas wrote, on 09 Jun 2017: > > 2017-06-09 15:46:56 +0100, Stephane Chazelas: > [...] > > In addition to leaving it unspecified whether a "." or ".." > > entry is returned, we may also want to clarify (or leave > > unspecified) what d_ino the ".." entry