I am trying to make it easier to run a program which currently involves running multiple separate scripts. I just want to be able to run one .sh file which will then open multiple terminal windows and execute separate scripts in each window. I am having a problem now though where the scripts appear to be running (when I close the terminal windows it informs me that there is a process running), but nothing is being printed to the screen / console. It almost looks like the processes are being run silently in the background. I have simplified the program / scripts here to isolate the issue that I am having.
Here is the main shell script that is being used to call the others:
---main_script.sh---
echo "run my program"
gnome-terminal -- ~/Path/To/program_script_1.sh
sleep 2
gnome-terminal -- ~/Path/To/program_script_2.sh
And here are the two program scripts being called from the main script:
---program_script_1.sh---
bash
conda activate MyEnv
echo "do the first thing"
sleep 1
echo "done"
---program_script_2.sh---
bash
conda activate MyEnv
echo "do the second thing"
sleep 1
echo "done"
all of the shell scripts are in the same folder / directory.
When I run main_script.sh, it runs successfully, but it doesn't print anything to the console, so it's as if the programs are running in the background.
I think that the issue may be related to the fact that I am calling bash within the shell script, but this is necessary in order to be able to load my conda environment.
Here are some screenshots showing what it looks like after running (notice that there is no text output in the 2 program scripts):
Related
Steps to reproduce.
Please note, I am using WSL (Ubuntu 18) version 1.
Windows version 1909 (OS Build 18363.900).
Create a dummy bash script foo.sh containing the option set -e.
#!/bin/bash
set -e
pwd
Execute the following commands in WSL.
$ source foo.sh
$ explorer.exe .
After I execute the second command explorer.exe . WSL closes abruptly.
I just tried it out, and indeed: When I run explorer, the explorer Windows opens in the background, and the process which starts the Explorer returns with exit code 1. I don't know why Microsoft in their infinite wisdom decided to implement it in this way.
Of course, having set -e in an interactive shell is insane. I suggest to unset it. If, the scenario is not an interactive shell (this is not entirely clear from your question), but you run the commands from inside a script, and you do want to stick with -e, start the explorer with
explorer.exe || true
to keep the shell running.
I made my own script to make testing a little faster to execute on my .NET projects.
The name of the script is TestCoverage and is located in /home/user/bin folder with executable permissions and also added to my PATH for convenience.
#!/bin/bash
echo "Collecting TestCoverage..."
dotnet test /p:CollectCoverage=true /p:CoverletOutputFormat=opencover
The script runs as expected but after it's done the terminal stops taking input. I can only press the Enter key and the cursor is blinking as usual.
Bash version 4.4.20 running on Ubuntu 18.04
I've made some testing and it seems to take input but it isn't showed to the console. The problem is not consistent, it comes and goes through different terminal sessions.
Your script (and likely the dotnet process it invokes, because echo is a shell intrinsic that usually returns within milliseconds) is probably still running and hasn't returned.
You can open another console and type ps aux -H to view the running processes - look out for some adjacent lines with TestCoverage, bash, and dotnet.
In those lines, you can see what state the process(es) are in
(RTM for further detail).
If you are running a console under X, you can first look around whether you accidentally pushed some running dotnet test ... window behind your console window. :-)
I have a simple, already-working bash script set up to launch specific files with specific programs in the gaming frontend EmulationStation on Windows.
But the frontend routes its actions through a Command Prompt. And when Command is used to run the script through Bash, the Bash shell just opens and then closes immediately.
Here's an image of what shows for the instant before Bash closes.
This is only happening when going through a separate Command Prompt first, such as Windows Command Prompt or Git Command Prompt. Running the script with an appropriate argument directly through the git-bash shell works just fine.
In case you want to see the script for any reason, here it is:
#!/bin/bash
defaultemulaunch="V:/Emulation/.emulationstation/systems/retroarch/retroarch.exe -L "V:/Emulation/.emulationstation/systems/retroarch/cores/bsnes_mercury_accuracy_libretro.dll" \"$1\""
emu1names=(\
"(1999) Fire Emblem - Thracia 776.smc")
emu1launch="V:/Emulation/.emulationstation/systems/retroarch/retroarch.exe -L "V:/Emulation/.emulationstation/systems/retroarch/cores/snes9x_libretro.dll" \"$1\""
gamename=`basename "$1"`
for index in ${!emu1names[*]}
do
game=${emu1names[index]}
if [ "$game" == "$gamename" ]; then
eval "$emu1launch"
fi
done
eval "$defaultemulaunch"
But it's worth pointing out that this is happening when trying to run any bash script when starting the process from a separate Command Prompt.
Note: Git is installed on the hard drive that houses the emulation frontend (V:)---not in the user directory or programs directory of the system's OS/boot drive (C:). I mention this because git-bash's failure at an apparent "login" step except when launched directly feels like it could be a default filepath issue.
Check if that program would still open/close a Windows when executed from the CMD with:
bash -c '/v/path/to/bash/script'
In your case:
set PATH=V:\Emulation\
set GIT_HOME=V:\Emulation\Git
set PATH=%GIT_HOME%;%GIT_HOME%\bin;%GIT_HOME%\usr\bin;%GIT_HOME%\mingw64\bin;%PATH
Then:
cd V:/Emulation/.emulationstation/roms/snes/
bash -c './gamelaunch.sh "./(1990) F-Zero.sfc"'
I usually make a run.bat script which would:
set the correct PATH
launch the correct script
That way, for any of my project, I just type run.
And it runs.
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'm trying to run a shell script from a breakpoint in Xcode 4.5 DP 3. I set the breakpoint as such using the Choose button.
However, upon hitting the breakpoint I get the following message:
Error in shell command for breakpoint "(selector name)". The command "/Users/Max/Developer/saveToLog.sh" does not exist.
I've tried to put regular shell commands, like "say test" but Xcode prints the same message (with a different command name, of course). The shell script works fine when I run it from terminal.
Ok, first check to make sure you have the shell permissions set correctly. In terminal type:
chmod u+x saveToLog.sh
And I would also locate the shell script inside the project folder (didn't seem to work correctly for me when the script was located on my desktop).
This is the script I tested on:
#!/bin/bash
touch ~/Desktop/ItWorks.txt
echo "This actually works!" > ~/Desktop/ItWorks.txt