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
Related
Whenever I execute a command using an alias, this command is not stored in the shell's command history.
So if I run history these commands do not appear in the list.
Nor do they appear when I press CTRL + r for reverse searching the command history.
When I press the keyboard's arrow up for scrolling through the last commands, I will see an aliased command only if it was the last command I ran. Other aliased commands are will not be displayed.
For example:
$ cd my-repo
$ gs # an alias to git status
$ history
Outputs the following:
2374 cd my-repo
(the gs command is not displayed)
A few notes:
gs is only an example. The issue is far more annoying in more complex commands since I have to retype them all over again instead of executing them from history (e.g. k get pods | grep <pod_name>, where k=kubectl).
gs is defined so: alias gs=' git status'.
I also have a few functions in ~/.alias, e.g.:
mkcd () {
mkdir -pv $1
For some reason, mkcd (or any other function in the alias file) is included in the history.
I do not mind if it prints out gs or expands to git status, I'll take any of the two...
I am using zsh with oh-my-zsh on macOS (Monterey). My shell aliases are defined in ~/.alias which is sourced in ~/.zshrc (source ~/.alias).
This happens both in iTerm2 and in the default Mac terminal.
Thank you for taking the time to help :-)
I will assume that your example alias is exactly what you have in your ~/.alias file.
So you have aliases like this (notice the space character in front of git command):
alias gs=' git status'
There is an shell option called HIST_IGNORE_SPACE which is doing exactly what you are experiencing - in short it will not add command to the history when it starts with space character. Example:
echo 'This command will make it to the history.'
echo 'This poor command will be forgotten.'
You can check your current options using setopt or specifically:
setopt | grep 'histignorespace'
So there are two ways how you can fix this - either by fixing your aliases to not start with space or, If you really don't want this functionality at all, by unsetting it in your ~/.zshrc like this:
unsetopt HIST_IGNORE_SPACE
I'm using iTerm2(Z shell) on macOS 11.5.2. Because I use certain Perl one-liners (one line of Perl command in a shell application like iTerm2) a lot, it would be a lot easier if adding some comments to the one-liners so I could navigate back to it using the search function of iTerm2.
Normally, it's like perl path-to-perl-snippet/xxx.pl --an-arg xxx --other-args xxx a.txt #this is doing some task to do some work with a.txt.
Recently, I clean install the system and find some issues with commenting using #, i.e. the content behind # is interpreted by the command. This is not what I intend; It should be just comments.
At first, I thought it was a Perl problem. But the simplest command ls #display list also has the exact same problem, giving the following error ls: #display: No such file or directory ls: list: No such file or directory"
The expected behavior should be like executing ls (without the #display list) in the iTerm2, which is to display all the files under current directory.
So the real problem probably doesn't lie with Perl. It could be a setting problem with iTerm2 or other settings.
Any suggestions would be helpful. Thank you.
Newer versions of OS X (as of 10.15 Catalina) use the zsh shell by default, which has an "interactivecomments" shell option. It is set "off" by default. Turn it on with:
setopt interactivecomments
To preserve this setting for future shells, edit that line into your ~/.zshrc file.
The setting is documented in the man zshoptions section or online at https://zsh.sourceforge.io/Doc/Release/Options.html#index-comments_002c-in-interactive-shells. It is listed there as INTERACTIVE_COMMENTS, but the introduction to that section says:
These names are case insensitive and underscores are ignored. For example, ‘allexport’ is equivalent to ‘A__lleXP_ort’.
This means that you have several ways to enable the option (a partial list):
set -o interactivecomments
set -o Interactive_Comments
set -k
setopt interactivecomments
as well as disabling it (a partial list):
set +o interactivecomments
set +o Interactive_Comments
set +k
setopt nointeractivecomments
Whether or not # introduces a comment in an interactive shell is controlled by the interactive_comments option. It should be enabled by default, but if it has been disabled, run
shopt -s interactive_comments
\curl -L https://get.rvm.io | bash -s stable
Why is the command starting with \?
This is the site where I saw it.
alias curl='curl --some --default --options'
If you have an alias for curl and you don't want to use it, putting a backslash in front disables the alias and runs the curl binary directly.
Note that this only applies at an interactive shell. Aliases don't take effect in scripts so it would be unnecessary there.
The (Bourne/POSIX) shell specification says that alias substitution in an interactive shell is suppressed when any character of the command word is quoted. A backslash is one way to do that, but there are also other well known ways to quote: single and double quotes. All of the following will suppress alias substitution:
\curl
cur\l
\c\u\r\l
"c"url
"curl"
"c""u""r""l"
'curl'
'cu'"rl"
Using \curl is just the most common and readable way. Since this is a standardized feature, you can expect it to work in all Bourne-heritage shells.
\curl looks a bit like a TeX command, doesn't it? :-)
I have a code like this:
#!/bin/bash
COLOR_REST='\e[0m'
COLOR_GREEN='\e[0;32m'
echo -e "${COLOR_GREEN}OK${COLOR_REST}"
When I copy and paste the code into my iTerm, it displays OK in the color of green.
However, when I store the code in a file named testColor.sh, and execute ./testColor.sh. It displays \e[0;32mOK\e[0m on my screen.
Why doesn't it display OK with green?
I've also tried bash testColor.sh, and sh testColor.sh. Both fail to display the text in green.
Another thing I feel strange is that I don't see the -e option in the BSD General Commands Manual in man echo.
I'm using macOS High Sierra as my operating system.
Use
#!/bin/bash
COLOR_REST="$(tput sgr0)"
COLOR_GREEN="$(tput setaf 2)"
printf '%s%s%s\n' $COLOR_GREEN 'OK' $COLOR_REST
which uses printf to avoid echo options and tput to be portable across different terminals.
Using printf instead of echo should work in any POSIX compliant shell. I tried this in High Sierra with the default terminal and it didn't work (there weren't any extended options, just -n).
As for an explanation, I haven't used iTerm so I'm not completely sure, but could be a different echo implementation by iTerm, which would cause the flag to work only when using iTerm itself, not /bin/bash. Notice that in the man page for echo, it says
NOTE: your shell may have its own version of echo, which usually supersedes the version described here. Please refer to your shell's documentation for details about the options it supports.
I am a fan of this syntax:
echo $'\e[31mRED\e[0m'
The $'...' notation causes the shell to honor escape codes e.g. \t, \n, \e.
This seems to work in bash, ksh, zsh, and sh -- yes, on MacOS.
The problem seems to be that Darwin's BSD-era /bin/echo does not actually accept -e argument at all. The zsh in recent versions of MacOS has a builtin echo that does take -e, but that's obviously not portable to other shells unless you want to run every shell script with zsh.
I'm trying to run source /Users/alastair/.rvm/scripts/rvm, but keep getting:
Bad : modifier in $ (").
Where would the problem be? Happy to paste other files in if these would help.
Are you in any case running a shell that is not Bash or ZSH? Bash >= 3.2.25 or ZSH >= 4.3.10 is required.
Your problem looks like you were using minimalistic shell sh which is not supported by RVM.
You can check user shell in /etc/passwd and change it with chsh -s /path/to/new/shell - list of allowed shells is available in /etc/shells - but make sure to pick Bash/ZSH, also note that links like sh->bash will not work as bash changes behavior based on the name that was invoked.