t;&2
echo "error message part 2" >&2
echo "third and final part of the error message" >&2
I have also seen pipelines written like this:
< infile filter1 | filter2 | filter3 > outfile
which gives a better "picture" of the data flow than this does:
filter1 < infile | filter2 | filter3 > outfile
--
Geoff Clare <g.cl...@opengroup.org>
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
Stephane Chazelas <stephane.chaze...@gmail.com> wrote, on 07 Nov 2016:
>
> 2016-11-07 16:20:08 +, Geoff Clare:
> [...]
> > > How so? "mv -i" with /dev/null as stdin ("no" answer to prompt)
> > > is not supposed to remove anything.
> >
me resolution follows symlinks
by default. So if it did not mention symlinks explicitly here,
a symlink with a non-existent target would not cause EEXIST.
--
Geoff Clare <g.cl...@opengroup.org>
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
Stephane Chazelas <stephane.chaze...@gmail.com> wrote, on 07 Nov 2016:
>
> 2016-11-07 15:40:15 +, Geoff Clare:
> [...]
> > > Same problem with "mv" (which I think would work just
> > > as well (with LC_ALL=C mv -i < /dev/null 2> /dev/null))
>
a conforming
application is executed with file descriptor 0 not open for reading
or with file descriptor 1 or 2 not open for writing, the environment
in which the utility or application is executed shall be deemed
non-conforming, and consequently the utility or application might
not behave as described in this standard.
--
Geoff Clare <g.cl...@opengroup.org>
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
EINVAL is intended to cover completely invalid values, such
as P_PID with a pid of -1.
> If EINVAL is correct here, is that an intended difference from waitpid()
> or just an error?
Seems to me that the standard is silent on this case. We would need
to do a survey of existing practice if we want to rectify that.
--
Geoff Clare <g.cl...@opengroup.org>
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
ormal text, I believe it is intentional. Where they
are in monospace font (particularly if it's example code), we should
consider fixing them.
Whether we can fix any of these problems now and replace C165 yet
again, or if they will have to wait until the next revision, is a
matter for Andrew and Ca
with -L as the default if somedir or otherdir
are symlinks, but go wrong if -P is the default.
I doubt if I have ever used:
ls ..
cd ..
because it is more natural to use:
cd ..
ls
--
Geoff Clare <g.cl...@opengroup.org>
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
efinition (option 1) is only that complicated because
it allows existing practice.
Option 2 is much simpler, and I would prefer that, but we are
constrained by our rules about existing practice, so we need the other
option as a fallback.
--
Geoff Clare <g.cl...@opengroup.org>
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
r cases. It's possible that some certified systems might not
conform, because there was a bug in the test for this, which I only fixed
back in May of this year. (I assumed that what prompted me to fix the bug
was a discussion on this mailing list, but if so, I can't find it in my
archive.)
--
Geoff Clare <g.cl...@opengroup.org>
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
ile time options to make it conform. Perhaps they have also
backported some patches from later versions.
--
Geoff Clare <g.cl...@opengroup.org>
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
by Geoff Clare, The Open Group. 4th August 2017
Attendees:
Mark Ziegast, SHware Systems
Jörg Schilling, FOKUS Fraunhofer
Don Cragun, IEEE PASC OR
Richard Hansen, Google
Nick Stoughton, USENIX, ISO/IEC JTC 1/SC 22 OR
Geoff Clare, The Open Group
David Clissold, IBM
best way to express it though.
I think the introductory part of 2.7 Redirection is probably the best
place to talk about restoring the previous state of file descriptors
on completion of a redirected command. I think it should apply to any
command that is not described in 2.9.1.1 (or 2.9.1.2 after bug 1157 is
applied) as being executed in a separate utility environment.
--
Geoff Clare <g.cl...@opengroup.org>
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
Joerg Schilling <joerg.schill...@fokus.fraunhofer.de> wrote, on 17 Jul 2017:
>
> Geoff Clare <g...@opengroup.org> wrote:
>
> > I thought initially that all uses of "command" should change to "utility",
> > but I think it is common for exe
th "ls" because they won't allow a function called "true" to
be defined, which seems to be a bug.)
However, the wording in the standard certainly does not match the intended
behaviour and needs to be corrected.
I thought initially that all uses of "command" should change to &
t;execute commands" and
this use of "commands" could be interpreted as invoking the defined term.
As discussed earlier, this would be contrary to the intended behaviour.
--
Geoff Clare <g.cl...@opengroup.org>
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
Chet Ramey <chet.ra...@case.edu> wrote, on 17 Jul 2017:
>
> On 7/17/17 10:45 AM, Geoff Clare wrote:
> >
> > Currently the standard says:
> >
> > If /exec/ is specified with /command/, it shall replace the shell with
> > /command/ without creating
xec
are needed. It needs to say that the only parts of the "Command Search
and Execution" stuff in 2.9.1 that apply are item 1.e without 1.e.i.a
and item 2. (It might be better to repeat the relevant parts rather
than risk the reference breaking if/when the item numbering in 2.9.1
changes.)
--
rds:
(exec printf '%g\n' "$float_value")
--
Geoff Clare <g.cl...@opengroup.org>
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
Eric Blake <ebl...@redhat.com> wrote, on 18 Jul 2017:
>
> On 07/18/2017 04:48 AM, Geoff Clare wrote:
> >
> > On page 2398 line 76737 section 2.14 exec, add to EXAMPLES:
> >
> > Execute the implementation's printf utility, ensuring that any
> >
ot;exec break"
> would be a little weird) and functions.
I don't really have an opinion on this. So far all I have done is
asserted what the original POSIX.2 developers intended to require (the
ksh88 behaviour) and proposed wording changes which specify that behaviour.
> The task of modifying where the shell searches to find a utility seems to
> be something better suited to the "command" utility, which is designed for
> that purpose.
Is there any existing practice of extending "command" to provide this
feature?
--
Geoff Clare <g.cl...@opengroup.org>
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
utility or function.
I accept that these days resources are less of an issue (except maybe
in embedded systems), so "exec foo" is probably now seen more as a
shortcut for "foo; exit". However, the fact that the most widely
used shells all still implement it the original way
shall be
performed in a subshell environment". If any of the shells which set Q
in the above command also set it when just executing:
> /tmp/JUNK-${Q=bla}
then that's a bug (or at least a non-conformance) in those shells.
--
Geoff Clare <g.cl...@opengroup.org>
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
d, all lines of the here-document shall
be expanded for parameter expansion, command substitution, and
arithmetic expansion.
It says nothing about which environment the expansion must be done in.
--
Geoff Clare <g.cl...@opengroup.org>
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
shwares...@aol.com <shwares...@aol.com> wrote, on 25 Jul 2017:
>
> I disagree about $M
The current wording is the result of Mantis bug 255 and was written that
way specifically to allow all of the observed behaviours.
--
Geoff Clare <g.cl...@opengroup.org>
The Open Group, A
t; clause is what matters,
The context here is a list of items that comprise a shell or utility
environment. This item in the list is concerned with what files are
open. Clearly there is no intention that the modifications and
additions it refers to means anything other than modifications and
add
by Geoff Clare, The Open Group. 28th July 2017
Attendees:
Don Cragun, IEEE PASC OR
Jörg Schilling, FOKUS Fraunhofer
Geoff Clare, The Open Group
Mark Ziegast, SHware Systems
Richard Hansen, Google
David Clissold, IBM
Eric Blake, Red Hat
Apologies:
Nick Stoughton
press. We then added "-m gzip" as an extensible
equivalent.
--
Geoff Clare <g.cl...@opengroup.org>
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
if so, why?
See above.
> And does anyone know of any other cases that are also likely to need
> special attention (cases where a # in an expansion is just a character,
> like ${var:-###} are not particularly exciting...)
${#-} and ${#?} are the lengths of $- and $? (not treated as ${var
o other possible meaning). (We do have tests for many other
> non-controversial, or just plain boring, cases, of course - but those ones
> I did not think of.)
[...]
> I expect that ${#:-} (etc) are treated the other way, right? As would
> be ${#-word} with a non-empty word.
Right.
--
d
as $SHELL.
This is in contrast to the normal case where $SHELL is the controlling
process, in which case the date and sleep commands would be in the
foreground and they would receive SIGINT but the shell would not.
--
Geoff Clare <g.cl...@opengroup.org>
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
93.)
Judging by the ksh88 error message it looks like it treated the a0
byte of the Unicode NO-BREAK SPACE as a delimiter, so it might use
all characters as delimiters in a single-byte locale, but
not doing it for multibyte characters means it doesn't behave as
described in the standard.
We sho
acter, Jilles is right and
there will be a final empty field. This is because quote removal
is done after field splitting. For example in:
set -- "a:b:"
IFS=:
printf '[%s]\n' $1''
When the word $1'' is expanded, parameter expansion produces:
a:b:''
field splitting turns this into:
field
e standard. IMO the best thing that a system could do here is
return an error in order to bring attention to the problem. (And the
documentation should say "If this error occurs, then unmount the file
system and run fsck.")
--
Geoff Clare <g.cl...@opengroup.org>
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
th dot and
> SUSv4TC1> dot-dot must be written in any case and because such a flag
> SUSv4TC1> would add to the list of those flags (which has proven in
> SUSv4TC1> itself to be objectionable) and might be abused.
This text was originally added in POSIX.1-1990 (B.5.1.2).
It was not in SUSv1/2 because they did not have RATIONALE sections.
--
Geoff Clare <g.cl...@opengroup.org>
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
ade explicitly
unspecified by the resolution of that bug (to be applied in Issue 8).
See http://austingroupbugs.net/view.php?id=221#c399
--
Geoff Clare <g.cl...@opengroup.org>
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
gt; The whole point of "-" and "--" is to ensure what follows is
> safely treated as a list of operands. It defeats the purpose if
> one can't use "--" or "-" in that list of operands.
>
> Am I missing something?
I'm fairly sure the intention is that only:
sh [options]... -- - [operands]...
is undefined, but it's been badly worded and thus also applies to other
cases that it obviously wasn't meant to cover.
--
Geoff Clare <g.cl...@opengroup.org>
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
Stephane Chazelas <stephane.chaze...@gmail.com> wrote, on 02 Jun 2017:
>
> 2017-06-02 16:33:03 +0100, Geoff Clare:
> [...]
> > I'm fairly sure the intention is that only:
> >
> > sh [options]... -- - [operands]...
> >
> > is undefined, but it's bee
equired.
> [...]
>
> Yes, it's hard to tell what behaviour one can rely on with the
> current text. Is opendir(".") required to open the current
> directory even if there's no "." entry in the current directory
> (same for "..")? Is foo/./bar required to be the same as
> foo/bar?
The answer to both of those question is yes. See XBD 4.13 Pathname
Resolution.
--
Geoff Clare <g.cl...@opengroup.org>
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
t; gmane)?
Try https://collaboration.opengroup.org/operational/mailarch.php?listid=2481
You will need to log in using the account that is subscribed to this
mailing list. I'm not sure if all subscribed accounts can access
this archive or only certain types of account.
--
Geoff Clare <g.cl...@opengroup.org>
Stephane Chazelas <stephane.chaze...@gmail.com> wrote, on 08 Jun 2017:
>
> 2017-06-08 12:11:22 +0100, Geoff Clare:
> [...]
> > > OK, but the question remains: "what does it mean?". A "stricter
> > > requirement" for what? That "." or
Stephane Chazelas <stephane.chaze...@gmail.com> wrote, on 08 Jun 2017:
>
> 2017-06-08 12:11:22 +0100, Geoff Clare:
> [...]
> > I can't answer that without knowing why the Base Working Group decided
> > to put in that text instead of using the POSIX.1-1990 text. It
making it?
https://collaboration.opengroup.org/austin/interps/documents/14359/AI-136.txt
--
Geoff Clare <g.cl...@opengroup.org>
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
t d_ino.
That's an interesting idea. Since the point of d_ino is to save
on lstat() calls, having a way of telling the application it needs to
use lstat() when a directory entry is a mount point would preserve this
advantage.
> So we might as well leave the behaviour unspecified.
>
> An
oes the attached program fail on GNU/Linux systems,
Because the GNU/Linux systems you ran it on do not conform.
--
Geoff Clare <g.cl...@opengroup.org>
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
quot;} is different, as this quotes "*". Even with this,
> Bourne Shell, ksh88 and bosh behave identical, only ksh93 differs.
>
> What I have in mind for "${a-"*"}" is [...]
This topic was discussed at great length when we resolved bug 221
back in 2010. I don't think there is anything to be gained from
starting a new discussion of "${a-"*"}".
--
Geoff Clare <g.cl...@opengroup.org>
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
all of these cases?
The changes to align VSC with SUSv4 TC2 are in VSC5.3.13betaNW which
just finished its beta review.
P.S. Joerg - you need to subtract 3 from the Issue number to get
the SUSvX number, i.e. Issue 7 is SUSv4 not SUSv7.
--
Geoff Clare <g.cl...@opengroup.org>
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
is not reliable, as some
of the numbers could change between when df processes the first
pathname and when it processes the second.
See my previous email in this thread for how to use the four numeric
fields (and the '%' on the fourth) as a "terminator" for the filesystem
name.
--
Geoff C
when trailing blanks are removed.
I tried it with the following command and it seems to work:
df -P file1 file2 |
sed '1d;s/\([[:blank:]]\{1,\}[[:digit:]]\{1,\}\)\{4\}%[[:blank:]].*//'
--
Geoff Clare <g.cl...@opengroup.org>
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
Danny Niu <danny...@hotmail.com> wrote, on 22 Nov 2017:
>
> Q1: What is the rationale for not making POSIX an application of ASCII?
So that systems which use other encodings (specifically EBCDIC) can
be POSIX-conforming. IBM z/OS is certified UNIX 95 and uses EBCDIC.
--
Geoff
have a fixed-length buffer because the return string
might need to be longer than the length of that buffer.
So I agree that buffer modification seems to be the only possible
way to implement basename() and dirname() with these new requirements.
--
Geoff Clare <g.cl...@opengroup.org>
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
So anything derived
from Annex G was not a requirement until C11.
Its absence from POSIX is something we will need to address in the
next revision, but it isn't a problem in the current standard as it
still references C99.
--
Geoff Clare <g.cl...@opengroup.org>
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
Martijn Dekker <mart...@inlv.org> wrote, on 21 Oct 2017:
>
> Op 19-10-17 om 15:06 schreef Martijn Dekker:
> > Op 18-10-17 om 16:11 schreef Geoff Clare:
> >> After the filesystem name there are four numeric fields with a trailing '%'
> >> on the four
Stephane Chazelas <stephane.chaze...@gmail.com> wrote, on 04 May 2018:
>
> 2018-05-04 09:30:56 +0100, Geoff Clare:
> [...]
> > > That's the point: we should allow \ to be an escaping operator
> > > inside brackets. In awk and anything else. Technically, that
>
Geoff Clare <g...@opengroup.org> wrote, on 04 May 2018:
>
> Stephane Chazelas <stephane.chaze...@gmail.com> wrote, on 04 May 2018:
> >
> > That would not be enough to match the current reality, I'd say
> > \ (\n, \ooo, \b...) at least should
> > be unde
g text says undefined, so we used it in the new additions
for consistency.
--
Geoff Clare <g.cl...@opengroup.org>
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
t; far as I can tell is compatible with most existing
> implementations)?
The main problem is you didn't supply detailed wording changes.
Another is that there was a major misinterpretation of the standard
in your problem description (about /.../ being like "strong quotes").
So we came
in
> the standard.
>
> If I have
>
> var='a*"?"'
>
> and then I do
>
> echo $var
>
> what should the result be? Is this absolutely the same as
>
> echo a*"?"
>
> ?
No it's not the same. The shell expands $var to a
Robert Elz <k...@munnari.oz.au> wrote, on 27 Apr 2018:
>
> Date:Fri, 27 Apr 2018 10:00:50 +0100
> From:Geoff Clare <g...@opengroup.org>
>
> | I believe the former text is misleading and should be deleted. It is
> | effectively duplicat
in a variable such
that a pattern-magic character can be treated literally is a reason to
keep the first paragraph of 2.13.1 as-is and say that shells which
behave differently than bash here do not conform.
--
Geoff Clare <g.cl...@opengroup.org>
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
C just in case we end up doing one, but we don't plan to.
There's a lot of work to do for Issue 8, so your guess of 2022 at
the earliest is probably not far wrong.
--
Geoff Clare <g.cl...@opengroup.org>
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
Joerg Schilling <joerg.schill...@fokus.fraunhofer.de> wrote, on 27 Apr 2018:
>
> Geoff Clare <g...@opengroup.org> wrote:
>
> > In summary: the need for a way to store a pattern in a variable such
> > that a pattern-magic character can be treated literally
plemented a filesystem without . and ..
> (my COW filesystem WOFS from 1990/1991), I would be happy if that was allowed.
If . and .. don't exist in the file system, then POSIX *requires* that
the expansion of .* does not include them. What we're discussing here
is allowing the expansion of .
Stephane Chazelas <stephane.chaze...@gmail.com> wrote, on 09 May 2018:
>
> 2018-05-09 15:07:24 +0100, Geoff Clare:
> [...]
> > > I don't see the point of "requiring" that $0 ~ "\\f" match a FF.
> >
> > It's a consequence of the way lit
ome characters that are not true digits
(according to iswdigit()).
--
Geoff Clare <g.cl...@opengroup.org>
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
a
> single backslash? As /\\/?
> Or does that match two backslashes?
You do it the way you always have. This change is to make the description
in the standard match what awk has always done.
When the ERE token /\\/ is processed lexically, the double backslash
represents itself. When the res
}> cannot include IO_LOCATION
(because the string \{foo} doesn't begin with '{'), whereas for {foo\}>
it can.
--
Geoff Clare <g.cl...@opengroup.org>
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
ization. Any quotes are just part of the token.
It has to be recognised during tokenization because the result of
tokenization differs depending on whether or not the delimiter
is '<' or '>'.
--
Geoff Clare <g.cl...@opengroup.org>
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
Joerg Schilling <joerg.schill...@fokus.fraunhofer.de> wrote, on 26 Apr 2018:
>
> Geoff Clare <g...@opengroup.org> wrote:
>
> > > > $ ksh -c 'echo {foo\}>&2'
> > > > ksh: foo\: invalid variable name
> > >
> > > I would
nd of the file open on
> stdin and look backward for the last line from there even if the
> initial position of stdin was past the start of that last line
> (it could even be past the end of the file).
The intention is certainly that when reading from standard input,
tail should not writ
Stephane Chazelas <stephane.chaze...@gmail.com> wrote, on 30 Apr 2018:
>
> 2018-04-30 15:50:10 +0100, Geoff Clare:
> > Stephane Chazelas
> > <stephane.chazelas-re5jqeeqqe8avxtiumw...@public.gmane.org> wrote, on 30
> > Apr 2018:
> > >
> > > T
lder cases, I think they are all ones where someone volunteered
to do some "homework" as input to a later meeting, and they have not
(yet) completed it.
--
Geoff Clare <g.cl...@opengroup.org>
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
on a
command being run in the current environment break when it is run in a
subshell.
> B4. Shell may exit if command not found. (XCU 2.8.1, last row in table)
>
> I was only just made aware by kre that POSIX allows this. It's another thing
> that no shell actually does.
Are you sure? If no shell does it, then it seems odd that it was
allowed in the resolution of bug 882 which was relatively recent (2015).
--
Geoff Clare <g.cl...@opengroup.org>
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
Joerg Schilling <joerg.schill...@fokus.fraunhofer.de> wrote, on 26 Apr 2018:
>
> Geoff Clare <g...@opengroup.org> wrote:
>
> > > Parsing:
> > >
> > > 2\> bla
> > >
> > > appears at the same level in the parser and I am su
by Geoff Clare, The Open Group. 3rd August 2018
Attendees:
Mark Ziegast, SHware Systems Dev.
Nick Stoughton, USENIX, ISO/IEC JTC 1/SC 22 OR
Joerg Schilling, FOKUS Fraunhofer
Geoff Clare, The Open Group
Don Cragun, IEEE PASC OR
Martin Rehak, Oracle, The Open Group
by Geoff Clare, The Open Group. 27th July 2018
Attendees:
Don Cragun, IEEE PASC OR
Mark Ziegast, SHware Systems Dev.
Nick Stoughton, USENIX, ISO/IEC JTC 1/SC 22 OR
Geoff Clare, The Open Group
Eric Blake, Red Hat
Joerg Schilling, FOKUS Fraunhofer
Apologies:
Andrew Josey
taff - historically
Andrew Josey, but since 2008-TC1 it has been me. So I was the "poor
unfortunate soul" who spent weeks applying the TC2 changes. (For TC1
I did about half, and Cathy did the other half herself. We started
at opposite ends of the TC1 document and met in the middle.)
--
Geoff Clare
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
"multiple fields" to "multiple fields or no fields" solve it?
I will make that change to the note in bug 1193.
I'm afraid I won't be able to contribute to this discussion further,
as I'll be finishing for the day soon and I'm away for a week from
tomorrow.
--
Geoff Clare
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
value of x ever be considered a numeric string (in the
> awk definition technical sense) ?
No it can't.
The standard has a list of 8 sources of string values that are
eligible for it to be considered a numeric string, and variable
assignment from a string literal does not qualify as any of t
rd empty
> fields from $@ or $* (it obviously can't happen if those are quoted) ? I
> suppose the tricky case would be ""$@ (or $*"" or similar).
We worked on the 2.5.2 wording relatively recently (TC2) and put the "may"
there because we found that some shells discard
quot;a"
> command.
Looking at bug 262, which was a request to allow arbitrary text instead
of editing commands in the -e option-argument and the file specified by
the -f option-argument, it appears that we chose not to do that and
instead just fixed the issue.
--
Geoff Clare
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
subject to the resolution of another issue,
> probably (hopefully) (once again) will not do quote removal either.
> PSn expansions don't do them all either.
This is already covered by the second sentence of 2.6, "Not all expansions
are performed on every word, as explained in the followin
shall be
removed before splitting the input into tokens.
Pay particular attention to the words "that is not quoted".
--
Geoff Clare
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
ed to -e
> and -f with newlines.
>
> - or a variant thereof that covers historical implementations,
> that is same as above except that a fragment can't end in a
> backslash.
The bug 262 resolution was applied in TC1, so further changes
should be requested via a new bug agains
Stephane Chazelas wrote, on 07 Aug 2018:
>
> 2018-08-07 09:40:21 +0100, Geoff Clare:
> [...]
> > Looking at bug 262, which was a request to allow arbitrary text instead
> > of editing commands in the -e option-argument and the file specified by
> > the -f option-argumen
Shware Systems wrote, on 07 Aug 2018:
>
>> On Tuesday, August 7, 2018 Geoff Clare wrote:
>>
>> Shware Systems wrote, on 07 Aug 2018:
>> >
>> > That is a bug in those shells, conformance wise. No buts. Consideration of
>> > quoting hap
Geoff Clare wrote, on 07 Aug 2018:
>
> Robert Elz wrote, on 06 Aug 2018:
> >
> > | For step 1 this would conflict with 2.5.2 which says that empty fields
> > | resulting from expanding @ and * _may_ be discarded. Your suggestion
> > | would require them to be
by Geoff Clare, The Open Group. 10th August 2018
Attendees:
Mark Ziegast, SHware Systems Dev.
Don Cragun, IEEE PASC OR
Nick Stoughton, USENIX, ISO/IEC JTC 1/SC 22 OR
Joerg Schilling, FOKUS Fraunhofer
Geoff Clare, The Open Group
Eric Blake, Red Hat
Apologies:
Andrew
Geoff Clare wrote, on 10 Aug 2018:
>
> Robert Elz wrote, on 10 Aug 2018:
> >
> > set --; A=; for x in a $A b $* c; do printf "[%s]\n" "$x"; done
> >
> > needs to produce
> >
> > [a]
> > [b]
> > [c]
[.
> relevant other places too I think) but simply results in field
> spliiting being a no-op (equivalent to not being performed,
> without the side effects of that.)
Agreed. I've added these changes to note 4082.
> Lastly (and trivially), in your new proposed resolution, that is,
> in note 4082, the first reference to a change in line 74998 should
> be line 74992 (the second reference to line 74998 is correct).
Thanks - I've fixed that.
--
Geoff Clare
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
update to the standard, whatever that is (TC3 or Issue 8).
--
Geoff Clare
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
> splitting an empty field cannot possibly change anything (there
> cannot be any chars from IFS in it) and so there's no point
> trying. Of course, that was back before field splitting gained the
> extra task of cleaning up unwanted empty fields...
Again, it is not field splitting that
Geoff Clare wrote, on 10 Aug 2018:
>
> Actually, I think the existing description of Field Splitting handles
> it correctly.
[...]
> So I think just deleting that paragraph, as bugnote 4082 currently has
> it, is the right thing to do.
I decided that this was worth an explicit m
Submitted by Geoff Clare, The Open Group. 24th August 2018
Attendees:
Mark Ziegast, SHware Systems Dev.
Nick Stoughton, USENIX, ISO/IEC JTC 1/SC 22 OR
Don Cragun, IEEE PASC OR
David Clissold, IBM
Geoff Clare, The Open Group
Martin Rehak, Oracle
Eric Blake, Red Hat
Apologies:
Andrew
ing has
no effect, then the end result would be an empty field. So to me the
second part does seem like an exception to the first part.
--
Geoff Clare
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
d=789
We agreed to leave this item open pending input from David Korn.
We had previously asked for input from Chet Ramey and David Korn and
got a reply from Chet but not from David.
--
Geoff Clare
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
k the main question we were hoping for input on is whether
it is worth standardising pipefail without support for arrays.
Since kre reported in bugnote 4102 that he added pipefail to the
NetBSD sh and it does not support arrays, it seems we have our
answer on that one.
--
Geoff Clare
The Open Grou
ot;
set -- $statuses
status2=$2
instead of just:
set -- $|
status2=$2
(the latter would be equivalent to: set -- $ | status2=$2)
--
Geoff Clare
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
iant
> software (xpg4/xpg6... packages are optional).
The certification doesn't specify a configuration, nor does it need to.
The delivered configuration doesn't need to provide a conforming
environment by default. The standard just requires that systems document
how to set up a conforming envir
ibly different, from what others are doing ?
Usually if a feature is proposed that isn't ready for standardisation
we would close the Mantis bug with a note saying (but less bluntly) "try
again when it's ready". However, I suppose we might make an exception if
there is good reason to do so.
--
Geoff Clare
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
1 - 100 of 638 matches
Mail list logo
