I have a simple shell script:
#!/bin/bash
echo test
I can execute script successfully as:
./test.sh
and
source ./test.sh
However, the following throws an error:
. ./test.sh
error:
.: Command not found.
What could be causing the error? This works on el capitan (which was an upgrade) but not on sierra. Did something change with the terminal or default shell in the past few major releases?
I'm running macOS 10.12.3 with the default terminal - this is a clean install and NOT an upgrade (upgrades hang onto previous shell settings).
It sounds like you've switched your default shell to something other than bash, probably csh, where (a) . is not built-in command (only source is), and (b) even if it were, you couldn't load Bash code into the current session anyway.
To check what your default shell is, run echo $SHELL.
Run chsh -s /bin/bash to switch back to bash as your default shell.
Related
I have tried to run:
uninstall_oh_my_zsh
but i get a message stating that: -bash: uninstall_oh_my_zsh: command not found
Other commands i have tried are:
chmod +x ~/.oh-my-zsh/tools/uninstall.sh
I get a response stating that: No such file or directory
sh ~/.oh-my-zsh/tools/uninstall.sh
Ran:
chsh -s /bin/bash
To change default terminal from /bin/zsh to /bin/bash
I also tried:
rm -rf ~/.oh-my-zsh
rm ~/.zshrc
cp ~/.zshrc.pre-oh-my-zsh ~/.zshrc
source ~/.zshrc
None of them have worked thus far, when i open my terminal. I get a message stating that:
The default interactive shell is now zsh.
To update your account to use zsh, please run chsh -s /bin/zsh
You don't have Oh My Zsh (a set of configuration files for zsh and a way to manage them) installed in the first place.
The warning is coming from /bin/bash itself; it's hard-coded into the executable supplied by macOS.
$ strings /bin/bash | grep "default interactive shell"
The default interactive shell is now zsh.
Though they don't say so, I suspect the warning is there because they plan to remove bash from future versions of macOS entirely. They stopped providing newer versions of bash years ago.
Your default shell is already /bin/bash; the warning is recommending that you switch to /bin/zsh.
You can continue to use bash, though I recommend installing a newer version (3.2 is old) using something like Homebrew, then changing your login shell to the new version.
However, unless you are really committed to using bash, I suggest given zsh a try.
I recently reinstalled Mojave on my Macbook Pro. Before the install, I had several bash scripts written, all of which were executable by double-clicking on them. They are all .command extensions. For each file, I ran chmod +x to make it executable. The shebang in each of the scripts is: #! /usr/bin/env bash
After the install, I cannot get the scripts to run by double-clicking. If I access the scripts through terminal, they run fine. But if I double-click, it opens a terminal window with the title of the script, but nothing happens, the script never executes.
I installed bash through homebrew, then entered /usr/local/bin/bash into /etc/shells. In terminal, if I enter which bash it returns /usr/local/bin/bash. If I enter echo $SHELL it returns /bin/bash.
I want my system to be running the bash 5 that homebrew installed. I thought I had my terminal configured correctly, but I can't figure this out. Any help would be extremely appreciated.
I attached a screenshot of the terminal output too in case it would be helpful. I wrote a script for an example titled "hello.command":
#! /usr/bin/env bash
echo 'Hello'
This is what shows up if I double click it:
In /etc/shells, add an entry on a newline:
/usr/local/bin/bash
Note that to add this entry to /etc/shells, you need root privileges.
The ${parameter[^|^^|,|,,][pattern]} parameter substitution is giving me a bad substitution error.
$ echo $greeting
hello world
$ echo "${greeting^}."
-bash: ${greeting^}.: bad substitution
I updated to the latest bash version and keep getting the error.
GNU bash, version 4.4.19(1)-release (x86_64-apple-darwin17.3.0)
I've looked everywhere and the only suggestion I've found is making sure it's running bash 4.
$ echo $SHELL
/bin/bash
I'm running macOS High Sierra.
Your default shell is not the bash shell (downloaded from brew install bash) that contains the v4 which supports the parameter expansion syntax you are referring to.
On macOS echo $BASH_VERSION will tell you the version of the current shell. bash --version tells you the version of the first bash in your $PATH. So the way you were looking at the version was not telling you the version that you were running.
You need to add the recent version of bash to the file /etc/shells as the last line and use the command to set the shell as the default on Terminal
chsh -s /usr/local/bin/bash "$USER"
After this close and re-open the Terminal to make it effect. Without adding this default option in your Terminal, you could only use the recent bash only on scripts with interpreter she-bang set to #!/usr/local/bin/bash
See also this Ask Different answer to - Update bash to version 4.0 on OSX
I have a simple Gruntfile that I want to be able to run from an icon in my OSX dock.
I have created a very simple shell script (launcher.sh) that I will save as an application so I can add it to my dock. It works great when I run it directly in my Terminal:
#!/usr/bin/env bash
$(grunt serve --open)
It also works fine with this shebang: #!/bin/bash
However when I call the shell script from an Automator workflow I get the following error:
launcher.sh: line 2: grunt: command not found
This is my Automator set up:
What am I doing wrong?
Update
If I put this in my launcher.sh file:
#!/bin/bash
`/usr/local/bin/grunt serve --open`
I get a different error in Automator: env: node: No such file or directory
But, as before, if I run the script directly in Terminal its fine - so I think #mklement0 is right about the PATH
Update 2
launcher.sh
#!/bin/bash
grunt serve --open
Automator
PATH="/usr/local/bin:$PATH"
~/Public/Sites/launcher.sh
Now I'm still getting an error popup when I run it in Automator, but it has no details - it just says:
The action "Run Shell Script" encountered an error.
The Log panel shows a blank entry. Is there a way to get more info? A verbose mode perhaps?
Update 3
So this is weird... if I use &> ~/log it works. Without it it fails.
But this is working, thanks #mklement0, it'll do for now
PATH="/usr/local/bin:$PATH"
cd ~/Public/Sites && ./launcher.sh &> ~/log
The problem is that the $PATH variable when running from Automator doesn't have the same entries as when running from Terminal.
Notably, /usr/local/bin is missing, which is where grunt is typically installed (if installed globally).
A simple workaround is to add the folder in which grunt is installed to your $PATH at the top of the Automator shell script:
PATH="/usr/local/bin:$PATH"
~/Public/Sites/Launcher.sh
Aside from that:
Your shell command, $(grunt serve --open), should be just grunt serve --open - no need for a command substitution ($(...) or `...`), as that would actually first execute the command and then try to execute the output from that command.
The default working dir. when running a shell script from Automator is ~ (your home folder), which may not be what your script expects; it looks like your script expects its own dir. to be the working dir., so use cd ~/Public/Sites && ./launcher.sh to invoke it.
Automator will report an error in case the shell script exits with a nonzero exit code; the error message will include the shell script's stderr output (and nothing else) - sounds like no stderr output is being produced in your case.
To capture all output for diagnostic purposes, use something like ./launcher.sh &> ~/log
On macOS 10.11 through at least 10.15 (as of this update), $PATH has the following value inside a shell script run from an Automator workflow: /usr/bin:/bin:/usr/sbin:/sbin
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!