5 Nisan 2021 Pazartesi tarihinde Jesse Hathaway
yazdı:
> This equivalence, though it is reasonable, creates a special case for the
> last
> value in an array which imposes a greater cognitive burden on the
> programmer.
> The programmer needs to be aware that omitting the last value will create
On Mon, Mar 29, 2021 at 4:18 PM Chet Ramey wrote:
> If you look at
>
> a=( k1 v1 k2 v2 k3 v3)
>
> as more or less syntactic sugar for
>
> a=( [k1]=v1 [k2]=v2 [k3]=v3 )
>
> it's reasonable that
>
> a=( k1 v1 k2 )
>
> is equivalent to
>
> a=( [k1]=v1 [k2]= ). And that's what bash does.
This
On 3/30/21 3:44 PM, Chet Ramey wrote:
Is this a serious piece of code, or just one to demonstrate a programming
error?
The latter
There is only one field, terminated by `|', which becomes one array
element. This is where you `lose' the null elements, not when you attempt
to copy. Nothing you
On Wed, Mar 31, 2021 at 09:40:34AM +0200, felix wrote:
> As bash read loop could be something slow, I use (when I'm quiet about data
> origin) something like:
>
> declare -A tags="($(
> sed -e 's/^\([^|]*\)|\?\(.*\)/[\1]="\2"/' < <(
> exiftool ...)) )"
> I'm not absolutely
On Tue, Mar 30, 2021 at 7:43 PM Eric Cook wrote:
> typeset -A tags=(); set --
> while IFS='|' read -ra ary; do
> set -- "$@" "${ary[@]}"
> done < <(
> exiftool -j *.flac |
> jq -r '.[]| {Artist, Track, Genre, Title}|to_entries[]| .key + "|" +
> .value'
> )
> eval 'tags=('"${*@Q}"\)
>
Quick array assignment from command...
> On Tue, Mar 30, 2021 at 12:42:46PM -0400, Eric Cook wrote:
> > eval 'tags=('"${*@Q}"\)
On Tue, Mar 30, 2021 at 01:16:14PM -0400, Greg Wooledge wrote:
> declare -A tags=()
> while IFS=\| read -r tag value; do
> tags[$tag]=$value
> done < <(exiftool ...)
On Tue, Mar 30, 2021 at 1:40 AM Eric Cook wrote:
> Its just when populating that array dynamically with another array
> if that second array didn't contain `v1' hypothetically, the array gets
> shifted to
>
> a=( [k1]=k2 [v2]=k3 [v3]= )
> which i would imagine to be unexpected for the author of
On 3/30/21 12:42 PM, Eric Cook wrote:
On 3/30/21 10:54 AM, Chet Ramey wrote:
On 3/29/21 6:40 PM, Eric Cook wrote:
Its just when populating that array dynamically with another array
if that second array didn't contain `v1' hypothetically, the array gets shifted
to
OK, how would you do
On Tue, Mar 30, 2021 at 12:42:46PM -0400, Eric Cook wrote:
> typeset -A tags=(); set --
> while IFS='|' read -ra ary; do
> set -- "$@" "${ary[@]}"
> done < <(
> exiftool -j *.flac |
> jq -r '.[]| {Artist, Track, Genre, Title}|to_entries[]| .key + "|" + .value'
> )
> eval 'tags=('"${*@Q}"\)
>
On 3/30/21 10:54 AM, Chet Ramey wrote:
> On 3/29/21 6:40 PM, Eric Cook wrote:
>> Its just when populating that array dynamically with another array
>> if that second array didn't contain `v1' hypothetically, the array gets
>> shifted to
>
> OK, how would you do that? What construct would you use
On 3/29/21 6:40 PM, Eric Cook wrote:
On 3/29/21 5:18 PM, Chet Ramey wrote:
If you look at
a=( k1 v1 k2 v2 k3 v3)
as more or less syntactic sugar for
a=( [k1]=v1 [k2]=v2 [k3]=v3 )
it's reasonable that
a=( k1 v1 k2 )
is equivalent to
a=( [k1]=v1 [k2]= ). And that's what bash does.
Its
On 3/29/21 5:18 PM, Chet Ramey wrote:
If you look at
a=( k1 v1 k2 v2 k3 v3)
as more or less syntactic sugar for
a=( [k1]=v1 [k2]=v2 [k3]=v3 )
it's reasonable that
a=( k1 v1 k2 )
is equivalent to
a=( [k1]=v1 [k2]= ). And that's what bash does.
Its just when populating that array
On 3/27/21 5:02 PM, Eric Cook wrote:
Hey,
When doing an assignment with an uneven number of elements bash currently
silently treat the last element
as a key and assigns it an empty string.
$ typeset -A ary=(this feature came from zsh); typeset -p ary
declare -A ary=([came]="from"
On 2021/03/28 11:02, Eric Cook wrote:
On 3/28/21 7:02 AM, Oğuz wrote:
As it should be. `[bar]' doesn't qualify as an assignment without an equals
sign, the shell thinks you're mixing two forms of associative array assignment
there.
In the new form, that a key is listed inside a compound
On Mon, Mar 29, 2021 at 1:56 AM Greg Wooledge wrote:
> Python is different:
>
> >>> y = ["a", "b", "c", "d"]
> >>> dict(zip(y[::2], y[1::2]))
> {'a': 'b', 'c': 'd'}
> >>> x = ["a", "b", "c"]
> >>> dict(zip(x[::2], x[1::2]))
> {'a': 'b'}
>
> It seems to discard the last (unmatched) value. Also,
On Mär 28 2021, Greg Wooledge wrote:
> Python is different:
>
y = ["a", "b", "c", "d"]
dict(zip(y[::2], y[1::2]))
> {'a': 'b', 'c': 'd'}
x = ["a", "b", "c"]
dict(zip(x[::2], x[1::2]))
> {'a': 'b'}
>
> It seems to discard the last (unmatched) value.
>>>
On Sun, Mar 28, 2021 at 10:01:14PM +0300, Oğuz wrote:
> On Sun, Mar 28, 2021 at 9:02 PM Eric Cook wrote:
>
> > in typeset -A ary=([key]=) an explicit empty string is the value
>
> No. An "explicit" empty string would be '', "", or something like that.
> After `=' a value is expected but it's
Date:Sun, 28 Mar 2021 22:01:14 +0300
From:=?UTF-8?B?T8SfdXo=?=
Message-ID:
| No. An "explicit" empty string would be '', "", or something like that.
No, not in sh it isn't - all quotes do is hide the effects of special
characters (and prevent some uses, eg: as a
On Sun, Mar 28, 2021 at 9:02 PM Eric Cook wrote:
> in typeset -A ary=([key]=) an explicit empty string is the value
No. An "explicit" empty string would be '', "", or something like that.
After `=' a value is expected but it's not there, so `[key]' is assigned
the empty string. `typeset -A
On 3/28/21 7:02 AM, Oğuz wrote:
As it should be. `[bar]' doesn't qualify as an assignment without an equals
sign, the shell thinks you're mixing two forms of associative array assignment
there.
In the new form, that a key is listed inside a compound assignment alone
implies that it was meant
28 Mart 2021 Pazar tarihinde Ilkka Virta yazdı:
> On Sun, Mar 28, 2021 at 10:16 AM Oğuz wrote:
>
>> That an idea was borrowed from another shell doesn't mean it should be
>> implemented the same kludgy way. Besides, bash doesn't offer compatibility
>> with zsh.
>>
>
> You don't think the realm
On Sun, Mar 28, 2021 at 10:16 AM Oğuz wrote:
> That an idea was borrowed from another shell doesn't mean it should be
> implemented the same kludgy way. Besides, bash doesn't offer compatibility
> with zsh.
>
You don't think the realm of POSIX-ish shells already has enough
incompatibilities
and
28 Mart 2021 Pazar tarihinde Eric Cook yazdı:
>
> 1) For consistency sake with the shell the idea was borrowed from mostly.
That an idea was borrowed from another shell doesn't mean it should be
implemented the same kludgy way. Besides, bash doesn't offer compatibility
with zsh.
> 2) Prior to
On 3/28/21 12:25 AM, Oğuz wrote:
Why? I think it's better this way.
--
Oğuz
1) For consistency sake with the shell the idea was borrowed from mostly.
2) Prior to this extension bash required specifying the key and value for
AA assignments, so it seems weird to silently ignore that a value
28 Mart 2021 Pazar tarihinde Eric Cook yazdı:
> Hey,
>
> When doing an assignment with an uneven number of elements bash currently
> silently treat the last element
> as a key and assigns it an empty string.
>
> $ typeset -A ary=(this feature came from zsh); typeset -p ary
> declare -A
Hey,
When doing an assignment with an uneven number of elements bash currently
silently treat the last element
as a key and assigns it an empty string.
$ typeset -A ary=(this feature came from zsh); typeset -p ary
declare -A ary=([came]="from" [this]="feature" [zsh]="" )
In zsh this is an
26 matches
Mail list logo
