'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.