Why Do I Have to Use Bash -L -C Inside My Container

Why do I have to use bash -l -c inside my container?

From bash(1):

• -l Make bash act as if it had been invoked as a login shell
• -c If the -c option is present, then commands are read from string.

You're running the command passed to the -c argument. -l makes it a login shell so bash first reads /etc/profile, which probably has the path to rvm which is what makes it work.

FWIW, here's what I do to install rvm in a docker container.

# Install some dependencies
RUN apt-get -y -q install curl rubygems

# Install rvm
RUN curl -L https://get.rvm.io | bash -s stable

# Install package dependencies
RUN /usr/local/rvm/bin/rvm requirements

# Install ruby
RUN /usr/local/rvm/bin/rvm install ruby-2.0.0

# create first wrapper scripts
RUN /usr/local/rvm/bin/rvm wrapper ruby-2.0.0 myapp rake rails gem

Customize docker container bash

I'm not sure using the ~/.profile configuration file is the best way to do what you want. Also, using RUN source /root/.profile won't have any effect since the line will be executed once only and won't be persistent when trying to execute the bash binary inside de container. (It will actually run a new bash session).

So.. first of all, the kind of configuration you are trying to do should be in the .bashrc file (Just because it is the place where it usually appear).

Then, as the bash man page say :

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 :

When an interactive shell that is not a login shell is started, bash
reads and executes commands from /etc/bash.bashrc and ~/.bashrc, if
these files exist.

What you should probably do :

In the Dockerfile :

COPY config/.bashrc /root/.bashrc

The .bashrc file you want to copy into your container is located in a config repo. This is where you should put you configuration.

Then, in the entrypoint :

exec "$@"

Then, you could run bash using the docker command :

docker run XXX /bin/bash

Can I run a bash script from a file in a separate docker volume before a container starts?

The problem is that the shell within which your /src/app/bin/start-app is ran is not an interactive shell => .bashrc is not read!

You can fix this by doing this:
Add the env file to instead:
/root/.profile

RUN echo "source /src/puppet/path/to/file/env/bootstrap" >> /root/.profile

And also run your command as login shell via (sh is bash anyhow for you via the hack in the Dockerfile :) ):

command: "sh -lc '/src/app/bin/start-app'"

as the command. This should work fine :)
The problem really is just missing to source that file because you're running in a non-interactive shell when running via the docker command instruction.
It works when you shell into the container, because bam you got an interactive shell that sources that file :)

How to set the locale inside a Debian/Ubuntu Docker container?

Put in your Dockerfile something adapted from

# Set the locale
RUN sed -i '/en_US.UTF-8/s/^# //g' /etc/locale.gen && \
    locale-gen
ENV LANG en_US.UTF-8  
ENV LANGUAGE en_US:en  
ENV LC_ALL en_US.UTF-8     

If you run Debian or Ubuntu, you also need to install locales to have locale-gen with

apt-get -y install locales

this is extracted from the very good post on that subject, from

http://jaredmarkell.com/docker-and-locales/

Path is different depending on how you connect to container

I'll answer my own question. This stack overflow post has the main info needed: Where to set system default environment variables in Alpine linux?

Given that, there are two alternatives:

• Declare PATH using the ENV option of the Dockerfile

• Or add PermitUserEnvironment yes to sshd_config file and define PATH in ~/.ssh/environment

docker msys2: Too many levels of symbolic links

I have found a solution - MSYS=nonativeinnerlinks

From: https://github.com/msys2/msys2-runtime/issues/58

Seems to be something relatively new that was imported from cygwin to do with mapped network drives. Not entirely sure what

---

Related Topics