"Don Cragun via austin-group-l at The Open Group"
wrote:
> I think you're confusing the requirements for printf and echo. The standard
> echo is not allowed to accept options. The standard printf does not define
> any options, but allows them as implementation extensions.
Thank you!
> On Sep 10, 2021, at 3:29 PM, Joerg Schilling via austin-group-l at The Open
> Group wrote:
>
> "Stephane Chazelas via austin-group-l at The Open Group"
> wrote:
>
>> 2021-09-10 22:46:26 +0100, Stephane Chazelas via austin-group-l at The Open
>> Group:
>> [...]
>>> I've personally used the
2021-09-11 00:29:44 +0200, Joerg Schilling via austin-group-l at The Open Group:
[...]
> > As mentioned on that mailing list and it's still undocumented,
> > -r can be used with print -f to disable reuse:
>
> The problem, POSIX defines printf(1) to not handle options. So I don't think,
> we
"Stephane Chazelas via austin-group-l at The Open Group"
wrote:
> 2021-09-10 22:46:26 +0100, Stephane Chazelas via austin-group-l at The Open
> Group:
> [...]
> > I've personally used the feature to reorder items in sets, so
> > would object to precluding reusing arguments.
> [...]
I agree...
2021-09-11 00:04:20 +0200, Joerg Schilling via austin-group-l at The Open Group:
> "Stephane Chazelas via austin-group-l at The Open Group"
> wrote:
>
> > For the record, see the interesting discussions on the zsh
> > mailing list from when that feature was added there almost
> > exactly 20
2021-09-10 22:46:26 +0100, Stephane Chazelas via austin-group-l at The Open
Group:
[...]
> I've personally used the feature to reorder items in sets, so
> would object to precluding reusing arguments.
[...]
As mentioned on that mailing list and it's still undocumented,
-r can be used with print
"Stephane Chazelas via austin-group-l at The Open Group"
wrote:
> For the record, see the interesting discussions on the zsh
> mailing list from when that feature was added there almost
> exactly 20 years ago:
>
> https://www.zsh.org/mla/workers/2001/msg02715.html
>From the information I
"Harald van Dijk via austin-group-l at The Open Group"
wrote:
> Either the distinction matters or it doesn't. If it matters, then it was
> important to switch back to talk about what O?uz wrote. If it doesn't
> matter, then it should not be a problem that I switched back to talk
> about what
For the record, see the interesting discussions on the zsh
mailing list from when that feature was added there almost
exactly 20 years ago:
https://www.zsh.org/mla/workers/2001/msg02715.html
https://www.zsh.org/mla/workers/2001/msg02716.html
https://www.zsh.org/mla/workers/2001/msg02740.html
On 10/09/2021 22:14, (Joerg Schilling) wrote:
Harald van Dijk wrote:
Not correct: ksh93 prints the same as bosh
Indeed, something went wrong with the copying there.
> and pleasew note that my example is
> using an integer format instead of a string format.
Irrelevant. You wrote:
>
Harald van Dijk wrote:
> > Not correct: ksh93 prints the same as bosh
>
> Indeed, something went wrong with the copying there.
>
> > and pleasew note that my example is
> > using an integer format instead of a string format.
>
> Irrelevant. You wrote:
>
> > That is exactly what existing
On 10/09/2021 21:34, (Joerg Schilling) wrote:
Harald van Dijk wrote:
No, it isn't. The second command prints
ksh93:
c a
d
zsh:
printf: 3: argument specifier out of range
c a
bosh:
c a
d
Not correct: ksh93 prints the same as bosh
Indeed, something went wrong
"Robert Elz via austin-group-l at The Open Group"
wrote:
> 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
Harald van Dijk wrote:
> No, it isn't. The second command prints
>
> ksh93:
>
>c a
>d
>
> zsh:
>
>printf: 3: argument specifier out of range
>c a
>
> bosh:
>
>c a
> d
Not correct: ksh93 prints the same as bosh and pleasew note that my example is
using an integer
On 10/09/2021 20:27, Joerg Schilling via austin-group-l at The Open
Group wrote:
"O?uz via austin-group-l at The Open Group"
wrote:
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? For example,
the
10 Eylül 2021 Cuma tarihinde Robert Elz yazdı:
>
> But the third argument is c the first time around.
> Why would that be replaced by '' ?
> It is then, perhaps, '' the next iteration of the format string.
>
I should have said "the current subset of arguments being processed" or
something like
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
"O?uz via austin-group-l at The Open Group"
wrote:
> 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? For example,
> the command:
>
> printf '%2$s %1$s\n' a b c d
>
> would print:
>
> b a
> d
10 Eylül 2021 Cuma tarihinde Robert Elz via austin-group-l at The Open
Group yazdı:
>
> When %n$ was added to those implementations of printf which support it,
> it seems to have been added in the simplest way possible - printf simply
> picks the identified arg, instead of the "next" one, and the
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
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//opengroup.org//NONSGML kigkonsult.se iCalcreator 2.22.1//
CALSCALE:GREGORIAN
METHOD:REQUEST
BEGIN:VTIMEZONE
TZID:America/New_York
X-LIC-LOCATION:America/New_York
BEGIN:DAYLIGHT
TZOFFSETFROM:-0500
TZOFFSETTO:-0400
TZNAME:EDT
DTSTART:20120311T02
"David A. Wheeler via austin-group-l at The Open Group"
wrote:
> Allow me to *try* to bring this back to the original topic :-).
>
> I think it?s vital that ?::=?, as (provisionally) accepted *8* years ago, be
> in the final version.
> The underlying semantics of this (GNU make?s :=) are
On Thu, 2021-09-09 at 10:07 +0100, Geoff Clare via austin-group-l at
The Open Group wrote:
> You took a risk when you added ::= to gmake while it was only an
> ccepted proposal, not part of an approved revision to the standard.
> And gmake users who make use of it in the expectation that is will
>
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
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
The following issue has been UPDATED.
==
https://austingroupbugs.net/view.php?id=1521
==
Reported By:kre
Assigned To:
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
|
The following issue has been set as RELATED TO issue 0001521.
==
https://austingroupbugs.net/view.php?id=1043
==
Reported By:kre
Assigned
The following issue has been set as RELATED TO issue 0001036.
==
https://austingroupbugs.net/view.php?id=1521
==
Reported By:kre
Assigned
The following issue has been set as RELATED TO issue 0001043.
==
https://austingroupbugs.net/view.php?id=1521
==
Reported By:kre
Assigned
The following issue has been set as RELATED TO issue 0001521.
==
https://austingroupbugs.net/view.php?id=1036
==
Reported By:kre
Assigned
The following issue has been UPDATED.
==
https://austingroupbugs.net/view.php?id=1521
==
Reported By:kre
Assigned To:
32 matches
Mail list logo