Re: bug adding K,V pairs to existing hash with HASH+=([K]=V)

[Linda Walsh]

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?

^^ You can make similar "logic" jumps in going the same way in
arrays as you can hashes.

... To me, if you want to add elements to an array or hash
and use '=' on the interior, that should assign, like scalars do.
Use '+=' on the interior to get an increment of the scalar.

Why would you assign special non-uniform rules for scalars in an array
vs. ones not in an array?

Re: bug adding K,V pairs to existing hash with HASH+=([K]=V)

[Dan Douglas]

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. With an unordered collection an outer +=
should obviously mean "add or update for each assignment". For an
ordered collection when appending beginning at an index lower than the
max index I'm not so sure.

-- 
Dan Douglas

Q: what is a fast way to see if an 'item' is present in an array?

[Linda Walsh]

I has a little 4 line func that returns true or false
if a string was in an array

I came up with a different way of doing it, that I
though might be faster... but...
putting them in a file and running loops on them.
(times below).  Obviously, my feeling for what might
be faster was way wrong. w/my 2nd method
being 15-44X slower depending on where the match is.

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.

The fast function was:
my fn1='() {
   my __
   my t="${2:?}[@]"
   for __ in "${!t}"; do [[ $1 == "$__" ]] && return 0;done
   return 1;
}
'
w/the slow func  being killed by a $() sub process, likely:
my fn2='() {   
 my t="${2:?}[*]"

   my arRE="^($(IFS="|"; echo "${!t}"))$"
   [[ $1 =~ $arRE ]]
}
'

Was wondering if anyone else had fast functions like this
to determine if a string is in a list?

I can attach the test script (doubles as an "include" or
"source" file), if people want to test their own...
The frameworks should be simple to copy in other test
functions...(or replace #2...)...

This was in bash-4.3.42.

---data results---



(-t [#loops] string WORDLIST):

so false case 1st:
 _in.shh -t 300 word {0..999} 

func(fn1): 1.49sec 1.48usr 0.00sys (100.02% cpu)
false
func(fn2): 22.78sec 18.38usr 4.32sys (99.69% cpu)
false

then true w/match @ end of the list

_in.shh -t 300 word {0..999} word
func(fn1): 1.49sec 1.49usr 0.00sys (100.03% cpu)
true
func(fn2): 22.85sec 18.46usr 4.31sys (99.67% cpu)
true

then true w/match @ beginning of list...


 _in.shh -t 300 word word {0..999}

func(fn1): 0.51sec 0.51usr 0.00sys (100.01% cpu)
true
func(fn2): 22.75sec 18.40usr 4.28sys (99.70% cpu)
true

Re: [Nano-devel] How to lock a terminal

[alpha]

On Mon, 15 Feb 2016 17:24:06 +
Nick Warne  wrote:

> I ma not sure if this is a bug, or if it is what causes it - if it 
> isn't, then it is me being stupid.
> 
> 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.
> 
> I don't know if this behaviour is expected or me being stupid, or 
> something else going on.

I did the same thing about a week ago. You can press CTRL+X to close nano and 
get back to the shell.

Re: inconsistent function of "-v" use w/arrays and hashes

[Linda Walsh]

Linda Walsh wrote:

I seem to remember some discussion of this before --
not being able to use -v to check if a hash was defined,
but having it "work"(?) w/arrays?


So instead of "-v" on an array/hash name only looking at the
value of [0] (for either), can it be enhanced to check the
type of the "varname", and if it is an array or hash,
check to see if the count of members returns >0? and use
that as a t/f value for multi-valued objects?

AW: List out

[Alexander.Elgert]

> -Ursprüngliche Nachricht-
> Von: bug-bash-bounces+alexander.elgert=external.t-systems@gnu.org
> [mailto:bug-bash-bounces+alexander.elgert=external.t-
> systems@gnu.org] Im Auftrag von Allodoxaphobia
> Gesendet: Montag, 15. Februar 2016 19:13
> An: gnu-bash-...@moderators.individual.net
> Betreff: Re: List out
> 
> On Mon, 15 Feb 2016 08:19:37 -0500, Greg Wooledge wrote:
> > On Sun, Feb 14, 2016 at 03:02:58AM +, Allodoxaphobia wrote:
> >> err... u... What's your *bash bug* ???
> >
> > I think what he meant to say is, "Questions of this type should be
> > sent to help-b...@gnu.org instead of bug-bash@gnu.org."
> >
> > Now... you've been given a Python solution, and I could write one in
> > Tcl or Perl as well.  Using pure bash for this task would be an
> utterly
> > poor choice, for performance reasons.
> >
> > The closest thing to a pure bash answer you can get, that would
> actually
> > be viable in real life, would be one using awk.
> >
> > awk '
> >   {
> > n=0
> > label=$2
> > for (i=3; i<=NF; i++) {
> >   if ($i == "NA") n++
> > }
> > print NR ".", label, n
> >   }
> > ' "$file"
> 
> Remeber to _always_ reply to homework assignments with
> the most advanced and obscure solutions so as to make
> the teacher/professor say "WHAT THE HELL...?!?!?!"


while read h x; do y=${x//NA/N}; echo "$h $((${#x}-${#y}))"; done


-- 
Deutsche Telekom AG
Seamless ICT Security Infrastructure & Management im Auftrag T-Systems 
International GmbH
Dipl. Inf Alexander Elgert Langwadener Strasse 17 64625 Bensheim
+49 176 22 717 661 (Mobil)
+49 671 9683-12 (Tel)
+49 671 9683-30 (Fax)
E-Mail: alexander.elg...@gmx.de

Re: How to lock a terminal

[John McKown]

Try a

Ctrl-X

That worked for me with the exact same command line as yours. It exits nano.

On Mon, Feb 15, 2016 at 11:24 AM, Nick Warne  wrote:

> Hi Everybody,
>
> I ma not sure if this is a bug, or if it is what causes it - if it isn't,
> then it is me being stupid.
>
> 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.
>
> I don't know if this behaviour is expected or me being stupid, or
> something else going on.
>
> Regards,
>
> Nick
> --
> 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"
>
>


-- 
The man has the intellect of a lobotomized turtle.

Maranatha! <><
John McKown

Re: redraw-current-line fails with multiline prompts

[Hugh Davenport]

February 16 2016 10:22 AM, "Chet Ramey"  wrote:
> On 2/15/16 3:57 PM, Hugh Davenport wrote:
> 
>> February 16 2016 9:11 AM, "Chet Ramey"  wrote:
>>> On 2/12/16 12:45 AM, Hugh Davenport wrote:
>>> 
 Bash Version: 4.3
 Patch Level: 30
 Release Status: release
 
 Description:
 Assume I have a multiline prompt (`PS1="first\nsecond"`), and a bind to
 redraw-current-line (`bind '"\er": redraw-current-line'`). When I
 refresh the line with M-r, I get the following output:
 first
 first
 second
 
 What is happening is that the redraw-current-line is assuming that I
 only have a single line prompt, and is just redrawing that current
 line. Two possible solutions to this are:
 1) Work out the last line of the prompt and only redraw that (makes
 sense with function name, or
 2) Work out number of lines in the prompt, and redraw entire prompt.
 
 Repeat-By:
 Have a rc file with the following
 PS1="first\nsecond"
 bind '"\er": redraw-current-line'
 
 Then start bash with that rc file, and hit M-r a few times, notice that
 the last line gets overwritten, but the first line doesn't. You can
 expand this by having PS="first\nsecond\nthird" and seeing that the
 third line gets overwritten, but not the first and the second. This
 leads to a lot of wasted vertical space if you are redrawing often.
 
 Fix:
 I've got a patch for option 2, which works well with existing methods,
 but makes the function name a bit misleading.
>>> 
>>> Thanks for the report. It's sufficient to change the call from
>>> rl_forced_update_display to rl_redraw_prompt_last_line (your option 1).
>>> This is what bash does for bash_execute_unix_command().
>> 
>> Hey Chet,
>> 
>> Thanks for your reply. OK, so my patch doesn't need that weird for loop.
>> I couldn't find the redraw_prompt_last_line function when I had a quick
>> search.
> 
> This is something that will be in bash-4.4/readline-7.0. You can get the
> current development sources to see how it will work. According to my
> change logs, it was added in November, 2014.

Cool, will grab the sources to test at some time, otherwise will wait for it
to be released to integrate it with the tool I'm playing with.

Cheers,

Hugh
> 
> Chet
> 
> --
> ``The lyf so short, the craft so long to lerne.'' - Chaucer
> ``Ars longa, vita brevis'' - Hippocrates
> Chet Ramey, ITS, CWRU c...@case.edu http://cnswww.cns.cwru.edu/~chet

How to lock a terminal

[Nick Warne]

Hi Everybody,

I ma not sure if this is a bug, or if it is what causes it - if it 
isn't, then it is me being stupid.


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.


I don't know if this behaviour is expected or me being stupid, or 
something else going on.


Regards,

Nick
--
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: redraw-current-line fails with multiline prompts

[Chet Ramey]

On 2/15/16 3:57 PM, Hugh Davenport wrote:
> February 16 2016 9:11 AM, "Chet Ramey"  wrote:
>> On 2/12/16 12:45 AM, Hugh Davenport wrote:
>>
>>> Bash Version: 4.3
>>> Patch Level: 30
>>> Release Status: release
>>>
>>> Description:
>>> Assume I have a multiline prompt (`PS1="first\nsecond"`), and a bind to
>>> redraw-current-line (`bind '"\er": redraw-current-line'`). When I
>>> refresh the line with M-r, I get the following output:
>>> first
>>> first
>>> second
>>>
>>> What is happening is that the redraw-current-line is assuming that I
>>> only have a single line prompt, and is just redrawing that current
>>> line. Two possible solutions to this are:
>>> 1) Work out the last line of the prompt and only redraw that (makes
>>> sense with function name, or
>>> 2) Work out number of lines in the prompt, and redraw entire prompt.
>>>
>>> Repeat-By:
>>> Have a rc file with the following
>>> PS1="first\nsecond"
>>> bind '"\er": redraw-current-line'
>>>
>>> Then start bash with that rc file, and hit M-r a few times, notice that
>>> the last line gets overwritten, but the first line doesn't. You can
>>> expand this by having PS="first\nsecond\nthird" and seeing that the
>>> third line gets overwritten, but not the first and the second. This
>>> leads to a lot of wasted vertical space if you are redrawing often.
>>>
>>> Fix:
>>> I've got a patch for option 2, which works well with existing methods,
>>> but makes the function name a bit misleading.
>>
>> Thanks for the report. It's sufficient to change the call from
>> rl_forced_update_display to rl_redraw_prompt_last_line (your option 1).
>> This is what bash does for bash_execute_unix_command().
> 
> Hey Chet,
> 
> Thanks for your reply. OK, so my patch doesn't need that weird for loop.
> I couldn't find the redraw_prompt_last_line function when I had a quick
> search.

This is something that will be in bash-4.4/readline-7.0.  You can get the
current development sources to see how it will work.  According to my
change logs, it was added in November, 2014.

Chet

-- 
``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)

[Chet Ramey]

On 2/15/16 3:48 PM, Linda Walsh wrote:
> 
> 
> Chet Ramey wrote:
>> On 2/15/16 12:35 PM, Linda Walsh wrote:
>>
>>  
>>> Bash Version: 4.3
>>> Patch Level: 42
>>> Release Status: release
>>>
>>> Description:
>>> [Detailed description of the problem, suggestion, or complaint.]
>>>
>>> When I create hash and later add keys using the form
>>> "HASH+=([key]=VALUE)", if KEY already existed in the HASH, then
>>> I get the += applied to the VALUE as well
>>> (strings get appended, ints get added).
>>>
>>> Whether '+=' or '=' is used in the VALUE assignment, the
>>> effect is '+='.
>>> 
>>
>> http://lists.gnu.org/archive/html/bug-bash/2014-11/msg00169.html
>> http://lists.gnu.org/archive/html/bug-bash/2014-11/msg00179.html
>>   
> 
> Right... and?
> 
> Did it never make it in to 4.3?  

It will be in bash-4.4.


-- 
``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: redraw-current-line fails with multiline prompts

[Hugh Davenport]

February 16 2016 9:11 AM, "Chet Ramey"  wrote:
> On 2/12/16 12:45 AM, Hugh Davenport wrote:
> 
>> Bash Version: 4.3
>> Patch Level: 30
>> Release Status: release
>> 
>> Description:
>> Assume I have a multiline prompt (`PS1="first\nsecond"`), and a bind to
>> redraw-current-line (`bind '"\er": redraw-current-line'`). When I
>> refresh the line with M-r, I get the following output:
>> first
>> first
>> second
>> 
>> What is happening is that the redraw-current-line is assuming that I
>> only have a single line prompt, and is just redrawing that current
>> line. Two possible solutions to this are:
>> 1) Work out the last line of the prompt and only redraw that (makes
>> sense with function name, or
>> 2) Work out number of lines in the prompt, and redraw entire prompt.
>> 
>> Repeat-By:
>> Have a rc file with the following
>> PS1="first\nsecond"
>> bind '"\er": redraw-current-line'
>> 
>> Then start bash with that rc file, and hit M-r a few times, notice that
>> the last line gets overwritten, but the first line doesn't. You can
>> expand this by having PS="first\nsecond\nthird" and seeing that the
>> third line gets overwritten, but not the first and the second. This
>> leads to a lot of wasted vertical space if you are redrawing often.
>> 
>> Fix:
>> I've got a patch for option 2, which works well with existing methods,
>> but makes the function name a bit misleading.
> 
> Thanks for the report. It's sufficient to change the call from
> rl_forced_update_display to rl_redraw_prompt_last_line (your option 1).
> This is what bash does for bash_execute_unix_command().

Hey Chet,

Thanks for your reply. OK, so my patch doesn't need that weird for loop.
I couldn't find the redraw_prompt_last_line function when I had a quick
search.

Would that change be something that you would do to replace the readline
function binding redraw_current_line, or would it be something else that
would be exposed? It would be great if there was a way to redraw the prompt
without it generating a lot of extra vertical lines.

Cheers,

Hugh
> 
> Chet
> 
> --
> ``The lyf so short, the craft so long to lerne.'' - Chaucer
> ``Ars longa, vita brevis'' - Hippocrates
> Chet Ramey, ITS, CWRU c...@case.edu http://cnswww.cns.cwru.edu/~chet

Re: bug adding K,V pairs to existing hash with HASH+=([K]=V)

[Linda Walsh]

Chet Ramey wrote:

On 2/15/16 12:35 PM, Linda Walsh wrote:

  

Bash Version: 4.3
Patch Level: 42
Release Status: release

Description:
[Detailed description of the problem, suggestion, or complaint.]

When I create hash and later add keys using the form
"HASH+=([key]=VALUE)", if KEY already existed in the HASH, then
I get the += applied to the VALUE as well
(strings get appended, ints get added).

Whether '+=' or '=' is used in the VALUE assignment, the
effect is '+='.



http://lists.gnu.org/archive/html/bug-bash/2014-11/msg00169.html
http://lists.gnu.org/archive/html/bug-bash/2014-11/msg00179.html
  


Right... and?

Did it never make it in to 4.3?  (Note, the "auto generated info
included with this bug report was wrong -- as explained in next bug
report...)

Re: Add a mirror to github

[Chet Ramey]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2/15/16 9:49 AM, Eric Blake wrote:

> In other words, if you DO add a github mirror, discussion of patches
> will still need to take place on this list, and not move to github.

The authoritative place for discussions about bash will remain this
list regardless of whether or not someone sets up a mirror on github.

Chet
- -- 
``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/
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iEYEARECAAYFAlbCNMsACgkQu1hp8GTqdKu49wCggIFpBgah/o1Goex7LLRqaTCx
VvwAnRCPbwY5LqvxxXWe2r98nGClMU1o
=KEB3
-END PGP SIGNATURE-

Re: Add a mirror to github

[Chet Ramey]

On 2/14/16 1:41 AM, konsolebox wrote:
> Hi Chet,
> 
> Please consider adding a mirror of bash's git repo in github.com.  It
> would be easier for many people in the community to contribute code
> and discuss it there.

There's nothing stopping people from doing that now, and I'd rather
discussions take place on this list.

-- 
``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: redraw-current-line fails with multiline prompts

[Chet Ramey]

On 2/12/16 12:45 AM, Hugh Davenport wrote:

> Bash Version: 4.3
> Patch Level: 30
> Release Status: release
> 
> Description:
>   Assume I have a multiline prompt (`PS1="first\nsecond"`), and a bind to
>   redraw-current-line (`bind '"\er": redraw-current-line'`). When I
>   refresh the line with M-r, I get the following output:
>   first
>   first
>   second
> 
>   What is happening is that the redraw-current-line is assuming that I
>   only have a single line prompt, and is just redrawing that current
>   line. Two possible solutions to this are:
> 1) Work out the last line of the prompt and only redraw that (makes
>   sense with function name, or
> 2) Work out number of lines in the prompt, and redraw entire prompt.
> 
> Repeat-By:
>   Have a rc file with the following
>   PS1="first\nsecond"
>   bind '"\er": redraw-current-line'
> 
>   Then start bash with that rc file, and hit M-r a few times, notice that
>   the last line gets overwritten, but the first line doesn't. You can
>   expand this by having PS="first\nsecond\nthird" and seeing that the
>   third line gets overwritten, but not the first and the second. This
>   leads to a lot of wasted vertical space if you are redrawing often.
> 
> Fix:
>   I've got a patch for option 2, which works well with existing methods,
>   but makes the function name a bit misleading.

Thanks for the report.  It's sufficient to change the call from
rl_forced_update_display to rl_redraw_prompt_last_line (your option 1).
This is what bash does for bash_execute_unix_command().

Chet

-- 
``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: 'bashbug behavior and doc problem(s)...

[Linda Walsh]

Greg Wooledge wrote:

On Mon, Feb 15, 2016 at 10:31:24AM -0800, LA Walsh wrote:
  

Ended up looking at manpage, where it says under "ENVIRONMENT":

 EDITOR Specifies the preferred editor. If EDITOR is not set, bashbug
defaults to emacs.



This is not correct (probably it used to be).  bashbug defaults to
/usr/bin/editor if that exists, then ce, then emacs (it looks in
multiple places, but doesn't check the PATH variable), then jove,
then finally vi.
  

wow...

I'm guessing your operating system has a /usr/bin/editor symlink
that points to gvim.
  

nep

 whence editor ce emacs jove vi

-bash: type: editor: not found
-bash: type: ce: not found
emacs is /usr/bin/emacs
emacs is /usr/bin/X11/emacs
-bash: type: jove: not found
vi is /usr/bin/vi
vi is /bin/vi
vi is /usr/bin/X11/vi

 ll {,/usr}/bin/{editor,ce,emacs,jove,vi}

ls: cannot access /bin/editor: No such file or directory
ls: cannot access /bin/ce: No such file or directory
ls: cannot access /bin/emacs: No such file or directory
ls: cannot access /bin/jove: No such file or directory
ls: cannot access /usr/bin/editor: No such file or directory
ls: cannot access /usr/bin/ce: No such file or directory
ls: cannot access /usr/bin/jove: No such file or directory
lrwxrwxrwx  1  3 May 27  2015 /bin/vi -> vim*
-rwxrwxr-x+ 2 28 Sep  3  2011 /usr/bin/emacs*
lrwxrwxrwx  1  8 May 27  2015 /usr/bin/vi -> /bin/vim*
---

It would find 'emacs' first, hmmm 28 bytes? ah HA!:

 more /usr/bin/emacs

#!/bin/bash
exec gvim "$@"

Well, at least that makes some sense...still...
the idea of using your cmdline editing mode to select
a default seems a bit more userfriendly, IMO ;-)

Re: Add a mirror to github

[Charles Daffern]

On 15/02/16 17:53, strom...@gmail.com wrote:
> On Monday, February 15, 2016 at 6:19:56 AM UTC-8, Chet Ramey wrote:
>> How does setting up a different place for people to get the code
>> contribute to a software monoculture? 
> github is becoming too popular for free software's own good.
>
> It's to the point that some people feel like if it's not on github, it's not 
> worth looking at.
I think hosting on a site like GitLab or BitBucket might be a good
compromise. It's essentially the same thing: a fancy web interface that
obviates the need for locally checked-out code. GitLab's community
edition is free software, and there are several online instances of that
software separate from GitLab's main website (which runs the nonfree
version).

It's a vain hope of mine that adding popular projects to hosts other
than GitHub might stop people from conflating "git" (the tool) with
"GitHub" (the website). Unfortunately I don't think that will ever happen.

All that said, I don't see what tangible benefit you would get from
mirroring the source repo on any of those sites. I don't think it vastly
improves readability, and since they all lack features like jumping to
symbol definitions, in the case of multiple files it greatly harms
readability compared to bog-standard vim with ctags. The only thing
you'd get out of it really is an issue tracker, and I doubt people are
going to move all discussion to some external website without a good
reason to do so.



signature.asc
Description: OpenPGP digital signature

Re: 'bashbug behavior and doc problem(s)...

[Greg Wooledge]

On Mon, Feb 15, 2016 at 10:31:24AM -0800, LA Walsh wrote:
> Ended up looking at manpage, where it says under "ENVIRONMENT":
> 
>  EDITOR Specifies the preferred editor. If EDITOR is not set, bashbug
> defaults to emacs.

This is not correct (probably it used to be).  bashbug defaults to
/usr/bin/editor if that exists, then ce, then emacs (it looks in
multiple places, but doesn't check the PATH variable), then jove,
then finally vi.

I'm guessing your operating system has a /usr/bin/editor symlink
that points to gvim.

Re: bug adding K,V pairs to existing hash with HASH+=([K]=V)

[Chet Ramey]

On 2/15/16 12:35 PM, Linda Walsh wrote:

> Bash Version: 4.2
> Patch Level: 53
> Release Status: release
> 
> Description:
>   [Detailed description of the problem, suggestion, or complaint.]
> 
>   When I create hash and later add keys using the form
> "HASH+=([key]=VALUE)", if KEY already existed in the HASH, then
> I get the += applied to the VALUE as well
> (strings get appended, ints get added).
> 
> Whether '+=' or '=' is used in the VALUE assignment, the
> effect is '+='.

http://lists.gnu.org/archive/html/bug-bash/2014-11/msg00169.html
http://lists.gnu.org/archive/html/bug-bash/2014-11/msg00179.html

-- 
``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/

'bashbug behavior and doc problem(s)...

[LA Walsh]

Configuration Information [Automatically generated, do not change]:

(NOTE: The automatically generated information is incorrect.
Just noticed it came from the suse build which is has joined
the dumb-down movement -- part of which is moving random
binaries & libs from the root partition (/bin /lib[64]) to
the /usr parition and putting 'symlinks' in the root
partition pointing to the later-mounted /usr partition that
are mounted via /bin/mount, a symlink pointing to
/usr/bin/mount, and with some libraries in /bin and some
libraries in /usr/bin.  Which they didn't see as being an
inherently less-reliable setup than putting boot-related
binaries and libs in /{bin,lib{64}} because they no longer
support users booting from their hard disk, but only
a 'ramdisk' image that they can encrypt and sign with
a microsoft-issued key (only type that will be able to
launch Windows on newer UEFI-only BIOS's) -- all in the name
of gaining a "trusted boot env", so your home linux machine
can be locked-down like Win10, game consoles, and
smartphones, and provide a secure-platform for their
parent company, Attachmate, to use to distribute
their office appliances among others.

Anyway, the correct information is below:

Machine: x86_64
OS: linux-gnu
Compiler: /usr/bin/gcc
Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' 
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-unknown-linux-gnu' 
-DCONF_VENDOR='unknown' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' 
-DSHELL -DHAVE_CONFIG_H   -I.  -I. -I./include -I./lib   -O2  -m64  -fpic 
-fasynchronous-unwind-tables  -fbranch-target-load-optimize  
-fdelete-null-pointer-checks  -fgcse-after-reload  -fgcse-las  -fgcse-sm  
-fgraphite-identity  -finline-functions -fipa-pta  -fivopts  -floop-block  
-floop-flatten  -floop-interchange  -floop-strip-mine  -fmessage-length=0  
-fpredictive-commoning  -frename-registers  -freorder-blocks-and-partition 
-ftracer -fsched-stalled-insns=1 -fsched-stalled-insns-dep=1 -ftree-loop-linear 
 -ftree-loop-distribution  -ftree-loop-distribute-patterns  -ftree-loop-im  
-ftree-loop-ivcanon  -ftree-vectorize  -ftree-slp-vectorize  -funswitch-loops  
-funwind-tables  -fvariable-expansion-in-unroller  -fvect-cost-model  -fweb  
-march=native -pipe -fuse-linker-plugi!
 n 
uname output: Linux Ishtar 4.1.0-Isht-Van #2 SMP PREEMPT Tue Jun 23 07:52:09 
PDT 2015 x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-unknown-linux-gnu

Bash Version: 4.3
Patch Level: 42
Release Status: release

Description:
Tried using bashbug for the 1st time.  Got:

> bashbug

/usr/bin/bashbug: You have not changed the subject from the default.
/usr/bin/bashbug: Please use a more descriptive subject header.
/usr/bin/bashbug: Type `y' to give up, and lose your bug report;
/usr/bin/bashbug: type `n' to re-enter the editor.
/usr/bin/bashbug: Do you want to give up? ^C^C^Y
[1]+  Stopped bashbug
Ishtar:/tmp> kill %1
[1]+  Exit 1  bashbug
---

It launched "gvim" in another window.  The graphical version
of vim automatically backgrounds unless told not to.

I don't know why it launched gvim.  When I really want to
edit using "EDITOR", I set it to "gvim -f" (to tell it to
run in foreground).  **Usually**, when I am in bash, if I am
editing the line, and press 'v', it brings up 'vim' in the
same window -- which I "leave" for reliability's sake, and
manually set EDITOR for times when I want it in a separate
window w/better color.

Ended up looking at manpage, where it says under "ENVIRONMENT":

 EDITOR Specifies the preferred editor. If EDITOR is not set, bashbug
defaults to emacs.

(which it doesn't -- it invoked gvim (!?).  I would have thought
it would have used the same editor used when pressing 'v' when
re-editing a line -- where it brings up 'vim' (maybe because
I edit in 'vi mode'?).  But it doesn't bring up 'gvim'
unless I set EDITOR (I guess it is normally unset).


Repeat-By:

For me, I just ran bashbug, EDITOR was unset.

Fix:

I'd suggest using the same mode that your command-line
re-editing uses.  (i.e. the value that you get when pressing
'v' when editing a command on the cmdline).  Since it would
be hard to know whether or not an editor (like a graphical
editor) would auto-background or not -- the user can be
responsible for adding flags to 'EDITOR' so that their
GUI-editor won't auto-bg.

Also, might want to correct the manpage to reflect the fix.  

Re: Add a mirror to github

[John McKown]

What's wrong with just using git://git.savannah.gnu.org/bash.git
​ ? Why github.com? Granted, it's popular. Of course, you could simply make
your own fork of the savannah repository on Github yourself. Why expect
Chet to do it? You could do something like:

git clone git://git.savannah.gnu.org/bash.git
cd bash
git remote add github g...@github.com:konsolebox:/bash.git
git push --mirror github  #assumes you've create bash.git repo

Then, using a CRON table entry, run a daily script similar to:

#!/bin/sh
cd ~/bash
git pull origin && \
git push --mirror github

​


On Sun, Feb 14, 2016 at 12:41 AM, konsolebox  wrote:

> Hi Chet,
>
> Please consider adding a mirror of bash's git repo in github.com.  It
> would be easier for many people in the community to contribute code
> and discuss it there.
>
> --
> konsolebox
>
>


-- 
The man has the intellect of a lobotomized turtle.

Maranatha! <><
John McKown

Re: List out

[Allodoxaphobia]

On Mon, 15 Feb 2016 08:19:37 -0500, Greg Wooledge wrote:
> On Sun, Feb 14, 2016 at 03:02:58AM +, Allodoxaphobia wrote:
>> err... u... What's your *bash bug* ???
>
> I think what he meant to say is, "Questions of this type should be
> sent to help-b...@gnu.org instead of bug-bash@gnu.org."
>
> Now... you've been given a Python solution, and I could write one in
> Tcl or Perl as well.  Using pure bash for this task would be an utterly
> poor choice, for performance reasons.
>
> The closest thing to a pure bash answer you can get, that would actually
> be viable in real life, would be one using awk.
>
> awk '
>   {
> n=0
> label=$2
> for (i=3; i<=NF; i++) {
>   if ($i == "NA") n++
> }
> print NR ".", label, n
>   }
> ' "$file"

Remeber to _always_ reply to homework assignments with 
the most advanced and obscure solutions so as to make 
the teacher/professor say "WHAT THE HELL...?!?!?!"

Re: Add a mirror to github

[strombrg]

On Monday, February 15, 2016 at 6:19:56 AM UTC-8, Chet Ramey wrote:
> On 2/14/16 12:53 PM, strom...@gmail.com wrote:
> > On Saturday, February 13, 2016 at 10:42:37 PM UTC-8, konsolebox wrote:
> >> Hi Chet,
> >>
> >> Please consider adding a mirror of bash's git repo in github.com.  It
> >> would be easier for many people in the community to contribute code
> >> and discuss it there.
> > 
> > Chet probably has his own thoughts on this, but IMNSHO, software 
> > monoculture is bad.
> 
> How does setting up a different place for people to get the code contribute
> to a software monoculture?

github is becoming too popular for free software's own good.

It's to the point that some people feel like if it's not on github, it's not 
worth looking at.

bug adding K,V pairs to existing hash with HASH+=([K]=V)

[Linda Walsh]

Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc -I/home/abuild/rpmbuild/BUILD/bash-4.2 
-L/home/abuild/rpmbuild/BUILD/bash-4.2/../readline-6.2
Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' 
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-suse-linux-gnu' 
-DCONF_VENDOR='suse' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL 
-DHAVE_CONFIG_H   -I.  -I. -I./include -I./lib   -fmessage-length=0 
-grecord-gcc-switches -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector 
-funwind-tables -fasynchronous-unwind-tables -g  -D_GNU_SOURCE -DRECYCLES_PIDS 
-Wall -g -Wuninitialized -Wextra -Wno-unprototyped-calls -Wno-switch-enum 
-Wno-unused-variable -Wno-unused-parameter -ftree-loop-linear -pipe 
-DBNC382214=0 -DIMPORT_FUNCTIONS_DEF=0 -fprofile-use
uname output: Linux Ishtar 4.1.0-Isht-Van #2 SMP PREEMPT Tue Jun 23 07:52:09 
PDT 2015 x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-suse-linux-gnu

Bash Version: 4.2
Patch Level: 53
Release Status: release

Description:
[Detailed description of the problem, suggestion, or complaint.]

When I create hash and later add keys using the form
"HASH+=([key]=VALUE)", if KEY already existed in the HASH, then
I get the += applied to the VALUE as well
(strings get appended, ints get added).

Whether '+=' or '=' is used in the VALUE assignment, the
effect is '+='.

  Can I suggest that, maybe, this "interesting" behavior be
limited to the in-parens, "[KEY][+]=VAL" part?

Repeat-By:
(Example)

> alias sv='my -p'  #(show_var)
> hash cfg=(); sv cfg
declare -A cfg='()' #empty hash

> cfg+=([one]=1 [two]=2) ; sv cfg
declare -A cfg='([one]="1" [two]="2" )' #two elements

> cfg+=([two]=2 [three]=3) ; sv cfg
declare -A cfg='([one]="1" [two]="22" [three]="3" )'  #Note key 'two'

> int cfg  # switch existing hash to integers.
   # explicitly use += in some
> cfg+=([one]+=1 [two]=2 [three]+=0-3 )# VALUE assignments
> sv cfg
declare -Ai cfg='([one]="2" [two]="24" [three]="0" )'


Fix:
Honor "=" to mean "set" and allow "+=" to continue to 
access this behavior.

Re: Comma expression in arithmetic evaluation referring to arrays make bash crash.

[Stephane Chazelas]

[...]
> Reproduced with 4.2.53 on Debian:
[...]



Actually, it was already reported in early 2013 and fixed for
4.3:

http://thread.gmane.org/gmane.comp.shells.bash.bugs/19384

-- 
Stephane

Re: Comma expression in arithmetic evaluation referring to arrays make bash crash.

[Stephane Chazelas]

2016-02-15 09:31:57 -0500, Chet Ramey:
> On 2/15/16 8:57 AM, Pontus Stenström wrote:
> 
> > Bash Version: 4.2
> > Patch Level: 24
> > Release Status: release
> > 
> > Description:
> > Comma expression in arithmetic evaluation referring to arrays make bash
> > crash.
> > 
> > Repeat-By:
> > This works fine:
> > ((c=3, d=4))
> > This crashes my bash:
> > a=(2 3 4 5)# OK
> > ((c=a[3], d=a[2])) # Crash
> 
> It runs fine on bash-4.3.42 on RHEL 5 and Mac OS X.
[...]

Reproduced with 4.2.53 on Debian:

Starting program: bash4.2.53 -c a=\(1\ 2\ 3\ 4\ 5\ 6\)\;\ \(\(b=a\[3\],\ 
c=a\[4\]\)\)\;\ typeset\ -p\ b\ c

Program received signal SIGSEGV, Segmentation fault.
strlen () at ../sysdeps/x86_64/strlen.S:106
106 ../sysdeps/x86_64/strlen.S: No such file or directory.
(gdb) bt
#0  strlen () at ../sysdeps/x86_64/strlen.S:106
#1  0x0043c952 in expr_bind_array_element (tok=tok@entry=0x6f5328 "c", 
ind=ind@entry=3, rhs=rhs@entry=0x6f5318 "5") at expr.c:331
#2  0x0043e2c8 in expassign () at expr.c:531
#3  0x0043d532 in expcomma () at expr.c:441
#4  0x0043d736 in subexpr (expr=0x6fb7c8 "b=a[3], c=a[4]") at expr.c:419
#5  0x0043e5ca in evalexp (expr=0x6fb7c8 "b=a[3], c=a[4]", 
validp=0x7fffda90) at expr.c:384
#6  0x004321d8 in execute_arith_command (arith_command=, 
arith_command=) at execute_cmd.c:3309
#7  execute_command_internal (command=0x6fb508, asynchronous=0, 
pipe_in=7320904, pipe_out=0, fds_to_close=0x6fdc88) at execute_cmd.c:901
#8  0x00432859 in execute_connection (fds_to_close=, 
pipe_out=, pipe_in=, asynchronous=,
command=) at execute_cmd.c:2326
#9  execute_command_internal (command=0x6fb5c8, asynchronous=0, pipe_in=-1, 
pipe_out=-1, fds_to_close=0x6fb7a8) at execute_cmd.c:891
#10 0x00433fce in execute_command (command=0x6fb5c8) at 
execute_cmd.c:382
#11 0x0043281e in execute_connection (fds_to_close=, 
pipe_out=, pipe_in=, asynchronous=,
command=) at execute_cmd.c:2324
#12 execute_command_internal (command=0x6fb748, asynchronous=0, pipe_in=-1, 
pipe_out=-1, fds_to_close=0x6fb788) at execute_cmd.c:891
#13 0x00471024 in parse_and_execute (string=, 
from_file=from_file@entry=0x4a990d "-c", flags=flags@entry=4) at 
evalstring.c:340
#14 0x0041d9ba in run_one_command (command=) at 
shell.c:1315
#15 0x0041c786 in main (argc=3, argv=0x7fffdf78, 
env=0x7fffdf98) at shell.c:688

See how it calls expr_bind_array_element on "c" as if it wanted
to assign something to c[3] instead of c. The 3 looks like it
comes from the previous a[3] expansion.

-- 
Stephane

Re: Comma expression in arithmetic evaluation referring to arrays make bash crash.

[Pontus Stenström]

Thanks,
it also works fine in GNU bash, version 4.3.42(4)-release (i686-pc-cygwin)
Sorry for troubbling you, I will upgrade my bash.
Regards -- Pontus



From:   Greg Wooledge 
To: Chet Ramey 
Cc: Pontus Stenström , bug-bash@gnu.org
Date:   2016-02-15 15:47
Subject:Re: Comma expression in arithmetic evaluation referring to 
arrays make bash crash.



On Mon, Feb 15, 2016 at 09:31:57AM -0500, Chet Ramey wrote:
> On 2/15/16 8:57 AM, Pontus Stenström wrote:
> 
> > Bash Version: 4.2
> > Patch Level: 24
> > Release Status: release
> > 
> > Description:
> > Comma expression in arithmetic evaluation referring to arrays make 
bash
> > crash.
> > 
> > Repeat-By:
> > This works fine:
> > ((c=3, d=4))
> > This crashes my bash:
> > a=(2 3 4 5)# OK
> > ((c=a[3], d=a[2])) # Crash
> 
> It runs fine on bash-4.3.42 on RHEL 5 and Mac OS X.

On HP-UX, it doesn't crash, but doesn't work quite right either:

imadev:~$ bash-4.2 -c 'echo "$BASH_VERSION"; a=(2 3 4 5); ((c=a[3], 
d=a[2])); declare -p a c d'
4.2.46(1)-release
declare -a a='([0]="2" [1]="3" [2]="4" [3]="5")'
declare -- c="5"
bash-4.2: line 0: declare: d: not found

4.2 is the second-newest release, but 4.2.24 is 29 patches behind.
The current patch level for 4.2 is 4.2.53.  I'm apparently a bit behind
the current patch level as well.

It works in 4.3, as Chet said.





You are hereby formally notified that all information contained in this 
communication and any attachments shall be deemed strictly confidential 
and privileged unless explicitly stated otherwise. Please note that your 
use of confidential information may be governed, and restricted, by a 
non-disclosure agreement. The information contained in this communication 
and any attachments is disclosed for the sole use of the intended 
recipient(s). If you are not the intended recipient, you are hereby 
formally notified that any unauthorized review, use, disclosure or 
distribution of this message is prohibited. Please notify the sender 
immediately by replying to this message and destroy all copies of this 
message and any attachments. Mycronic is neither liable for the proper and 
complete transmission of the information contained in this communication, 
nor for any delay in its receipt.

Re: Add a mirror to github

[Eric Blake]

On 02/13/2016 11:41 PM, konsolebox wrote:
> Hi Chet,
> 
> Please consider adding a mirror of bash's git repo in github.com.  It
> would be easier for many people in the community to contribute code
> and discuss it there.

Add your own mirror.  Nothing is stopping you from doing it.  But the
canonical upstream repo should NOT live on github.com, since that site
actively promotes the use of non-free software.  I don't care if you
want to pull from github, but I do care if you make me try to use
github's add-on features above and beyond what I can already do using
only free software without using github.

In other words, if you DO add a github mirror, discussion of patches
will still need to take place on this list, and not move to github.

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: Comma expression in arithmetic evaluation referring to arrays make bash crash.

[Greg Wooledge]

On Mon, Feb 15, 2016 at 09:31:57AM -0500, Chet Ramey wrote:
> On 2/15/16 8:57 AM, Pontus Stenström wrote:
> 
> > Bash Version: 4.2
> > Patch Level: 24
> > Release Status: release
> > 
> > Description:
> > Comma expression in arithmetic evaluation referring to arrays make bash
> > crash.
> > 
> > Repeat-By:
> > This works fine:
> > ((c=3, d=4))
> > This crashes my bash:
> > a=(2 3 4 5)# OK
> > ((c=a[3], d=a[2])) # Crash
> 
> It runs fine on bash-4.3.42 on RHEL 5 and Mac OS X.

On HP-UX, it doesn't crash, but doesn't work quite right either:

imadev:~$ bash-4.2 -c 'echo "$BASH_VERSION"; a=(2 3 4 5); ((c=a[3], d=a[2])); 
declare -p a c d'
4.2.46(1)-release
declare -a a='([0]="2" [1]="3" [2]="4" [3]="5")'
declare -- c="5"
bash-4.2: line 0: declare: d: not found

4.2 is the second-newest release, but 4.2.24 is 29 patches behind.
The current patch level for 4.2 is 4.2.53.  I'm apparently a bit behind
the current patch level as well.

It works in 4.3, as Chet said.

Re: Comma expression in arithmetic evaluation referring to arrays make bash crash.

[Chet Ramey]

On 2/15/16 8:57 AM, Pontus Stenström wrote:

> Bash Version: 4.2
> Patch Level: 24
> Release Status: release
> 
> Description:
> Comma expression in arithmetic evaluation referring to arrays make bash
> crash.
> 
> Repeat-By:
> This works fine:
> ((c=3, d=4))
> This crashes my bash:
> a=(2 3 4 5)# OK
> ((c=a[3], d=a[2])) # Crash

It runs fine on bash-4.3.42 on RHEL 5 and Mac OS X.

-- 
``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: Add a mirror to github

[Chet Ramey]

On 2/14/16 12:53 PM, strom...@gmail.com wrote:
> On Saturday, February 13, 2016 at 10:42:37 PM UTC-8, konsolebox wrote:
>> Hi Chet,
>>
>> Please consider adding a mirror of bash's git repo in github.com.  It
>> would be easier for many people in the community to contribute code
>> and discuss it there.
> 
> Chet probably has his own thoughts on this, but IMNSHO, software monoculture 
> is bad.

How does setting up a different place for people to get the code contribute
to a software monoculture?

Chet
-- 
``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/

Comma expression in arithmetic evaluation referring to arrays make bash crash.

[Pontus Stenström]

 Configuration Information [Automatically generated, do not change]:Machine: x86_64OS: linux-gnuCompiler: gcc -I/home/abuild/rpmbuild/BUILD/bash-4.2 -L/home/abuild/rpmbuild/BUILD/bash-4.2/../readline-6.2Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-suse-linux-gnu' -DCONF_VENDOR='suse' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H   -I.  -I. -I./include -I./lib   -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g  -D_GNU_SOURCE -DRECYCLES_PIDS -Wall -g -std=gnu89 -Wuninitialized -Wextra -Wno-unprototyped-calls -Wno-switch-enum -Wno-unused-variable -Wno-unused-parameter -ftree-loop-linear -pipe -fprofile-useuname output: Linux urd 3.4.11-2.16-desktop #1 SMP PREEMPT Wed Sep 26 17:05:00 UTC 2012 (259fc87) x86_64 x86_64 x86_64 GNU/LinuxMachine Type: x86_64-suse-linux-gnuBash Version: 4.2Patch Level: 24Release Status: releaseDescription:    Comma _expression_ in arithmetic evaluation referring to arrays make bash crash.Repeat-By:    This works fine:    ((c=3, d=4))    This crashes my bash:    a=(2 3 4 5)    # OK    ((c=a[3], d=a[2])) # CrashWarning: Program '/bin/bash' crashed.You are hereby formally notified that all information contained in this communication and any attachments shall be deemed strictly confidential and privileged unless explicitly stated otherwise. Please note that your use of confidential information may be governed, and restricted, by a non-disclosure agreement. The information contained in this communication and any attachments is disclosed for the sole use of the intended recipient(s). If you are not the intended recipient, you are hereby formally notified that any unauthorized review, use, disclosure or distribution of this message is prohibited. Please notify the sender immediately by replying to this message and destroy all copies of this message and any attachments. Mycronic is neither liable for the proper and complete transmission of the information contained in this communication, nor for any delay in its receipt.

Re: List out

[Greg Wooledge]

On Sun, Feb 14, 2016 at 03:02:58AM +, Allodoxaphobia wrote:
> err... u... What's your *bash bug* ???

I think what he meant to say is, "Questions of this type should be
sent to help-b...@gnu.org instead of bug-bash@gnu.org."

Now... you've been given a Python solution, and I could write one in
Tcl or Perl as well.  Using pure bash for this task would be an utterly
poor choice, for performance reasons.

The closest thing to a pure bash answer you can get, that would actually
be viable in real life, would be one using awk.

awk '
  {
n=0
label=$2
for (i=3; i<=NF; i++) {
  if ($i == "NA") n++
}
print NR ".", label, n
  }
' "$file"