I'm new to bash and scripting in general.
In short, I'm to run a particular build and one of the tasks fails. This is the first time I'm running this build so I was expecting all sort of issues.
The script starts with: #!/usr/bin/env bash
And fails with : python3.8: command not found at line X, which is: python3.8 -m venv $ENV_PATH
I'm using zsh, brew installed.
Which python:
➜ ~ which python3
/usr/bin/python3
➜ ~ which python
/usr/bin/python
Exact version:
➜ ~ python3 --version
Python 3.8.9
I also edited the .zshrc file and added an alias:
alias python3.8='python3'
And it opens up the Python3.8 terminal when I type 'python3.8' now.
What could be the source of this issue? I know I might have messed up a lot of things. I'm also confused with all of these Bash profiles. Using zsh while it loads the default bash? where does it take it's commands from?
Appreciate any help...
You need to source your PATH: Before you call python, you should put:
PATH+=:/usr/bin
The path in the shell script is different from your system path, so you need to source your system path within the shell script.
Related
The oneAPI toolkit provided by Intel requires sourcing of a bash script to add several executables/libraries to $PATH and other environment variables.
For this, the documentation instructs to run a provided script as
source setvars.sh
However, on a fresh Ubuntu 20.04 system (supported by Intel OneAPI), I get the following error.
$ source setvars.sh
:: ERROR: No env scripts found: No "env/vars.sh" scripts to process.
This can be caused by a bad or incomplete "--config" file.
Can also be caused by an incomplete or missing oneAPI installation.
After pouring through forums, I came upon a workaround here for zsh-type shells.
Following those hints, when I run
bash -c 'source setvars.sh'
There are no errors reported and the script runs perfectly. As expected, the env variables are not available after execution of the bash -c command.
One workaround to this, is to do
bash -c 'source setvars.sh; exec bash'
every time I open a new terminal. This is very annoying.
I would like to source setvars.sh somewhere inside .bashrc or .profile and forget about it.
Why does source setvars.sh not work and bash -c 'source setvars.sh' run without errors here.
Answering my own question.
This turned out to be an issue with the cd command being aliased to
cd "$#" && ls. Sourcing the setvars.sh script before the alias definition solved the issue.
Refer discussion on the Intel Communities forum here.
I am trying to install Anthos Service Mesh (ASM) for a Kubeflow installation and need /bin/bash to be v5+. MacOS comes with Bash v3.2.57 which doesn't work. Simply installing Bash v5+ in "/usr/local/bin" doesn't work either as several shell scripts for the install points to "/bin/bash" and thus I still get the old version.
I had hoped I could just temporarily move the new bash v5+ to "/bin/bash" and then revert after completing the ASM install - something like this:
>>>$sudo mv /bin/bash /bin/bash_old
>>>$sudo cp /usr/local/bin/bash /bin
>>>$make install_asm
>>>$sudo mv /bin/bash_old /bin/bash
>>>mv: rename /bin/bash to /bin/bash_old: Operation not permitted
So that doesn't seem to be possible
What would be the best way to get around this? It doesn't seem to work just adding an alias to .zshrc in the hope that whenever I execute a shellscript with "#!/bin/bash" it would actually call "/usr/local/bin/bash":
~/.zshrc:
alias /bin/bash="/usr/local/bin/bash"
>>>$/bin/bash --version
>>>GNU bash, version 5.1.8(1)-release (x86_64-apple-darwin19.6.0)
test_bash.sh:
#!/bin/bash
/bin/bash --version
>>>$sh ./test_bash.sh
>>>GNU bash, version 3.2.57(1)-release (x86_64-apple-darwin19)
Perhaps there is a way for me be permitted to move the binaries as in the example above?
By the way already the "/usr/local/bin/bash" is a link - not sure if that has any influence on what I am trying to do.
>>>$ll /usr/local/bin/bash
>>>/usr/local/bin/bash -> ../Cellar/bash/5.1.8/bin/bash
Any hints are warmly welcomed!
I used a combination of adding my new shell location to the list of approved shells in /etc/shells, then changing my user's default shell with:
chsh -s /path/to/new/bash/version
as well as making sure my new bash location was exported to the front of my path not the end, so commands looking for just any bash find that first:
export PATH=/opt/homebrew/bin/bash:$PATH
No issues with this for far but this is a new machine and I'm just getting it set-up. If you have a SHELL environment variable set in any of your bash start-up scripts make sure to change it to your new bash binary also.
I own the licensed version of Pycharm. I have installed BashSupport plugin as well.
However, I am not sure what steps are required to remotely test and execute a bash script on RHEL server.
I am able to configure a remote interpreter but the interpreter path is /usr/bin/python.
In my logic you need to change interpreter path to /bin/bash instead of /usr/bin/python or i don't understand what you are trying to do..
I've met the save problem today.
If I use the default pycharm bash configuration, I'll get the following error:
C:\windows\system32\bash.exe C:/git/NewProject/run.sh
/bin/bash: C:/git/NewProject/run.sh: No such file or directory
Process finished with exit code 127
So, I change the default Windows Script path to Linux absolute Script path as following:
Run successfully.
You gotta check the path on server, If there is alias set, You can check alias
$ which python
$ whence python (Some version)
$ ls -l `which python`
When running bash scripts inside zsh-Terminal I want it to use the homebrew bash version 4 instead of the default 3 of OS X.
How can I do that?
I installed bash 4 on my MacBook.
brew install bash
Instead of using it as the default shell using the following command, I want to keep my zsh.
chsh -s $(brew --prefix)/bin/bash # BAD! as I lose zsh
Still I want to run:
./my-cool-bash.sh
Use the following shebang in your scripts:
#!/bin/env bash
This makes them use the first bash in the PATH; which is the one you want.
This solution works with any Bash on any UNIX-like system.
use your new bash path:
ex, if new bash is in /usr/local/bin/
/usr/local/bin/bash my-cool-bash.sh
or write first line of script:
#!/usr/local/bin/bash
you could put an alias in your .zshrc file, something to the effect of
alias mcb='./usr/local/bin/bash/my-cool-bash.sh so that you can call it from your normal zsh whenever you want.
I tried activating a VirtualEnv through a shell script like the one below but it doesn't seem to work,
#!/bin/sh
source ~/.virtualenvs/pinax-env/bin/activate
I get the following error
$ sh virtualenv_activate.sh
virtualenv_activate.sh: 2: source: not found
but if I enter the same command on terminal it seems to work
$ source ~/.virtualenvs/pinax-env/bin/activate
(pinax-env)gautam#Aspirebuntu:$
So I changed the shell script to
#!/bin/bash
source ~/.virtualenvs/pinax-env/bin/activate
as suggested and used
$ bash virtualenv_activate.sh
gautam#Aspirebuntu:$
to run the script .
That doesn't throw an error but neither does that activate the virtual env
So any suggestion on how to solve this problem ?
PS : I am using Ubuntu 11.04
TLDR
Must run the .sh script with source instead of the script solely
source your-script.sh
and not
your-script.sh
Details
sh is not the same as bash (although some systems simply link sh to bash, so running sh actually runs bash). You can think of sh as a watered down version of bash. One thing that bash has that sh does not is the "source" command. This is why you're getting that error... source runs fine in your bash shell. But when you start your script using sh, you run the script in an shell in a subprocess. Since that script is running in sh, "source" is not found.
The solution is to run the script in bash instead. Change the first line to...
#!/bin/bash
Then run with...
./virtualenv_activate.sh
...or...
/bin/bash virtualenv_activate.sh
Edit:
If you want the activation of the virtualenv to change the shell that you call the script from, you need to use the "source" or "dot operator". This ensures that the script is run in the current shell (and therefore changes the current environment)...
source virtualenv_activate.sh
...or...
. virtualenv_activate.sh
As a side note, this is why virtualenv always says you need to use "source" to run it's activate script.
source is an builtin shell command in bash, and is not available in sh. If i remember correctly then virtual env does a lot of path and environment variables manipulation. Even running it as bash virtualenv_blah.sh wont work since this will simply create the environment inside the sub-shell.
Try . virtualenv_activate.sh or source virtualenv_activate.sh this basically gets the script to run in your current environment and all the environment variables modified by virtualenv's activate will be available.
HTH.
Edit: Here is a link that might help - http://ss64.com/bash/period.html
On Mac OS X your proposals seems not working.
I have done it this way. I'am not very happy with solution, but share it anyway here and hope, that maybe somebody will suggest the better one:
In activate.sh I have
echo 'source /Users/andi/.virtualenvs/data_science/bin/activate'
I give execution permissions by: chmod +x activate.sh
And I execute this way:
`./activate.sh`
Notice that there are paranthesis in form of ASCII code 96 = ` ( Grave accent )
For me best way work as below.
Create start-my-py-software.sh and pest below code
#!/bin/bash
source "/home/snippetbucket.com/source/AIML-Server-CloudPlatform/bin/activate"
python --version
python /home/snippetbucket.com/source/AIML-Server-CloudPlatform/main.py
Give file permission to run like below.
chmod +x start-my-py-software.sh
Now run like below
.start-my-py-software.sh
and that's it, start my python based server or any other code.
ubuntu #18.0
In my case, Ubuntu 16.04, the methods above didn't worked well or it needs much works.
I just made a link of 'activate' script file and copy it to home folder(or $PATH accessible folder) and renamed it simple one like 'actai'.
Then in a terminal, just call 'source actai'. It worked!