On Wed, 2024-02-14 at 09:18 -0500, Chet Ramey via austin-group-l at The
Open Group wrote:
> POSIX requires this, since it says that return sets $? to 1 here.
I assume you mean the description of the exit status from `return`?
> The value of the special parameter '?' shall be set to n, an
>
Hey.
I was playing around with dash, whether I'd be able to implement
draft 3's -d option for read, but I didn't understand the standard
completely and found several parts to be improvable (which I've markde
with => ).
I) My understanding was that `read` reads logical lines, where a
logical
Hey.
POSIX 4.13 Pathname Resolution says:
> If a pathname begins with two successive characters, the
> first component following the leading characters may be
> interpreted in an implementation-defined manner, although more than
> two leading characters shall be treated as a single
>
On Wed, 2023-01-25 at 09:31 -0800, Bruce Korb via austin-group-l at The
Open Group wrote:
> He also thinks that maybe the UUCP related code deserves a sunset.
> All
> of it. It's kind of old and essentially obsolete. :)
Wouldn't that also mean that (at least GNU people) loose the ability to
On Fri, 2023-01-20 at 20:48 +, Thorsten Glaser wrote:
> > IMO it should only be removed if replaced by the base64 utility.
>
> Which of them, GNU base64(1) or BSD b64{en,de}code(1)?
>
> Let POSIX not become a GNU shipping house, please.
>
> Also, uu is standard for clasic eMail attachments.
On Thu, 2023-01-12 at 13:44 +0700, Robert Elz via austin-group-l at The
Open Group wrote:
> If there was anything to do here with uuencode/uudecode it would be
> to
> (again) consider removing them from the standard - but not because of
> security issues, just because they are now essentially
On Wed, 2023-01-11 at 13:48 -0800, Alan Coopersmith via austin-group-l
at The Open Group wrote:
> Below is a message sent to the Open Source Security mailing list over
> the holidays about a security risk in uudecode, which the GNU
> maintainer
> pointed out was forced by the current language of
On Sat, 2022-12-31 at 06:11 +0200, Oğuz wrote:
> This seems to have already been addressed
> here https://austingroupbugs.net/view.php?id=621 by the way
Ah thanks... that resolves it. Haven't found it as I was searching for
Issue 8 draft issues only.
Cheers,
Chris.
On Fri, 2022-12-30 at 08:17 +0300, Oğuz İsmail Uysal wrote:
> I think so, but perhaps it should say "terminates normally" instead,
Which, if it's only written in the exit built-in’s description, could
still be mistaken as "only when via done so via a call to the exit
utility" - and e.g. not if
Hey.
I recently read a question on the bash mailing list about shell
behaviour which reminded me on something else I've noticed my self a
while ago in dash and which I felt was unexpected behaviour.
This in turn brought me to the question whether POSIX specifies in
which exact cases the EXIT
Hey folks.
A while ago we had this discussion about pattern matching notation and
characters vs. bytes.
Back then, Harald von Dijk did some investigation on whether the
standard could be changed to allow for bytes (and not just characters)
without breaking all kinds of shells.
IIRC, when he
Hey.
On Mon, 2022-08-08 at 15:15 +, Austin Group Bug Tracker via austin-
group-l at The Open Group wrote:
> This was discussed during the 2022-08-08 conference call. Since
> there is
> clear disagreement about the scope of local variables, it is not
> clear
> that consensus can be reached.
Hey.
I noted the following...
1) First, my understanding is, that a variable needs not to be set, but
can still have attributes (e.g. export/readonly) set for it.
Not sure whether I just didn't find it, but I think this behaviour is
not specifically mentioned somewhere, or is it?
2) The
On Thu, 2022-05-19 at 09:05 +0100, Harald van Dijk wrote:
> >
> > The above, AFAIU, mean that any shell/fnmatch matches a valid
> > multibyte
> > character... but also a byte that is not a character in the locale.
>
> Correct, though as I wrote later on, the way they go about it is
> different.
On Sun, 2022-05-15 at 16:14 +0100, Harald van Dijk wrote:
> Please see the tests and results here.
So dash/ash/mksh/posh/pdksh,... and every other shell that doesn't
handle locales at all (and thus works in the C locale)... is anyway
always right (except for bugs), since any (non-NUL) byte is
On Fri, 2022-05-06 at 14:38 +0100, Andrew Josey via austin-group-l at
The Open Group wrote:
> Bug 1560: clarify wording of command substitution OPEN
> https://austingroupbugs.net/view.php?id=1560
>
> Leave this and related bugs 1561, and 1564 open pending
> reviews/discussions.
Just in case
On Thu, 2022-04-21 at 15:10 +0100, Geoff Clare via austin-group-l at
The Open Group wrote:
> > >
> > > does not work, because if it appears unescaped later
> > > in
> > > the RE, it either escapes the following character, which can then
> > > never be the ending delimiter
> >
> > It feels a bit
Hey Eric.
On Mon, 2022-04-25 at 11:06 -0500, Eric Blake wrote:
> The GNU sed developers can be reached at bug-...@gnu.org (per the
> output of 'sed --help', and as done in this email).
Ah, I think I had written to sed-devel in January.
> So if I'm restating your complaint correctly
On Mon, 2022-04-25 at 10:21 +0100, Geoff Clare via austin-group-l at
The Open Group wrote:
> This was discussed during our work on bug 1233 and resulted in
> additions
> to the sed APPLICATION USAGE (line 106286 in draft 2.1) and FUTURE
> DIRECTIONS.
Hmm... AFAICS, that was only done for sed,
On Mon, 2022-04-25 at 12:02 +0100, Geoff Clare via austin-group-l at
The Open Group wrote:
> > > > May I suggest to rather directly write something like:
> > > > "The following four varieties of parameter expansion provide
> > > > for
> > > > substring
> > > > processing, with each of them
On Mon, 2022-04-25 at 11:32 +0100, Geoff Clare via austin-group-l at
The Open Group wrote:
> > Do you think that similar explanations would be needed for the
> > other
> > expansions/substitutions?
>
> I searched all of XCU chapter 2 for the word "character" when I
> worked
> on my proposed
Hey.
Geoff, I haven't had time yet to look at your updated proposal of
#1550, not sure whether I manage to do it this night or in the next
days.
But I'll definitely reply, so please be a bit more patient. :-)
However, on thing came to my minds again, which I think needs further
discussion...
Oh and I've "reviewed" your new proposal in note #5818 and thinks it
looks good.
Cheers,
Chris.
On Fri, 2022-04-22 at 16:12 +0100, Geoff Clare via austin-group-l at
The Open Group wrote:
> > ---
> > ---
> > (0005806) calestyo (reporter) - 2022-04-15 02:55
> > https://www.austingroupbugs.net/view.php?id=1562#c5806
> >
On Fri, 2022-04-22 at 15:36 +0100, Geoff Clare via austin-group-l at
The Open Group wrote:
> > Cause if it's that a shell must not "take over" e.g.
> > '+=whatAWeirdVariable', then this was (at least indirectly) already
> > clear
> > before, by variables being parameters and these, as per 2.5,
On Fri, 2022-04-22 at 12:03 +0100, Geoff Clare via austin-group-l at
The Open Group wrote:
>
> I like this suggestion, although "any character of the characters"
> is a bit strange. I'll go with "any of the characters".
Yes, that makes sense.
> > 3) You introduce bytes/byte sequences vs.
Hey.
On Tue, 2022-04-19 at 01:52 +0100, Harald van Dijk wrote:
> Even I did not to apply this to pattern matching. The
> lexical locale, the locale used for lexing, is only used for lexing,
> i.e. for recognising tokens, not to how those tokens are then
> interpreted later on. If locale comes
On Fri, 2022-04-08 at 09:57 +0100, Geoff Clare via austin-group-l at
The Open Group wrote:
>
> Please don't raise unrelated issues in bugnotes. Either ask on the
> mailing list or submit a separate bug.
sorry
>
>
> I think a new bug report asking for:
>
> A portable BRE shall escape a
On Tue, 2022-04-05 at 15:54 +0100, Geoff Clare via austin-group-l at
The Open Group wrote:
> > ---
> > ---
> > (0005771) calestyo (reporter) - 2022-04-02 01:53
> > https://austingroupbugs.net/view.php?id=1550#c5771
> >
On Tue, 2022-04-05 at 23:33 +0700, Robert Elz via austin-group-l at The
Open Group wrote:
> Not just portable, but sane. Only a moron would actually use . ? *
> [ ( ...
> as a delimiter, there are plenty of perfectly good alternatives
> available
> when good old / isn't the best choice (which it
On Fri, 2022-04-15 at 00:44 +0100, Harald van Dijk via austin-group-l
at The Open Group wrote:
> Hmm, I would.
I like that :-D This would have been the preferred alternative I've
asked for to look at, in the ticket.
> Shells
> are not in agreement on whether such single bytes can be matched
On Tue, 2022-04-12 at 18:54 +0700, Robert Elz via austin-group-l at The
Open Group wrote:
> The point was that, at least as I read the proposed text, you're
> defining
> things like '*' to only work (reliably as specified) when the locale
> is
> POSIX (aka C). In the user's locale, who knows
On Fri, 2022-04-08 at 10:29 +0100, Geoff Clare via austin-group-l at
The Open Group wrote:
> As you have probably seen, I have posted an updated proposal to
> bug 1550. Hopefully that will help with your review.
Yes,.. but still haven't gotten around to look into it (and all the
others that I
On Thu, 2022-04-07 at 16:26 -0700, Don Cragun wrote:
> Note that the definition of "escape sequence" is being added in
> section 9.1 (titled" Regular Expression Definitions") in the Base
> Definitions Volume of the standard; not in Section 3 where
> definitions go that pertain to the entire
Hey.
btw: It should not be forgotten, that this definition of escape
sequence/character, escaped character is in principle only valid for
the RE chapter. Except of course, something explicitly refers to that
or - like with sed - extends the RE language.
Just wanted to point that out again, to be
On Mon, 2022-04-04 at 15:24 +0100, Geoff Clare via austin-group-l at
The Open Group wrote:
> An escape sequence is defined as the escape character (a
>
> that is neither in a bracket expression nor itself escaped),
> followed
> by any single character.
The ordering of that sounds
On Sun, 2022-04-03 at 05:51 +0300, Oğuz wrote:
> 3 Nisan 2022 Pazar tarihinde Christoph Anton Mitterer via austin-
> group-l at The Open Group yazdı:
> > But many of those extensions made by implementations in areas where
> > POSIX doesn't define things, cause IMO
On Sun, 2022-04-03 at 08:41 +0700, Robert Elz via austin-group-l at The
Open Group wrote:
> Actually there's no reason to forbid them, they simply do
> not work. Applications cannot expect them to work.
> That's all that needs to be said.
Well than let's not call it forbid, but - as already the
On Tue, 2022-02-22 at 09:29 +, Geoff Clare via austin-group-l at
The Open Group wrote:
> Since all character strings are strings, it is not wrong per se.
Well that sounds a bit far fetched ;)
> However, it could be changed to say "character strings" without
> altering the requirements.
On Mon, 2022-02-21 at 09:58 +, Geoff Clare via austin-group-l at
The Open Group wrote:
> The reason the LC_ALL=C is needed to avoid unspecified behaviour is
> because the description of the ${parameter%[word]} expansion refers
> to 2.13 for how the pattern matching is done, and 2.13 is worded
On Fri, 2022-02-18 at 00:35 +, Thorsten Glaser wrote:
> You can have nōn-POSIX locales. For example, in mksh, I have a UTF-8
> mode, but I specify that only the "C" locale attempts POSIX
> conformance.
But that sounds like a violation of POSIX, e.g. if you had a locale 'C'
which would encode
Don,
On Fri, 2022-02-18 at 04:04 +, Austin Group Bug Tracker via austin-
group-l at The Open Group wrote:
> (0005678) Don Cragun (manager) - 2022-02-18 04:04
> https://www.austingroupbugs.net/view.php?id=1558#c5678
> -
> -
Hey.
I'm still trying to write up some in-depth documentation (e.g. for
StackOverflow) why things (i.e. the command substitution with trailing
newlines) work the way (and have to be the way), as it was described
here before.
And unfortunately, stumbled over some more...
1)
a) As per POSIX,
Hey Eric.
On Tue, 2022-02-08 at 15:21 -0600, Eric Blake wrote:
> Yes. And another fallout of that requirement: you cannot have a
> single
> POSIX system supporting both ASCII and EBCDIC locales.
What does that mean in practise... does e.g. Linux/glibc ship these
locales just for the purpose of
Hey.
I'm afraid but some more questions came up on my side:
1) POSIX says:
"The encoded values associated with , , , and
shall be invariant across all locales supported by
the implementation."
When now, for example, is encoded as the byte 0x2E ... the
consequence would be that it had to be
On Mon, 2022-01-31 at 10:45 +, Geoff Clare via austin-group-l at
The Open Group wrote:
> >
> Okay, I was assuming the typical case where the output is only
> valid for exit status 0. If other exit statuses also have valid
> output then they would need to be allowed for (such as grep
> exiting
On Sat, 2022-01-29 at 01:00 +0100, Christoph Anton Mitterer wrote:
> What about:
> result="$(some_command ; e=$?; print '.' && exit $e || exit 666 )"
Dammit... it's my notebook's "f" key... starts to stop working.
result="$(some_command ; e=$?; printf '.' && exit $e || exit 666 )"
On Fri, 2022-01-28 at 09:51 +, Geoff Clare via austin-group-l at
The Open Group wrote:
> > result="$(command ; e=$?; print '.' ; exit $?)"
>
> The print should be printf, and I assume you intended exit $e here.
Of course... sorry,... shouldn't write such things late in the night ^^
>
On Fri, 2022-01-28 at 11:26 +, mirabilos wrote:
> Christoph Anton Mitterer via austin-group-l at The Open Group dixit:
>
> > However, that may have been crashed again by [2] respectively [3].
>
> |it actually finds "XL"? One possible behavior is to rep
On Thu, 2022-01-27 at 12:44 +, Geoff Clare via austin-group-l at
The Open Group wrote:
>
> It seems to me that there are three cases to consider:
>
> * The command's output is expected to contain byte sequences that
> might not form valid characters.
> In this case LC_ALL=C should be
On Thu, 2022-01-27 at 18:09 +, Harald van Dijk via austin-group-l
at The Open Group wrote:
>
> I have to disagree. The use of " character" to me clearly
> means
> that the output of the command is processed as a sequence of
> characters,
> as opposed to a sequence of bytes.
While not being
On Thu, 2022-01-27 at 17:07 +, Harald van Dijk via austin-group-l
at The Open Group wrote:
> That is not what POSIX says. It says "The value of an environment
> variable is a string of characters" (8.1 Environment Variable
> Definition), and "character" is defined as "a sequence of one or
On Thu, 2022-01-27 at 15:18 +, Harald van Dijk via austin-group-l
at The Open Group wrote:
> The benefit of this that when the
> shell's locale changes, variables still hold their original text (as
> opposed to their original bytes).
But doesn't that by itself already violate POSIX?
There
Hey Geoff.
Thanks and funny you came up with that...
On Tue, 2022-01-25 at 09:25 +, Geoff Clare via austin-group-l at
The Open Group wrote:
> You are correct, and a common method of preserving trailing newlines
> is to append a non-newline character and then strip it, e.g.:
>
>
Hey.
Perhaps someone can help me with this.
Many areas in the shell are defined to work with text or lines of text
(i.e. containing a trailing newline).
For command substitution the standard says:
"The shell shall expand the command substitution by executing command
in a subshell environment
On Fri, 2022-01-14 at 13:03 +0300, Oğuz wrote:
> Yes you can, and it can be that simple. Providing a valid RE is
> application developer's responsibility
Which is impossible again, especially in a portable manner, when it's
ambiguous what a valid RE is.
> Backslash not being special inside a
>
On Fri, 2022-01-14 at 00:10 -0800, Don Cragun wrote:
> It isn't that simple.
IMO it's even more complex ;-)
> When you find the first delimiter, you can't look for the second
> delimiter in the middle of a bracket expression and you can't look
> for the second delimiter in the middle of a
On Fri, 2022-01-14 at 09:07 +0300, Oğuz wrote:
> > And where does it say that? I mean in the standard.
> > I.e. where does it say, that parsing is only allowed to happen in
> > one
> > stage from left to right, especially not only with respect to an RE
> > itself, but also when an RE is embedded
btw: Things seem even worse, as also non-special characters used as
delimiters may be affected by implementation-ambiguities:
GNU sed:
$ printf '%s\n' '9+' | sed 's+9\++X+'
X
$ printf '%s\n' '99+' | sed 's+9\++X+'
9X
$ printf '%s\n' '999+' | sed 's+9\++X+'
99X
=> these results are IMO
On Thu, 2022-01-13 at 10:04 +0300, Oğuz via austin-group-l at The Open
Group wrote:
> > a) Is it defined, how the unescaping of delimiters vs. special
> > characters happens?
> > Consider the following example:
> > s(\\((X(
> > There are at least two ways to parse that:
>
> I see only one. From
Hey Don.
On Mon, 2022-01-10 at 22:27 -0800, Don Cragun wrote:
> * In a context address, the construction "\cREc",
> where c is any character other than
> or , shall be identical to "/RE/". If
> the character designated by c appears following
> a , then it
Hey.
Maybe someone can help me with this (or point out that it's undefined -
and perhaps should be):
I was looking into when BREs/EREs are used with delimiters (i.e. sed's
s- and y-commands) that are also special characters with respect to the
respective RE syntax.
There were some things which
62 matches
Mail list logo
