On Thu, Aug 19, 2021 at 5:49 AM Koichi Murase
wrote:
> FYI, zsh provides this feature for associative arrays with the syntax
> ${(kv)assoc} or ${(@kv)assoc}. Note that Bash-5.1 already has a
> similar feature ${array[@]@K}, but the substitution result is quoted
> so cannot be directly used for th
2021年8月19日(木) 18:16 Ilkka Virta :
> On Thu, Aug 19, 2021 at 5:49 AM Koichi Murase wrote:
>> FYI, zsh provides this feature for associative arrays with the syntax
>> ${(kv)assoc} or ${(@kv)assoc}. Note that Bash-5.1 already has a
>> similar feature ${array[@]@K}, but the substitution result is quot
Le 19/08/2021 à 12:09, Koichi Murase écrivait :
$ printf '<%s>\n' "${A[@]@A}"
<-A>
The problem of ${A[@]@A} is that it is not so useful when one wants to
define a clone associative array with a different name but with the
same contents as A. Instead, using ${A[@]@K}, one could do
$ declare -
2021年8月19日(木) 19:37 Léa Gris :
> Current implementation of @K is pretty-much useless for the dialog use-case:
>
> > #!/usr/bin/env bash
> >
> > declare -A assoc=(
> > [P]=piano
> > [TB]='foldable table'
> > ['CH AIR']=chair
> > )
> >
> > options=("${assoc[@]@K}")
I this particular case, you
Have been using $EPOCHREALTIME but can see that the output is as follows.
1629376497,853634
The utilisation of tho comma `,` is very inconvenient for those who want to do
time
computations. A change towards a period `.` would be the proper way to display
the
variable.
Furthermore, one gets nan
Le 19/08/2021 à 14:43, hancooper via Bug reports for the GNU Bourne
Again SHell écrivait :
Have been using $EPOCHREALTIME but can see that the output is as follows.
1629376497,853634
The utilisation of tho comma `,` is very inconvenient for those who want to do
time
computations. A change towa
‐‐‐ Original Message ‐‐‐
On Thursday, August 19, 2021 12:58 PM, Léa Gris wrote:
> Le 19/08/2021 à 14:43, hancooper via Bug reports for the GNU Bourne
> Again SHell écrivait :
>
> > Have been using $EPOCHREALTIME but can see that the output is as follows.
> > 1629376497,853634
> > The util
On Thu, Aug 19, 2021 at 4:12 PM hancooper wrote:
> On Thursday, August 19, 2021 12:58 PM, Léa Gris
> wrote:
> > (LC_NUMERIC=C; echo "$EPOCHREALTIME")
>
> the unix time stamp is merely the number of
> seconds between a particular date and the epoch. Technically, it should
> be pointed out
> that
Le 19/08/2021 à 15:10, hancooper écrivait :
Thusly, EPOCHREALTIME should not be made to depend on the locale. I have seen
many
workarounds, that complicate rather than simplify something that should be
straighforward
and germaine to direct numeric computation.
A agree 100%
It is as frustrat
On 8/19/21 9:41 AM, Léa Gris wrote:
> This will fail because of questionable design decision of having a mutable
> argument format:
>
> LC_NUMERIC=fr_FR@UTF-8; printf 'Pi: %2.4f\n` "$(bc -l <<<'4*a(1)')"
>
> Note how the format indicator still use a dot, but the argument format's
> decimal separ
On 8/19/21 9:41 AM, Léa Gris wrote:
> Le 19/08/2021 à 15:10, hancooper écrivait :
>> Thusly, EPOCHREALTIME should not be made to depend on the locale. I
>> have seen many
>> workarounds, that complicate rather than simplify something that
>> should be straighforward
>> and germaine to direct numer
On Thu, Aug 19, 2021 at 10:30:39AM -0400, Chet Ramey wrote:
> On 8/19/21 9:41 AM, Léa Gris wrote:
> > This will fail because of questionable design decision of having a mutable
> > argument format:
> >
> > LC_NUMERIC=fr_FR@UTF-8; printf 'Pi: %2.4f\n` "$(bc -l <<<'4*a(1)')"
> >
> > Note how the fo
Le 19/08/2021 à 16:41, Eli Schwartz écrivait :
On 8/19/21 9:41 AM, Léa Gris wrote:
The error occurs, one would imagine, during the "convert string to
float" stage, after parsing argv or forking to bc or whatever, but
*before* passing it as an argument to printf(3). Here, bash is just
doing go
On Thu, Aug 19, 2021 at 06:18:46PM +0200, Léa Gris wrote:
> printf arguments are program source even if argument comes from a variable.
I don't agree with this. I'd say that the *first* argument of printf
is part of the program source code, and any additional arguments given
are typically data, b
On 8/19/21 12:18 PM, Léa Gris wrote:
> Le 19/08/2021 à 16:41, Eli Schwartz écrivait :
>> On 8/19/21 9:41 AM, Léa Gris wrote:
>
>
>> The error occurs, one would imagine, during the "convert string to
>> float" stage, after parsing argv or forking to bc or whatever, but
>> *before* passing it as an
The
general consensus seems to be that this isn't really a bug (from what
I've understood), but it looks like I can use a variable reference to
solve the issue nevertheless.
Regardless,
I'm still wanting to almost classify this as a bug (or possibly a
feature request; it feels like it's get
20 Ağustos 2021 Cuma tarihinde Hunter Wittenborn <
hun...@hunterwittenborn.com> yazdı:
>
> So, in my opinion, this should logically work (from the view of an end
> user):
>
>
>
> declare "var"=("i" "j")
>
`"var"=("i" "j")' doesn't qualify as an assignment statement as the
variable name is quoted.
17 matches
Mail list logo
