I have a docker file as below. launch.sh is the entry point in this docker image.
FROM ubuntu:16.04
USER root
RUN apt-get update && apt-get install -y \
curl \
vim \
net-tools \
git \
iputils-ping \
wget
RUN apt-get install -y python
RUN apt-get update && apt-get install -y gcc g++ make libgflags-dev libsnappy-dev zlib1g-dev libbz2-dev liblz4-dev libzstd-dev
RUN curl -o- https://raw.githubusercontent.com/creationix/nvm/v0.33.11/install.sh | bash
ENV NVM_DIR /root/.nvm
RUN . $NVM_DIR/nvm.sh && \
nvm install 7.9.0 && npm install -g npm#5.6.0
ADD ./Docker/launch.sh /workspace/
CMD ["/bin/sh", "/workspace/launch.sh"]
The content of launch.sh is:
#!/bin/bash
cd /workspace/demo
npm install
node index.js
when I run the docker container: docker run IMAGE_NAME, I got this error:
npm: not found
node: not found
The node in this image is managed by nvm which has been installed and its script has been set on /root/.bashrc file. But I don't know why it can't find the nodejs commands. But if I run the container by docker run -it IMAGE_NAME bash, then manually run workspace/launch.sh command, everything works fine. It seems the ~/.bashrc is not executed when run the image. How can I let the container source .bashrc?
The content of /root/.bashrc is:
# ~/.bashrc: executed by bash(1) for non-login shells.
# see /usr/share/doc/bash/examples/startup-files (in the package bash-doc)
# for examples
# If not running interactively, don't do anything
[ -z "$PS1" ] && return
# don't put duplicate lines in the history. See bash(1) for more options
# ... or force ignoredups and ignorespace
HISTCONTROL=ignoredups:ignorespace
# append to the history file, don't overwrite it
shopt -s histappend
# for setting history length see HISTSIZE and HISTFILESIZE in bash(1)
HISTSIZE=1000
HISTFILESIZE=2000
# check the window size after each command and, if necessary,
# update the values of LINES and COLUMNS.
shopt -s checkwinsize
# make less more friendly for non-text input files, see lesspipe(1)
[ -x /usr/bin/lesspipe ] && eval "$(SHELL=/bin/sh lesspipe)"
# set variable identifying the chroot you work in (used in the prompt below)
if [ -z "$debian_chroot" ] && [ -r /etc/debian_chroot ]; then
debian_chroot=$(cat /etc/debian_chroot)
fi
# set a fancy prompt (non-color, unless we know we "want" color)
case "$TERM" in
xterm-color) color_prompt=yes;;
esac
# uncomment for a colored prompt, if the terminal has the capability; turned
# off by default to not distract the user: the focus in a terminal window
# should be on the output of commands, not on the prompt
#force_color_prompt=yes
if [ -n "$force_color_prompt" ]; then
if [ -x /usr/bin/tput ] && tput setaf 1 >&/dev/null; then
# We have color support; assume it's compliant with Ecma-48
# (ISO/IEC-6429). (Lack of such support is extremely rare, and such
# a case would tend to support setf rather than setaf.)
color_prompt=yes
else
color_prompt=
fi
fi
if [ "$color_prompt" = yes ]; then
PS1='${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u#\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\$ '
else
PS1='${debian_chroot:+($debian_chroot)}\u#\h:\w\$ '
fi
unset color_prompt force_color_prompt
# If this is an xterm set the title to user#host:dir
case "$TERM" in
xterm*|rxvt*)
PS1="\[\e]0;${debian_chroot:+($debian_chroot)}\u#\h: \w\a\]$PS1"
;;
*)
;;
esac
# enable color support of ls and also add handy aliases
if [ -x /usr/bin/dircolors ]; then
test -r ~/.dircolors && eval "$(dircolors -b ~/.dircolors)" || eval "$(dircolors -b)"
alias ls='ls --color=auto'
#alias dir='dir --color=auto'
#alias vdir='vdir --color=auto'
alias grep='grep --color=auto'
alias fgrep='fgrep --color=auto'
alias egrep='egrep --color=auto'
fi
# some more ls aliases
alias ll='ls -alF'
alias la='ls -A'
alias l='ls -CF'
# Alias definitions.
# You may want to put all your additions into a separate file like
# ~/.bash_aliases, instead of adding them here directly.
# See /usr/share/doc/bash-doc/examples in the bash-doc package.
if [ -f ~/.bash_aliases ]; then
. ~/.bash_aliases
fi
# enable programmable completion features (you don't need to enable
# this, if it's already enabled in /etc/bash.bashrc and /etc/profile
# sources /etc/bash.bashrc).
#if [ -f /etc/bash_completion ] && ! shopt -oq posix; then
# . /etc/bash_completion
#fi
export NVM_DIR="$HOME/.nvm"
[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh" # This loads nvm
[ -s "$NVM_DIR/bash_completion" ] && \. "$NVM_DIR/bash_completion" # This loads nvm bash_completion
Each command runs a separate sub-shell, so the environment variables are not preserved and .bashrc is not sourced (see this answer).
You have to source your script manually in the same process where you run your command so it would be:
CMD source /root/.bashrc && /workspace/launch.sh
provided your launch.sh is an executable.
As per documentation exec form you are using does not invoke a command shell, so it won't work with your .bashrc.
Edit:
BASH wasn't your default shell so
CMD /bin/bash -c "source /root/.bashrc && /workspace/launch.sh"
was needed in order to run your script.
If you want yo set your shell as BASH by default, you can use SHELL instruction as described in documentation, e.g.:
SHELL ["/bin/bash", "-c"]
None of the existing answers accurately answer the title question: Why ~/.bashrc is not executed when run docker container?
There are two things to be aware of:
Use login shell
According to the bash man page:
When bash is invoked as an interactive login shell, or as a non-interactive shell with the --login option, it first reads and executes commands from the file /etc/profile, if that file exists. After reading that file, it looks for ~/.bash_profile, ~/.bash_login, and ~/.profile, in that order, and reads and executes commands from the first one that exists and is readable. The --noprofile option may be used when the shell is started to inhibit this behavior.
Therefore, in order to have .profile/.bashrc read automatically upon invocation of bash, it is necessary to invoke bash with the --login or -l option.
You can do this in a couple ways:
1. Set the shell to include -l option. For example,
SHELL ["/bin/bash", "-l", "-c"]
2. Invoke -l for specific commands using the exec form of RUN:
CMD ["/bin/bash", "-l", "-c", "/workspace/launch.sh"]
Note top of .bashrc
From the man page above, we know the order in which profile files are searched and loaded. If you look at /root/.profile you may see something like this:
# ~/.profile: executed by Bourne-compatible login shells.
if [ "$BASH" ]; then
if [ -f ~/.bashrc ]; then
. ~/.bashrc
fi
fi
mesg n 2> /dev/null || true
This is how ~/.bashrc gets source for a bash shell. Therefore, we can expect ~/.bashrc to be sourced when the bash shell is used.
However, look carefully near the top of your .bashrc file:
# If not running interactively, don't do anything
[ -z "$PS1" ] && return
This means that effectively the remaining contents of .bashrc are ignored except for interactive shells.
One answer suggests using the -i option of bash to invoke an interactive shell. This does work because the environment variable PS1 is set for interactive shells, and therefore .bashrc continues.
However, perhaps you don't want an interactive shell. In this case, there are a few options:
1. Comment out the return line. You can use something like this in your Dockerfile:
RUN sed -e '/[ -z "$PS1" ] && return/s/^/#/g' -i /root/.bashrc
This modification to .bashrc will prevent its early exit from non-interactive invocations.
2. Move the nvm setup to .profile. Move the last three lines of your .bashrc file to .profile so they're executed unconditionally.
3. Manually source .bashrc. As other answers have already noted, you can certainly manually source .bashrc as needed, as in,
RUN source /root/.bashrc && /workspace/launch.sh
Observe that much of the content of .bashrc makes the most sense for interactive shells and is usually unnecessary otherwise, which may make option 2 above the most appealing.
with CMD and shell form
CMD /bin/bash -i "/workspace/launch.sh"
Edit
should also work with ENTRYPOINT and and using exec form using
ENTRYPOINT ["bash","-i","/workspace/entrypoint.sh"]
I believe the -i flag works in the intended way, the .bashrc file is used as intended, the other solutions did not work for me, the .bashrc file was never used
solution may not be ideal for everyone, with the -i flag the program may prompt for user interaction
ps: I used docker create and docker start -i "container name"
You can add source /path/to/bashrc in launch.sh and change the CMD to the following instead of changing to bash through CMD itself:
CMD ["/workspace/launch.sh"]
Alternatively, You can do the following in your Dockerfile instead of depending on bashrc
ENV NVM_DIR /root/.nvm
ENV NODE_VERSION 7.9.0
ENV NODE_PATH $NVM_DIR/v$NODE_VERSION/lib/node_modules #Ensure that this is the actual path
ENV PATH $NVM_DIR/versions/node/v$NODE_VERSION/bin:$PATH
RUN . $NVM_DIR/nvm.sh && \
nvm install $NODE_VERSION && npm install -g npm#5.6.0
Is it possible to start the mc-wrapper with sudo and still use the last selected directory on the console when quitting sudo mc (requirement number 4)? My default alias looks like this.
alias mc='EDITOR="${EDITOR-mcedit}" . /usr/lib/mc/mc-wrapper.sh'
Some errors (for the Googlers)
sudo: mc: command not found
sudo: .: command not found # "." == "source"
My requirements
Ubuntu 18.04.1.
The alias should work with and without sudo call.
If possible, a single alias for mc in /etc/bash.bashrc for all users.
The directory you changed to with sudo mc should be "preserved" after closing the Midnight Commander. This means that you will not be in the same directory as you started sudo mc (provided it is not the same directory).
Optional requirements
See if the alias was started with super powers.
See if the alias was started with sudo.
If the alias mc was started without super powers or sudo, ask if the program mc should still be started with sudo rights.
If the question is answered No, use my default alias.
In all other cases, the first four requirements should be met.
The editor (e.g. mcedit or vi) within mc should be selectable via another alias like mcvi (for vi) without code duplication.
Arguments should be passed on to the program, like sudo mc /opt/ /mnt/
Here's one hacky solution (tested, but the last two optional requirements are still missing).
/etc/bash.bashrc
alias sudo='sudo ' # fixes "sudo: mc: command not found" (breaks with an argument: sudo -H ll)
# sudo apt update && sudo apt install dialog mc pwgen
#
# Start the alias with a "real" command (instead of a shell keyword like "if") so that sudo is not confused.
# This first command (env) will eat sudo and all arguments! Even the following file redirection including the angle bracket is already executed without sudo.
alias mc='env > "/tmp/mc.env.$(whoami).$$"
MC_USER="$(whoami)"
MC_ENV_FILE="/tmp/mc.env.${MC_USER}.$$"
# cat "${MC_ENV_FILE}"
if [ "$(cat "${MC_ENV_FILE}" | grep "$(id -nu 0)" | wc -l)" -gt "3" ]; then
# echo "This alias was called with super powers."
MC_ROOT="root"
fi
if [ "$(cat "${MC_ENV_FILE}" | grep "^SUDO_" | wc -l)" -gt "3" ]; then
# echo "This alias was called with sudo (possibly sudo -i or sudo -s was entered before)."
MC_SUDO="sudo"
fi
if [ "${MC_ROOT}" == "root" ] || [ "${MC_SUDO}" == "sudo" ]; then
MC_DIALOG="0"
else
# echo "This alias was called as normal user."
dialog --cr-wrap --defaultno --title "sudo mc" --yesno "Do you want super powers (sudo/root)?\n\n(Alternatively you can use \"sudo mc\" directly next time.)\n\nAgain: Do you want super powers (sudo/root)?" 9 64
MC_DIALOG="$?"
tput reset
fi
if [ "${MC_DIALOG}" != "0" ]; then
# echo "No, do not use sudo and stay normal user."
# echo "Standard wrapper (without arguments)..."
EDITOR="${EDITOR-mcedit}" . /usr/lib/mc/mc-wrapper.sh # does not work with sudo because "." is not a program like "ls" or "grep"!
else
# echo "Yes, exec those decisive commands with super powers."
# echo "Custom wrapper (also without arguments)..."
MC_PWD_FILE_DIRNAME="${TMPDIR-/tmp}/mc-${MC_USER}/"
MC_PWD_FILE="${MC_PWD_FILE_DIRNAME}mc.pwd.$$.$(pwgen 13 1)"
sudo mkdir -p "$MC_PWD_FILE_DIRNAME"
sudo chown "$(sudo whoami)":"$(sudo whoami)" "$MC_PWD_FILE_DIRNAME"
sudo chmod 0700 "$MC_PWD_FILE_DIRNAME"
sudo EDITOR="${EDITOR-mcedit}" /usr/bin/mc -P "$MC_PWD_FILE"
sudo chown -R "$MC_USER":"$MC_USER" "$MC_PWD_FILE_DIRNAME"
if test -r "$MC_PWD_FILE"; then
MC_PWD=$(cat "$MC_PWD_FILE")
if test -n "$MC_PWD" && test -d "$MC_PWD"; then
cd "$MC_PWD"
fi
unset MC_PWD
fi
rm -f "$MC_PWD_FILE"
unset MC_PWD_FILE
unset MC_PWD_FILE_DIRNAME
fi
unset MC_DIALOG
unset MC_SUDO
unset MC_ROOT
rm -f "${MC_ENV_FILE}"
unset MC_ENV_FILE
unset MC_USER
# This terminating line break is required:
'
I didn't manage to use a function mcwrapper (and $(declare -f mcwrapper)) and I don't think it's that easy either!?
I'm trying to run this script by typing ~/scripts/recomposeUi.zsh but am receiving the following error when doing so:
/Users/me/scripts/recomposeUi.zsh:2: command not found: dcrs
Here is my script, recomposeUi.zsh:
#!/bin/zsh
cd ~/myProject/ && npm run build && docker build -t wm . && cd ~/projectTwo/ && dcrs && cd ~/myProject/
Here is my .zshrc:
alias dcd='docker-compose down'
alias dcu='docker-compose up -d'
alias dcp='docker-compose pull'
alias dcrs='dcd && dcp; dcu'
What is going wrong?
.zshrc is executed in interactive shell.
Shell for script isn't interactive.
Try to move your aliases to .zshenv (executed always) or add to head of your script command source ~/.zshrc (manually read)
I have 2 shell scripts and 2 mpkg installer, I am trying to use an unix excitable file to run them all. here is the script I have, but it always has error message "No such file or directory" ?
#!/bin/sh
# Find the absolute script current path
path=$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )
sudo sh $path/join.sh
sudo sh $path/join2.sh
#/usr/sbin/installer -dumplog -verbose -pkg $path/“esetv8.mpkg" -target /
#/usr/sbin/installer -dumplog -verbose -pkg $path/“sccm.mpkg” -target /
exit 0
Thanks so much!
The most common issue when handling variables containing paths of directories and files is the presence of special characters such as spaces. To handle those correctly, you should always quote the variables, using double quotes. Better code would therefor be:
sudo sh "$path/join.sh"
sudo sh "$path/join2.sh"
It is also advised to wrap the variables using curly braces, this can also help to avoid unwanted issues. Resulting in following code:
sudo sh "${path}/join.sh"
sudo sh "${path}/join2.sh"
While this should work, it's also appropriate to mention that it's advised to check whether the files actually exist before executing them. Checking a file for existence can be done using -f and checking execute permission using -x. The proper code is therefor:
[ -f "${path}/join.sh" ] && [ -x "${path}/join.sh" ] && sudo sh "${path}/join.sh"
[ -f "${path}/join2.sh" ] && [ -x "${path}/join2.sh" ] && sudo sh "${path}/join2.sh"
Note that if you have a bunch of these, you'd be better off executing them using a for loop. Note also that -f becomes redundant when checking -x so better code would be:
[ -x "${path}/join.sh" ] && sudo sh "${path}/join.sh"
[ -x "${path}/join2.sh" ] && sudo sh "${path}/join2.sh"
Writing a script to automate my flask environment setup.
if [[ -z $1 ]];
then
echo "usage: flaskup <dirname> <template dir>";
exit
else
virtualenv $1 &&
cd ./$1 &&
source bin/activate &&
bin/pip install flask &&
mkdir ./app &&
mkdir ./app/static &&
mkdir ./app/templates &&
exit;
fi
I'm expecting this to leave me in the directory it created, with the virtual environment activated, however it leaves me in the same directory I ran the script from. What can I do to make the script exit with the shell in the activated virtual environment?
If you run the script in its own shell (run it as /path/to/script or script if it lives in your $PATH) then you can't get what you want. The shell that runs the script is a different shell then the one you ran it from and it cannot change the status of the parent shell. The closest you could do would be to have the script echo the path as output and run it as cd "$(/path/to/script)" or similar.
Alternatively, if you run the script as . /path/to/script (or similar) then you are running it with your current shell and any directory changes it makes will be happening in your current shell and not a sub-shell.