Date:Thu, 10 Sep 2020 09:32:03 +0100
From:"Geoff Clare via austin-group-l at The Open Group"
Message-ID: <20200910083203.GA29472@localhost>
| You read it again. You are ignoring the last sentence.
No, I am not.
| Yes. The last sentence. It clearly implies
Date:Fri, 11 Sep 2020 15:59:26 +0100
From:"Geoff Clare via austin-group-l at The Open Group"
Message-ID: <20200911145926.GA7856@localhost>
| Although Andrew asked us to take this to the offtopic list, I would
| like instead to bring it back on topic, by making
austin-group-l@opengroup.org said:
| Replies should work the same way they used to[*]. If you use your email
| client's "reply all" function
First, see how that citation of your message looks when I don't go and
manually fix it, that's because the address used is that from the From:
field
austin-group-l@opengroup.org said:
| Some applications might find it useful that 0 is translated to "EXIT".
Apart from the implementation of trap -l (which isn't even a standard
option) name a single one? That "EXIT" is translated to 0 makes it
fractionally easier to implement "trap" I
Date:Wed, 9 Sep 2020 17:12:56 +0100
From:"Geoff Clare via austin-group-l at The Open Group"
Message-ID: <20200909161256.GA15692@localhost>
| There's your problem right there. You are using an email client that
| is not fit for purpose.
While it might (well,
Date:Tue, 8 Sep 2020 17:11:16 +0100
From:"Geoff Clare via austin-group-l at The Open Group"
Message-ID: <20200908161116.GA1829@localhost>
| Initially I had assumed (from the Solaris man page) that sig2str()
| only translated signal numbers, and specified it as
I knew it was from the distant past. That it was AT corporate
(the commercial computer people there, back then) that made a dumb
decision is no surprise, they made so many...
This one actually, if confined to its original uses, and not
proposed as a general purpose interface, is understandable.
Date:Mon, 14 Sep 2020 23:09:21 +0200
From:"Steffen Nurpmeso via austin-group-l at The Open Group"
Message-ID: <20200914210921.h1m8r%stef...@sdaoden.eu>
| This is of course very primitive handling and does not take care
| for RFC 2822, no Sender: handling, etc.
Date:Tue, 15 Sep 2020 15:37:31 +0200
From:Steffen Nurpmeso
Message-ID: <20200915133731.cpghp%stef...@sdaoden.eu>
Quoting RFC822:
| the presence of the "Reply-to" field SUPERSEDES the sending
| of a reply to the person named in the "From" field.
I suspect
Date:Sat, 12 Sep 2020 19:30:22 +0200
From:Steffen Nurpmeso
Message-ID: <20200912173022.shnqc%stef...@sdaoden.eu>
| I do not know how you can say this. (If it last your original
| address entirely, where is the improvement?)
It is at least now directing replies
Date:Tue, 1 Sep 2020 10:32:55 +0100
From:"Geoff Clare via austin-group-l at The Open Group"
Message-ID: <20200901093255.GA7629@localhost>
| but I'm not sure how useful this would be to applications. In any case
| it would be highly unusual for an application
joerg.schill...@fokus.fraunhofer.de said:
| Many of the new features from Svr4 have been developed by David Korn in
| 1988 and I definitely doubt that these interfaces are a result of dumb
| decisions.
For an internal interface in the shell, designed in the 80's, perhaps not.
As a
Garrett Wollman said:
| "The shell" is one instance of a programming-language runtime.
Maybe (probably) I wasn't as clear as I should have been, by "the shell"
I didn't just mean the thing that POSIX specifies as sh, but any shell
like program (even csh) - plus implementations of various
Date:Thu, 8 Oct 2020 09:49:26 +0100
From:"Geoff Clare via austin-group-l at The Open Group"
Message-ID: <20201008084926.GA19154@localhost>
| Isn't an array whose total size exceeds SIZE_MAX bytes an impossibility?
It is, I think the point might have been that
Date:Thu, 8 Oct 2020 13:52:16 +
From:Wojtek Lerch
Message-ID: <136001a9769d49babe52348edeaf2...@blackberry.com>
| Chapter and verse please? :)
I don't do C standards stuff (a committee that does far too much invention
for my tastes) but as I understand it, a
Note this is forwarding a NetBSD query ... I claim no knowledge
about any of this ... but I can relay any replies (and I have included
Thomas Klausner in the Reply-To so he doesn't need to wait for me, and/or
so you can ask him for more details if needed ... I'm not sure if this list
allows
Date:Tue, 22 Sep 2020 11:05:05 + (UTC)
From:"shwaresyst via austin-group-l at The Open Group"
Message-ID: <1248402378.5117076.1600772705...@mail.yahoo.com>
| Once pthread_attr_init() successfully completes the guardsize should be
| set to the default value
Date:Tue, 22 Sep 2020 14:38:07 + (UTC)
From:shwaresyst
Message-ID: <32911555.5186984.1600785487...@mail.yahoo.com>
| Yes, it is no longer a factor,
I would have guessed that is what "not used" means, but:
| and no, it will return what last setting was, be
Date:Thu, 1 Oct 2020 10:44:23 +
From:"Austin Group Bug Tracker via austin-group-l at The Open
Group"
Message-ID: <4a154351239ff24caf6e4c91062bf...@austingroupbugs.net>
| It seemed simpler to specify this in terms of which outgoing header
| they are marked
Date:Sat, 24 Oct 2020 19:22:07 + (UTC)
From:shwaresyst
Message-ID: <1984361807.3011984.1603567327...@mail.yahoo.com>
| Could an implementor represent integers as an internal
| form with 0 bits
You're concentrating on a reductio-ad-absurdum comment I threw
Date:Mon, 26 Oct 2020 15:02:26 +0100
From:Joerg Schilling
Message-ID: <5f96d6f2.jkFuBT5X4/F/wqwv%joerg.schill...@fokus.fraunhofer.de>
| If the code you are using is from FreeBSD (Garret Damore)
Where it originated I don't know for sure, but it has been in the
Date:Mon, 26 Oct 2020 19:18:10 +0100
From:Joerg Schilling
Message-ID: <5f9712e2.+zlga0iaqihkovkz%joerg.schill...@fokus.fraunhofer.de>
| There is a simple rule of thumb: If you like to use %n$ for localization,
| use a matching number of arguments and % units with
Is there somewhere, anywhere, where it is possible to infer what
range of values printf (the utility, not the C library function)
is expected to handle?
I can find nothing in the XCU 3.printf page, nor in XBD 5 (and also
not in XBD 12, which would be another plausible place). There doesn't
seem
Date:Sat, 24 Oct 2020 16:47:41 + (UTC)
From:shwaresyst
Message-ID: <160402159.2963847.1603558061...@mail.yahoo.com>
| The text relevant to all this I see is the paragraph at line 104150, page 3=
| 114, c181.pdf,
That is the text I quoted in the previous
A couple of messages back I wrote:
| But it is obvious that at least the NetBSD sh, bash, bosh, zsh,
| and ksh93 have a builtin printf (the error messages differ...)
I should have included dash and yash in that list - their error messages
are very similar to what /usr/bin/printf on NetBSD
Date:Thu, 6 Aug 2020 16:38:07 +
From:"Jefferson Carpenter via austin-group-l at The Open Group"
Message-ID: <86788af2-b318-424e-dd6a-51ee300f6...@aoeu2code.com>
| First, I was imagining myself using Linux. If I went to change the
| locale, and the
When I first submitted issue 1389, I had forgotten to fill in
the "Category" field (select "shell and Utilities" from the
drop down menu.
So after getting the error because of that (that was fine) I
used my browser's "back" button to return to the form, filled
in the missing field, and submitted
I am about to submit 3 (related) interpretation requests (bug reports)
against Issue 7 TC2 (the text has changed in Issue 8, but those changes
are not relevant to the issues reported, though if accepted, some of the
changed text will require more changes).
These 3 issues should all be linked as
Date:Thu, 13 Aug 2020 14:26:06 -0700
From:Don Cragun
Message-ID:
| The Severity, Type, and Name fields have all been corrected on
| bugid:1389 and all three bugs have been related to each other.
dcra...@sonic.net said:
| The Section and Page Number sections
Date:Wed, 05 Aug 2020 11:28:45 -0400
From:"Paul Smith via austin-group-l at The Open Group"
Message-ID: <1d8c5e6e96fbdd47ce143a566b57db2c803d4898.ca...@gnu.org>
| do you consider the pseudoterminal as providing to the terminal, or the
| terminal as providing to
Date:Tue, 4 Aug 2020 19:57:22 +0100
From:"Andrew Josey via austin-group-l at The Open Group"
Message-ID: <08605dfa-f6c7-4eb8-9275-6511fbd37...@opengroup.org>
| I will be monitoring and we can revert if it causes issues
It causes issues, and is hideous. Please
Date:Thu, 3 Dec 2020 20:08:35 + (UTC)
From:shwaresyst
Message-ID: <542954052.4149333.1607026115...@mail.yahoo.com>
| It's my understanding the practice predates Issue 6
| and stems from a desire to not break code similar to:
| #include
| #if
Date:Thu, 3 Dec 2020 18:43:13 +
From:Austin Group Bug Tracker
Message-ID: <2b7895fb8cafbe206e7246596b3d5...@www.austingroupbugs.net>
| A NOTE has been added to this issue.
I am replying on the list, rather than via another note, as this
reply adds nothing of
Date:Thu, 3 Dec 2020 10:53:43 -0800
From:Nick Stoughton
Message-ID:
| If the value is 200112L, then the implementation of the monotonic clock is
| as specified in that version of the standard (where it was optional). If
| the value is 200809L, then the
Date:Thu, 3 Dec 2020 17:21:47 +
From:"Austin Group Bug Tracker via austin-group-l at The Open
Group"
Message-ID:
| A NOTE has been added to this issue
The issue is now closed, so I cannot append a new note [Aside:
adding proposed text, and immediately
Date:Thu, 3 Dec 2020 18:11:51 + (UTC)
From:shwaresyst
Message-ID: <684426419.4103424.1607019111...@mail.yahoo.com>
| The 20yymmL shall be replaced with the value specific to Issue 8 when that
| is finalized, not that an implementation may choose an arbitrary
This has been discussed (somewhere) before - but in the context of being
able to guarantee that the filesystem command is run, and not anything
else. Specifying the full path will do that, but to do that portably
means the script needs to do its own PATH search, and that's ugly.
The overall
Another issue where new text with a proposed resolution is posted
to the bug, and the bug is then closed within minutes, preventing
any further (in bug report) discussion.
People, please stop doing this - if a new note is added with a proposed
resolution (other than "apply the text in note NNN"
I think we should cease discussions of how options are parsed, or
what bash does with ulimit, and return to documenting what is
reasonable to document for ulimit.
There is another case not yet considered:
ulimit -n -n
The shells that only allow a single option and report whatever was
Date:Mon, 9 Nov 2020 10:38:26 +
From:"Austin Group Bug Tracker via austin-group-l at The Open
Group"
Message-ID:
| I have realised the desired action doesn't cover the behaviour when more
| than one resource-selection option is specified. If no operand is
Date:Mon, 9 Nov 2020 15:07:43 +
From:"Geoff Clare via austin-group-l at The Open Group"
Message-ID: <20201109150742.GA13372@localhost>
| The ksh and bash behaviour of reporting multiple values seems more
| useful to me,
That might be, sometimes - the other
Date:Thu, 14 Jan 2021 13:39:29 -0500
From:Richard Hansen
Message-ID: <873368db-6447-6f90-be5d-65037e06b...@rhansen.org>
| The accepted text has been updated to address your comments.
| Please let us know if we missed anything.
Looks fine now. Thanks.
|
Date:Sun, 31 Jan 2021 06:48:25 +
From:"Austin Group Bug Tracker via austin-group-l at The Open
Group"
Message-ID: <79086278e43eeebd97f64b7f45613...@www.austingroupbugs.net>
| A NOTE has been added to this issue.
This comment isn't worthy of a note, but
|
Date:Wed, 03 Feb 2021 18:35:01 +0100
From:Steffen Nurpmeso
Message-ID: <20210203173501.srcqv%stef...@sdaoden.eu>
| What else. Having \$ would be nice,
It doesn't exist in shells, so it cannot be in the standard.
| that i do not understand reluctance of you
Date:Wed, 3 Feb 2021 09:59:20 -0800
From:Scott Lurndal
Message-ID: <20210203175920.ge19...@dragon.sl.home>
| When you combine "not block indefinitly" with O_NDELAY/O_NONBLOCK,
The standard doesn't (currently) say anything about expecting those
to be set on the
Date:Tue, 2 Feb 2021 15:24:33 -0800
From:"Scott Lurndal via austin-group-l at The Open Group"
Message-ID: <20210202232433.gc19...@dragon.sl.home>
| The application will not block _indefinitely_.
That's not what the standard actually says, nor would it really
Date:Sun, 4 Jul 2021 10:31:06 +0100
From:Stephane Chazelas
Message-ID: <20210704093106.2ce2cyg77f2nm...@chazelas.org>
| That would make is non-compliant then.
s/is/it/ ... and yes, so?
| SUS> When there are multiple key fields, later keys shall be
There was
Date:Thu, 1 Jul 2021 11:45:40 +0100
From:"Geoff Clare via austin-group-l at The Open Group"
Message-ID: <20210701104540.GA4023@localhost>
| Because it is a precondition of this discussion. I.e. what we are
| debating is what is the required behaviour if pwd
Date:Sun, 4 Jul 2021 19:26:25 +0100
From:Harald van Dijk
Message-ID: <40fc0b0c-364f-8ff8-0613-a76c887d4...@gigawatt.nl>
| I think the definition of "write", in Base Definitions, tries to say so,
To a degree, yes, but I don't think that actually adds anything to
Date:Mon, 5 Jul 2021 00:41:23 +0100
From:Harald van Dijk
Message-ID: <88337ff9-c726-c563-4d4f-3fa74d964...@gigawatt.nl>
| I was looking at the HTML version. Aside from its search function, you
| can find it there under System Interfaces (top left frame), then
Date:Mon, 05 Jul 2021 20:05:20 +0200
From:"Joerg Schilling via austin-group-l at The Open Group"
Message-ID: <20210705180520.kgbgk%sch...@schily.net>
| That would be in conflict with long existing practice
Apparently not in most versions of sort.
| If you
Date:Tue, 29 Jun 2021 09:49:40 +0100
From:"Geoff Clare via austin-group-l at The Open Group"
Message-ID: <20210629084940.GA8391@localhost>
| You are wrong when you say it "printed it". It tried to print it but
| failed to do so.
But how do you actually know?
Date:Tue, 29 Jun 2021 01:52:32 +0200
From:Vincent Lefevre
Message-ID: <20210628235232.gb46...@zira.vinc17.org>
| Where is this written (at least for the particular case of builtins)?
Philip Guenther supplied the text - there's nothing special about
builtins
Date:Mon, 28 Jun 2021 10:03:39 +0100
From:"Geoff Clare via austin-group-l at The Open Group"
Message-ID: <20210628090339.GA13976@localhost>
| The (builtin) pwd utility got an error when it tried to write() to
| standard output.
But did it "encounter" the error?
Date:Mon, 28 Jun 2021 13:26:48 +0200
From:"Joerg Schilling via austin-group-l at The Open Group"
Message-ID: <20210628112648.qkgag%sch...@schily.net>
Several messages to which to reply ... but I'll start with the
easy ones.
| It could be argued that setting up
Date:Mon, 28 Jun 2021 15:48:33 +0200
From:Vincent Lefevre
Message-ID: <20210628134833.ga46...@zira.vinc17.org>
| So, if writing to a closed fd yields unspecified behaviour, what
| does "refers to no open file" mean?
No, you misunderstood. It isn't writing to
Date:Mon, 12 Jul 2021 09:48:33 +0100
From:"Geoff Clare via austin-group-l at The Open Group"
Message-ID: <20210712084833.GA31700@localhost>
| That's not the only way. The usual traversal via .., ../.., etc. could
| be done, but just storing dev/ino pairs on the
Date:Mon, 5 Jul 2021 10:51:04 +0100
From:"Geoff Clare via austin-group-l at The Open Group"
Message-ID: <20210705095104.GA23845@localhost>
| As I said before, there is nothing in the standard that requires pwd
| to be written in C.
No issue with that,
| Nor
Date:Mon, 5 Jul 2021 09:33:32 +0100
From:"Geoff Clare via austin-group-l at The Open Group"
Message-ID: <20210705083332.GA21700@localhost>
| If we add both -s and -S and specify "last one wins",
That's what the NetBSD implementation does.
kre
Date:Mon, 05 Jul 2021 18:04:59 +0200
From:"Joerg Schilling via austin-group-l at The Open Group"
Message-ID: <20210705160459.e40cs%sch...@schily.net>
| How do you believe is -S related to what -s could probably do?
The -S under discussion is simply !-s (as -s is
Date:Thu, 8 Jul 2021 10:57:13 +0100
From:"Geoff Clare via austin-group-l at The Open Group"
Message-ID: <20210708095713.GA24532@localhost>
| As Vincent pointed out, you are misinterpreting the standard. "If an
| error is detected, output shall not be written to
Date:Fri, 2 Jul 2021 14:41:50 +0100
From:"Geoff Clare via austin-group-l at The Open Group"
Message-ID: <20210702134150.GB16587@localhost>
| I've always assumed that the intention for -c is to answer the
| question "if I ran this command without -c would the
Date:Thu, 04 Feb 2021 21:59:52 +0100
From:Steffen Nurpmeso
Message-ID: <20210204205952.fw6wv%stef...@sdaoden.eu>
| Ok, of course, but let me disagree with the latter. Bizarre rules
| and Bourne/Korn shell etc ... just look at ${aXb} and quoting
| rules within.
Date:Tue, 6 Apr 2021 14:23:35 +
From:"Austin Group Bug Tracker via austin-group-l at The Open
Group"
Message-ID:
| Another difference between BSD and GNU:
|
| BSD (macOS)
NetBSD grep is the same.
kre
Date:Fri, 19 Mar 2021 17:29:34 +
From:"Harald van Dijk via austin-group-l at The Open Group"
Message-ID: <84ab3a1c-6445-b73f-8ab2-a92d9fd3d...@gigawatt.nl>
| This is technically true, but if there is no conforming shell that
| implements 2.9.1 other than by
In note 5287 to bug 1460 (an innocuous change to the hash command)
( https://austingroupbugs.net/view.php?id=1460#c5287 )
Geoff said:
[...] that statement about PATH is pointing out a normative requirement
from XCU 2.9.1. In Issue 8 draft 1.1 it's on page 2292 line 74177:
Once a
Date:Thu, 18 Mar 2021 18:52:20 +
From:"Austin Group Bug Tracker via austin-group-l at The Open
Group"
Message-ID:
| A NOTE has been added to this issue.
| I also just noticed, that in the Application Usage section of hash, it
| says
[...]
If you saw
I just noticed (you really don't want to know the chain of
thought that got me here!) that when bug 1272 was applied,
some non-ideal language was added in the CHANGE HISTORY section
for Issue 8. (This is in XCU 2.14, Special Built-in Utilities
("colon") on page 2316 of draft 1.1 of issue 8)
Date:Mon, 12 Apr 2021 15:07:28 + (UTC)
From:shwaresyst
Message-ID: <1662152200.1116623.1618240048...@mail.yahoo.com>
| Then that is conformance bugs in those kernels,
Rubbish.
| in that files of this type are not load images exec() is to handle
There is no
Date:Sat, 10 Apr 2021 23:08:40 +0700
From:"Robert Elz via austin-group-l at The Open Group"
Message-ID: <20226.1618070...@jinx.noi.kre.to>
Now to add to something I said in the previous reply (so so the rest
of the audience here don't think I have
Date:Sat, 10 Apr 2021 11:54:34 +0200
From:"Jan Hafer via austin-group-l at The Open Group"
Message-ID: <15c15a5b-2808-3c14-7218-885e704cc...@rwth-aachen.de>
| my inquiry is a question about the potential unexpected behavior of the
| shell execution environment
Date:Sun, 11 Apr 2021 14:02:15 +0200
From:"Joerg Schilling via austin-group-l at The Open Group"
Message-ID: <20210411120215.wchk4%sch...@schily.net>
| If command -v should become able to do more, we would need to invent a
| way to execute _any_ utility
Date:Mon, 12 Apr 2021 18:42:03 +0100
From:Harald van Dijk
Message-ID:
| No, not anything. It still has to be shell start-up activity.
And your definition of what is a shell start-up activity comes from ?
| The starting a thread would be shell start-up
Date:Tue, 13 Apr 2021 10:16:26 +0100
From:Harald van Dijk
Message-ID: <7ab68758-b423-ae1b-4451-cd02c4b6b...@gigawatt.nl>
I think we have probably largely converged about this issue (with
Chet's assistance) so this will probably be my last message about it.
|
Date:Fri, 16 Apr 2021 09:43:25 +0100
From:"Geoff Clare via austin-group-l at The Open Group"
Message-ID: <20210416084325.GA32494@localhost>
| It would be best to submit a new bug against D1.1.
OK, will submit one when I am back at my
laptop rather than phone...
Date:Sun, 11 Apr 2021 17:04:05 +0100
From:Harald van Dijk
Message-ID: <92113e70-5605-10f4-8e57-47c9f64cd...@gigawatt.nl>
| This only applies when a remembered location exists at all, though.
Yes, but in the examples I showed, it did (you can see that from the
Date:Sun, 11 Apr 2021 13:25:46 +0100
From:Harald van Dijk
Message-ID:
| > My tests show that ksh, bash, yash, mksh do not find gcc in that case.
|
| Huh. My tests with ksh were with 93v, it's possible different versions
| behave differently.
I see the
Date:Sun, 11 Apr 2021 10:46:48 + (UTC)
From:shwaresyst
Message-ID: <1413127944.766378.1618138008...@mail.yahoo.com>
| That's bugs in those shells for POSIX mode then, that I see.
That's nonsense.
| The conforming behavior is /usr/gcc is found and succeeds
Date:Sun, 11 Apr 2021 22:27:19 +0100
From:Harald van Dijk
Message-ID: <79b98e30-46ba-d468-153f-c1a2a0416...@gigawatt.nl>
| Okay, but that is a technicality. The pre-seeding is only permitted at
| startup time,
No, what it says is "an unspecified shell
Date:Sun, 11 Apr 2021 19:46:36 +0100
From:Harald van Dijk
Message-ID: <9ab286f9-125d-55a4-a65f-08d4af04d...@gigawatt.nl>
| Sure, that's why I then switched to a different example that did not
| have an earlier "command -v" to point out how this leads to
Date:Sun, 11 Apr 2021 20:17:09 + (UTC)
From:shwaresyst
Message-ID: <1360977422.847706.1618172229...@mail.yahoo.com>
| We are talking about the shell, not some bastardization of execve(),
| that sees it's not a directly loadable process image so treats it as
Date:Fri, 05 Feb 2021 21:54:52 +0100
From:Steffen Nurpmeso
Message-ID: <20210205205452.7tbl2%stef...@sdaoden.eu>
| Well .. if i recall correctly quoting inside of ${xYz} has been
| clarified not too long ago
Not the way that you seem to think.
| |And last
Date:Sat, 06 Feb 2021 21:55:19 +0100
From:Steffen Nurpmeso
Message-ID: <20210206205519.43rln%stef...@sdaoden.eu>
| Fiddling with bytes is something completely different.
But how is the shell supposed to know?
Consider
U1=$'\u021c'
U2=$'\u0a47'
Date:Sun, 21 Feb 2021 18:11:23 +0100
From:"Joerg Schilling via austin-group-l at The Open Group"
Message-ID: <20210221171123._9r9e%sch...@schily.net>
| It would be interesting to know whether shells that accept
|
| case easac in
|
| esac) echo yes
Date:Fri, 19 Feb 2021 07:52:19 -0800
From:"Donn Terry via austin-group-l at The Open Group"
Message-ID:
| I agree with the existing-implementations policy, but making it clear
| that the committee was looking for an improvement (and setting some
| clear
Date:Fri, 19 Feb 2021 15:11:58 +
From:"Harald van Dijk via austin-group-l at The Open Group"
Message-ID: <4b4f2cbf-2a2e-f0bf-34ca-a7357f99c...@gigawatt.nl>
| Observe that rule 4 is applied for the first word in a pattern even if
| that pattern follows an
Date:Fri, 19 Feb 2021 14:30:25 -0500
From:Chet Ramey
Message-ID: <2b32112c-de72-c713-3f87-6840828c3...@case.edu>
| Nope, it's consistent with the standard.
I can understand that argument.
| that's not a fair reading of rule 4.
Whenever we need to rely upon
Date:Sat, 20 Feb 2021 00:56:34 +0700
From:"Robert Elz via austin-group-l at The Open Group"
Message-ID: <23942.1613757...@jinx.noi.kre.to>
Upon reflection:
| The statement "case foo in (esac" is valid according to the grammar,
perhaps
Date:Fri, 19 Feb 2021 18:13:09 +
From:"Harald van Dijk via austin-group-l at The Open Group"
Message-ID:
| The grammar only allows the '(' in a case_item or case_item_ns.
Yes. as you will have seen from my later reply (to my own message) I
realised that
Date:Fri, 3 Sep 2021 11:05:24 +0100
From:"Geoff Clare via austin-group-l at The Open Group"
Message-ID: <20210903100524.GA17338@localhost>
| If cmd is not a special built-in or a function, it is already
| explicitly unspecified.
Yes, I was actually more
Date:Wed, 1 Sep 2021 19:04:12 +0100
From:Harald van Dijk
Message-ID: <837d3b5b-ac61-98eb-2741-d667a78e2...@gigawatt.nl>
| $? is defined as "Expands to the decimal exit status of the most recent
| pipeline (see Pipelines)."
I suspect this is just a slightly more
First, just to avoid anyone wasting time by pointing it
out, to exchange the values of two variables in sh, the
following works, and is the safe way to do it
t=$a ; a=$b ; b=$t
(then unset t if you want).
But using multiple commands isn't always possible, eg:
without resorting to
Soon after posting it, I realised that the "=>"
followed by nothing in
https://www.austingroupbugs.net/view.php?id=1437#c5446 =>
is saying that that URL was changed to nothing, that is
as in there is currently no "Final Accepted Text"
That's fine, I understand now.
kre
| 2021-09-02 16:37 rhansenFinal Accepted Text
| https://www.austingroupbugs.net/view.php?id=1437#c5446 =>
| ==
I see that added today (well, yesterday, if timezones matter).
But should that be note 5446 as
Date:Wed, 1 Sep 2021 16:38:00 +0300
From:"=?UTF-8?B?T8SfdXo=?= via austin-group-l at The Open Group"
Message-ID:
| true
| a=$? b=`exit 1` b=$? >`echo /dev/null; exit 2`
| echo $? $a $b
| Now, I wonder, what did I miss?
That $? (the exit status) is
Date:Wed, 1 Sep 2021 19:04:12 +0100
From:Harald van Dijk
Message-ID: <837d3b5b-ac61-98eb-2741-d667a78e2...@gigawatt.nl>
| Is there any statement that overrides the general definition to
| explicitly make this unspecified? If not, the general definition applies
Date:Fri, 10 Sep 2021 12:14:01 +0100
From:"Geoff Clare via austin-group-l at The Open Group"
Message-ID: <20210910111401.GA791@localhost>
| I have changed it to .
That's fine, thanks.
kre
Date:Fri, 10 Sep 2021 08:41:31 +
From:"Austin Group Bug Tracker via austin-group-l at The Open
Group"
Message-ID: <2b9815f52cb2fe2472beb407a5ddd...@austingroupbugs.net>
| I have updated the desired action to fix the problems noted in
|
I gather that it is likely that the work on gettext is going to
want to add support for the "pick an argument" printf conversion
type (%n$) of conversions that are defined currently in XSH for
the printf family of interfaces, but isn't defined in XCU printf.
That's probably a good idea, but I
Date:Fri, 10 Sep 2021 21:43:32 +0300
From:=?UTF-8?B?T8SfdXo=?=
Message-ID:
| Wouldn't it be more useful if, in printf(1), `n' in `%n$' referred to the
| nth argument in the current set of arguments being processed?
That's what it does in current
1 - 100 of 251 matches
Mail list logo
