Re: Q: what is a fast way to see if an 'item' is present in an array?
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"? An alias for "local"?)
Try this:
appears_in() {
local IFS="|" val="$1"
shift
[[ "$IFS$*$IFS" == *"$IFS$val$IFS"* ]]
}
if appears_in "somevalue" "${array[@]}"; then do stuff; fi
For anyone reading who may not know, the trick is that "$*" expands to a
single string containing all the positional parameters separated by the
first character of $IFS (or with no separator if IFS is empty, but
that's not useful here).
Of course this function is dependent on none of the elements containing
"|". But this lets you set any separator you want, so you could use a
really unlikely character such as IFS=$'\1'.
- M.
Re: Q: what is a fast way to see if an 'item' is present in an array?
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: http://stromberg.dnsalias.org/~strombrg/database/
Re: Q: what is a fast way to see if an 'item' is present in an array?
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 associative array (hash) from the beginning instead of, or in addition to, storing your information in a "list" (indexed array). It would also take throwing away previous cfg-file compat as well as changing the linux kernel interface. Somehow I don't think that is going to be easier: (cd /sys/class/net/br0/brif/; echo *) eth0 eth5 grep ^BRIDGE_PORTS "$CFG" BRIDGE_PORTS='eth0 eth5' --- In my case it's only 2, but other interfaces... still not that long *usually*, (cd $PWD/holders; echo *) dm-0 dm-1 dm-12 dm-2 dm-3 dm-4 dm-5 dm-6 dm-7 dm-8 dm-9 But I tend to think about worst case behaviors and at least try to ask around if anyone has anything better... but in this case, the impact is minimal. Though when designing 'anew', I try to make things data/table driven as much as possible for things that fit into that paradigm. Thanks! L.
Re: How to lock a terminal
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, because it annoys me when nano > drops into the background when I accidentally hit ^Z.) I do not have a nanorc file at all. The defaults are okay for suspension without any specific configuration. Since you are specifically configuring suspend disabled one must presume that you will already know about job control and have specifically disabled it and will work around it by other means. Such as in your case M-Z or another terminal or other method. Bob
Re: [Nano-devel] How to lock a terminal
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 > nanorc. (Which I don't have, because it annoys me when nano > drops into the background when I accidentally hit ^Z.) > > Luckily one can toggle suspendability on with M-Z, but... > somehow that doesn't seem to work when nano is screenless. > > When I use nano with --ignorercfiles, M-Z does work. > Maybe the colors do something strange with the pipe? > > And when I use LANGUAGE=en, it works too. Ha! > Esperanto pisses off the pipe, too. :) > > Benno M-Z Ctrl-Z works for me with that testcase. While Ctrl-Z is a generic solution, I don't think it is reasonable an expectation of M-Z to enable it, as it is really domain-specific.
Re: [Nano-devel] How to lock a terminal
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 it annoys me when nano drops into the background when I accidentally hit ^Z.) Luckily one can toggle suspendability on with M-Z, but... somehow that doesn't seem to work when nano is screenless. When I use nano with --ignorercfiles, M-Z does work. Maybe the colors do something strange with the pipe? And when I use LANGUAGE=en, it works too. Ha! Esperanto pisses off the pipe, too. :) Benno -- http://www.fastmail.com - IMAP accessible web-mail
Re: How to lock a terminal
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', but then forgot to change it to 'cat'). > > > > The terminal just sits there doing nothing - CTRL+C doesn't do anything; in > > a SSH session, the only option is to kill the terminal. On a local machine, > > you can use kill -9 from another terminal to get out of it. > > On a remote machine you can do the same. There really is no > difference between local and remote here. You just use a second > terminal for it. > > However 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. sometimes ^Z doesn't work once nano starts up. probably should add isatty checking to nano itself. -mike signature.asc Description: Digital signature
Re: How to lock a terminal
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. Sorry for the noise. Nick On 16/02/16 10: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', but then forgot to change it to 'cat'). The terminal just sits there doing nothing - CTRL+C doesn't do anything; in a SSH session, the only option is to kill the terminal. On a local machine, you can use kill -9 from another terminal to get out of it. On a remote machine you can do the same. There really is no difference between local and remote here. You just use a second terminal for it. However 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. rwp@havoc:~$ nano /var/log/messages | grep a ^Z [1]+ Stopped nano /var/log/messages | grep a rwp@havoc:~$ jobs [1]+ Stopped nano /var/log/messages | grep a rwp@havoc:~$ kill %1 Received SIGHUP or SIGTERM rwp@havoc:~$ jobs [1]+ Terminated nano /var/log/messages | grep a rwp@havoc:~$ jobs rwp@havoc:~$ Simply stop the process and then kill it using the same terminal. Bob P.S. The other suggestions to use Control-X to exit nano are also good too but job control is general for the entire class type of commands like this and I think good to know too. -- Gosh that takes me back... or is it forward? That's the trouble with time travel, you never can tell." -- Doctor Who "Androids of Tara"
Re: bug adding K,V pairs to existing hash with HASH+=([K]=V)
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 thinking was that this is due to bash's unique auto-incrementing of > indexed array keys. A simple bug, nothing more. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: bug adding K,V pairs to existing hash with HASH+=([K]=V)
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]="5" [5]="6")' If you're proposing a change to this, it will break MANY scripts.
Re: Q: what is a fast way to see if an 'item' is present in an array?
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 beginning instead of, or in addition to, storing your information in a "list" (indexed array).
Re: How to lock a terminal
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 terminal just sits there doing nothing - CTRL+C doesn't do anything; in > a SSH session, the only option is to kill the terminal. On a local machine, > you can use kill -9 from another terminal to get out of it. On a remote machine you can do the same. There really is no difference between local and remote here. You just use a second terminal for it. However 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. rwp@havoc:~$ nano /var/log/messages | grep a ^Z [1]+ Stopped nano /var/log/messages | grep a rwp@havoc:~$ jobs [1]+ Stopped nano /var/log/messages | grep a rwp@havoc:~$ kill %1 Received SIGHUP or SIGTERM rwp@havoc:~$ jobs [1]+ Terminated nano /var/log/messages | grep a rwp@havoc:~$ jobs rwp@havoc:~$ Simply stop the process and then kill it using the same terminal. Bob P.S. The other suggestions to use Control-X to exit nano are also good too but job control is general for the entire class type of commands like this and I think good to know too.
Re: bug adding K,V pairs to existing hash with HASH+=([K]=V)
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.
Re: bug adding K,V pairs to existing hash with HASH+=([K]=V)
\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
>> more than one element at a time.
>>
>> My thinking was that this is due to bash's unique auto-incrementing of
>> indexed array keys. Since in ksh you're not allowed to specify an
>> index for one element of a compound assignment without specifying it
>> for all elements, bash has some additional things to consider.
>>
>> ~ $ bash-4.2 -c 'typeset -ia a=({0..5}); a+=([0]+=1 {2..4}); typeset -p
>> a'
>> declare -ai a='([0]="1" [1]="3" [2]="5" [3]="7" [4]="4" [5]="5")'
>>
>> Bash 4.4:
>> ~ $ ./doc/programs/bash-build/bash -c 'typeset -ia a=({0..5});
>> a+=([0]+=1 {2..4}); typeset -p a'
>> declare -ai a=([0]="1" [1]="2" [2]="3" [3]="4" [4]="4" [5]="5")
>>
>> I almost think it makes sense to treat ordered and unordered
>> collections differently.
>
> Why?
>>
>> With an unordered collection an outer +=
>> should obviously mean "add or update for each assignment".
>
> For an array, you mean? like
> array a=( 1 2 3)
> array a+=( 4 5 6)
> then you get array a=(5 7 9). Or are you saying
> for an ordered array you'd have to use indexes, like
> array a=(1 2 3)
> array a+=([0]=4 [1]=7 [2]=10), then that would do your
> -- but wouldn't that be doing a vector operation of
> sorts?
I mean exactly the example I posted. In bash if you explicitly specify
an index for an assignment at any point within an auto-incrementing
compound assignment, bash will jump to that position and continue
incrementing. Bash is the only shell that has that property.
There's nothing wrong with that feature but the question of what to do
when an auto-incrementing assignment encounters an element with a
previous value isn't as obvious because the semantics differ. For an
ordered collection the outer += translates to "append to the list"
while with an unordered collection it roughly means to "union" the two
sets of keys.
You could argue that for consistency bash should always bulldoze over
previous values even if auto-incrementing keys. That makes sense from
a certain perspective and is consistent. From another perspective you
might expect the outer += to mean append for each sub-assignment to an
auto-incrementing array when not appending to the end of the array.
That especially makes sense if it's an integer array. I can understand
the logic either way.
I wrote about all of these issues years ago (I'm pretty sure also on
this list) so people probably know about them and possibly believed
the old behavior was by design like I did.
http://wiki.bash-hackers.org/syntax/arrays#bugs_and_portability_considerations.
