Harald van Dijk wrote, on 01 Jul 2019:
>
> On 01/07/2019 10:36, Geoff Clare wrote:
> >Harald van Dijk wrote, on 30 Jun 2019:
> >>
> >>POSIX does not even limit the concept of "syntax errors" to errors in the
> >>syntax, see e.g. the "shift
e the current text says, it
> says it *is* quoted.
That's extremely picky, but I take your point. Here's an alternative that
I think fixes the problem:
[...] If any character (ordinary, shell
special, or pattern special) is quoted or (where shell quoting is not
Stephane Chazelas wrote, on 03 Jul 2019:
>
> 2019-07-03 09:24:10 +0100, Geoff Clare:
> [...]
> > [...] If any character (ordinary, shell
> >special, or pattern special) is quoted or (where shell quoting is not
> >in effect) escaped
Joerg Schilling wrote, on 03 Jul 2019:
>
> Geoff Clare wrote:
>
> > Stephane Chazelas wrote, on 03 Jul 2019:
> > > And again, that's an incompatible change for dash, ksh88, ksh93,
> > > pdksh, mksh, bosh, yash where:
> > >
> > > a=
Joerg Schilling wrote, on 03 Jul 2019:
>
> Geoff Clare wrote:
>
> > Joerg Schilling wrote, on 03 Jul 2019:
>
> > > Do you like to say that pax behaves inconsistent to ls?
> >
> > The inconsistentcy has nothing to do with ls. It's with how those
Stephane Chazelas wrote, on 03 Jul 2019:
>
> 2019-07-03 11:08:57 +0100, Geoff Clare:
> [...]
> > > And again, that's an incompatible change for dash, ksh88, ksh93,
> > > pdksh, mksh, bosh, yash where:
> > >
> > > a='\*'
Joerg Schilling wrote, on 03 Jul 2019:
>
> Geoff Clare wrote:
>
> > Joerg Schilling wrote, on 03 Jul 2019:
> > > pax is not a shell and ls does not include own pattern matching.
> > >
> > > You thus cannot compare the behavior of these programs wit
Harald van Dijk wrote, on 03 Jul 2019:
>
> On 03/07/2019 11:08, Geoff Clare wrote:
> >Stephane Chazelas wrote, on 03 Jul 2019:
> >>
> >>2019-07-03 09:24:10 +0100, Geoff Clare:
> >>[...]
> >>> [...] If any char
ern is not
affected by shell quoting, only a preceding backslash can be used.
although it might be helpful to the reader to include the "(such as ...)"
by way of illustration.
--
Geoff Clare
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
#x27;*'
> ls -ld "$a"
>
> This does work for listing only a file literally named '*'.
That's because of the double quotes around $a. Pathname expansion
is not done inside double quotes, so there is no pattern here, just
a string that contains a '*'.
--
Geoff Clare
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
[Starting a new thread for this so it doesn't get lost in the bug 1234 one]
Geoff Clare wrote, on 04 Jul 2019:
>
> Subject: Re: [1003.1(2016)/Issue7+TC2 0001234]: in most shells, backslash
> doesn't have two meaning wrt pattern matching
>
> Harald van Di
Stephane Chazelas wrote, on 04 Jul 2019:
>
> 2019-07-04 09:26:50 +0100, Geoff Clare:
> [...]
> > > > a='*'
> > > > ls -ld "$a"
> > > >
> > > > This does work for listing only a file literally named '*'.
&
bitrary data...))
I think these are ones that you previously touched upon (where you said
that in the past I had responded that examples can assume IFS has the
default value). If you think it is worth the bother of updating them,
then by all means submit a bug with the necessary detailed wording changes.
I don't object to changing them, I just don't think it is worth the
effort of working out the wording changes and submitting a bug.
--
Geoff Clare
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
Geoff Clare wrote, on 04 Jul 2019:
>
> I started thinking it would be better to handle this in 2.13.1, but
> then realised it would be difficult to specify there given that 2.6.2
> says "Enclosing the full parameter expansion string in double-quotes
> shall not cause the foll
Geoff Clare wrote, on 04 Jul 2019:
>
> Harald van Dijk wrote, on 03 Jul 2019:
> >
> > >No, it's a context where shell-quoting backslash *doesn't* work. Therefore
> > >the backslash should act as an escape character just like in find, pax,
> > >fn
C_NUMERIC_MASK, argv[2], (locale_t)0);
if (locale == (locale_t)0)
{
fprintf(stderr, "newlocale(LC_NUMERIC_MASK, \"%s\", 0)
failed\n",
argv[2]);
return 1;
}
printf("Month 1 is %s\n", nl_langinfo_l(MON_1, locale));
}
--
Geoff Clare
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
the sleep).
I think in both of these cases the shell ought to notice what is happening
(by catching SIGTSTP in the first case, and seeing via SIGCHLD that sleep
was stopped with SIGTSTP in the second case) and mimic the "normal"
job control behaviour. However, I'm not sure if we should require this
or should just treat it as a quality-of-implementation issue.
--
Geoff Clare
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
Geoff Clare wrote, on 17 Jul 2019:
>
> On page 65 line 1924 section 3.202 Job, change:
>
> A set of processes, comprising a shell pipeline, and any processes
> descended from it, that are all in the same process group.
>
> Note: See also [xref to XCU 2.9.
rrent directory is not readable.
The shell should ignore EACCES errors from opendir() (and probably
ELOOP, ENAMETOOLONG, ENOENT and ENOTDIR, none of which apply for "*.c")
but if opendir() fails with EMFILE or ENFILE the shell should report
an error.
--
Geoff Clare
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
Stephane Chazelas wrote, on 23 Jul 2019:
>
> 2019-07-23 09:55:52 +0100, Geoff Clare:
> [...]
> > > Why GLOB_ERR? The shell does silently ignore directory open and
> > > read errors when expanding globs. In
> > >
> > >ls -ld -- *.c
> > &g
Stephane Chazelas wrote, on 23 Jul 2019:
>
> 2019-07-23 12:29:29 +0100, Geoff Clare:
> [...]
> >
> > If any shell does not report an error when opendir() returns EMFILE
> > or ENFILE then that's definitely a bug in that shell. Silently
> > executing a comm
Stephane Chazelas wrote, on 23 Jul 2019:
>
> 2019-07-23 14:12:22 +0200, Joerg Schilling:
> > Geoff Clare wrote:
> >
> > > If any shell does not report an error when opendir() returns EMFILE
> > > or ENFILE then that's definitely a bug in that shell. Si
H_MAX-related ENAMETOOLONG not
to NAME_MAX.
--
Geoff Clare
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
Stephane Chazelas wrote, on 23 Jul 2019:
>
> 2019-07-23 16:54:28 +0100, Geoff Clare:
> [...]
> > Good idea. The rationale could then say which of the standard error
> > numbers are in each category.
> >
> > Something like:
> >
> > If these per
Joerg Schilling wrote, on 24 Jul 2019:
>
> Geoff Clare wrote:
>
> > Some standard utilities are already required to handle pathnames
> > longer than PATH_MAX.
>
> Mmm, I did not see related text, could you give an example please?
"The find utility shall be abl
Stephane Chazelas wrote, on 24 Jul 2019:
>
> 2019-07-24 09:39:27 +0100, Geoff Clare:
> [...]
> > > But with EACCES or ENAMETOOLONG, one can't infer that "reading
> > > the directory would not produce any" match.
> >
> > EACCES does not nee
non-zero
value if the eerrno parameter indicates an error condition that is
not related to file system contents. See [xref to C.2.13.3] for
information about which error conditions are related to file
system contents.
--
Geoff Clare
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
Stephane Chazelas wrote, on 25 Jul 2019:
>
> 2019-07-25 10:57:35 +0100, Geoff Clare:
> [...]
> > Here's a revised version of my proposal that uses your idea of
> > distinguishing no-error conditions from error ones by whether they are
> > related to file system con
n error, and shall continue to
| look for matches.
plus similar fixes further down the page.
--
Geoff Clare
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
Stephane Chazelas wrote, on 29 Jul 2019:
>
> 2019-07-29 10:45:35 +0100, Geoff Clare:
> [...]
> > I noticed the same problem when I was working on the wording changes
> > to glob() as part of the pathname expansion fixes that arose from
> > bug 1255, which is why the pro
Stephane Chazelas wrote, on 29 Jul 2019:
>
> 2019-07-29 11:43:11 +0100, Geoff Clare:
> [...]
> > > But here I'm saying that the ENOENT/ENOTDIR errors should be
> > > ignored with GLOB_ERR. It can already be implied to some extent
> > > in that if you ge
These are the draft minutes from today's call. Andrew will need
to allocate the Austin-xxx document number and add the file to the
document register after he returns.
Regards,
Geoff.
---
Minutes of the 29th July 2019 Teleconference Austin-xxx Page 1 of 1
Submitted by Geoff Clare
Stephane Chazelas wrote, on 29 Jul 2019:
>
> 2019-07-29 12:12:28 +0100, Geoff Clare:
> [...]
> > > in */*.c, Solaris returns with an error if the current directory
> > > contains a non-directory file (and calls errfunc() with ENOTDIR
> > > and that file), whi
Stephane Chazelas wrote, on 30 Jul 2019:
>
> 2019-07-30 10:48:49 +0100, Geoff Clare:
> [...]
> > The odd thing about all these implementations that ignore ENOTDIR and ENOENT
> > (or don't but think they should), is that they are not following either of
> > the
Stephane Chazelas wrote, on 30 Jul 2019:
>
> 2019-07-30 11:27:15 +0100, Geoff Clare:
> [...]
> > > For ENOENT, that can be seen as a pathological case worth
> > > reporting as well, especially in the */*.c case where the
> > > current directory conta
command might succeed (operating on the wrong file) and the user
would not be alerted to the problem. Particularly bad if it was an
rm command.
--
Geoff Clare
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
cept from the occasional
> accidental 'cat foo* > bar*' type error, and when they have done that
> the problem tends to be more "how do I get rid of just that file" rather
> that "why did that file get deleted".
>
> The (much less likely, except for users attempting to shoot themselves
> in the foot, deliberately) EMFILE and ENFILE cases are not different at
> all.
However, they are easily preventable, so why not do that?
--
Geoff Clare
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
e of the few parts of the shell where
> execution time really matters so I can check for them. Really?
Slow down? You jest. The shell is making a system call to open a
directory. The time taken to check the errno value is negligible in
comparison to that.
--
Geoff Clare
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
Stephane Chazelas wrote, on 30 Jul 2019:
>
> 2019-07-30 15:31:13 +0100, Geoff Clare:
> [...]
> > It's not invention because the standard already requires it. (It also
> > requires EACCES, ELOOP, ENAMETOOLONG, ENOENT, ENOTDIR to be treated as
> > errors. The que
s up to you. But you should let other shell authors come to
their own decision about the matter, not try to force them to do it
your way by pushing for the standard to require EMFILE to be ignored.
--
Geoff Clare
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
part probably needs further
discussion.
--
Geoff Clare
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
OB_NOCHECK: "... shall return a list consisting of only pattern".
No allowance for a slash to be appended.
GLOB_MARK: "Each pathname that is a directory that matches pattern ..."
If pattern does not match anything, then it is not "a directory that
matches pattern" even
These are the draft minutes from yesterday's call. Andrew will need
to allocate the Austin-xxx document number and add the file to the
document register after he returns.
Regards,
Geoff.
---
Minutes of the 1st August 2019 Teleconference Austin-xxx Page 1 of 1
Submitted by Geoff
These are the draft minutes from yesterday's call. Andrew will need
to allocate the Austin-xxx document number and add the file to the
document register after he returns.
Regards,
Geoff.
---
Minutes of the 5th August 2019 Teleconference Austin-xxx Page 1 of 1
Submitted by Geoff
Geoff Clare wrote, on 17 Jul 2019:
>
> For foreground jobs, shells differ:
>
> Ksh93 has it as an AND-OR list:
>
> $ sleep 3 && sleep 4
> ^Z[1] + Stopped sleep 3 && sleep 4
> $ jobs
> [1] + Stopped sleep 3 &a
ore you type "sh",
or better still arrange for sh to replace bosh as your login shell
before you try the test:
bosh$ exec bash
bash$ exec -a -sh sh
sh$ ...
This is what I did to test ksh93 and bash.
--
Geoff Clare
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
child process, so at that point you have
"divorced" the command from your current shell environment and can
no longer expect assignments etc. to take place in the current shell
environment even if you subsequently bring it back to the foreground.
--
Geoff Clare
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
nd.
It will probably be simpler and easier to fix both problems in one
go by changing to treat the whole AND-OR list as a job. It would
also improve consistency with background jobs where (AFAIK) all
shells treat the whole AND-OR list as one job.
--
Geoff Clare
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
Stephane Chazelas wrote, on 08 Aug 2019:
>
> 2019-08-08 10:21:14 +0100, Geoff Clare:
> [...]
> > A bigger issue with bg, in shells that treat each pipeline in a
> > foreground AND-OR list as a separate job, is that if one of those jobs
> > is stopped and then pla
Stephane Chazelas wrote, on 08 Aug 2019:
>
> 2019-08-08 11:43:53 +0100, Geoff Clare:
> [...]
> > I tested a complex (although not as complex as yours) AND-OR list in
> > ksh93 and it treated the whole thing as one job:
> >
> > $ { sleep 3 | sleep 4; sleep 1 |
Stephane Chazelas wrote, on 08 Aug 2019:
>
> 2019-08-08 15:39:18 +0100, Geoff Clare:
> []
> > I have repeated it with /bin/sleep instead of sleep. It still treated the
> > whole AND-OR list as one job:
> >
> > $ { /bin/sleep 3 | /bin/sleep 4; /bin/sleep 1
These are the draft minutes from yesterday's call. Andrew will need
to allocate the Austin-xxx document number and add the file to the
document register after he returns.
Regards,
Geoff.
---
Minutes of the 8th August 2019 Teleconference Austin-xxx Page 1 of 1
Submitted by Geoff
t a complete
AND-OR list (however complex) run in the foreground can be stopped and
continued, and will then run to completion properly, we may have to
resort to saying that the behaviour when a foreground job is stopped is
unspecified except in the case that the job consists of a single
pipeline in which each component is a simple command.
--
Geoff Clare
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
p://austingroupbugs.net/bug_report_page.php
choose 1003.1(2016)/Issue7+TC2 as the project and fill in the form.
Might be best to submit three separate bugs, one for each header.
--
Geoff Clare
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
the reserved word ! and command1 is a
subshell command, the application shall ensure that the ( operator at
the beginning of command1 is separated from the ! by one or more
characters. The behavior of the reserved word ! immediately
followed by the ( operator is unspecified.
--
Geoff Clare
The Open
sure that something that is a single token occuring
where a simple command can begin, and which is not an operator or a
reserved word, can't change the expected syntax of what follows.
So how about:
If a returned ASSIGNMENT_WORD token begins with a valid name,
assignment of the value after the
Stephane Chazelas wrote, on 22 Aug 2019:
>
> 2019-08-22 09:50:56 +0100, Geoff Clare:
> [...]
> > So how about:
> >
> > If a returned ASSIGNMENT_WORD token begins with a valid name,
> > assignment of the value after the first to the name
> > sha
These are the draft minutes from yesterday's call. Andrew will need
to allocate the Austin-xxx document number and add the file to the
document register after he returns.
Regards,
Geoff.
---
Minutes of the 22nd August 2019 Teleconference Austin-xxx Page 1 of 1
Submitted by Geoff
Sorry, I forgot to update the subject line on this email to say 22nd.
Regards,
Geoff.
Geoff Clare wrote, on 23 Aug 2019:
>
> Subject: Draft minutes of the 8th August 2019 Teleconference
>
> These are the draft minutes from yesterday's call. Andrew will need
> to all
ssue7
> 2018ed.
>
> An error occurred while getting the requested content. Please contact the
> store owner.
>
> How should I contact the store owner?
--
Geoff Clare
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
his looks to be
a problem introduced by the HTML translation.
--
Geoff Clare
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
rst case, where bash 4 and earlier do what's specified in the
bug 1234 resolution but in bash 5, printf "%s\n" $var outputs *
when a * file exists?
> Also applies to glob().
Looks like we should modify the description of GLOB_NOCHECK. It refers
to rule 3 in XCU 2.13.3 but then goes on to describe the behaviour in
a way that doesn't (fully) match that rule any more.
--
Geoff Clare
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
ve as per the bug 1234 resolution (if/when it becomes an
approved interpretation).
> In zsh, backslash is given this special treatment only if the next character
> is special, so an indirect [a]\? matches a?, but an indirect [a]\b does not
> match ab.
That seems highly inconsistent w
Harald van Dijk wrote, on 24 Sep 2019:
>
> On 24/09/2019 12:24, Geoff Clare wrote:
> >Harald van Dijk wrote, on 24 Sep 2019:
> >>
> >>>2. Existing practice in most shells that do treat backslash as special in
> >>>"indirect" patterns in pat
nent. Each component that contains a that will
be treated as special may require read permission in the
directory containing that component. Any component, except the
last, that does not contain any '*', '?', or '[' characters that
will be treated as special shall require search permission.
--
Geoff Clare
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
scapes the shell-quoting backslash.
Here's suggestion for how to fix that in the 1st bullet in 2.13.1:
A character that is not inside a bracket expression
shall preserve the literal value of the following character, unless
the following character is in a part of the pattern where shell
quoting can be used and is a shell quoting character, in which case
the behavior is unspecified.
It says the behaviour is unspecified because it seems to cause bash4
not to match anything:
$ var='a\'
$ ls
a*b a\*b
$ printf '%s\n' $var\*b*
a\*b*
(It left the pattern unchanged - the shell-quoting backslash was then
removed by quote removal.)
--
Geoff Clare
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
Harald van Dijk wrote, on 25 Sep 2019:
>
> On 25/09/2019 10:22, Geoff Clare wrote:
> >Harald van Dijk wrote, on 24 Sep 2019:
> >>
> >>>>Regardless, a single shell is not enough to say "most shells", not even if
> >>>>it is multiple v
case x in [[."x."]]) echo x ;; esac # same
>
> I believe this is incorrect for the same reason as the quoting in character
> classes. The quoting of "x" should be okay, but the quoting of "=" or "."
> should disable the recognition as an equivalence class or collating symbol,
> so the meaning of the pattern [[="x="]] should change to "one of [=x=,
> followed by ]", just like how the pattern [["=x="]] is treated already. Does
> that sound right?
Again this could be just one aspect of the general bugginess of some shells
regarding shell quoting in bracket expressions in general.
--
Geoff Clare
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
uoted
> > character produces unspecified results. Otherwise, '[' shall
> >match the character itself.
>
> No such exception has been written for character classes and collating
> elements.
The reference to XBD RE Bracket Expression (9.3.5) applies to the whole
of 9.3
Geoff Clare wrote, on 26 Sep 2019:
>
> > Are shells required to support this, and are shells therefore implicitly
> > required to translate patterns to regular expressions, or should it be okay
> > to implement this with single character support only?
>
> Shells are re
h
> such things, rather than just "matches the next character" ?
My previous reply was based on XBD 9.3.5 item 4, but I have just spotted
that the intro paragraph of 9.3.5 uses the word "may":
A bracket expression ... is an RE that shall match a specific set
of single characters, and may match a specific set of
multi-character collating elements, ...
So it appears that it is optional whether matching a bracket expression
against more than one character is supported.
--
Geoff Clare
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
ven when the
> bracket expression is
> [[=ch=]]
>
> Who knows?
The word "may" has a strict usage. See XBD 1.5 - it "Describes a
feature or behavior that is optional for an implementation that
conforms to POSIX.1-2017."
However, there have been cases in the past where incorrect uses "may"
have been found and changed to "can".
In any case, the "shall" in XCU 2.13.1 overrides it.
--
Geoff Clare
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
n user
code, and it was rarely if ever implemented correctly. The current
standard leaves it unspecified whether a bracket expression
matches a multi-character collating element, allowing both
historical and ISO POSIX-2:1993 standard implementations to
conform.
This rationale would have been added at the same time the word "may" was
introduced in the normative text. So the "shall" in XCU 2.13.1 appears
to be something that was overlooked when this change was made.
--
Geoff Clare
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
These are the draft minutes from yesterday's call. Andrew will need
to allocate the Austin-xxx document number and add the file to the
document register after he returns.
Regards,
Geoff.
---
Minutes of the 26 September 2019 Teleconference Austin-xxx Page 1 of 1
Submitted by Geoff
and pdksh and posh.)
Because it's not the exception you thought it was? If the one stated
in 2.13.3 applied here, then it would apply to *[ as well as [*.
> Finally, just to clarify, with bs='\' and expanding [/$bs.] in a context
> where pathname expansion could be performed,
;
> >Because it's not the exception you thought it was? If the one stated
> >in 2.13.3 applied here, then it would apply to *[ as well as [*.
>
> It does apply to *[ as well as [* in most of those shells.
That's surprising.
> case a[ in *[) echo match ;; *) echo no match ;; esac
>
> This still prints "no match" in bosh, ksh and pdksh and posh, so the
> exception in 2.13.3 should still apply here if it is intended to match
> existing shell behaviour.
I think this should be raised as a separate bug. Since you are the
person who noticed it, do you want to be the one to submit the bug?
--
Geoff Clare
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
ith CMSG_SPACE) in Issue 8 via bug 978.
http://austingroupbugs.net/view.php?id=978#c3242
--
Geoff Clare
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
do that in
order to conform.
> BTW: the filesystem is not POSIX compliant by default (does not distinct
> character case). Is there a documented way to switch the filesystem into a
> POSIX compliant mode?
Yes there is.
--
Geoff Clare
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
c99 -D_XOPEN_SOURCE=600
(where c99 is the macOS front-end to clang).
Do you get the same result if you compile that way?
--
Geoff Clare
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
r or application to
escape a slash with a backslash, I see no reason why this shouldn't be
made unspecified.
I suggest adding the following to the bug 1234 resolution:
On page 2383 line 76261 section 2.13.3, append to item 1:
If a character is found following an unescaped
character
t;
> be shortened to
>
> case $dir in
> (/*|) CDPATH= cd -P "$dir";;
> (*) CDPATH= cd -P "./$dir";;
> esac
>
> ?
>
> Also, from a usability perspective, I think it would be better if `-' lost
> its special meaning after `--'. This would make the above code superfluous.
>
> Konrad Schwarz
--
Geoff Clare
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
Eric Blake wrote, on 23 Oct 2019:
>
> On 10/23/19 9:49 AM, Geoff Clare wrote:
> >
> >The status changing to APPLIED means that the edits have now been made
> >to the troff source of the standard.
> >
> >Although that doesn't mean they are set-in-stone, we
Harald van Dijk wrote, on 23 Oct 2019:
>
> On 22/10/2019 09:47, Geoff Clare wrote:
> >Good catch. Since there is no reason for a user or application to
> >escape a slash with a backslash, I see no reason why this shouldn't be
> >made unspecified.
> I wanted to a
Robert Elz wrote, on 27 Oct 2019:
>
> If it hasn't already happened in some other issue/bug report that
> I'm unaware of, could we do the same thing as was done for "nolog"
> to the absurd -h option?
See bug 1063.
--
Geoff Clare
The Open Group, Apex Plaza
These are the draft minutes from yesterday's call. Andrew will need
to allocate the Austin-xxx document number and add the file to the
document register after he returns.
Regards,
Geoff.
---
Minutes of the 4th November 2019 Teleconference Austin-xxx Page 1 of 1
Submitted by Geoff
These are the draft minutes from yesterday's call. Andrew will need
to allocate the Austin-xxx document number and add the file to the
document register after he returns.
Regards,
Geoff.
---
Minutes of the 7th November 2019 Teleconference Austin-xxx Page 1 of 1
Submitted by Geoff
pplications (since opening /dev/tty
can fail for other reasons than the process not having a controlling
terminal, such as EMFILE).
We should also consider requiring that ctermid() sets errno when it fails,
and specify an error number for the "no controlling terminal" case (as
a "shall fail" for option 1 or a "may fail" for option 2).
--
Geoff Clare
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
low that requirement, the
behaviour is undefined.
We certainly should not add an equivalent of mtx_timed to pthreads, as that
would break all existing applications that use pthread_mutex_timedlock().
The most we should do is add some rationale about the issue.
--
Geoff Clare
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
Don Cragun wrote, on 22 Nov 2019:
>
> Note that the 2018 edition of the standard is SUSv7;
> not SUSv4.
No, it is SUSv4. You are mixing up the Issue numbers and the
Version numbers.
See https://publications.opengroup.org/t101
--
Geoff Clare
The Open Group, Apex Plaza, Forbury Road
Danny Niu wrote, on 22 Nov 2019:
>
> I'm completely clueless about the issues before it,
> So please do teach me about those.
Issue 7 = SUSv4
Issue 6 = SUSv3
Issue 5 = SUSv2
Issue 4V2 = SUSv1
Issue 4 = XPG4
Issue 3 = XPG3
Issue 2 = XPG2
Issue 1 = XPG1
--
Geoff Clare
The Op
Joerg Schilling wrote, on 22 Nov 2019:
>
> Geoff Clare wrote:
>
> > Danny Niu wrote, on 22 Nov 2019:
> > >
> > > I'm completely clueless about the issues before it,
> > > So please do teach me about those.
> >
> > Issue 7 = SUSv4
&g
the HP-UX 11i bundled compiler shown on this page:
http://nixdoc.net/man-pages/HP-UX/man1/cc_bundled_pa.1.html
only mentions the use of -o to override the default a.out for the
linker output file.
--
Geoff Clare
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
us bug, and not worthy of any mention in the standard
> at all.
This behaviour of ksh was the reason I proposed the unspecified behaviour.
The bug, as I see it, is that the value of $? and the behaviour of exit
differ. I.e. I think the important thing here is that exit with no argument
should
Robert Elz wrote, on 22 Jan 2020:
>
> From: Geoff Clare
>
> | If we do add something, then I think that some non-normative words along
> | the lines of your explanation at the bottom ("to clarify that ...")
> | would be more helpful than the type o
Geoff Clare, The Open Group. 28th January 2020
Attendees:
Don Cragun, IEEE PASC OR
Nick Stoughton, USENIX, ISO/IEC JTC 1/SC 22 OR
Joerg Schilling, FOKUS Fraunhofer
Geoff Clare, The Open Group
Mark Ziegast, SHware Systems Dev.
Eric Blake, Red Hat, Open Group OR
Eric Ackermann
Robert Elz wrote, on 27 Jan 2020:
>
> From: Geoff Clare
>
> | On page 2373 line 75814 section 2.9.4.4 The if Conditional Construct, add:
> |
> | Note: Although the exit status of the if or elif
> | compound-list
>
> Would it be possible t
at mean that 128 isn't special itself?
Correct, but see https://austingroupbugs.net/view.php?id=1229#c4269
(specifically the RATIONALE addition, last bullet point).
--
Geoff Clare
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
tsdam
Geoff Clare, The Open Group
Apologies:
Andrew Josey, The Open Group
* General news
None
* 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 13th June 2019 and earlier)
Martijn Dekker wrote, on 31 Jan 2020:
>
> Op 31-01-20 om 10:11 schreef Geoff Clare:
> >Martijn Dekker wrote, on 30 Jan 2020:
> >>A status that signifies termination by a signal is > 128, isn't it? Doesn't
> >>that mean that 128 isn'
with the sign bit set), it is not "negative". The
terms "positive zero" and "negative zero" are misleading and should
be avoided in formal use.
--
Geoff Clare
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
101 - 200 of 729 matches
Mail list logo
