I am writing a little shell script to help setup a production/development environment for some of our software and part of it requires subversion.
I need a way to check if subversion is installed on a *nix(usually mac) machine.
I was thinking of checking if export SUBVERSION_HOME=/opt/subversion exists in .profile since that is what the devs use here, but are there any more concrete ways?
You could do something crude:
which svn
In a test:
if [[ -n $(which svn) ]]; then
# do something
fi
Caveat: this would fail in the very unlikely even that someone has a svn installed that is not actually Subversion.
Something simple like this maybe?
which svn > /dev/null
if [ $? -eq 1 ]; then
echo "subversion is not installed"
exit 1
fi
Related
I cannot get VS Code code.exe to run properly within WSL. (I found a connected question here, but it does not solve this issue - Launch VS Code from WSL Bash).
Within WSL (any distro) we can access any executables on Windows. e.g.
alias chrome="\"/mnt/c/Program Files/Google/Chrome/Application/chrome.exe\"" # Open Chrome from WSL
alias notepad++="\"/mnt/c/Program Files/Notepad++/notepad++.exe\"" # Open Notepad++
Typing chrome in bash will open Chrome and notepad++ ~/.bashrc would open .bashrc in Notepad++
This all works great.
However, I have hit a problem with code.exe provided by the choco inst VisualStudioCode installation. When I try:
alias vscode="\"/mnt/c/ProgramData/chocolatey/bin/code.exe\""
This fails really badly.
[main 2021-01-24T18:44:17.966Z] update#setState idle
(node:20404) Electron: Loading non-context-aware native module in renderer: '\\?\C:\tools\vscode\resources\app\node_modules.asar.unpacked\vscode-sqlite3\build\Release\sqlite.node'. This is deprecated, see https://github.com/electron/electron/issues/18397.
(node:20404) Electron: Loading non-context-aware native module in renderer: '\\?\C:\tools\vscode\resources\app\node_modules.asar.unpacked\spdlog\build\Release\spdlog.node'. This is deprecated, see https://github.com/electron/electron/issues/18397.
(node:18692) Electron: Loading non-context-aware native module in renderer: '\\?\C:\tools\vscode\resources\app\node_modules.asar.unpacked\spdlog\build\Release\spdlog.node'. This is deprecated, see https://github.com/electron/electron/issues/18397.
So, I can ignore that and just use code.exe within Ubuntu (as WSL will scan the path for executables). This sort of works but with the following error:
'\\wsl$\Ubuntu-20.04\home\boss'
CMD.EXE was started with the above path as the current directory.
UNC paths are not supported. Defaulting to Windows directory.
VS Code does open, but if put a filename as an argument that file fails to open (while noting that for the notepad++ example, all files open perfectly run with the above alias).
It seems to be saying that code.exe can't support UNC paths, but it does support UNC paths as I can see from PowerShell. code.exe \\HPEnvy\Drive-D\test.txt opens perfectly.
It would really round out my WSL setup to be able to open code that I'm working on seamlessly with VS Code. Does anyone have an idea why this might be happening / how to fix?
My installation has a shell script for launching VSCode in ../Microsoft VS Code/bin/code. I'm fairly certain that it is installed with VSCode, but there's a chance it comes from the "Remote - WSL" extension.
Is that present in your installation? If so, add that bin directory to your path (the full installer does this automatically). Then just use code rather than code.exe to launch from within WSL.
If not, first make sure the "Remote - WSL" extension is installed in VSCode (or better yet, the "Remote Development" extension pack, which includes the WSL support). If it's still not there after that, here are the contents of the script that should live in VSCode/bin/code:
#!/usr/bin/env sh
#
# Copyright (c) Microsoft Corporation. All rights reserved.
# Licensed under the MIT License. See License.txt in the project root for license information.
if [ "$VSCODE_WSL_DEBUG_INFO" = true ]; then
set -x
fi
COMMIT="ea3859d4ba2f3e577a159bc91e3074c5d85c0523"
APP_NAME="code"
QUALITY="stable"
NAME="Code"
DATAFOLDER=".vscode"
VSCODE_PATH="$(dirname "$(dirname "$(realpath "$0")")")"
ELECTRON="$VSCODE_PATH/$NAME.exe"
IN_WSL=false
if [ -n "$WSL_DISTRO_NAME" ]; then
# $WSL_DISTRO_NAME is available since WSL builds 18362, also for WSL2
IN_WSL=true
else
WSL_BUILD=$(uname -r | sed -E 's/^[0-9.]+-([0-9]+)-Microsoft.*|.*/\1/')
if [ -n "$WSL_BUILD" ]; then
if [ "$WSL_BUILD" -ge 17063 ]; then
# WSLPATH is available since WSL build 17046
# WSLENV is available since WSL build 17063
IN_WSL=true
else
# If running under older WSL, don't pass cli.js to Electron as
# environment vars cannot be transferred from WSL to Windows
# See: https://github.com/microsoft/BashOnWindows/issues/1363
# https://github.com/microsoft/BashOnWindows/issues/1494
"$ELECTRON" "$#"
exit $?
fi
fi
fi
if [ $IN_WSL = true ]; then
export WSLENV="ELECTRON_RUN_AS_NODE/w:$WSLENV"
CLI=$(wslpath -m "$VSCODE_PATH/resources/app/out/cli.js")
# use the Remote WSL extension if installed
WSL_EXT_ID="ms-vscode-remote.remote-wsl"
ELECTRON_RUN_AS_NODE=1 "$ELECTRON" "$CLI" --locate-extension $WSL_EXT_ID >/tmp/remote-wsl-loc.txt 2>/dev/null </dev/null
WSL_EXT_WLOC=$(cat /tmp/remote-wsl-loc.txt)
if [ -n "$WSL_EXT_WLOC" ]; then
# replace \r\n with \n in WSL_EXT_WLOC
WSL_CODE=$(wslpath -u "${WSL_EXT_WLOC%%[[:cntrl:]]}")/scripts/wslCode.sh
"$WSL_CODE" "$COMMIT" "$QUALITY" "$ELECTRON" "$APP_NAME" "$DATAFOLDER" "$#"
exit $?
fi
elif [ -x "$(command -v cygpath)" ]; then
CLI=$(cygpath -m "$VSCODE_PATH/resources/app/out/cli.js")
else
CLI="$VSCODE_PATH/resources/app/out/cli.js"
fi
ELECTRON_RUN_AS_NODE=1 "$ELECTRON" "$CLI" "$#"
exit $?
Permissions on the file are 0777. And, as mentioned above, it should be in your path.
I recently got a git hook from someone that aims to add the issue number, which is in a specific location of the branch name, to the beginning of all commits. The goal is to take the #number from feature/#number-issue. Here is some info:
➜ .githooks pwd
/home/luctia/.githooks
➜ .githooks git config --global --list
user.name=luctia
user.email=myemail
core.hookspath=/home/luctia/.githooks
➜ .githooks cat commit-msg
#!/bin/sh
WI=$(git status --branch | grep -iPo "(feature|bug)\/#\d+" | head -1)
WI=$(echo "($WI)" | grep -Po "\d+")
if [[ ! -z "$WI" ]]; then
WI="#$WI"
CM=$(cat "$1")
if [[ ! $CM == *"$WI "* ]]; then
echo "$WI $CM" > "$1"
fi
fi
This doesn't seem to work, though. The script is executable for every user, so that's not the issue. I have tried switching from sh to bash, and with that edit I've executed the script on a file in a repo, which added the number to the beginning of the file, so I know it works. I'm not sure if git hooks can execute bash files, but it doesn't make a difference whether I use sh or bash, though I would like to know if it can run bash scripts.
I'm using Webstorm for my IDE right now, and it doesn't work in there, and it also doesn't work on CLI git. I have no idea how to proceed.
Edit: I am pretty sure the script is not executed. When I add data > /tmp/hook to the script, no file appears. I do have to change from sh to bash though.
The problem was that I was trying to make this work on a pre-existing project, with an existing .git directory. I thought changing the config with the --global flag would just work, but apparently the config inside the .git directory of the project did not change, and the old hookspath was still there. When I changed it, the script started working.
I was trying to change M2_HOME in bash_profile to configure a new version of Maven. Earlier, it was set to 2.2.1. Now I'm trying to change the path to 3.3.3. This is my bash_profile
export JAVA_HOME=/Library/Java/JavaVirtualMachines/jdk1.8.0_25.jdk/Contents/Home
export M2_HOME=/usr/local/apache-maven-3.3.3
#export M2_HOME=/usr/local/apache-maven-2.2.1
export PATH=$PATH:$JAVA_HOME/bin
export PATH=$PATH:$M2_HOME/bin
export CATALINA_HOME=/Library/Tomcat/apache-tomcat-7.0.68
When I try to run source ~/.bash_profile and then mvn -version I get the following error -
$mvn -version
Error: Could not find or load main class org.codehaus.classworlds.Launcher
Any suggestions to solve this please?
PS: I'm on OS X El Captain
A simpler alternative is to set up some bash aliases. I have added the following to my ~/.bash_profile for switching between maven versions and Java versions:
export BASE_PATH=$PATH
#alias java5="export JAVA_HOME=`/usr/libexec/java_home -v1.5 -a x86_64 -d64`"
alias java6="export JAVA_HOME=`/usr/libexec/java_home -v1.6`"
alias java7="export JAVA_HOME=`/usr/libexec/java_home -v1.7`"
alias java8="export JAVA_HOME=`/usr/libexec/java_home -v1.8`"
# maven versions
alias m30="PATH=~/tools/apache-maven-3.0.5/bin:$BASE_PATH"
alias m31="PATH=~/tools/apache-maven-3.1.1/bin:$BASE_PATH"
alias m32="PATH=~/tools/apache-maven-3.2.5/bin:$BASE_PATH"
alias m33="PATH=~/tools/apache-maven-3.3.9/bin:$BASE_PATH"
Note the use of /usr/libexec/java_home for setting up JAVA_HOME which is similar to linux alternatives for switching java versions.
So, in a new terminal session the following:
[steve#steves-mbp ~]$ java8
[steve#steves-mbp ~]$ m33
[steve#steves-mbp ~]$
sets me up to use maven 3.3 and Java 8.
Please also take into account the comment by ~khmarbaise regarding M2_HOME and forget that this environment variable exists.
Add a new symlink for mvn3 worked for me
ln -s /usr/local/apache-maven-3.3.3/bin/mvn /usr/local/User/bin/mvn3
It is common, particularly in an environment where a product portfolio is quite large, to have to support multiple Maven versions. Similar to having to support multiple Java versions, you can create a script that will track and modify your environment accordingly. I use a Mac, so the notion of a jEnv type of mechanism is what I use for Java. On Windows, a similar concept can be used although It would take some coding to properly adjust the path settings.
Here's a /usr/local/bin/mvnEnv bash script that I use to quickly change my Maven runtime. It's not nearly as comprehensive as jEnv, but it works for me so perhaps it can work for you. Adjust the various parameters to conform to your various Maven installs and update your PATH appropriately, if on Windows. (I know you're using a Mac, so the Windows comment is for others that may have this issue on Windows.)
Just update your ~/.bash_profile to call this script with the appropriate parameters if you need a default. Then, when you need a different version of Maven, you can just execute the script like
mvnEnv v33
And voila, you've just quickly changed your Maven version! If you don't know what versions of Maven are supported, simply execute the mvnEnv command and a list of valid versions will be printed. You will, however, have to add any new versions of Maven to the script for the new version to be available.
#!/bin/bash
echo "Setting the maven implementation version"
v22=/usr/local/Cellar/maven2/2.2.1/libexec/bin/mvn
v30=/usr/local/Cellar/maven30/3.0.5/libexec/bin/mvn
v31=/usr/local/Cellar/maven31/3.1.1/libexec/bin/mvn
v32=/usr/local/Cellar/maven32/3.2.5/libexec/bin/mvn
v33=/usr/local/Cellar/maven/3.3.9/libexec/bin/mvn
if [ -e /usr/local/bin/mvn ]
then
echo "Remove the maven soft link."
sudo rm /usr/local/bin/mvn
else
echo "Maven soft link could not be found."
fi
maven=$v22
if [ $# == 0 ] || [ -z "${!1// }" ]
then
echo "No Arguments supplied, using default $maven"
echo "Available versions:"
echo " v22 = 2.2.1"
echo " v30 = 3.0.5"
echo " v31 = 3.1.1"
echo " v32 = 3.2.5"
echo " v33 = 3.3.9"
elif [ -e ${!1} ]
then
echo "Setting maven to use ${!1} via $1"
maven=${!1}
else
echo "Using the default maven setting, provided argument [$1] is not recognized."
fi
echo "Creating new soft link to $maven";
sudo ln -s $maven /usr/local/bin/mvn
RVM is not working over SSH.
At the command-line:
leifg#host:~$ which ruby
/usr/local/rvm/rubies/ruby-1.9.2-p290/bin/ruby
Connected over SSH:
local:~$ ssh leifg#server 'which ruby'
/usr/bin/ruby
I'm using Ubuntu 11.04.
How do I get SSH to use the same Ruby as it is on the system?
I already verified some prequisites:
Ruby was already installed using apt-get install ruby. Does that make any difference?
sshd_config has the option "PermitUserEnvironment yes", and I restarted the daemon.
The .bashrc on the server contains these lines, but I see the same behavior when I remove them:
if [ -s "$HOME/.rvm/scripts/rvm" ] ; then
. "$HOME/.rvm/scripts/rvm"
elif [ -s "/usr/local/rvm/scripts/rvm" ] ; then
. "/usr/local/rvm/scripts/rvm"
fi
Actually, your ~/.bashrc will be executed. The problem is usually that one adds the
[[ -s "$HOME/.rvm/scripts/rvm" ]] && source "$HOME/.rvm/scripts/rvm" # Load RVM into a shell session *as a function*
... snippet at the bottom of the file. However, the default .bashrc on ubuntu systems includes the following near the top
# If not running interactively, don't do anything
[ -z "$PS1" ] && return
That call will stop executing the rest of the script and will therefore not set the proper paths. So you can either put the rvm call at the top of the file or remove the return call.
From the ssh man page:
If command is specified, it is executed on the remote host instead of
a login shell.
This should mean that your .bashrc won't get sourced, so RVM doesn't get set up.
Solution
This did the trick in the end:
ssh <host> bash --login -c <command>
Start bash as a login shell through SSH and then start the RVM installed Ruby via SSH's -c option.
Actually there's totally another, more safe and lightweight option.
You add "PermitUserEnvironment yes" somewhere to your sshd_config in /etc/(open)ssh
Now you are allowed to specify user environment in /home/user/.ssh/environment. So what do you put there ?
Just something like :
user# env | grep rvm > ~/.ssh/environment
so it looks like below :
user#app3:~$ cat ~/.ssh/environment
rvm_bin_path=/usr/local/rvm/bin
GEM_HOME=/usr/local/rvm/gems/ree-1.8.7-2012.02
IRBRC=/usr/local/rvm/rubies/ree-1.8.7-2012.02/.irbrc
MY_RUBY_HOME=/usr/local/rvm/rubies/ree-1.8.7-2012.02
rvm_path=/usr/local/rvm
rvm_prefix=/usr/local
PATH=/usr/local/rvm/gems/ree-1.8.7-2012.02/bin:/usr/local/rvm/gems/ree-1.8.7-2012.02#global/bin:/usr/local/rvm/rubies/ree-1.8.7-2012.02/bin:/usr/local/rvm/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
rvm_version=1.14.5 (stable)
GEM_PATH=/usr/local/rvm/gems/ree-1.8.7-2012.02:/usr/local/rvm/gems/ree-1.8.7-2012.02#global
Note: this also works work user-install RVM (not only for the system wide)
Now your are able to use ruby in ssh non interactive sessions :
ssh user#app3 'ruby --version'
ruby 1.8.7 (2012-02-08 MBARI 8/0x6770 on patchlevel 358) [x86_64-linux], MBARI 0x6770, Ruby Enterprise Edition 2012.02
Voila!
“rvm” has two invocation bugs: the default installation drops the file /etc/profile.d/rvm.sh and believes any bash trick is now globally available. – This assumption is wrong.
Files in /etc/profile.d/ are “sourced” on login, but maybe not from bash, maybe not even from a shell. So the cd hook it installs is not there after the shell which runs these files exits. Actually, because of the buggy way “rvm” installs this hook, it is already gone once you run naked bash in a login-shell!
I don’t know if “rvm” supports an explicit invocation for virtual environments, without relying on cding into some directory (that I consider the second bug).
There is one sane workaround:
Make your shell source /etc/profile.d/rvm.sh from e.g. ~/.bashrc. .bashrc is executed from any non-login bash, and login-bash is usually setup to source .bashrc from those login-shell files like ~/.profile
For your ssh problem: should a proper ssh-shell not be login-shell anyway?
I've just added at the top of ~/.bashrc (for git user) this string:
[[ -s "/usr/local/rvm/scripts/rvm" ]] && source "/usr/local/rvm/scripts/rvm"
Mentioned solutions work certainly fine, but mine was to run
source /usr/local/rvm/environments/<ruby version>#<gemset version>
at the start of the remote ssh call. Something like:
ssh -l <remote username> <server ip> "source /usr/local/rvm/environments/<ruby version>#<gemset version> ; <rest of the remote script>"
(if using Capistrano) Don't use rvm1/capistrano3 or rvm/capistrano; don't set :pty.
Change ~/.rvmrc for the runner user, on the server, to this — note that it has to come before the line where it kills itself when not running interactively:
# get rvm for non-interactive shells (eg capistrano) too
source /etc/profile.d/rvm.sh
export BASH_ENV=$HOME/.bashrc
export rvm_is_not_a_shell_function=0
# If not running interactively, don't do anything
[ -z "$PS1" ] && return
I had the same problem. I realized, that I accidentally installed RVM for multiple users, too. After deleting the directory /usr/local/rvm and edit ~/.bashrc like zoonmix suggested, the problem was solved.
Make sure that on the server you have done something like rvm --default 1.9.2 to set RVM's Ruby to be the default. Otherwise, it will always use the default system Ruby.
zoomix's is the best solution. But when you change with "ruby rvm use system" in terminal or what else you get an error :
Warning! PATH is not properly set up, is not at first place.... To solve that put the snippet just before the return instead of at the top of the .bashrc file (Debian Jessie here)
case $- in
*i*) ;;
*)
[[ -s "$HOME/.rvm/scripts/rvm" ]] && source "$HOME/.rvm/scripts/rvm" # Load RVM into a shell session *as a function*
return;; esac
I'm having trouble getting the Ruby Version Manager rvm to source from my Ubuntu 10.04 .profile. The code:
[[ -s "$HOME/.rvm/scripts/rvm" ] && . "$HOME/.rvm/scripts/rvm"
...never does what I expect it to (i.e. give me the rvm program when I open a new shell or start a new session); but if I execute
source .profile
in a new shell after logging in, it works! Why will it work when I manually source it, but not automatically at login?
It would appear that Ubuntu handles it's logon scripts differently than most other linux distros
http://ubuntuforums.org/showpost.php?p=9127226&postcount=6
The above post has hints that GDM logins in Ubuntu don't process .bash_profile or .profile the way most other linux distros do. I have had to put the line loading RVM in the ~/.bashrc and that has not caused any problems yet.
Sourcing $HOME/.rvm assumes you have installed RVM a single user, specially, the user whose home directory is $HOME. Likely, on your Ubuntu system, RVM has been installed system wide, and thus you must source the RVM scripts as such:
In your .bashrc file add:
\# Set rvm path
[[ -s "/usr/local/rvm/scripts/rvm" ]] && source "/usr/local/rvm/scripts/rvm"
before this line; this line will exit and not execute anything past it, which is fine for interactive logins, bit would be a problem is you are using non-interactive SSH logins for automation purposes.
\# If not running interactively, don't do anything
[ -z "$PS1" ] && return
The RVM installation page has a series of things to check to test the initialization of RVM. Read the "Troubleshooting your Install" section at the end of the RVM installation page.
Also, here's a description of how Bash reads its startup files which can help with this sort of problem.
I had a problem with Atom editor not picking up RVM environment and thus not finding rubocop command on Ubuntu 16.04. But the problem was not there when I started Atom from gnome terminal. What I've found was that RVM script ~/.rvm/scripts/rvm that you're supposed to be loading in your .profile has these lines at the beginning:
if
builtin test -n "${BASH_VERSION:-}" -o -n "${ZSH_VERSION:-}" -o -n "${KSH_VERSION:-}"
then
...
else
return 0
fi
Strangely, when executed at login, I've found $BASH_VERSION to be empty (while in gnome terminal it's sth like 4.3.46(1)-release), so the script would do early return leaving RVM not loaded properly. I tried to set BASH_VERSION to whatever and it worked fine.
Here is the complete code from my .profile that loads RVM:
local rvm_home="${HOME}/.rvm"
export PATH="$PATH:${rvm_home}/bin"
if [ -z "$BASH_VERSION" ]; then
export BASH_VERSION=4
fi
source "${rvm_home}/scripts/rvm"