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.)
Related
I am studying zsh on macOS and I find when adding software to $PATH you are usually supposed to write them in .zshrc (zsh). However, Visual Studio Code documentation suggests
To add VS Code to your path, to do so run the following commands:
cat << EOF >> ~/.zprofile
# Add Visual Studio Code (code)
export PATH="\$PATH:/Applications/Visual Studio Code.app/Contents/Resources/app/bin"
EOF
I find zprofile set the environment for login shells while zshrc sets the environment for interactive shells. However, I cannot really see differences between two methods on macOS terminal since each terminal tab is a login session on macOS by default.
Is there any reason why Visual Studio Code on macOS suggests add $PATH to zprofile instead of zshrc and what will be the good practice?
If you read this and this answer as well as the man page (man zsh under STARTUP/SHUTDOWN FILES) you might come to the following conclusion:
You are using MacOS, therefore every zsh you open is a login shell, that way you made sure, that .zprofile will always be read. So if you append your $PATH in your .zprofile and and use zsh as a non interactive-shell you will be able to access your appended $PATH. This might happen in a script of if other programs try to use a program that you added to your $PATH.
Now on the other hand if you added VSCode to your .zshrc it will always be available in an interactive shell. Which mean if you use VSCode 'manually' you will always have it at your disposal in zsh. But other programs/scripts might not find it.
If you set environment variables in .zshrc or .zshenv it can be awkward if you want to use a different value. Say you install a different version of vscode in a different directory. Any new shell will reset the environment variable instead of inheriting it. As environment variables are inherited, there is no need to reset them for every new shell. So .zprofile is often a better choice - the variable is set on first login and inherited but can be changed for a shell and its children. Another option is to set them from .zshenv but use a condition around them such as if [[ ! -o privileged && -o rcs && $SHLVL = 1 ]]; then
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.
Having just installed VScode I have noticed as it uses Bash by default on OSX, with the shell's default prompt of bash-3.2$; consequently, I cannot see the current working directory. It means having to type 'pwd' and 'ls' quite frequently which is obvious quite tedious.
I have tried changing the default shell in the settings to
"terminal.integrated.shell.osx": "/Applications/Utilities/Terminal.app"
or
"terminal.integrated.shell.osx": "/Applications/iTerm.app"
This doesn't seem to work, have I made a mistake here?
I would also like to know if I am limited to bash, can I configure it to display the working directory instead of simply bash-3.2$ ?
See this screenshot of how the VSCode integrated terminal looks by default
Thanks in advance!
I use Ubuntu, and only add the following lines to the end of ~/.bashrc:
if [ "$TERM_PROGRAM" = "vscode" ]; then
PS1='\$ '
fi
Try it and let me know if it works on your OS.
You can set your prompt to contain the current working directory by defining PS1 as follows:
PS1="\w $"
The $ is just some visual sugar. There all manner of things you can have your prompt display. Put the definition in your ~/.bashrc or ~/.profile for it to be set when you login.
Check out the Controlling the Prompt section of the GNU Bash manual for details.
If you are not accustomed to editing your bash init files you can do it with Visual Studio Code by going to View->Command Palette and execute the following command (one-time only):
Install 'Code' command in path
Then open the integrated terminal and type the following:
code ~/.bashrc
Then add the PS1 definition to the bottom of that file.
What is the proper way to modify environment variables like PATH in Yosemite?
This is this question Setting environment variables in OS X? but specifically for yosemite since it doesn't work anymore.
Have you tried editing ~/.bash_profile?
Adding a line like this to bash_profile ought to do it:
export PATH=/usr/local/bin:$PATH
What shell are you using? I'm assuming you're using the default Bash shell. There's also Csh, Ksh, and Zsh.
The Terminal.app on Mac OS X by default starts a new login shell each time a window is open. This means that $HOME/.bash_profile or $HOME/profile is always executed when you open a new terminal window. You can set particular defaults in here. For example, I set PS1 and set -o vi.
NOTE: This may not be the case if you're using other Terminal apps like xterm. These open new terminal windows as just new shells. This means that you may not see the changes made in .bash_profile until you log out and log back in.
You can try editing $HOME/.bashrc and see if that helps.
What about other shells?
If you're using Kornshell (ksh), you need to edit the $HOME/profile and not $HOME/.bash_profile. If you're using Zshell (zsh), you're on your own. It's too wacky to describe here. Read the manpage for zsh and search for ZDOTDIR.
When you run a shell script, the $HOME/.bashrc is executed. Most people put something like this in their .bash_profile, so their .bashrc settings are included in a new terminal window:
[[ -x $HOME/.bashrc ]] && source "$HOME/.bashrc"
Some people set things they want to be set when they run a shell script, for example export $PS4="\$LINENO> ".
The $PATH is a bit different. You can set it in .bash_profile (I would not set it in .bashrc), But, Mac OS X has an automated why on how systemwide paths are set. A file called /etc/paths is used to set the default path for all users using either Bash or Kornshell via the /usr/libexec/path_helper program.
On my Mac, I set my $PATH to:
/usr/local/bin:/usr/share/bin:/bin:/usr/bin:/usr/sbin:/sbin:$HOME/bin
When I install programs, I usually install them under /opt when possible. Then, I link their binaries (where ever they're placed) to /usr/local/bin. This way, I don't have to keep building my PATH. Plus, it allows me to override system defaults. For example, /usr/bin/git is at 1.9.3. while my installed /usr/local/bin/git is at version 2.2.1.
One thing you should not do is modify /etc/profile because changes there may be replaced on OS X upgrades.
The problem is not with environment variables set and accessed from within /bin/bash or /bin/sh, but with envars that should be set for programs NOT executed from the shell; i.e. normal apps executed from the dock or Finder.
After finally getting things right with launchctl in Mavericks, Apple is in the process of changing things again. The useful subcommands of launchctl are now labelled as "legacy subcommands", some of which are no longer supported. That leaves a question mark over the others.
In any case, the most important subcommands are still available for now.
launchctl allows for the setting of the overall environment in which user processes execute. It appears that the overall user environment is inherited by all Terminal processes; i.e. all setenv variables are exported. It's a bit tricky to confirm that. In any case, you will still need your .profile and .bashrc to define functions and aliases, which are not supported by launchctl.
I go to some lengths to ensure that all of my launchctl vars are also defined in my profile. This enables me to set up the same environment on remote or VM linux systems, with a few minor tweaks.
Al of my setup is described in this blog post .
following solution worked for me.
Open Terminal
Click on Terminal Menu at right upper corner.
click on Preferences
Click on General
Change Shell open with to command and put /bin/bash in text box.
Now whatever configuration you do in ~/.bash_profile takes effect. Previously you were not using bash(were using ksh) that is why it was not reading .bash_profile.
Just compiled MacVim with homebrew. Here's what it looks like when I :sh and then type ls:
http://cloud.jtmkrueger.com/image/2N0S0T3k3l1J
As you can see, it's just character codes.
UPDATE
I run oh-my-zsh
Tried installing the plugin named here:
http://vim.1045645.n5.nabble.com/ANSI-colors-td1219411.html
Didn't seem to help
ANOTHER UPDATE
Upon removing my zsh syntax highlighting plugin It seems to work ok. Is there a way to turn off zsh plugins when using oh-my-zsh only when it's a vim 'dumb terminal'?
When you do :sh in GVim or MacVim, you don't get a real terminal emulator.
It's "dumb" and there's no way to make it understand those escape sequences. You better get used to it or ask (with convincing arguments and a ready-made patch) on the vim-dev mailing list.
You might want to try the ConqueTerm plugin which does its best to interpret ANSI sequences, even inside MacVim.
Just for the reference, :h guioptions now support the following flag:
'!' External commands are executed in a terminal window. Without
this flag the MS-Windows GUI will open a console window to
execute the command. The Unix GUI will simulate a dumb
terminal to list the command output.
The terminal window will be positioned at the bottom, and grow
upwards as needed.
Set :set go+=!, run :sh, and be surprised :).
What you see is actually not just character codes, but your usual shell prompt which contains color codes. You can probably disable it by redefining PS1 or remove your modified definition in ~/.bashrc.
If you would like to use a color prompt on the command line, but not in MacVim you can fix this in ~/.bashrc by setting PS1 differently when inside vim (from here)
if [ $VIM ]; then
export PS1='\h:\w\$ '
fi
You could try the following, instead of ls, type command ls; it shouldn't show the escapes codes.
If it works you can simple create a new file in a folder in your path, say vls, with the following contents:
#!/bin/sh
command ls $#
after that chmod +x vls and again, if it is in your path, you should be able to use that from vim.