0

I am having a shell .myenv which is calling another shell testenv.sh

  • .myenv 
    #!/usr/bin/env sh
source ./testenv.sh
  • testenv.sh 
    #!/usr/bin/env bash
if [[ "$OSTYPE" == "linux-gnu" ]]; then
  echo 'Linux detected'
  python_binaries_path='/usr/local/bin:/usr/bin:/bin'
elif [[ "$OSTYPE" == "darwin"* ]]; then
  echo 'MacOS detected'
  python_binaries_path='/opt/local/bin:/usr/local/bin:/usr/bin:/bin'
else
  echo "Cannot determine OS type: ${OSTYPE}"
  exit 1
fi
python_binaries='python3.7 python3 python'
python_path=$(PATH=${python_binaries_path} which ${python_binaries} | head -n 1) || true
echo "python_path=$python_path"
python_major_version=$(${python_path} -c 'import platform; major, minor, patch = platform.python_version_tuple(); print(major)')

    echo "python_major_version=$python_major_version"
echo "python_binaries_path=$python_binaries_path"

When I do source .myenv, it's not able to detect the python_major_version

Linux detected
python_path=alias python='python3.7'
-bash: alias: -c: not found
-bash: alias: `import platform; major, minor, patch ': invalid alias name
python_major_version=
python_binaries_path=/usr/local/bin:/usr/bin:/bin

When I do sh testenv.sh, it is able to detect the python_major_version

Linux detected
python_path=/usr/local/bin/python3.7
python_major_version=3
python_binaries_path=/usr/local/bin:/usr/bin:/bin

Below line is creating problem and I am running these scripts on Centos7.

python_major_version=$(${python_path} -c 'import platform; major, minor, patch = platform.python_version_tuple(); print(major)')

But this script is working fine in Google cloud shell which obviously as cloud shell runs in Debian environment

$ cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux 10 (buster)"
NAME="Debian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"
VERSION_CODENAME=buster
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"

I am looking for a solution or change to a script so that it can work in both Linux and cloud shell environment.

I feel alias is causing some problem. below is my .bashrc file

# .bashrc

Source global definitions


if [ -f /etc/bashrc ]; then
        . /etc/bashrc
fi


Uncomment the following line if you don't like systemctl's auto-paging feature:


export SYSTEMD_PAGER=


User specific aliases and functions


alias python=python3.7
alias pip=pip3.7
AdminBee
  • 22,803
vikrant rana
  • 248

1 Answers1

2
  1. Let's start with the easy bit

When I do sh testenv.sh [...]

That's wrong. You've written a bash script, and even declared it as such, so call it with bash not with sh.

  1. More of the same

In the file .myenv you show that you have

#!/usr/bin/env sh
source ./testenv.sh

so you're declaring that this is a sh script (not a bash script), but then you're using source to pull testenv.sh in to this instance of sh. But we've already seen that testenv.sh is a bash script, not a sh script. So, unless you're using bash to run this sh script it will all come miserably tumbling down at the first opportunity.

On your local system you probably have sh as an alias for bash. On your cloud system it is almost certain that sh is an alias for a different shell such as dash. This is perfectly correct and the system is trying to make sense of your incorrect code.

Please stop using source, and also stop mixing sh and bash interchangeably. They are (or can be) different shells with different syntax.

Chris Davies
  • 116,213
  • 16
  • 160
  • 287
  • 2
    It might also be worth pointing out that source is a non-portable, bash alias for the standard . command. – terdon Sep 21 '20 at 15:26
  • Thanks for your answer, I have accepted that but I cannot change the way they are executing this script. I did change one line as "python_path=$(PATH=${python_binaries_path} type -P ${python_binaries} | head -n 1) || true" It is working now.. is that fine to do so. Please suggest – vikrant rana Sep 21 '20 at 15:33
  • 1
    I haven't even looked at the python line. The rest is so wrong it really ought to be fixed first – Chris Davies Sep 21 '20 at 15:37
  • In production we are executing it as source .myenv only – vikrant rana Sep 21 '20 at 16:10
  • 1
    @vikrantrana from what shell? Whatever that is, it's what is executing all your different scripts. Stop using source. – Chris Davies Sep 21 '20 at 16:23
  • they are executing this in cloud shell env but for testing I have to execute them in Linux also.. I got your point. Thanks – vikrant rana Sep 21 '20 at 16:28
  • could you please suggest also for below issue https://unix.stackexchange.com/questions/610875/modulenotfounderror-no-module-named-sqlite3 – vikrant rana Sep 23 '20 at 06:14