When I try to compile and run simple bash script.
export TEST_DRIVE=$(shell pwd)
echo $TEST_DRIVE
I get error shell: not found
comment:- I wanted to point out that I saw this on makefile.
Because shell isn't a command your system knows.
That's a valid make assignment though.
Did you mean export TEST_DRIVE=$(pwd)?
Related
I'm trying to run a CLI tool in Linux (Mint) which allows me to edit subtitles. It is named subedit: github link. In order to run it, I've added executable permission with chmod +x and added it to the path in bash. However, when I run it, I get the following error message:
bash: /home/main/Documents/shellTools/subedit/subedit: /usr/bin/bash: bad interpreter: No such file or directory
I'm not very experienced with external bash programs and forgot to do something that would be obvious in hindsight.
When I do echo $PATH this is the output:
/home/main/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/home/main/Documents/shellTools/subedit/
Could somebody please help?
Assuming bash is installed, (it usually is), change the first line of subedit from:
#!/usr/bin/bash
to:
#!/bin/bash
Or if one would prefer not to edit subedit, try this one-liner covering what Al-waleed Shihadeh suggested:
ln -s "$(which bash)" /usr/bin/bash
It seems that you don't have bash installed, you can verify that by running
which bash
if the above command returns "bash not found", then you need to install it.
In case the above command returns a path, you can use the below command to add a symlink to the expected path
ln -s $(path from the above command) /usr/bin/bash
Use the command termux-chroot ONCE!
If you want to always run at the start of a session, be sure to check if it was never run before.
if [ -z $CHROOT ]; then
CHROOT=1
termux-chroot
fi
When zsh was exporting a PATH from a script, it didn't read the path correctly.
My PATH was export PATH="~/path/to/stuff/", but when I tried to run a command located at that path, zsh could not find it.
When I changed the PATH to export PATH="$HOME/path/to/stuff/", then the zsh was able to run the command.
EDIT: The strange thing is that I just checked this and it's working again with export PATH="~/path/to/stuff/". There must be something weird going on with my dev environment.
EDIT 2: I failed to mention earlier that the script I am reading export PATH="~/path/to/stuff/" from is building a local dev environment for a team of developers who mainly use bash as their shell. I prefer to use zsh so I have to get my shell to play nice with all of the configs for the dominant bash setup across the team.
Use the following code to get what you want:
export PATH=~/Desktop/Capture/
echo $PATH
# Result: /Users/swift/Desktop/Capture/
Although, when you're using a string, you'll get this:
export PATH="~/Desktop/Capture/"
echo $PATH
# Result: ~/Desktop/Capture/
So to get it right, you'll have to try this approach:
tilde=~
export PATH="${tilde}/Desktop/Capture/"
echo $PATH
# Result: /Users/swift/Desktop/Capture/
P.S. Also, there's one useful command for tilde to be expanded.
Here's an example:
echo tilda=~
# Result: tilda=~
Use magicequalsubst command in zsh:
set -o magicequalsubst
echo tilda=~
# Result: tilda=/Users/swift
I am trying to build the open source drivers for the c1000a to fix my router. However, I run into a weird issue:
$ make PROFILE=963268BGW
make version is 3.81
kernel version is 3.13.0-29-generic
shell is /bin/sh. Bash version is
***************************************************
ERROR: /bin/sh does not invoke bash shell
***************************************************
make: *** [prebuild_checks] Error 1
Can anyone explain what this might mean?
The answer is that someone wrote a script or Makefile which depends on /bin/sh being Bash, and went out of their way to write code to detect that this is the case, rather than to write code which finds the shell that is required to run the script, like /bin/bash or /usr/bin/bash.
It is easy to tell GNU Make what shell to use for executing build "recipes" (bodies of rules), namely the SHELL variable. The default is /bin/sh/ but if you put
SHELL = /usr/bin/bash # or whatever else
then GNU Make will use that.
I'd gut the Makefile of the logic which tests /bin/sh and bails out, and set up the SHELL variable to point to Bash.
This error might happen when you are doing compilation in Debian flavor distributions such as Ubuntu. Use the command below to compile:
$> make PROFILE=963268BGW SHELL=/bin/bash
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!
I'm trying to write (what I thought would be) a simple bash script that will:
run virtualenv to create a new environment at $1
activate the virtual environment
do some more stuff (install django, add django-admin.py to the virtualenv's path, etc.)
Step 1 works quite well, but I can't seem to activate the virtualenv. For those not familiar with virtualenv, it creates an activate file that activates the virtual environment. From the CLI, you run it using source
source $env_name/bin/activate
Where $env_name, obviously, is the name of the dir that the virtual env is installed in.
In my script, after creating the virtual environment, I store the path to the activate script like this:
activate="`pwd`/$ENV_NAME/bin/activate"
But when I call source "$activate", I get this:
/home/clawlor/bin/scripts/djangoenv: 20: source: not found
I know that $activate contains the correct path to the activate script, in fact I even test that a file is there before I call source. But source itself can't seem to find it. I've also tried running all of the steps manually in the CLI, where everything works fine.
In my research I found this script, which is similar to what I want but is also doing a lot of other things that I don't need, like storing all of the virtual environments in a ~/.virtualenv directory (or whatever is in $WORKON_HOME). But it seems to me that he is creating the path to activate, and calling source "$activate" in basically the same way I am.
Here is the script in its entirety:
#!/bin/sh
PYTHON_PATH=~/bin/python-2.6.1/bin/python
if [ $# = 1 ]
then
ENV_NAME="$1"
virtualenv -p $PYTHON_PATH --no-site-packages $ENV_NAME
activate="`pwd`/$ENV_NAME/bin/activate"
if [ ! -f "$activate" ]
then
echo "ERROR: activate not found at $activate"
return 1
fi
source "$activate"
else
echo 'Usage: djangoenv ENV_NAME'
fi
DISCLAIMER: My bash script-fu is pretty weak. I'm fairly comfortable at the CLI, but there may well be some extremely stupid reason this isn't working.
If you're writing a bash script, call it by name:
#!/bin/bash
/bin/sh is not guaranteed to be bash. This caused a ton of broken scripts in Ubuntu some years ago (IIRC).
The source builtin works just fine in bash; but you might as well just use dot like Norman suggested.
In the POSIX standard, which /bin/sh is supposed to respect, the command is . (a single dot), not source. The source command is a csh-ism that has been pulled into bash.
Try
. $env_name/bin/activate
Or if you must have non-POSIX bash-isms in your code, use #!/bin/bash.
In Ubuntu if you execute the script with sh scriptname.sh you get this problem.
Try executing the script with ./scriptname.sh instead.
best to add the full path of the file you intend to source.
eg
source ./.env instead of source .env
or source /var/www/html/site1/.env