> On Sep 8, 2021, at 2:03 PM, Joerg Schilling via austin-group-l at The Open
> Group wrote:
>
> "David A. Wheeler via austin-group-l at The Open Group"
> wrote:
>
>>
>>> On Sep 8, 2021, at 1:06 PM, Joerg Schilling via austin-group-l at The Open
>>> Group wrote:
>>> Hasn't it been
"David A. Wheeler via austin-group-l at The Open Group"
wrote:
>
> > On Sep 8, 2021, at 1:06 PM, Joerg Schilling via austin-group-l at The Open
> > Group wrote:
> > Hasn't it been explained many times that the non-orthogonal behavior of
> > gmake
> > for the += operator for macros created
> On Sep 8, 2021, at 1:06 PM, Joerg Schilling via austin-group-l at The Open
> Group wrote:
> Hasn't it been explained many times that the non-orthogonal behavior of gmake
> for the += operator for macros created with the gmake := operator is a source
> of unpredictable behavior, in special
"Paul Smith via austin-group-l at The Open Group"
wrote:
> I asked for examples, or explanations of situations, where using the
> POSIX ::= operator as currently defined isn't sufficient, and the
> different behavior of the :::= operator is required instead.
Hasn't it been explained many times
On Wed, 2021-09-08 at 17:13 +0200, sch...@schily.net wrote:
> That as introduced by accident, because I did not realize at that
> time that gmake used an icompatible implementation that differs from
> smake and BSD make.
I don't see how it can be possible that there was any confusion about
this.
"David A. Wheeler" wrote:
> > That as introduced by accident, because I did not realize at that time that
> > gmake used an icompatible implementation that differs from smake and BSD
> > make.
>
> That?s an unfortunate bug but easily fixed. It *is* specifically noted in the
> Rationale :-).
Date:Wed, 8 Sep 2021 09:09:35 +0100
From:"Geoff Clare via austin-group-l at The Open Group"
Message-ID: <20210908080935.GA26035@localhost>
| yash's creator(s) are right that a newline cannot occur within a line.
| The definition of "line" in XBD chapter 3 is "A
Date:Wed, 8 Sep 2021 11:51:27 +0100
From:Harald van Dijk
Message-ID: <84fcabec-16f2-3bd2-0871-cefe53455...@gigawatt.nl>
| Only speaking for gwsh, but yes, I consider this is a bug and will make
| sure to fix it.
Yes, it is a bug. I just fixed it for the NetBSD
> On Sep 8, 2021, at 11:13 AM, Joerg Schilling via austin-group-l at The Open
> Group wrote:
>
> "David A. Wheeler via austin-group-l at The Open Group"
> wrote:
>
>> I agree with Paul Smith. This was agreed on 8 years ago, and the widely-used
>> GNU make has
>> supported ::= as immediate
"Paul Smith via austin-group-l at The Open Group"
wrote:
> On Wed, 2021-09-08 at 11:10 +0200, Joerg Schilling via austin-group-l
> at The Open Group wrote:
> > The :::= operator has been implemented in two independent make
> > programs before it was standardized.
> >
> > The :::= operator was
"David A. Wheeler via austin-group-l at The Open Group"
wrote:
> I agree with Paul Smith. This was agreed on 8 years ago, and the widely-used
> GNU make has
> supported ::= as immediate expansion since 2013. That?s strong precedence.
> See the discussion here:
>
On Wed, 2021-09-08 at 11:10 +0200, Joerg Schilling via austin-group-l
at The Open Group wrote:
> The :::= operator has been implemented in two independent make
> programs before it was standardized.
>
> The :::= operator was introduced to smake and SunPro Make in March.
I can't consider this a
On Sep 8, 2021, at 9:53 AM, Paul Smith via austin-group-l at The Open Group
wrote:
> No, that's not right. In issue 7 there is no way to have any sort of
> immediate expansion in standard make. That's clearly something that
> users wanted (for the record note that I was not the one who wanted
On Wed, 2021-09-08 at 09:29 +0100, Geoff Clare via austin-group-l at
The Open Group wrote:
> Personally I see no reason to prefer one over the other. This leads
> to three choices for what goes in Issue 8:
>
> 1. Just an operator that works like gmake :=
> 2. Just an operator that works like BSD
8 Eylül 2021 Çarşamba tarihinde Harald van Dijk yazdı:
> On 08/09/2021 08:15, Oğuz via austin-group-l at The Open Group wrote:
>
>> Sorry for butting in, but according to the standard, is there really a
>> syntax error in the following?
>>
>> sh -c ': << do | for x in xxx
>> do
>> do echo $x
>>
On 08/09/2021 08:15, Oğuz via austin-group-l at The Open Group wrote:
Sorry for butting in, but according to the standard, is there really a
syntax error in the following?
sh -c ': << do | for x in xxx
do
do echo $x
done'
busybox sh, dash, gwsh, netbsd sh, and freebsd sh complain about a
"O?uz via austin-group-l at The Open Group"
wrote:
> Sorry for butting in, but according to the standard, is there really a
> syntax error in the following?
>
> sh -c ': << do | for x in xxx
> do
> do echo $x
> done'
>
> busybox sh, dash, gwsh, netbsd sh, and freebsd sh complain about a
>
"Paul Smith 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 BSD make has a
> different operator that works in this same way but that's not the same
> thing: no existing
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
Sorry for butting in, but according to the standard, is there really a
syntax error in the following?
sh -c ': << do | for x in xxx
do
do echo $x
done'
busybox sh, dash, gwsh, netbsd sh, and freebsd sh complain about a
missing `done'.
21 matches
Mail list logo
