On Wed, Sep 6, 2023 at 9:38 AM Robert Elz wrote:
> Adding a different %b to printf(1) wasn't currently even proposed, just
> deprecating the current one so it wouldn't conflict with the usage of
> %b in printf(3) (which is being defined in C23, and is apparently already
> firmly entrenched, even t
On 2023-09-06 05:45, Robert Elz wrote:
Date:Tue, 05 Sep 2023 22:32:39 +0200
From:Dragan Simic
Message-ID: <7cfed11b50d35cbfaaa647c1fcd39...@manjaro.org>
| Are there any official explanations why is the invalidation
actually
| happening now?
It was proposed becaus
On 9/5/23 7:34 PM, Rob Landley wrote:
C23 is going to use %b to print binary literals.
Upper case %B was taken?
I asked the same question. The short answer is that no one trusts the C
committee.
https://lists.gnu.org/archive/html/bug-bash/2023-08/msg00121.html
--
``The lyf so short, the c
On 9/5/23 10:13 PM, William Bader wrote:
Has bash ever had a change before that would break valid scripts?
Yes, but I try to keep those to a minimum.
Could the printf format change be settable by a variable or by an option
like the -e/-E in echo?
It could, sure. Anything is possible.
Is i
On 9/6/23 6:28 AM, Dragan Simic wrote:
No invalidation would be happening now, merely a note in the coming standard
that the %b in printf(1) would (might) be removed in a later version of
the standard - so implementations have time to implement something to
replace it, and applications to stop u
On 9/6/23 4:02 AM, Oğuz wrote:
I don't think bash should deprecate %b.
I don't have any plans to change %b.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.e
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu'
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE
Has bash ever had a change before that would break valid scripts?
Could the printf format change be settable by a variable or by an option like
the -e/-E in echo?
Is it necessary for bash printf to match C printf?
I suppose that it is already decided.
Could the bash printf implementation warn
On Wed, Sep 06, 2023 at 02:13:44AM +, William Bader wrote:
> Has bash ever had a change before that would break valid scripts?
Yes. Many times, sadly. Most recently, bash 5.2 introduced some changes
to how associative array indexes are handled, which will break
backward compatibility in seve
The following 'hash -d' statements have different exit statuses.
bash --noprofile --norc -c \
'hash -d ls; echo $?' ## 0
bash --noprofile --norc -c \
'cat /dev/null; echo $?' ## 1
This depends on a hashable command being given (e.g. cat https://pubs
Date:Wed, 06 Sep 2023 12:28:34 +0200
From:Dragan Simic
Message-ID: <03abecb9d905252bd63867d1c8b2a...@manjaro.org>
| It's good to know that the
| 2013, 2016 and 2018 versions/revisions of POSIX actually don't count.
As Chet said, that is not what I meant. The "
On 2023-09-06 15:07, Chet Ramey wrote:
On 9/6/23 6:28 AM, Dragan Simic wrote:
No invalidation would be happening now, merely a note in the coming
standard
that the %b in printf(1) would (might) be removed in a later version
of
the standard - so implementations have time to implement something
On 2023-09-06 17:10, Robert Elz wrote:
Date:Wed, 06 Sep 2023 12:28:34 +0200
From:Dragan Simic
Message-ID: <03abecb9d905252bd63867d1c8b2a...@manjaro.org>
| It's good to know that the
| 2013, 2016 and 2018 versions/revisions of POSIX actually don't
count.
As Chet s
On 9/5/23 7:00 PM, Emanuele Torre wrote:
If you have a CHLD trap set, and you run any command that has more than
one command substitution, or an array subscript with more than one
command substituion in an arithmetic context, or also in a prompt
string, you will get parse errors.
Thanks for the
On Wed, Sep 06, 2023 at 09:03:29AM -0400, Chet Ramey wrote:
> On 9/5/23 10:13 PM, William Bader wrote:
> > Has bash ever had a change before that would break valid scripts?
>
> Yes, but I try to keep those to a minimum.
>
> > Could the printf format change be settable by a variable or by an optio
On Wed, Sep 06, 2023 at 10:45:09AM +0700, Robert Elz wrote:
>
> However, my "read of the room" at the minute is that this simply won't
> happen, and printf(1) %b will remain as it is, and not be removed any
> time soon (or probably, ever). If printf(1) ever really needs a method
> to output in b
On 9/6/23 12:03 PM, Eric Blake wrote:
The austin group has decided what they'd like to do, and what they'd like
implementors to do. The question is whether or not people go along with it.
The Austin Group decided merely:
If we do nothing now for Issue 8, then Issue 9 WILL have a conflict
betw
On 9/6/23 05:28, Dragan Simic wrote:
> Thank you for this detailed clarification. It's good to know that the
> 2013, 2016 and 2018 versions/revisions of POSIX actually don't count.
You didn't change the URL. You didn't update the SUSvX number. It's still says
"issue 7" at the top. That's YOU tel
On 2023-09-07 03:03, Rob Landley wrote:
On 9/6/23 05:28, Dragan Simic wrote:
Thank you for this detailed clarification. It's good to know that the
2013, 2016 and 2018 versions/revisions of POSIX actually don't count.
You didn't change the URL. You didn't update the SUSvX number. It's
still s
OK. That's well and good. But my main problem now is that that fact is
not documented anywhere.
(Also here it is again, so as to remove any confusion about "compound
assignment" (some readers might think it meant two ='s on the same line.)
$ bash -c 'set a b c; set -x; m=$@; n=($@)'
+ m='a b c'
+
20 matches
Mail list logo
