PDA

View Full Version : bash tabbing for autocompletion escapes $



dinesh_suse
08-Sep-2015, 20:47
Hi, I am using SLES 11 SP3 on an AWS EC2 instance. I have two different bash versions on two different servers.

In shell (GNU bash, version 4.2.47(1)-release (x86_64-suse-linux-gnu)), when I hit tab for autocompletion, the "$" is escaped after the variable name is completed, but if there is no completion then it just bells. E.g.

$ ls $JDK_H<tab>
results in
$ ls \$JDK_HOME (with a trailing space)

On an old GNU bash, version 3.2.51(1)-release (x86_64-suse-linux-gnu), it did not escape the "$" after completion which is what I would like.

How do I get the old behavior in the new bash? Am I missing some setup options. FWIW these are my shell options:

BASHOPTS=checkwinsize:cmdhist:expand_aliases:extgl ob:extquote:force_fignore:histappend:interactive_c omments:login_shell:progcomp:promptvars:sourcepath
SHELLOPTS=braceexpand:emacs:hashall:histexpand:his tory:interactive-comments:monitor

Thanks

ab
08-Sep-2015, 21:47
Out of curiosity, how did you get the newer bash on there? Is that
something you pulled from SUSE, or a version you added manually, or maybe
on another Linux distribution?

What happens if you start by using double-quotes before your '$' symbol?

> ls "$JDK_H<tab>

On my bash 3.x system it still behaves properly, and I'm not sure if it
will help 4.x (which I do not have to test) but maybe it'll help make
things more-clear for bash.

--
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below...

dinesh_suse
08-Sep-2015, 23:40
>how did you get the newer bash on there?
It came in a standard distro on EC2. I don't think I did anything special to get that. Not applied any patches or anything.

> What happens if you start by using double-quotes before your '$' symbol?
I suppose in normal usage one wouldn't want to do that. But I tried. It does not even expand the shell variable.

$ ls "$JD<tab>

just bells and does not become JDK_HOME

I also tried a few more things, hoping something would shed a light on it.
"shopt -s compat31" -- did not complete at all.
"shopt -s compat32" -- escapes the $
"sh" -- the standard shell (4.2) worked fine, completing to "ls $JDK_HOME"

It this a bug?

This is what I get from uname:
$ uname -a
Linux ip-10-0-0-84.ec2.internal 3.12.44-52.10-default #1 SMP Wed Jul 15 22:18:05 UTC 2015 (a6f3717) x86_64 x86_64 x86_64 GNU/Linux

ab
08-Sep-2015, 23:54
Maybe it is worthwhile to post in the forum specific to EC2 instances, in
case something they are doing is really off. For what it is worth, the
kernel version I have from a SLES 11 SP4 box I built today is
3.0.101-63-default so that, at least, is very different. I'm not sure
what the SP3 kernel is these days, but I think it's still in the 3.0.101
area, so I think yours is quite a bit off from what is expected. Amazon
may have done some tweaking.

--
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below...

dinesh_suse
09-Sep-2015, 04:33
I doubt if this has anything to do with AWS, unless AWS is building the whole login / profile setup. I would also be curious is if this is a bug or a feature :-) It is surely very frustrating.

This seems to afflict only "cd". The . /etc/profile.d/bash_completion.sh is bracketed for bash 4.1 or greater. And there are a lot more complete options in this version compared to my older sles systems.


$ cd $JD<tab>
>>>> becomes cd $JDK_HOME
$ echo $JD<tab>
>>>> becomes echo $JDK_HOME
$ ls $JD<tab>
>>>> becomes ls \$JDK_HOME

$ shopt -s
checkwinsize on
cmdhist on
expand_aliases on
extglob on
extquote on
force_fignore on
histappend on
interactive_comments on
login_shell on
progcomp on
promptvars on
sourcepath on

ab
09-Sep-2015, 04:39
If you say so. I just patched my SLES 11 SP3 AWS system with all of the
latest patches and I am using this kernel:

Linux mybox #1 SMP Thu May 28 08:25:11 UTC 2015 (dc083ee) x86_64 x86_64
x86_64 GNU/Linux

Since that's nothing at all like yours, I can only conclude that your box
is vastly different, and maybe not even SLES. Note: openSUSE != SLES.
Are you sure you are not using an openSUSE version of some sort, maybe
13.2 instead of SLES 11 SP3? That would explain how you have a bash 4.x
kernel, though my openSUSE laptop (this box) still does not behave like
your system does.

--
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below...

malcolmlewis
09-Sep-2015, 12:17
On Wed 09 Sep 2015 03:39:44 AM CDT, ab wrote:

If you say so. I just patched my SLES 11 SP3 AWS system with all of the
latest patches and I am using this kernel:

Linux mybox #1 SMP Thu May 28 08:25:11 UTC 2015 (dc083ee) x86_64 x86_64
x86_64 GNU/Linux

Since that's nothing at all like yours, I can only conclude that your
box is vastly different, and maybe not even SLES. Note: openSUSE !=
SLES. Are you sure you are not using an openSUSE version of some sort,
maybe 13.2 instead of SLES 11 SP3? That would explain how you have a
bash 4.x kernel, though my openSUSE laptop (this box) still does not
behave like your system does.



Hi
That system is SLE 12.. kernel is up to date, but not bash (4.2-75.2).

--
Cheers Malcolm °¿° LFCS, SUSE Knowledge Partner (Linux Counter #276890)
SUSE Linux Enterprise Desktop 12 GNOME 3.10.1 Kernel
3.12.44-52.10-default If you find this post helpful and are logged into
the web interface, please show your appreciation and click on the star
below... Thanks!