\On Tue, Feb 16, 2016 at 1:30 AM, Linda Walsh wrote:
>
>
> Dan Douglas wrote:
>>
>> Ah so `arr+=([a]=x [b]=y)` will no longer be the same as `arr+=([a]+=x
>> [b]+=y)`? I never liked that for associative arrays because the only
>> workaround was to do multiple arr[key]= assignments to update or add
Sorry, spoofed identity (thanks gmail for picking a random sender).
I'll be rid of gmail as soon as I get a little free time.
Nick Warne wrote:
> I was in a SSH session, and checking something inadvertently issued:
>
> > nano /var/log/messages | grep a
>
> (I was searching for something else than an 'a', but the above example shows
> the issue - about to use 'nano', but then forgot to change it to 'cat').
>
> The termi
On Mon, Feb 15, 2016 at 07:59:21PM -0800, Linda Walsh wrote:
> Obviously, If I could precook the array into
> a hash, I'd think it would be faster... but
> the "cooking part", I think, is the high
> overhead part.
Redesign the entire script so that you use the associative array (hash)
from the beg
On Mon, Feb 15, 2016 at 11:30:13PM -0800, Linda Walsh wrote:
> For an array, you mean? like
> array a=( 1 2 3)
> array a+=( 4 5 6)
> then you get array a=(5 7 9).
Oh dear gods, no.
imadev:~$ a=(1 2 3)
imadev:~$ a+=(4 5 6)
imadev:~$ declare -p a
declare -a a='([0]="1" [1]="2" [2]="3" [3]="4" [4]="
On 2/16/16 2:06 AM, Dan Douglas wrote:
> Ah so `arr+=([a]=x [b]=y)` will no longer be the same as `arr+=([a]+=x
> [b]+=y)`? I never liked that for associative arrays because the only
> workaround was to do multiple arr[key]= assignments to update or add
> more than one element at a time.
>
> My th
OK, everybody,
Thanks for the replies. As I stated, it was me being stupid - why I
didn't think of Ctrl+Z I don't know - I have only been using GNU/Linux
for 14 years :)
Mind you, it was late and I was rushing to stop my Raspberry Pi
connecting to the AP rather than the range extender.
So
On 16 Feb 2016 18:19, Bob Proulx wrote:
> Nick Warne wrote:
> > I was in a SSH session, and checking something inadvertently issued:
> >
> > > nano /var/log/messages | grep a
> >
> > (I was searching for something else than an 'a', but the above example shows
> > the issue - about to use 'nano',
On Tue, Feb 16, 2016, at 11:19, Bob Proulx wrote:
> [...] this is the perfect case for job control. No need for a
> second terminal. Here is an example. Use Control-Z to stop the
> foreground job.
For that to work, it requires having 'set suspend' in your
nanorc. (Which I don't have, because
Benno Schulenberg wrote:
> On Tue, Feb 16, 2016, at 11:19, Bob Proulx wrote:
> > [...] this is the perfect case for job control. No need for a
> > second terminal. Here is an example. Use Control-Z to stop the
> > foreground job.
>
> For that to work, it requires having 'set suspend' in your
>
Benno Schulenberg wrote:
> Bob Proulx wrote:
> > [...] this is the perfect case for job control. No need for a
> > second terminal. Here is an example. Use Control-Z to stop the
> > foreground job.
>
> For that to work, it requires having 'set suspend' in your
> nanorc. (Which I don't have, be
Greg Wooledge wrote:
On Mon, Feb 15, 2016 at 07:59:21PM -0800, Linda Walsh wrote:
Obviously, If I could precook the array into
a hash, I'd think it would be faster... but
the "cooking part", I think, is the high
overhead part.
Redesign the entire script so that you use the associativ
On Monday, February 15, 2016 at 7:59:35 PM UTC-8, Linda Walsh wrote:
> I has a little 4 line func that returns true or false
> if a string was in an array
Arrays aren't really a great datastructure for testing presence and absence in.
An associative array / dictionary / hash is better.
Consider:
Linda Walsh schreef op 16-02-16 om 04:59:
> w/the slow func being killed by a $() sub process, likely:
Yes, subshells are fatal for performance, particularly on bash.
> my fn2='() {my t="${2:?}[*]"
>my arRE="^($(IFS="|"; echo "${!t}"))$"
>[[ $1 =~ $arRE ]]
> }
> '
(What's "my"?
14 matches
Mail list logo
