The other day one of our projects at work had its Git master branch updated, I had been working on a few projects of my own with local branches based off of the earlier master branch. As usual, I had to pull down the latest version of master and merge it in to my local branch. My normal workflow is for this is:
# Ensure I switch to the master branch locally git checkout master # Pull down the latest version of the repo git fetch -p origin # Merge the pulled down origin in to my local master git merge origin/master # Switch to the branch I am working on git checkout my-local-branch # Merge the master branch in to my-local-branch git merge master
The above works great and is my regular workflow. Most of the time I am able to merge things without conflict, however on this occasion there was a merge conflict. This wouldn’t be an issue, however I overlooked the
git output that indicated this to me.
What followed is I built a local
.deb package to test on one of our dev servers. I pushed to the package up, installed it via
dpkg and thought awesome, let’s give it a test. That’s when I ran in to a problem.
-bash: /usr/local/lib/path/to/the/script.sh: line 20: syntax error near unexpected token `<<<' -bash: /usr/local/lib/
path/to/the/script.sh: line 20: `<<<<<<< HEAD' Connection to dev.server closed.
Well that’s not good! Essentially the profile on the server loads a set of scripts by default and in one of those scripts was my merge error from
git. This caused a syntax error when reading the file and the profile failed to load, closing my
I didn’t have direct root access so I started looking for a way to disable loading of the profiles in order to allow me to SSH in. This yielded the following to tack on to the SSH command:
ssh dev.server "bash --noprofile"
The above tacks executes the
bash command with the
--noprofile flag. This flag specifically prevents profiles from loading, including as explained in the Bash man pages and includes
/etc/profile as well as local user profiles such as
This is great, I was able to log in, however at the same time, what I found was that this also meant a
TTY terminal control session was not started and I was unable to
sudo in order to edit or remove the file. I kept running into the following error:
sudo: no tty present and no askpass program specified
After some searching I found a great article on shell-tips.com that shed some further light on to what was happening with regard to the lack of a
TTY session and the proposed fix being adding the
-t flag to the
SSH call. In a nutshell the flag provides a pseudo-sudo shell when the connection is made, allowing me to run
sudo commands without loading the profiles that were calling the corrupt file.
I was able to successfully amend the file on the server and restore access while resolving the merge conflict locally and successfully merging the branches. The above is a great way to get around issues where a script being called from a user profile fails and your SSH session fails to load.