Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 5 years ago.
Improve this question
Is it possible with bash (or maybe even zsh) to use a character other than the tilde ("~") do designate one's home directory? For example, "cd ~" takes you to your home directory. Hitting the shift key with my right pinky and then ~ key with my left pinky simultaneously has always seemed very awkward to me, particularly since it's a keystroke combination that's used so much. Is there another way to do this? I don't want to have to type $HOME all the time either. Ideally, I'd like to be able to use something more natural like shift+$ or shift+% instead of shift+~. Can this be done? By the way, I'm not looking for a shortcut such as "cd" to get back to my home directory. I want to make it easier to get to directories beneath my home directory.
Just use cd without arguments to go to the HOME directory.
See man bash
You can remap backtick ` to tilde ~ in Bash. With a US keyboard layout, this saves you a Shift:
bind '"`": "~"'
This only affects the shell prompt, and has the additional benefit of reminding you to always use $(..) over deprecated `..` for command substitution.
Several proposals that cannot work:
"shift+~" is just a symbol, not some weird metakey-combo!
"shift+%" gives a '%', which is already reserved for job
control
"shift+$" gives a '$', which is already reserved for variables and spawning child processes as in '$(cat blah)'
Some ideas that might work:
Instead of using $HOME, define $H in ~/.bashrc. That's only 2 characters, and $ is much less complicated to type
If it's your computer, you could create a symlink '/h' that points to your home directory, so that you could type /h/foo/bar instead of ~/foo/bar.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 3 years ago.
The community is reviewing whether to reopen this question as of 4 days ago.
Improve this question
I am happy and really like the Ctrl-R backward search feature of the bash shell. Some of my colleagues don't like it, since it is sometimes confusing. I understand them. If you enter the wrong characters, the current position in the history is somewhere in the past, and you won't find the recent matches.
Is there a more user friendly alternative for seaching backward in the shell history?
I want to stick with bash. Suggesting an alternative shell is not an answer to this question.
The issue with the "lost position" is explained here: Reset bash history search position These solutions work. That's right. But the solution there are not easy and user friendly according to my point of view. These solutions are not simple and straight forward. These are solutions of the past. In the past the human needed to learn the way the computer wanted the input. But today the tools should accept the input in a way which is easy for the user.
You can also use history-search-backward. It's not bound to any key by default, so you need to add
"\eq": history-search-backward
to your ~/.inputrc. Then you can type a prefix of the command you want to find in the history, e.g.
cd /l
then press Alt+q and the shell will expand it to
cd /last-visited-dir
Pressing the key combination again will search for a previous mention, etc.
If you type the wrong characters to search for, press Ctrl-G to stop the search and then Ctrl-R and the correct characters to restart the search.
You can also set up Ctrl-S to reverse the direction of the search in case you entered the correct search characters but went to many steps backward. The Ctrl-S allows you to go forward. To enable this, you will need to add:
stty -ixon
to your Bash startup file.
That command turns off the default flow control function of Ctrl-S and Ctrl-Q and makes those key combinations available for other uses. In Bash by default Ctrl-S is used for history search and Ctrl-Q is a duplicate of Ctrl-V which performs quoted insert (e.g. pressing Ctrl-V Enter results in ^M being inserted as a representation for the single character for Return).
And you might need to add:
"\C-s": forward-search-history
to your ~/.inputrc.
Piping history through grep gives you a "less interactive" way to interface with the history buffer, but sometimes less interactive is what you need.
You can re-execute a specific numbered command from the grep output with !number
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 6 years ago.
Improve this question
When I want to input the command echo $bash_, then I press Tab key, the autocompletion can't occur.
But when I input the command echo $BASH_, then I press Tab, the completion list will output like this:
$BASH_ALIASES $BASH_COMMAND $BASH_SOURCE
$BASH_ARGC $BASH_COMPLETION_COMPAT_DIR $BASH_SUBSHELL
$BASH_ARGV $BASH_LINENO $BASH_VERSINFO
$BASH_CMDS $BASH_REMATCH $BASH_VERSION
And my .inputrc file contains the readline ignorecase option, set completion-ignore-case on, and the filename completion case insensitive is okay.
So, I want the variable name tab completion can ignore the variable case.
There are case-insensitive filesystems, and on such systems it makes sense for filename completion to be case-insensitive. In an ideal world, bash could tell if a component of a filepath were case insensitive, but in practice there is no standard interface which provides this information, so bash falls back to letting you explicitly configure case-insensitive filename completion: (quote from bash manual, emphasis added)
completion-ignore-case
If set to on, readline performs filename matching and completion in a case-insensitive fashion. The default value is ‘off’.
Similarly, you can configure glob expansion and/or case patterns to be case-insensitive.
But you cannot make bash variables case-insensitive. $bash and $BASH are different variables. Similarly with bash function names, bash builtin names and bash keywords. Bash can do tab-completion with all of those, but regardless of the configuration of filename case sensitivity, the tab-completion is case sensitive.
While that seems like a reasonable justification, it turns out that bash tab-completion is always case sensitive except for filenames (including directories and bash commands, which map onto filenames), which can be configured to be case-insensitive. Even things which are typically case-insensitive, like signal names and host names can only be completed case-sensitively.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 8 years ago.
Improve this question
I saw someone use cd * and then use other commands like ls et al after that.
What does it do? Can someone explain it?
The shell expands * to an alphabetical list of the current directory's contents.
cd ignores all arguments after the first.
In lucky and/or extremely controlled circumstances, you can rely on the first item in the wildcard expansion to be the directory you want to cd into.
This may be marginally useful and/or entertaining if you have just created and descended into the current directory and populated it with a single subdirectory. I find it hard to imagine it could have other actual uses.
This command:
cd *
will only work if first list from current path is a directory since it expands to very first entry (file or directory) in the current path. You can see what comes first by doing echo *.
I would suggest not really relying on it since alphabetically first expansion can give you a file also like .bashrc or some other file name starting with dot.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 8 years ago.
Improve this question
Suppose I have these directories:
CSCI100
CSCI200
CSCI300
CSCI400
If I do
cd C<TAB>
it completes up to
cd CSCI
and then I must type a number to proceed.
Is there a way to do
cd 200<TAB>
which then alters the full command to
cd CSCI200
?
Bash's readline command "menu-complete" enables this behavior. You can either have this replace the Tab key's usual behavior (with the command bind "Tab: menu-complete", or by putting "Tab: menu-complete" in your .inputrc file), or choose a different keyboard shortcut for this function.
EDIT: Sorry, I misunderstood the question; it's about completing a suffix rather than a prefix of a filename. You can sort of do this with the default settings in bash if you use a wildcard and there's only one match for the pattern:
cd *200<TAB>
expands to:
cd CSCI200
If there's more than one match, it'll list matches if you TAB again. Binding TAB to menu-complete will make it cycle through matches instead. I don't know of any way to do this in bash without explicitly giving a wildcard to tell it where to do the expansion.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I exported a variable in ~/.bashrc as follows (followed by source ~/.bashrc)
export w=/home/user/workspace/
When I'm on commandline I try to access sub-directories of $w in following way
user$ vi $w/
After this when I hit the tab key, a mysterious backslash appears
user$ vi \$w/
It disables further tab-completion. Why? May not be vi specific as it occurs even with ls.
Bash version 4.2.24(1)-release (i686-pc-linux-gnu)
Running Ubuntu 11.04
Edit
Workaround: Hit Esc+Ctrl+E before hitting tab.
Bash is a little smart, but not that smart. It's not going to be able to expand out your variable, then tab complete to whatever dir that evaluates to. So it's not the backslash "disabling" tab completion, it's the fact that bash can't find any completion suggestions to make.
Given that completion isn't going to help you if you actually do have environment variables in your path, the only way completion could help you at all is if you meant to type a literal dollar sign. I think bash is just being overzealous in trying to complete to something.
Still, I'd call it a bug, since in your case it not only fails to complete, but also changes the meaning of what you've typed.