On Linux, you can do
$ scp some-file.txt user#remote.host.com:/some/pa<tab>
and it would autocomplete the remote path, if you have key based authentication up and running for that host. However, on OSX it doesn't seem to work, using iTerm2. Any hints?
This depends on your shell. In case you are using bash you need the correct bash completion scripts.
See the Bash completion project, and especially this script: https://github.com/scop/bash-completion/blob/master/completions/ssh
Default location where those have to be put is /etc/bash_completion and then you can load them from your .bashrcor .profile file by adding something like . /etc/bash_completion (mind the . to source the file)
While focused on Linux they should work on Mac, too.
Homebrew and other software managers provide bash-completion, too. If installed check your .bashrc/.profile according to the instructions to properly load it.
Related
I would like to use something like oh-my-bash in vscode using WSL2. However according to the docs:
When VS Code Remote is started in WSL, no shell startup scripts are run. This was done to avoid issues with startup scripts that are tuned for shells. If you want to run additional commands or modify the environment this can be done in a setup script ~/.vscode-server/server-env-setup (Insiders: ~/.vscode-server-insiders/server-env-setup). If present, the script is processed before the server is started.
I have added a ~/.vscode-server/server-env-setup and according to the logs it is found and executed, but my linux skills are quite basic and i can't figure out how to get my profile installed. I have tried
bash ~/.profile
...but that doesn't seem to do anything. I have also tried
#!/bin/bash
source ~/.profile
which gives me an error /mnt/c/Users/cber/.vscode/extensions/ms-vscode-remote.remote-wsl-0.40.3/scripts/wslServer.sh: 3: /home/cber/.vscode-server/server-env-setup: source: not found
UPDATE
The question of how to source a profile is answered below, but my problem with getting powerline-go to work in vs-code on WSL2 persists, but i moved that to a new question in order to close this one.
In order to persist your settings in your current shell, you need to source your config instead of just executing it (see this link for more details).
The problem is that vscode is using dash to load your config file instead of bash.
However, source is a bash keyword, and is not understood by dash. So you'll have to use the more portable syntax, ., in order to make it work with dash.
Try replacing your file by the following content (no need for #!/bin/bash) :
# if the profile file exists, we source it
if [ -f ~/.profile ]
then
. ~/.profile
fi
I have a bunch of bash completion files in
/usr/local/etc/bash_completion.d
most of the scripts in there have something like this at the bottom of them:
complete -F _tmux tmux
the above is for tmux.
My question is - it doesn't look like bash by default sources these files?
I see some instructions online about doing something like this:
for f in '/usr/local/etc/bash_completion.d/'*; do
source "$f"
done;
do I need to do this manually or should bash be doing this out of the box?
This varies depending on your platform and/or versions of bash and bash-completion. For example:
Ubuntu
On Ubuntu 20.04 the file /etc/bash_completion does this:
. /usr/share/bash-completion/bash_completion
And in that file I find
for dir in ${XDG_DATA_DIRS:-/usr/local/share:/usr/share}; do
dirs+=( $dir/bash-completion/completions )
done
Which indicates that /usr/local/share/bash-completion/completions is scanned for completion scripts. Empirical experiments supports this.
MacOS/Brew
I could not find anything about bash completion in /etc or /usr/share on my MacOS 11.2.3. Which indicates that bare Darwin does not have bash completion, which makes sense since Apple have left Bash at 3.2 because of licensing. Might have for zsh, though, I didn't look.
/usr/local/etc/bash-completion.d, which you reference, is a part of the Homebrew installation under /usr/local. In there I found some completion scripts, but not the activation script. You should not have to activate those explicitly yourself.
I did find /usr/local/share/bash-completion, again from Homebrew, and it has the script bash_completion. In it are the same lines as Ubuntu, which also makes sense since Homebrew is kinda complete "GNU" but under /usr/local. But it also reference the directory /usr/local/etc/bash-completion.d. Sourcing /usr/local/share/bash-completion/bash_completion added the completion from that directory also.
But /usr/local/share/bash-completion/bash_completion is not executed by default, so you have to add that to your ~/bash_profile or ~/profile as described here. It also describes how to handle zsh and fish.
Cygwin
Cygwin is another Posix-compliant environment which has bash completion. (I haven't checked if bash completion is part of the Posix standard, though) After installing the bash-completion package there is /usr/share/bash-completion/bash_completion as Ubuntu and Homebrew has. Here there is no /etc/bash_completion and as the ~/.bashrc I had (generated long ago) did only look for this completions wasn't activated.
Summary
Many GNU-like environments support bash_completion but you might have to
install a package
ensure that it is sourced when you log in, which is not always the case by default
If it is not activated by default in your environment, you can activate it by sourcing the "root" script (in /etc, /usr/share/bash-completion or where it might be located) from your .bashrc, bash_profile or similar.
I'm guessing YMMV for all other possible platforms (other Linux distros, MSYS2 etc.) but the above might help you to figure out how to enable completion. Which is really helpful when available.
I'm running IntelliJ 2018.3 on Windows 7, as well as openSUSE Leap 15.
Under Windows 7, I've configured IntelliJ to use Git Bash, i.e., in Settings, under Tools -> Terminal, I'm setting Shell path to:
C:\Program Files (x86)\Git_2.17.1\bin\bash.exe
One of IntelliJ's new features is the ability to save and reload terminal sessions (see this link).
It works perfectly with openSUSE, however, on Windows, while the terminal tab names are correctly restored, I always end up with a new shell.
Is there a way to make IntelliJ and Git Bash play well together so that I can retain the current working directory and shell history after restarting IntelliJ?
You can try and setup your Git for Windows bash to remember the last used path for you, as seen in "How can I open a new terminal in the same directory of the last used one from a window manager keybind?"
For instance:
So instead of storing the path at every invocation of cd the last path can be saved at exit.
My ~/.bash_logout is very simple:
echo $PWD >~/.lastdir
And somewhere in my .bashrc I placed this line:
[ -r ~/.lastdir ] && cd $(<~/.lastdir)
That does not depend on Intellij IDEA directly, but on the underlying bash setup (here the Git for Windows bash referenced and used by Intellij IDEA.
Here's a possible workaround. It was heavily inspired by VonC's answer, as well as other answers to the question that he mentioned.
~/.bashrc
if [[ -v __INTELLIJ_COMMAND_HISTFILE__ ]]; then
__INTELLIJ_SESSION_LASTDIR__="$(cygpath -u "${__INTELLIJ_COMMAND_HISTFILE__%history*}lastdir${__INTELLIJ_COMMAND_HISTFILE__##*history}")"
# save path on cd
function cd {
builtin cd $#
pwd > $__INTELLIJ_SESSION_LASTDIR__
}
# restore last saved path
[ -r "$__INTELLIJ_SESSION_LASTDIR__" ] && cd $(<"$__INTELLIJ_SESSION_LASTDIR__")
fi
I don't like the fact that I had to wrap the cd command, however Git Bash does not execute ~/.bash_logout unless I explicitly call exit or logout; unfortunately due to this limitation, the .bash_logout variant is inadequate for the mentioned scenario.
The workaround above also leave small junk files inside __INTELLIJ_COMMAND_HISTFILE__ parent dir, however, I couldn't do any better.
Additionally I've opened a ticket in Jetbrain's issue tracker. There are many different shells that may benefit from official support. It would be great if JetBrains could eventually support powershell and popular terminals like windows-subsystem-for-linux, cygwin and git-bash. The only shell that currently works out of the box for me is cmd.
I am using Perlbrew in a brand new server (CentOs 6).
In my previous system (RedHat 4) WiTHOUT Perlbrew I used to use some aliases in the bash shell, like alias nreload='/usr/local/nginx/sbin/nginx -s reload' for example, to restart Nginx just putting the line in the .bash_profile file.
Now, with Perlbrew, I tried it in .bash_profile and in .bashrc, with no luck. I can make aliases on the fly, but I can't have them permanently available.
I followed the Perlbrew installation tips and copied the line source ~/perl5/perlbrew/etc/bashrc in the .bashrc file. I thought it should activate the Perlbrew Perl just by logging-in to the server, but it doesn't. So I must write source ~/perl5/perlbrew/etc/bashrc; everytime I need to use the Perlbrew Perl. It doesn't seems to be the right way.
Maybe the real problem is how I run Perlbrew. Maybe I do not understand the concept of Perlbrew opening another shell. If there is another shell, a subshell, how can I use alias in it?
Here is the content of my .bash_profile:
# .bash_profile
# Get the aliases and functions
if [ -f ~/.bashrc ]; then
. ~/.bashrc
fi
# User specific environment and startup programs
PATH=$PATH:$HOME/bin
source ~/perl5/perlbrew/etc/bashrc
export PATH
alias nreload='/usr/local/nginx/sbin/nginx -s reload'
BTW: the server is a remote one, and I control it from a local Macintosh, using Terminal. I have read something about Terminal is more a visual tool than a real Unix terminal, but I do not completely understand it.
I have found the way: aliases must be in .bashrc
I connect using (Macintosh) Terminal, and when logged to the online server I just "activate" a new shell typing "/bin/bash".
In this new shell I have the right Perlbrew Perl, an all the alias, because this new shell takes everything from the .bashrc file.
What confused me was that "a new shell" is not really "a new terminal window" as I was expecting, but a new "process", and this new process, obviously uses .bashrc as a start point.
I am a new iMac user. I have extensive experience with Linux on a PC. I downloaded latest version of emacs to the Applications folder. I want to invoke emacs from the command line. However, the default path for emacs is /usr/bin/emacs. what is the best practice for adding the new emacs to the path? I am tempted to create a ~/bin directory and a link to the new emacs and adding ~/bin to the beginning of my path. This is how we did things in our software development environment on linux PC's
Best way is to use Homebrew and use
brew install emacs --cocoa
so you have a easy to update emacs installation. The Cocoa will make sure you have your mac keybinding working before emacs. Make the binary run at startup as a daemon (because it starts up not very fast), for instance:
/usr/local/Cellar/emacs/23.2/Emacs.app/Contents/MacOS/Emacs --daemon
And make an script to the emacsclient command and saved it to /bin/emacs file (don't forget to make it executable):
#!/bin/bash
exec /Applications/Emacs.app/Contents/MacOS/bin/emacsclient -n -c "$#"
so when you fire up at bash "emacs something.txt" the already running emacs daemon opens it instantly. You can also extend it to open Emacs if the daemon is not running!
I tested it on the latest emacs 23.2, some features are not present on early versions.
Assuming you were still in linux land, wouldn't the canonical place to put this be in /usr/local/bin (and add that to your path?) ... I'd stick with that, if you were to go that route, but this is how I have my emacs setup:
I've downloaded the latest plain/vanilla Emacs from emacsforosx.com
I've made an emacs alias that I use to fire up a terminal-based version of emacs when I don't want (or can't) run the GUI version, like so:
alias emacs='/Applications/Emacs.app/Contents/MacOS/Emacs -nw'
If you want to fire up the GUI version of Emacs from the terminal, you can just type the following (which, AFAIK, is a mac-ism, so you wouldn't have known that coming from linux):
$ open -a Emacs
There's a slew of information about emacs on OS X at the emacs wiki.
~/bin or /usr/local/bin will work fine, as will manipulating your PATH.
Assuming you're using Emacs.app, simplest thing to do is to use open -a /Applications/Emacs.app "$#". open is the command line equivalent of double-clicking on something in Finder. Put that into a shell script, stick it into your PATH and go.
Installing emacs-app via MacPorts is probably the simplest way to get and maintain a Cocoa emacs.
You may wish to look into Aquamacs which is a further refinement of emacs for OS X. The emacs wiki page on Aquamacs is very helpful. It also has an option to add a little aquamacs script to your PATH that will open a file in the aquamacs GUI.
I create a shell script named emacs in my ~/bin directory containing:
open -a Emacs "$#"
Obviously, ~/bin needs to be before /usr/bin in my PATH which I set in ~/.profile so that it shadows the preinstalled emacs binary.
I also create a symlink via ln -s /Applications/Emacs.app/Contents/MacOS/bin/emacsclient ~/bin/emacsclient so that this also shadows the preinstalled emacsclient binary.
For additional connivence, I create an alias ec='emacsclient -a emacs -n ' and include (server-start) in my emacs init scripts. This enables me to open a file from the commandline using ec filename regardless if emacs is or is not already running.
Another tip: When you launch the emacs via Applications or open, emacs does not inherit the same path as you have in your terminal environment, so one thing I have found very useful is to run the following in my .profile after setting my path to change the PATH inherited cocoa applications:
defaults write ${HOME}/.MacOSX/environment PATH "$PATH"
That will work. If this is a native mac application, the binary is actually located under the application directory (not the capitalization of the binary): .../Emacs.app/Contents/MacOS/Emacs
Since you are coming from linux, you might be interested in MacPorts. This is a large collection of packages ported from linux. It allows packages to be installed and upgraded from the command line, doe sdependancy management, all the stuff you would expect. It includes a native version of Emacs, that can be invoked from the command line.