On 2/4/20 9:29 AM, Eric Blake wrote:
On 2/4/20 9:16 AM, Robert Elz wrote:
I am putting this in a new thread, as it isn't really important,
more just amusing, but the solution to this issue, with respect
to the "." command, is I think, causing that command to be in
violation of the standard (in
Date:Tue, 4 Feb 2020 16:45:23 + (UTC)
From:Shware Systems
Message-ID: <738169782.299418.1580834723...@mail.yahoo.com>
| Many do feel as you do from a theoretical standpoint, that zero has no sign
That's not quite the representation, it is that it is neither
A NOTE has been added to this issue.
==
https://austingroupbugs.net/view.php?id=252
==
Reported By:eblake
Assigned To:ajosey
I have, it is you that hasn't, so I feel no embarrassment at all. It doesn't
matter how much you want to hold on to your irrelevant misunderstanding of it,
either, what does is the phrasing in Section 6. I said there are multiple ways
the phrase is construed in academia, which means it's a
I am putting this in a new thread, as it isn't really important,
more just amusing, but the solution to this issue, with respect
to the "." command, is I think, causing that command to be in
violation of the standard (in a completely different way than what
the previous discussion is about).
The
A NOTE has been added to this issue.
==
https://austingroupbugs.net/view.php?id=252
==
Reported By:eblake
Assigned To:ajosey
On 2/4/20 9:16 AM, Robert Elz wrote:
I am putting this in a new thread, as it isn't really important,
more just amusing, but the solution to this issue, with respect
to the "." command, is I think, causing that command to be in
violation of the standard (in a completely different way than what
2020-02-04 19:56:05 +0700, Robert Elz:
[...]
> What I am at the very least unclear about, is that the way that this
> group chose to require "--" processing, appears to me to also require
> that any arg (before that "--" or an arg not starting with "-") which
> does start with "-" be treated as an
Shware Systems wrote, on 03 Feb 2020:
>>
>> On Monday, February 3, 2020 Geoff Clare wrote:
>> Shware Systems wrote, on 03 Feb 2020:
>> >
>> >> C99 only specifies the behaviour of raise() and signal() for SIGABRT,
>> >> SIGFPE, SIGILL, SIGINT, SIGSEGV, and SIGTERM. The behaviour for all
>> >>
The following issue has been SUBMITTED.
==
https://austingroupbugs.net/view.php?id=1322
==
Reported By:andras_farkas
Assigned To:
Schwarz, Konrad wrote, on 04 Feb 2020:
>
> I would often like to pass arguments to dot, like so,
>
> . ./myscript arg1 arg2 ...
>
> temporarily setting $0 $1 $2 ..., similar to shell functions.
>
> Currently, this is not permitted by POSIX.
It's an allowed extension. It is even
Date:Tue, 4 Feb 2020 07:58:43 -0600
From:Eric Blake
Message-ID: <4e4b95da-9e30-5e55-faa9-58be84ed8...@redhat.com>
| Implementations are allowed to provide any number of options as extensions.
Sure, that's not an issue.
| No, the standard still leaves plenty of
> -Original Message-
> From: Robert Elz
> Sent: Tuesday, February 4, 2020 1:56 PM
> To: Steffen Nurpmeso
> Cc: austin-group-l@opengroup.org
> Subject: Re: [1003.1(2008)/Issue 7 252]: dot should follow Utility Syntax
> Guidelines
>
> What I am at the very least unclear about, is
On 2/4/20 6:56 AM, Robert Elz wrote:
What I am at the very least unclear about, is that the way that this
group chose to require "--" processing, appears to me to also require
that any arg (before that "--" or an arg not starting with "-") which
does start with "-" be treated as an option -
Date:Mon, 03 Feb 2020 23:46:26 +0100
From:Steffen Nurpmeso
Message-ID: <20200203224626.fhclq%stef...@sdaoden.eu>
| I see, after having read the issue, it was from 2010.
Yes, I only noticed it when I saw the message saying that the resolution
(from way back then)
15 matches
Mail list logo
