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
Related
I noticed when in vi mode in bash (i.e. the mode enabled with "set -o vi"), that some commands, such as "diw", that work in vim but not in vi, don't work on the bash command line. Is there an easy way to configure bash so that its keybindings will support vim commands? I would like to be able to enter vim commands on the command line without having to actually start the vim program, as described in this question.
The best way of doing this that I know of would be to use athame.
It can be a surprisingly powerful experience in some cases. I particularly like it for interacting with a repl.
Athame patches your shell to add full Vim support by routing your keystrokes through an actual Vim process. Athame can currently be used to patch readline (used by bash, gdb, python, etc) and/or zsh (which doesn't use readline).
Alternatively I find spacemacs with the eshell to be a reasonably functional if strange solution.
Teach vi-command-mode diw to any software that uses readline (such as bash) by adding this to your ~/.inputrc:
set keymap vi-command
"diw": "bde"
First, the "vi mode" you get with set -o vi is not vi itself. It's an incomplete approximation of vi's behavior built into readline, the command-line editing library used by bash under the hood.
Second, because it is incomplete there's no reason whatsoever to expect every vi command to work.
Third, no, there's no "vim mode" so even less reason to expect any vim commands to work.
Fourth, if you absolutely want to edit the current command-line with Vim-like commands, why don't you go all the way and… actually use Vim:
<C-x><C-e>
That said, $ man readline tells you everything you need to customize its behavior and add bindings.
You can use ble.sh. Which is a command line editor written in pure Bash which replaces the default GNU Readline. I like to call it "zsh for bash".
Appart from vim-style navigation it gives you:
Enhanced completion
Syntax highlighting
Other interesting features
After installation don't forget to add (recommended) to your .bashrc:
# at the start of your .bashrc file
[[ $- == *i* ]] && source /usr/share/blesh/ble.sh --noattach
...
#for vim-style mode
set -o vi
...
#at the end of your .bashrc file
[[ ${BLE_VERSION-} ]] && ble-attach
or you can just:
# at the start of your .bashrc file
source /usr/share/blesh/ble.sh
but this may not work as expected - read this.
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'm experiencing the following behaviour in bash that I find very annoying:
Type export VARIABLE=~/
Now I'd like auto-completion for the next segment of the path, so I press <tab>.
Bash clobbers the VARIABLE=, leaving just export ~/.
Why is this happening?
My bash version is 4.3.33, OS is Debian testing, terminal is Konsole.
Verify that $COMP_WORDBREAKS includes an =. If not, try this:
COMP_WORDBREAKS+==
If the export completion works to your satisfaction after that, then you need to figure out what startup file is changing COMP_WORDBREAKS.
For example, if you've installed node.js, the npm completion script (in /etc/bash_completions.d/npm removes = and # from COMP_WORDBREAKS.
Many completion scripts, somewhat annoyingly, change global settings. (For example, the standard Debian/Ubuntu completion scripts enable the extglob shell option.)
I've just moved from bash to zsh. It's a great terminal shell, but I'm missing one property - file name completion for non-standard executables.
For example, If ls gives thread_pool_examples and thread_pools:
Then typing du, space and tab would autocomplete the common prefix thread_pool, nd another click will iterate over the options:
Clicking Enter will pick the highlighted item.
The problem is that this does not work with my custom scripts. For example, if I run rmf - a Python executable in my path - and click tab, no autocomplete options will appear.
Any ideas how to make zsh autocomplete filenames for every executable?
Honestly, IMO something in your shell configuration is breaking things up. Try doing this to verify it:
zsh -f # starts a new shell ignoring your configuration
autoload compinit
compinit
./my-shell-script [TAB]
it completes with files. That is the default.
FWIW, if you want to bind a particular completer to a command/alias etc, you can do
compdef _jstack jstack
# simple _files completion
compdef _files my-local-python-script
# restrict to some file extensions
compdef '_files -g "*.(eps|ps|pdf)"' okular
In a bash shell script you can prompt the user for input and enable readline completion for the user with the -e flag. (e.g. read -e -p 'GET YOUR FILE: ' file would allow a the user to use tab-completion to find the file.)
ZSH's completion is more advanced and extendable, so I hoped that I might be able to find a zsh builtin that allowed similar behavior.
I'm sure there's a better answer (I just recently started experimenting with zsh), but you can use vared.
$ vared -c line