Re: List out
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"
Comma expression in arithmetic evaluation referring to arrays make bash crash.
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: Add a mirror to github
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/
Re: Comma expression in arithmetic evaluation referring to arrays make bash crash.
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: 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.
Re: Add a mirror to github
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.
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: Comma expression in arithmetic evaluation referring to arrays make bash crash.
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.
[...] > 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
bug adding K,V pairs to existing hash with HASH+=([K]=V)
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: Add a mirror to github
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.
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...?!?!?!"
Re: Add a mirror to github
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
'bashbug behavior and doc problem(s)...
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: bug adding K,V pairs to existing hash with HASH+=([K]=V)
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/
Re: 'bashbug behavior and doc problem(s)...
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: Add a mirror to github
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 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: redraw-current-line fails with multiline prompts
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: Add a mirror to github
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: Add a mirror to github
-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: bug adding K,V pairs to existing hash with HASH+=([K]=V)
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: redraw-current-line fails with multiline prompts
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)
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
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/
How to lock a terminal
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
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
Re: How to lock a terminal
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
AW: List out
> -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: inconsistent function of "-v" use w/arrays and hashes
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?
Re: [Nano-devel] How to lock a terminal
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.
Q: what is a fast way to see if an 'item' is present in an array?
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: bug adding K,V pairs to existing hash with HASH+=([K]=V)
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
Re: bug adding K,V pairs to existing hash with HASH+=([K]=V)
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?
