Steffen Nurpmeso wrote, on 01 Sep 2020:
>
> |Do the existing implementations ever return such things? Do they
> |hide them by making the reclen of the previous entry (if there is
> |one in the buffer) bigger, or do they squash them out, moving the
> |next existing entry down to follow
Wojtek Lerch wrote, on 01 Sep 2020:
>
> Geoff Clare wrote:
> > We can't require d_name in struct dirent to be a VLA since there are
> > implementations where it is not.
>
> Another good reason is that standard C does not allow structure members to be
> VLAs.
Mea culpa. I tried to save some
Philip Guenther wrote, on 01 Sep 2020:
>
> If a posix_getdents() implementation returned the names of all the files
> that ever existed in the given directory, including ones that were removed
> before the fd for this call was opened, what requirement in the standard
> would that violate? I don't
Per Mildner wrote, on 30 Aug 2020:
>
> The posix_getdents() function shall ... place ... posix_dent structures in
> the buffer pointed to by buf up to a maximum of nbyte bytes"
> "The array d_name ... shall contain a filename of at most {NAME_MAX} bytes
> followed by a terminating null byte."
Robert Elz wrote, on 09 Sep 2020:
>
> Date:Tue, 8 Sep 2020 17:11:16 +0100
> From: "Geoff Clare via austin-group-l at The Open Group"
>
>
> | Initially I had assumed (from the Solaris man page) that sig2str()
> | only translate
Robert Elz wrote, on 09 Sep 2020:
>
> ps: this new e-mail encapsulation is still inserting bogus Reply-To headers
> that request replies go only to the sender of the message ... one of the
> messages I sent you (Geoff) earlier (I have forgotten what it was about)
> was actually intended for the
to those on the offtopic list.)
Robert Elz wrote, on 10 Sep 2020:
>
> Date:Thu, 10 Sep 2020 09:32:03 +0100
> From:"Geoff Clare via austin-group-l at The Open Group"
>
>
> | Yes. The last sentence. It clearly implies that the address in the
>
Robert Elz wrote, on 09 Sep 2020:
>
> And thanks for the tutorial on how to use e-mail - but my e-mail client
> doesn't have a "reply all" function, I don't want it to, the notion of
> just "reply" vs "reply all" is absurdly simplistic. What I have is "reply"
> which by default replies to the
> --
> (0004976) kre (reporter) - 2020-09-08 15:32
> https://www.austingroupbugs.net/view.php?id=1138#c4976
> --
> Re:
Robert Elz wrote, on 10 Sep 2020:
>
> | The Reply-To header is used to indicate where the author prefers to
> | have replies sent *instead of the address in the From header*.
>
> From where do you obtain that idea?
>
> What RFC5322 says on this is:
>
>The originator fields also provide
Robert Elz wrote, on 10 Sep 2020:
>
... a hugely long email that I have neither the time nor the energy to
reply to point by point. Most of it constitutes an attempt to reverse
a decision that has already been made in a teleconference - that we
will standardise sig2str() and str2sig() as
Mark Harris wrote, on 12 Sep 2020:
>
> > | Solaris uses "Reply-To:" to replace just "From:"
> > | (although it has "R" and "r" the wrong way round!)
>
> This is controlled by the POSIX-standard mailx variable "flipr". It
> can be set system-wide (/etc/mail.rc) or per-user ($HOME/.mailrc).
n Tuesday, September 1, 2020 Geoff Clare via austin-group-l at The Open
> Group wrote:
> Per Mildner wrote, on 30 Aug 2020:
> >
> > The posix_getdents() function shall ... place ... posix_dent structures in
> > the buffer pointed to by buf up to a maximum of nbyte bytes"
> --
> (0004953) philip-guenther (reporter) - 2020-08-28 22:52
> https://www.austingroupbugs.net/view.php?id=697#c4953
> --
> I think the unspecified nature
> --
> (0004958) philip-guenther (reporter) - 2020-08-30 23:06
> https://austingroupbugs.net/view.php?id=697#c4958
> --
> The proposed text includes:
>
> --
> (0004949) kre (reporter) - 2020-08-28 17:52
> https://www.austingroupbugs.net/view.php?id=697#c4949
> --
> I suspect that the intent of all of this is
> --
> (0005036) shware_systems (reporter) - 2020-10-07 14:28
> https://austingroupbugs.net/view.php?id=697#c5036
> --
> That is an error in read(), and
Wojtek Lerch wrote, on 07 Oct 2020:
>
> Geoff Clare wrote:
> > For fread(), the return type is size_t not ssize_t, so it doesn't
> > have quite the same problem. The question is what should happen if
> > the mathematical product of the size and nitems arguments is greater
> > than SIZE_MAX. POSIX
Geoff Clare wrote, on 19 Aug 2020:
>
> > --
> > (0004926) geoffclare (manager) - 2020-08-19 09:22
> > https://austingroupbugs.net/view.php?id=1392#c4926
> >
> --
> (0004926) geoffclare (manager) - 2020-08-19 09:22
> https://austingroupbugs.net/view.php?id=1392#c4926
> --
> I think we should issue a "standard is
Steffen Nurpmeso wrote, on 29 Sep 2020:
>
> |Do you know of an implementation that de-dups across header fields?
>
> Mine.
Is that a recent change? It's not what I see with s-nail v14.9.11 on
a Debian system when using 'r' on a message with these headers:
From: aut...@example.com
To:
> --
> (0005005) kre (reporter) - 2020-09-28 14:16
> https://www.austingroupbugs.net/view.php?id=1401#c5005
> --
> Re
Steffen Nurpmeso wrote, on 29 Sep 2020:
>
> The vaporisation of address lists happens after the compose-mode is left:
> P.S.: and this is because alias expansion, hooks
> (*on-compose-leave* plus, which can use `digmsg' to edit the
> message), automatic receivers (*autocc*, *autobcc*) as well as
Playing around with export and readonly in shells that support array
assignments, it's clear that they are treating them as separate tokens
in the grammar in order to accept array assignment syntax:
$ bash -c 'export a=(1 2 3); echo ${a[0]}'
1
$ bash -c 'e=export; $e a=(1 2 3); echo
> --
> (0005005) kre (reporter) - 2020-09-28 14:16
> https://www.austingroupbugs.net/view.php?id=1401#c5005
> --
[...]
> It may also be worth considering
Geoff Clare wrote, on 14 Sep 2020:
>
> Mark Harris wrote, on 12 Sep 2020:
> >
> > > | Solaris uses "Reply-To:" to replace just "From:"
> > > | (although it has "R" and "r" the wrong way round!)
> >
> > This is controlled by the POSIX-standard mailx variable "flipr". It
> > can be set
Robert Elz wrote, on 24 Oct 2020:
>
> 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
Harald van Dijk wrote, on 31 Jul 2020:
>
> Take the previous example glibc's cy_GB.UTF-8 locale, but with a different
> collating element: in this locale, "dd" is a single collating element too.
> Therefore, this must be matchable by bracket expressions.
Incorrect.
I think you overlooked these
Steffen Nurpmeso wrote, on 05 Aug 2020:
>
> Michael Kerrisk via austin-group-l at The Open Group wrote in
> :
> |Elliot Hughes and I both noticed a point from "Minutes of the 3rd August \
> |2020
> |Teleconference":
> ..
> |On Tue, Aug 4, 2020 at 5:52 PM Andrew Josey wrote:
> ...
> |> *
shwaresyst wrote, on 05 Aug 2020:
>
> On Wednesday, August 5, 2020 Geoff Clare via austin-group-l at The Open Group
> wrote:
>
>> My own thoughts up to now had been that, since the slave side is the
>> side that is intended to be used as a terminal in the normal
casper@oracle.com wrote, on 10 Dec 2020:
>
> I noticed after recently that the ps(1) manual pages lists the
> following:
>
> TTY (all) The controlling terminal for the process.
>
> However, later when the "-o" options are listed, the tty option is
> listed with the header "TT".
>
> Was
Robert Elz wrote, on 10 Dec 2020:
>
> This has been discussed (somewhere) before
It was discussed on this list and resulted in bug 1157 (which was
applied in Issue 8 draft 1).
--
Geoff Clare
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
Steffen Nurpmeso wrote, on 11 Dec 2020:
>
> Geoff Clare wrote in
> <20201211100245.GA1627@localhost>:
> |Steffen Nurpmeso wrote, on 10 Dec 2020:
> |>
> |> While talking about iconv, i got closed glibc bug[1] as "resolved
> |> invalid", but wouldn't you all agree that in the following
> |>
>
Thorsten Glaser wrote, on 12 Dec 2020:
>
> Geoff Clare via austin-group-l at The Open Group dixit:
>
> >since the standard requires the POSIX locale to have 256 valid
> >single-byte characters.
>
> WTF, how is *that* supposed to be implemented?
>
> I guess I
Steffen Nurpmeso wrote, on 10 Dec 2020:
>
> While talking about iconv, i got closed glibc bug[1] as "resolved
> invalid", but wouldn't you all agree that in the following
>
> #include
> #include
> #include
> #include
> int main(void){
> char inb[16], oub[16], *inbp, *oubp;
>
Joerg Schilling wrote, on 09 Nov 2020:
>
> Geoff Clare via austin-group-l at The Open Group
> wrote:
>
> > Paul Smith wrote, on 07 Nov 2020:
> > >
> > > Unless we are proposing pattern rules for inclusion in POSIX, [...]
> >
> > This was
Jilles Tjoelker wrote, on 13 Nov 2020:
>
> On Mon, Nov 09, 2020 at 03:07:43PM +, Geoff Clare via austin-group-l
> at The Open Group wrote:
> > The ksh and bash behaviour of reporting multiple values seems more
> > useful to me, but I wouldn't object if others want to make
Chet Ramey wrote, on 16 Nov 2020:
>
> > Thanks. Looks like bash is parsing the ulimit options in an unusual
> > way instead of using getopt() or similar.
>
> Quite the opposite. The bash ulimit builtin uses the same internal_getopt
> code as the rest of the builtins, with the addition that
Jilles Tjoelker wrote, on 17 Nov 2020:
>
> On Tue, Nov 17, 2020 at 03:14:43PM +, Geoff Clare via austin-group-l
> at The Open Group wrote:
> > Or I could just go with my original suggestion of adding:
>
> > Conforming applications shall specif
Robert Elz wrote, on 18 Nov 2020:
>
> There is another case not yet considered:
>
> ulimit -n -n
>
> The shells that only allow a single option and report whatever was
> requested last just act the same way for that one as they do when the
> two options selected differ - process whatever
Chet Ramey wrote, on 16 Nov 2020:
>
> On 11/16/20 11:05 AM, Geoff Clare via austin-group-l at The Open Group wrote:
> > Chet Ramey wrote, on 16 Nov 2020:
> > >
> > > > Thanks. Looks like bash is parsing the ulimit options in an unusual
> > >
Chet Ramey wrote, on 17 Nov 2020:
>
> One consequence of the POSIX description is, as I said above, that it
> restricts each invocation to modifying one limit. That's how it can finesse
> the `newlimit is an operand'. I'm not going to reduce functionality and
> throw away backwards compatibility
Chet Ramey wrote, on 17 Nov 2020:
>
> On 11/17/20 10:14 AM, Geoff Clare via austin-group-l at The Open Group wrote:
>
> > Maybe you could handle those by seeing that the option argument is
> > alphabetic (and not "unlimited") and treating it as a string of
> >
> --
> (0005108) nick (manager) - 2020-11-08 23:42
> https://austingroupbugs.net/view.php?id=1302#c5108
> --
> The following issue was pointed out by Hubert
Paul Smith wrote, on 07 Nov 2020:
>
> Unless we are proposing pattern rules for inclusion in POSIX, [...]
This was proposed in 2011 in bug 513, which is still open.
--
Geoff Clare
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
Robert Elz wrote, on 09 Nov 2020:
>
> 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
Vincent Lefevre wrote, on 11 Nov 2020:
>
> On 2020-11-09 09:39:25 +, Geoff Clare via austin-group-l at The Open
> Group wrote:
> > I believe this is a misuse of "negative". The RETURN VALUE section
> > says "For finite values of x < 0, and finite non-
Joerg Schilling wrote, on 31 Oct 2020:
>
> Well this is true. As long as POSIX does not mention parallel builds at all,
> it makes no sense for .WAIT to appear in a POSIX standard - except as a
> reserved special target.
It's already in the reserved namespace, so no need to reserve it
> --
> (0005096) psmith (developer) - 2020-11-03 15:31
> https://austingroupbugs.net/view.php?id=1325#c5096
> --
> Apropos of the example given here: I just
Geoff Clare wrote, on 04 Nov 2020:
>
> > > If a target rule or inference rule for the pathname has been parsed
> > > before the include line is parsed, make shall use the rule to attempt
> > > to create the file or to bring it up-to-date.
> >
> > I don't think this is quite correct. In GNU make,
Paul Smith wrote, on 04 Nov 2020:
>
> On Wed, 2020-11-04 at 16:47 +, Geoff Clare via austin-group-l at
> The Open Group wrote:
> > Here's a modified version of the proposed example that uses this new
> > technique. Note that you have to use "make -r" otherwi
Joerg Schilling wrote, on 05 Nov 2020:
>
> Geoff Clare via austin-group-l at The Open Group
> wrote:
>
> > The make utility shall use one of the following two methods
> > to attempt to create the file or bring it up-to-date:
> >
> >
Paul Smith wrote, on 04 Nov 2020:
>
> On Wed, 2020-11-04 at 10:48 +, Geoff Clare via austin-group-l at
> The Open Group wrote:
> > The aim here was to describe the cut-off-point where all include file
> > generation has been completed and after which the new contents of
Paul Smith wrote, on 05 Nov 2020:
>
> On Thu, 2020-11-05 at 09:57 +, Geoff Clare via austin-group-l at
> The Open Group wrote:
> > > > The aim here was to describe the cut-off-point where all include
> > > > file generation has been completed and aft
Paul Smith wrote, on 05 Nov 2020:
>
> On Thu, 2020-11-05 at 09:25 +, Geoff Clare via austin-group-l at
> The Open Group wrote:
> > > .SUFFIXES:
> > > .SUFFIXES: .c .i .o
> The order in which suffix rules are found depends on the order in which
>
> --
> (0005094) psmith (developer) - 2020-11-03 15:23
> https://austingroupbugs.net/view.php?id=1325#c5094
> --
> Thank you for all your effort Geoff! I
Martijn Dekker wrote, on 09 Jan 2021:
>
> Op 23-09-20 om 15:11 schreef Geoff Clare via austin-group-l at The Open
> Group:
> >
> > In order to make "command export ..." and "command readonly ..."
> > work the same, all that's necessary is for those
Jilles Tjoelker wrote, on 24 May 2021:
>
> On Tue, May 04, 2021 at 01:07:39AM +0200, Bruno Haible via
> austin-group-l at The Open Group wrote:
> > https://posix.rhansen.org/p/gettext_split
> > says (line 92):
>
> > "The returned string may be invalidated by a subsequent call to
> >
Stephane Chazelas wrote, on 04 Jul 2021:
>
> That's even more justification for adding -s to the standard
> though so people can at least choose to get a stable sort
> portably. -S could probably be added as well, but I don't think
> it wise to make the default behaviour unspecified.
If we add
Robert Elz wrote, on 05 Jul 2021:
>
> 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 precondit
Robert Elz wrote, on 07 Jul 2021:
>
> 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 noth
Stephane Chazelas wrote, on 01 Jul 2021:
>
> BTW, for "expr", what is "zero" meant to be?
>
> I see some variation in behaviour for "00", " 0", "-0", "+0",
> $'\r0', which some (but not all) also treat as zero.
> Also 0,000 or 0,000,000 in locales where "," is a thousand
> separator with
Stephane Chazelas wrote, on 02 Jul 2021:
>
> Is:
>
> printf '%s\n' a,b a,a | sort -c -t, -k1,1
>
> Meant to succeed or not?
>
> It fails in GNU, busybox, OpenBSD, FreeBSD, Solaris, though with a
> confusing:
>
> sort: -:2: disorder: a,a
>
> diagnostic and succeeds in NetBSD.
>
> It succeeds
Stephane Chazelas wrote, on 02 Jul 2021:
>
> btw, it seems to me -C should be referenced in the EXIT STATUS
> section and in the -u description like for -c.
Yes, also in STDOUT.
--
Geoff Clare
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
Vincent Lefevre wrote, on 02 Jul 2021:
>
> On 2021-07-02 09:31:11 +0100, Geoff Clare via austin-group-l at The Open
> Group wrote:
> > I would say the standard is unclear. To me the most reasonable
> > interpretation of "The expression evaluates to null or zero
Vincent Lefevre wrote, on 02 Jul 2021:
>
> On 2021-07-02 14:30:44 +0100, Geoff Clare via austin-group-l at The Open
> Group wrote:
> > > With busybox expr (version 1.30.1), I get:
> > >
> > > $ busybox expr 0 ; echo $?
> > > 0
> > >
Joerg Schilling wrote, on 02 Jul 2021:
>
> > > > sort: -:2: disorder: a,a
> > >
> > > Try to use the POSIX sort variant to avoid the message.
> > [...]
> >
> > I suppose you mean the -C option, which
> > still checks but doesn't output a diagnostics message.
>
> No, I was referring to
Robert Elz wrote, on 29 Jun 2021:
>
> 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 sa
Stephane Chazelas wrote, on 01 Jul 2021:
>
> 2021-07-01 11:45:40 +0100, Geoff Clare via austin-group-l at The Open Group:
>
> > The GNU implementations (including bash builtins) of the POSIX utilities
> > do it right. Of course, I don't know whether they were alr
Robert Elz wrote, on 28 Jun 2021:
>
> 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 utilit
tg...@mirbsd.org wrote, on 27 Jun 2021:
>
> Don Cragun via austin-group-l at The Open Group dixit:
>
> > • When an unrecoverable error condition is
> > encountered, the utility shall exit with a
> > non-zero exit status.
>
> Is “pwd >/dev/full” an “unrecoverable error condition”
tg...@mirbsd.org wrote, on 28 Jun 2021:
>
> Stephane Chazelas via austin-group-l at The Open Group dixit:
>
> >2021-06-28 20:01:03 +0700, Robert Elz:
> >[...]
>
> I see significant support here for my interpretation of this.
I suspect it is a vocal minority, and the vast majority of members
of
Robert Elz wrote, on 28 Jun 2021:
>
> austin-group-l@opengroup.org (really Geoff Clare) said:
> | The error occurred, and because of it the utility did not do what it is
> | supposed to do.
>
> That's debatable. The outcome was not what was desired, but the utility
> did exactly what was
Robert Elz wrote, on 09 Jul 2021:
>
> | The whole
> | point of that bit of rationale is that pwd should not write each
> | component of the pathname individually as it works them out;
>
> You'd think so, but that doesn't make a lot of sense, as if the code
> is obtaining the path component
Joerg Schilling wrote, on 05 Jul 2021:
>
> "Robert Elz via austin-group-l at The Open Group"
> wrote:
>
> > Date:Mon, 05 Jul 2021 18:04:59 +0200
> > From:"Joerg Schilling via austin-group-l at The Open Group"
> >
> > Message-ID:
Joerg Schilling wrote, on 06 Jul 2021:
>
> "Geoff Clare via austin-group-l at The Open Group"
> wrote:
>
> > > If you like to disable -s, better use +s
> >
> > That wouldn't be suitable for standardisation as it doesn't follow
> > syntax guidel
Oğuz wrote, on 25 Apr 2021:
>
> On Sat, Apr 24, 2021 at 6:22 PM Austin Group Bug Tracker via
> austin-group-l at The Open Group wrote:
> > $ echo 'x,,z' | awk -F'[^,]*' '{for (i=1;i<=NF;i++) print i, "<"$i">"}'
> > 1 <>
> > 2 <,,>
> > 3 <>
>
> This seems rather like an implementation bug.
Robert Elz wrote, on 20 Mar 2021:
>
> 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
Robert Elz wrote, on 16 Apr 2021:
>
> Austin Group Defect 1272 is applied, clarifying that the null utility
>does not expand its arguments,
>does not recognize the "--" end-of-options delimiter,
>does not support any options,
>and does not write to standard error.
>
Harald van Dijk wrote, on 21 Feb 2021:
>
> On 19/02/2021 16:21, Geoff Clare via austin-group-l at The Open Group wrote:
> > It may be prudent to clarify matters by rearranging things in the
> > grammar so that it ends up saying "Do not apply rule 4" when a '('
> >
Harald van Dijk wrote, on 19 Feb 2021:
>
> On 19/02/2021 09:59, Geoff Clare via austin-group-l at The Open Group wrote:
> > How about changing that problem sentence in 2.10.1 to:
> >
> > When a TOKEN is seen where one of those annotated productions could
> >
> --
> (0005246) kre (reporter) - 2021-02-18 10:32
> https://www.austingroupbugs.net/view.php?id=1454#c5246
> --
> Re
Harald van Dijk wrote, on 19 Feb 2021:
>
> On 19/02/2021 15:04, Geoff Clare via austin-group-l at The Open Group wrote:
> > Harald van Dijk wrote, on 19 Feb 2021:
> > >
> > > On 19/02/2021 09:59, Geoff Clare via austin-group-l at The Open Group
> >
Chet Ramey wrote, on 19 Feb 2021:
>
> On 2/19/21 10:33 AM, Geoff Clare via austin-group-l at The Open Group wrote:
>
> > > Observe that rule 4 is applied for the first word in a pattern even if
> > > that
> > > pattern follows an opening parenth
Harald van Dijk wrote, on 19 Feb 2021:
>
> On 19/02/2021 15:33, Geoff Clare via austin-group-l at The Open Group wrote:
> > Harald van Dijk wrote, on 19 Feb 2021:
> > >
> > > On 19/02/2021 15:04, Geoff Clare via austin-group-l at The Open Group
> > > wrot
Harald van Dijk wrote, on 01 Sep 2021:
>
> The second problem is the redirection. Based on the above, command
> substitutions in a redirection are supposed to affect the exit status just
> as any other command substitution, but the standard says:
>
> 3. Redirections shall be performed as
Robert Elz wrote, on 07 Sep 2021:
>
> | But, as I mentioned above, if the shell looks for the delimiter before
> | it removes instead of after, it will get this
> | case wrong:
> |
> | $ cat < | > foo\
> | > EOF
> | > EOF
> | fooEOF
> | $
>
> Sure: From the NetBSD sh
Paul Smith wrote, on 07 Sep 2021:
>
> On Thu, 2021-08-12 at 15:19 +, Austin Group Bug Tracker wrote:
> > A NOTE has been added to this issue.
> > ==
> > https://austingroupbugs.net/view.php?id=1471
> >
Paul Smith wrote, on 08 Sep 2021:
>
> On Wed, 2021-09-08 at 09:29 +0100, Geoff Clare via austin-group-l at
> The Open Group wrote:
>
> > > But here we're inventing an entirely new operator that NO VERSION
> > > of make currently implements (yes, I understand that
Robert Elz wrote, on 10 Sep 2021:
>
> However, you also deleted the \ between the and the - that one
> should be replaced if possible ( \ not just ).
Oops. I assumed the \ was there to try to prevent the < from being taken
as an HTML tag, but I now see from the context you intended a backslash
Paul Smith wrote, on 08 Sep 2021:
>
> On Tue, 2021-09-07 at 18:30 -0700, Nick Stoughton wrote:
> > The problem we were trying to address with this change is that
> > bsd make (bmake) and GNU make both have a := operator, but they
> > behave differently. We originally added ::= to match the gmake
>
Robert Elz wrote, on 08 Sep 2021:
>
> That's where the null string end delimiter I mentioned last time came
> from, "" is a shell word (even after quote removal). But it turns out
> that wasn't the example I really wanted to use (that's too easy a case
> to get right). The one I wanted was
Robert Elz wrote, on 06 Sep 2021:
>
> | Which ones do it the other way? All the shells I tried (bash, dash,
> ksh88,
> | ksh93, mksh) do it "right".
>
> FreeBSD (or at least the slightly old version I have to test) and NetBSD:
>
> sh $ a=foo; b=bar; a=$b b=$a; echo $a$b
> barfoo
> sh $
Robert Elz wrote, on 03 Sep 2021:
>
> if one wants to do
>
> a=$b b=$a cmd
>
> is there any way to make that do what is expected (or perhaps hoped),
> that can be relied upon to work?
>
> That is is one of the following actually specified to work?
>
> a=$b b=$a
> ort=$a a=$b
Robert Elz wrote, on 12 Jul 2021:
>
> 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>
>
> | Together these things constit
Robert Elz wrote, on 13 Jul 2021:
>
> Date:Tue, 13 Jul 2021 10:18:02 +0100
> From: "Geoff Clare via austin-group-l at The Open Group"
>
> Message-ID: <20210713091802.GA28355@localhost>
>
> Let's rearrange the order of this to mak
[Catching up after a few days' vacation]
Robert Elz wrote, on 25 Jul 2021:
>
> Date:Thu, 15 Jul 2021 10:19:17 +0100
> From: "Geoff Clare via austin-group-l at The Open Group"
>
> Message-ID: <20210715091917.GA13523@localhost>
>
These are the draft minutes from yesterday's call. Andrew will need
to allocate the Austin- document number and add the file to the
document register after he returns.
Regards,
Geoff.
--
Minutes of the 29th July 2021 Teleconference
Robert Elz wrote, on 30 Jul 2021:
>
> Date:Thu, 29 Jul 2021 10:38:25 +0100
> From: "Geoff Clare via austin-group-l at The Open Group"
>
> Message-ID: <20210729093825.GA7847@localhost>
>
> | Therefore, in the case of pwd,
> --
> (0005502) kre (reporter) - 2021-10-10 23:51
> https://austingroupbugs.net/view.php?id=1524#c5502
> --
> While not directly related to this bug, it is
1 - 100 of 265 matches
Mail list logo
