I have found that shopt -s nullglob apparently disables tab-completion for files and directories, and shopt -u nullglob restores it. Why does tab-completion for directories apparently rely on nullglob being unset?
I am using Bash 4.2.37(1)-release on Debian 7.
This is apparently a known issue with bash-completion and is listed as an objective to be fixed in the 3.0 version.
But apparently it has been that way since at least 2012.
See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=666933 for reference.
Edit: At least 2011: http://thread.gmane.org/gmane.comp.shells.bash.completion.devel/3652
I do not at all understand how nullglob causes the problem listed in that email though.
Edit: I now understand what is happening. The problem is that glob expansion is dumb. It sees the entire "word" $2[$j]=\${!ref}\${COMP_WORDS[i]} as a single glob and tries to expand it. Normally that fails and it gets left alone but will nullglob on that entire argument simply vanishes (thus causing the problem).
Quick testing indicates that replacing this:
eval $2[$j]=\${!ref}\${COMP_WORDS[i]}
with either:
eval $2\[$j\]=\${!ref}\${COMP_WORDS\[i\]}
or:
eval "$2[$j]=\${!ref}\${COMP_WORDS[i]}"
seems to fix the problem. I can't vouch for either of those being a fully correct fix though.
Update: This is fixed in the debian bash-completion git repository already (in a way I hadn't thought of but which is clearly better).
This commit fixes it. There are other globbing related fixes too.
Grabbing the __reassemble_comp_words_by_ref from git head and sourcing that on top of the current one appears to fix the problem as a temporary workaround/solution.
Related
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.
Is there a way to get that old behavior without strong side-effects? My BASHOPTS and SHELLOPTS are:
# (indented for readability)
BASHOPTS=checkwinsize:cmdhist:expand_aliases:extglob:extquote
:force_fignore:histappend:interactive_comments:login_shell
:progcomp:promptvars:sourcepath
SHELLOPTS=braceexpand:emacs:hashall:histexpand:history
:interactive-comments:monitor
Thanks. I am using SLES SP11.
--UPDATE. Other completions seem to work as usual, e.g. cd or echo do not escape the $. I also momentarily commented out /etc/share/bash-completion/bash_completion from my /etc/bash.bashrc which stopped $-escaping. So it appears like some kind of complete config issue.
Recent bash versions introduced some compatibility issues regarding this. Try like this:
complete -r # temporarily disable all completion rules
shopt -s direxpand
Links to similar problems reported to the bug-bash mail list:
http://lists.gnu.org/archive/html/bug-bash/2014-01/msg00062.html
http://lists.gnu.org/archive/html/bug-bash/2015-08/msg00176.html
I am migrating from bash to zsh and as part of that I am transitioning over my dotfiles. Is there an equivalent to "checkwinsize" in zsh? I couldn't find one after searching, the relevant code in my .bashrc is
shopt -s checkwinsize
I tried
setopt -s checkwinsize
to no avail. It might be the case that this option isn't needed in zsh (my understanding is that this fixes some sort of bash bug with resizing the windows after exiting an editor).
Zsh doesn't have that option - at least, there's no mention of it in the Z Shell Manual (Chapter 16:Options).
If you see issues with your terminal after resizing the window I guess reset is always an option!
Me:~ me$ cd desktop
Me:desktop me$ pwd
/Users/me/desktop
What is the correct way to force case sensitivity (so that cd desktop fails but cd Desktop goes to the correct directory)? I would assume there was a shopt for that but the manpage doesn't suggest any obvious option.
Sounds like filesystem in question is not case-sensitive -- see the first answer here to verify.
Case-sensitivity is an option of the file system, not of the shell. Therefore you cannot change this with a shell option.
(To understand why, just consider that it is possible to have case-sensitive and case-insensitive filesystems mounted at the same time. How would you handle this with a single shell option?)
I'm using zsh on Mac OS 10.6.8.
So, all of a sudden one of my machines asks me for confirmation every time I rm.
Frankly, I hate this with an abiding passion. I've never had a problem with rm, and I don't need to debate the potentialities.
First thing I did was which rm, which reports rm: aliased to rm -i.
Now, I've hunted high and low for this alias. zshrc, .config (which I don't have), the default zshrc files: everywhere I can think of. No mention of aliasing rm anywhere.
Is there a simple way to determine where this alias is being configured? Or to list all locations where zsh might be looking for config lines?
Nope, there's no way to know which startup file an alias has been configured from, sort of searching them yourself.
The Z-shell startup files can be found here.
A comment for the question suggests /etc/profile; this is incorrect (unless you're sourcing it yourself), as /etc/profile is a Bourne-type shell startup file.
If you can't find the place it's sourced, you could unset the alias [bottom paragraph] in ~/.zshrc: unset rm. That should work provided it's done after the alias is set.
In bash, environmental variables will tab-expand correctly when placed after an echo command, for example:
echo $HOME
But after cd or cat, bash places a \ before the $ sign, like so:
cd \$HOME
If I use a variable as the second argument to a command, it won't expand at all:
cp somefile $HOM
What mysterious option do I have in my .bashrc or .inputrc file that is causing me such distress?
What you're describing is a "feature" introduced in bash 4.2. So you don't have any mysterious option causing you distress, but just "intended" behaviour.
I find this very annoying since I preferred it the way it used to be and haven't found any configuration options yet to get the earlier behaviour back. Playing with complete options as suggested by other answers didn't get me anywhere.
Try complete -r cd to remove the special programmatic completion function that many Linux distributions install for the cd command. The function adds searching a list of of directories specified in the CDPATH variable to tab completions for cd, but at the expense of breaking the default completion behavior.
See http://www.gnu.org/software/bash/manual/bashref.html#Programmable-Completion for more gory details.
For the second instance, you can press ESC before tab to solve it.
I don't know the solution to your problem, but you could look in /etc/bash_completion or the files under /etc/bash_completion.d to determine what commands use autocompletion and how.
help complete
Might also be helpful.
The Bash Reference Manual has more information than you might want on expansion errata.
Section 8.7 looks like it would be the place to start. It give information on the 'complete' function, among other things.
Check the answer for
https://superuser.com/questions/434139/urxvt-tab-expand-environment-variables by Dmitry Alexandrov:
This is about direxpand option. $ shopt -s direxpand and $FOO_PATH/ will be expanded by TAB.
I'm answering 4-year-old question! Fantastic!
This is a bash bug/feature which was unintentionally introduced in v4.2, and was unnoticed for a long period of time. This was pointed out by geirha in this tread. Confirmed as unintended feature here
I came across this problem when running Ubuntu at home. At work I have bash-3.00, so I've spent some time browsing around to see what's going on. I wonder if I can 'downgrade'....