I am trying to set the default python in my docker container to be python3 and have set the aliases in the dockerfile. When I open the .bashrc file, they show up. As far as I can tell, it should work but the default python version is still 2.7. if I run which python, it will still point to usr/bin/python rather than python3. Same with pip. Can anyone tell me what the problem is? Here is the command I'm using to alias:
RUN \
echo 'alias python="/usr/bin/python3"' >> /root/.bashrc && \
echo 'alias pip="/usr/bin/pip3"' >> /root/.bashrc
Does this look right? I am using ubuntu 17.10
You try to create a symlink for python bin
RUN ln -s /usr/bin/python3 /usr/bin/python & \
ln -s /usr/bin/pip3 /usr/bin/pip
other option is use update-alternatives for more visit this site
sudo update-alternatives --install /usr/bin/python python /usr/bin/python3
and another option is trying source the bashrc file after updating
RUN \
echo 'alias python="/usr/bin/python3"' >> /root/.bashrc && \
echo 'alias pip="/usr/bin/pip3"' >> /root/.bashrc && \
source /root/.bashrc
I recommend seeing all options of python images on Docker Hub
Tip: use anaconda or conda for managing your python versions (conda site)
The answer above is great, except it should be as follows:
RUN ln -s /usr/bin/python3 /usr/bin/python && \
ln -s /usr/bin/pip3 /usr/bin/pip
Perhaps they typo-ed by writing ls which just lists the contents of the directory, rather than using ln which actually creates symlinks.
Related
I'am trying to install brew on linux using
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install.sh)"
then adding brew to the path using
test -d ~/.linuxbrew && eval $(~/.linuxbrew/bin/brew shellenv)
test -d /home/linuxbrew/.linuxbrew && eval $(/home/linuxbrew/.linuxbrew/bin/brew shellenv)
test -r ~/.bash_profile && echo "eval \$($(brew --prefix)/bin/brew shellenv)" >>~/.bash_profile
echo "eval \$($(brew --prefix)/bin/brew shellenv)" >>~/.profile
It works fine on the current opened terminal but when i change the terminal I get
Command 'brew' not found
Any Idea how to fix this?
I found out the answer, it seems that I have to set the environment variable to
export PATH="/home/linuxbrew/.linuxbrew/bin:$PATH"
and not
export PATH="$HOME/.linuxbrew/bin:$PATH"
I know clearly how to install python3.6 in centos step by step.How can I do it automatically through shell scripts?
Through step-by-step methods, I use
tar -xvf python-file.tgz
./configure --prefix=/path/to/python3
make && make install
to install python3.6 successfully. What I want to do is to write these commands into a shell script and install it automatically.
My script is as follows:
#!/bin/bash
# creat folder if not exists. That folder if the directory of Python3 programs.
if [ ! -d /usr/python3 ];then
mkdir /usr/python3
else
echo "'/usr/python3' exists"
fi
DIR=`pwd`
# extract file from compressed file to tartget directory
tar -xvf Python-3.6.0.tgz -C /usr
# specify installation location
cd /usr/Python-3.6.0 && ./configure --prefix=/usr/python3
# make file and install
cd /usr/Python-3.6.0 && make && make install
# creat symlink
ln -s /usr/python3/bin/python3 /usr/bin/python3
ln -s /usr/python3/bin/pip3 /usr/bin/pip3
cd ${DIR}
pip3 install --no-index --find-links=./pkgs -r ./requirements.txt
It seems that this script isn't run line by line because /usr/python3 is empty, I want to know why.
Besides, I add && \ in each line except the last one, it seems works! I am really confused about it.
I'm writing a shell script to set up my virtual env environment and install all related python packages via pip.
virtualenv -q -p /usr/bin/python3.5 $1
/bin/bash $1/bin/activate
pip install -r requirements.txt
$1 is the name of the virtualenv.
The problem I have is that the pip command does not work in my virtualenv but is executed globally instead.
As I mean to know you have to activate the virtualenv with:
source activate
I am not sure if this can be done from within a shell script, but you can try it as follows:
virtualenv -q -p /usr/bin/python3.5 $1
source $1/bin/activate
$1/bin/pip install -r requirements.txt
# pip install -r requirements.txt
Excerpt from activate:
$ cat activate
# This file must be used with "source bin/activate" *from bash*
# you cannot run it directly
Looks like you've found the solution to your problem, but for future reference, you don't need to activate the virtualenv in order to run pip inside it:
#!/bin/bash
virtualenv -q -p /usr/bin/python3.5 $1
$1/bin/pip install -r requirements.txt
What was missing was the shebang
and I had to start the script using source myscript.sh
#!/bin/bash
virtualenv -q -p /usr/bin/python3.5 $1
source $1/bin/activate
pip install -r requirements.txt
I use the command docker run --rm -it govim bash -l to run Docker images, but it does not display color output.
If I source ~/.bash_profile or run bash -l again, output will then correctly be output with color.
Bash Prompt Image
My bash_profile and bash_prompt files.
The OP SolomonT reports that docker run with env do work:
docker run --rm -it -e "TERM=xterm-256color" govim bash -l
And Fernando Correia adds in the comments:
To get both color support and make tmux work, I combined both examples:
docker exec -it my-container env TERM=xterm-256color script -q -c "/bin/bash" /dev/null
As chepner commented (earlier answer), .bash_profile is sourced (itis an interactive shell), since bash_prompt is called by .bash_profile.
But docker issue 9299 illustrates that TERM doesn't seem to be set right away, forcing the users to open another bash with:
docker exec -ti test env TERM=xterm-256color bash -l
You have similar color issues with issue 8755.
To illustrate/reproduce the problem:
docker exec -ti $CONTAINER_NAME tty
not a tty
The current workaround is :
docker exec -ti `your_container_id` script -q -c "/bin/bash" /dev/null
Both are supposing you have a running container first, which might not be convenient here.
Based on VonC's answer I adding the following to my Dockerfile (which allows me to run the container without typing the environment variables on the command line every time):
ENV TERM xterm-256color
#... more stuff
CMD ["bash", "-l"]
And sure enough it works with:
docker run -it my-image:tag
For tmux to work with color, in my ~/.tmux.conf I need:
set -g default-terminal "screen-256color"
and for UTF-8 support in tmux, in my ~/.bashrc:
alias tmux='tmux -u'
My Dockerfile:
FROM fedora:26
ENV TERM xterm-256color
RUN dnf upgrade -y && \
dnf install golang tmux git vim -y && \
mkdir -p /app/go/{bin,pkg,src} && \
echo 'export GOPATH=/app/go' >> $HOME/.bashrc && \
echo 'export PATH=$PATH:$GOPATH/bin' >> $HOME/.bashrc && \
mkdir -p ~/.vim/autoload ~/.vim/bundle && \
curl -LSso ~/.vim/autoload/pathogen.vim \
https://tpo.pe/pathogen.vim && \
git clone https://github.com/farazdagi/vim-go-ide.git \
~/.vim_go_runtime && \
bash ~/.vim_go_runtime/bin/install && \
echo "alias govim='vim -u ~/.vimrc.go'" >> ~/.bashrc && \
echo "alias tmux='tmux -u'" >> ~/.bashrc && \
echo 'set -g default-terminal "screen-256color"' >> ~/.tmux.conf
CMD ["bash", "-l"]
The Dockerfile builds an image based off Fedora 26, updates it, installs a few packages (Git, Vim, golang and tmux), installs the pathogen plugin for Vim, then it installs a Git repository from here vim-go-ide and finally does a few tweaks to a few configuration files to get color and UTF-8 working fine. You just need to add persistent storage, probably mounted under /app/go.
If you have an image with all the development tools already installed, just make a Dockerfile with ENV statement and add the commands to modify the configuration files in a RUN statement without the installation commands and use your base image in the FROM statement. I prefer this solution because I'm lazy and (besides the initial setup) it saves typing when you want to run the image.
Using Vim and plugins within tmux
Adding -t is working for me:
docker exec -t vendor/bin/phpunit
Adding to VonC's answer, I made this Bash function:
drun() { # start container with the specified entrypoint and colour terminal
if [[ $# -lt 2 ]]; then
echo "drun needs 2+ arguments: image entrypoint" >&2
return
fi
docker run -ti -e "TERM=xterm-256color" "$#"
}
I think this is something that you'd have to implement manually. My container has Python, so here's how I print in color using a single line:
Example Docker file:
FROM django:python3
RUN python -c "print('\033[90m HELLO_WORLD \033[0m')"
RUN python -c "print('\033[91m HELLO_WORLD \033[0m')"
RUN python -c "print('\033[92m HELLO_WORLD \033[0m')"
RUN python -c "print('\033[93m HELLO_WORLD \033[0m')"
RUN python -c "print('\033[94m HELLO_WORLD \033[0m')"
RUN python -c "print('\033[95m HELLO_WORLD \033[0m')"
RUN python -c "print('\033[96m HELLO_WORLD \033[0m')"
RUN python -c "print('\033[97m HELLO_WORLD \033[0m')"
RUN python -c "print('\033[98m HELLO_WORLD \033[0m')"
Standard terminal:
You need to add the following line to your Dockerfile:
RUN echo PS1="'"'\[\e]0;\u#\h: \w\a\]${debian_chroot:+($debian_chroot)}\ \033[01;32m\]\u#\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\$ '"'" >> /app/.bashrc
Change the /app/.bashrc to where your .bashrc file is in the docker.
If you want ls command to have colors too add this line:
RUN echo alias ls="'"'ls --color=auto'"'" >> /app/.bashrc
I compiled the library GLEW. It seemed to work fine, here is the output of make install:
install -d -m 0755 "/usr/include/GL"
install -m 0644 include/GL/wglew.h "/usr/include/GL/"
install -m 0644 include/GL/glew.h "/usr/include/GL/"
install -m 0644 include/GL/glxew.h "/usr/include/GL/"
sed \
-e "s|#prefix#|/usr|g" \
-e "s|#libdir#|/usr/lib64|g" \
-e "s|#exec_prefix#|/usr/bin|g" \
-e "s|#includedir#|/usr/include/GL|g" \
-e "s|#version#|1.11.0|g" \
-e "s|#cflags#||g" \
-e "s|#libname#|GLEW|g" \
-e "s|#requireslib#|glu|g" \
< glew.pc.in > glew.pc
install -d -m 0755 "/usr/lib64"
install -m 0644 lib/libGLEW.so.1.11.0 "/usr/lib64/"
ln -sf libGLEW.so.1.11.0 "/usr/lib64/libGLEW.so.1.11"
ln -sf libGLEW.so.1.11.0 "/usr/lib64/libGLEW.so"
install -m 0644 lib/libGLEW.a "/usr/lib64/"
install -d -m 0755 "/usr/lib64"
install -d -m 0755 "/usr/lib64/pkgconfig"
install -m 0644 glew.pc "/usr/lib64/pkgconfig/"
Now I wanted to use it on a KDevelop project. I created my CMakeLists.txt and linked the library there using find_package:
cmake_minimum_required( VERSION 2.6 )
project(openglengine)
include_directories(headers)
set(SOURCE_FILES src/main.cpp)
set(CMAKE_CXX_FLAGS "--pedantic-errors -Wall -std=gnu++11")
add_executable(openglengine ${SOURCE_FILES} ${HEADER_FILES})
find_package(PkgConfig REQUIRED)
pkg_search_module(GLFW REQUIRED glfw3)
include_directories(${GLFW_INCLUDE_DIRS})
target_link_libraries(openglengine ${GLFW_STATIC_LIBRARIES})
find_package(GLEW)
if (GLEW_FOUND)
include_directories(${GLEW_INCLUDE_DIRS})
target_link_libraries (openglengine ${GLEW_LIBRARIES})
endif (GLEW_FOUND)
install(TARGETS openglengine RUNTIME DESTINATION ~/projects/OpenGLEngine/bin)
I get no build errors.
When I try to run the program here is the output:
error while loading shared libraries: libGLEW.so.1.11: cannot open shared object file: No such file or directory
Any help will be appreciated.
EDIT:
Using the command locate libGLEW I get this output:
/home/lhahn/.local/share/Steam/ubuntu12_32/steam-runtime/amd64/usr/lib/x86_64-linux-gnu/libGLEW.so.1.10
/home/lhahn/.local/share/Steam/ubuntu12_32/steam-runtime/amd64/usr/lib/x86_64-linux-gnu/libGLEW.so.1.10.0
/home/lhahn/.local/share/Steam/ubuntu12_32/steam-runtime/amd64/usr/lib/x86_64-linux-gnu/libGLEW.so.1.6
/home/lhahn/.local/share/Steam/ubuntu12_32/steam-runtime/amd64/usr/lib/x86_64-linux-gnu/libGLEW.so.1.6.0
/home/lhahn/.local/share/Steam/ubuntu12_32/steam-runtime/i386/usr/lib/i386-linux-gnu/libGLEW.so.1.10
/home/lhahn/.local/share/Steam/ubuntu12_32/steam-runtime/i386/usr/lib/i386-linux-gnu/libGLEW.so.1.10.0
/home/lhahn/.local/share/Steam/ubuntu12_32/steam-runtime/i386/usr/lib/i386-linux-gnu/libGLEW.so.1.6
/home/lhahn/.local/share/Steam/ubuntu12_32/steam-runtime/i386/usr/lib/i386-linux-gnu/libGLEW.so.1.6.0
/home/lhahn/.local/share/Trash/files/glew/lib/libGLEW.a
/home/lhahn/.local/share/Trash/files/glew/lib/libGLEW.so
/home/lhahn/.local/share/Trash/files/glew/lib/libGLEW.so.1.11
/home/lhahn/.local/share/Trash/files/glew/lib/libGLEW.so.1.11.0
/home/lhahn/.local/share/Trash/files/glew/lib/libGLEWmx.a
/home/lhahn/.local/share/Trash/files/glew/lib/libGLEWmx.so
/home/lhahn/.local/share/Trash/files/glew/lib/libGLEWmx.so.1.11
/home/lhahn/.local/share/Trash/files/glew/lib/libGLEWmx.so.1.11.0
/home/lhahn/Documents/OpenGL-Utils/GLEW/glew-1.11.0/lib/libGLEW.a
/home/lhahn/Documents/OpenGL-Utils/GLEW/glew-1.11.0/lib/libGLEW.so
/home/lhahn/Documents/OpenGL-Utils/GLEW/glew-1.11.0/lib/libGLEW.so.1.11
/home/lhahn/Documents/OpenGL-Utils/GLEW/glew-1.11.0/lib/libGLEW.so.1.11.0
/home/lhahn/Documents/OpenGL-Utils/GLEW/glew-1.11.0/lib/libGLEWmx.a
/home/lhahn/Documents/OpenGL-Utils/GLEW/glew-1.11.0/lib/libGLEWmx.so
/home/lhahn/Documents/OpenGL-Utils/GLEW/glew-1.11.0/lib/libGLEWmx.so.1.11
/home/lhahn/Documents/OpenGL-Utils/GLEW/glew-1.11.0/lib/libGLEWmx.so.1.11.0
/usr/lib64/libGLEW.a
/usr/lib64/libGLEW.so
/usr/lib64/libGLEW.so.1.11
/usr/lib64/libGLEW.so.1.11.0
Which show that I have the library. Does that mean that the command find_package may be not working? Which is strange because I get no link errors.
So, I managed to make it work by creating a symbolic link in /usr/lib/ for the library that was in /usr/lib64.
sudo ln -s /usr/lib64/libGLEW.so.1.11 /usr/lib/libGLEW.so.1.11
Now it works fine. Since I am no expert on linux I don't know if that will bring me problems in the future.
I don't know if the answer by #Ihahn will have any issues but, if the some program is not finding your shared libraries, then first find the folder that your library was installed and is not in your shared library folder and then run sudo ldconfig <location_where_your_library_or_program_was_installed>. Sometimes this happens when you're installing/building programs via make install.Reference here..