[SOLVED] Bash script exits, but doesn't exit

The "exit" is from the debugger - it signifies the exit from the while loop:
man -P 'less +421' bash

The "+" before the "exit" shows that it comes from the trace:
man -P 'less +1029' bash

The script never arrives at the user written "exit" statement in the bash script.

I agree with NevemTeve that it looks like the error isn't in the bash script, but in the python script - it doesn't terminate.


EDIT: please ignore my remark about the exit from the loop - testing by using exit with a return code (to identify the exit) shows that it is the user defined exit.

Hi,

Originally Posted by dwhitney67 Suffice to say, I would argue that using /bin/sh is NOT the proper syntax to use, especially for a script that will be used on multiple dissimilar Linux and/or Unix systems.

Sorry, but I couldn't disagree more, especially if you are looking for portability. If the script is fully compliant with bourne shell (eg no bashisms etc) then it should indeed specify #!/bin/sh. Every system has /bin/sh (regardless of what it is linked to), but not every system will have bash, dash, ksh, zsh or whatever.

Evo2.

Sorry, I was backwards with my thinking, I do use /bin/bash as well, my brain was in reverse there. Appreciate the corrections.

My other point was that the +exit was showing before the python script. However in running a brief test with the following script, the output does show the +exit before the echo.

#!/bin/bash
while ! ping -q -w5 -c1 127.0.0.1;
do
sleep 5
done
echo "This line" &
exit

Output result:

~/testcode$ bash -x pre-exit.sh 
+ ping -q -w5 -c1 127.0.0.1
PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data.

--- 127.0.0.1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.034/0.034/0.034/0.000 ms
+ exit
+ echo 'This line'
~/testcode$ This line

However the result here is that the script exits.

What you're saying is that you can only get back to a prompt if you use CTRL-C. Anything happen if you do CTRL-Z and then type bg<RET>? Another thing to test would be to issue ps before you run the script and then when you get back to a prompt (providing you do without CTRL-C) type ps again to see if there is a new bash running.

As an example, say I run emacs from the terminal but don't place it in the background

~/testcode$ ps
  PID TTY          TIME CMD
 7514 pts/4    00:00:00 bash
 7729 pts/4    00:00:00 ps
~/testcode$ emacs

And then if I hit CTRL-Z and enter bg<RET> I see that emacs is a process, but can't type anything in my terminal until I stop emacs.

I hit return here and it created some newlines, but no prompt


^Z
[1]+  Stopped                 emacs
~/testcode$ ps
  PID TTY          TIME CMD
 7514 pts/4    00:00:00 bash
 7730 pts/4    00:00:00 emacs
 7745 pts/4    00:00:00 ps
~/testcode$

To me it sounds as if your python script is running, but maybe not running in the background as you expect.

Agreed, it's not running in the background as I would expect it to. I'm using the same syntax with Dropbox and it has no problems.

The only thing I can think of is it's some sort of Python problem. Maybe the coder(s) who wrote My-Weather-Indicator didn't anticipate it being launched from a Bash script. I mean it is running properly, it just isn't letting the script finish.

The original reason I decided to do this was that if I went to cafe to work and the Internet connection wasn't immediately available it would crash. I wrote this script to have certain apps wait until there actually was an active Internet connection before starting. Who knew it would turn into such a hairball!

Originally Posted by rtmistler Sorry, I was backwards with my thinking, I do use /bin/bash as well, my brain was in reverse there. Appreciate the corrections. My other point was that the +exit was showing before the python script. However in running a brief test with the following script, the output does show the +exit before the echo. #!/bin/bash while ! ping -q -w5 -c1 127.0.0.1; do sleep 5 done echo "This line" & exit Output result: ~/testcode$ bash -x pre-exit.sh + ping -q -w5 -c1 127.0.0.1 PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data. --- 127.0.0.1 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 0.034/0.034/0.034/0.000 ms + exit + echo 'This line' ~/testcode$ This line However the result here is that the script exits. What you're saying is that you can only get back to a prompt if you use CTRL-C. Anything happen if you do CTRL-Z and then type bg<RET>? Another thing to test would be to issue ps before you run the script and then when you get back to a prompt (providing you do without CTRL-C) type ps again to see if there is a new bash running. As an example, say I run emacs from the terminal but don't place it in the background ~/testcode$ ps PID TTY TIME CMD 7514 pts/4 00:00:00 bash 7729 pts/4 00:00:00 ps ~/testcode$ emacs And then if I hit CTRL-Z and enter bg<RET> I see that emacs is a process, but can't type anything in my terminal until I stop emacs. I hit return here and it created some newlines, but no prompt ^Z [1]+ Stopped emacs ~/testcode$ ps PID TTY TIME CMD 7514 pts/4 00:00:00 bash 7730 pts/4 00:00:00 emacs 7745 pts/4 00:00:00 ps ~/testcode$ To me it sounds as if your python script is running, but maybe not running in the background as you expect.

Guys, please. I do it this way because I've always used Bash and I have templates set up to use Bash whenever I need a quck script. The templates I use include lots of comment headings for documentation because I can't remember every single nuance of every script I've cobbled together over the years. I'm not concerned about portability because every system I work on I make sure I have Bash available to me. If for some reason I don't have Bash available I use the available shell and make sure the script works before releasing it. It's all good.

Originally Posted by evo2 Hi, Sorry, but I couldn't disagree more, especially if you are looking for portability. If the script is fully compliant with bourne shell (eg no bashisms etc) then it should indeed specify #!/bin/sh. Every system has /bin/sh (regardless of what it is linked to), but not every system will have bash, dash, ksh, zsh or whatever. Evo2.

I don't want it to terminate so much just run in the background so the script can finish. It's just supposed to launch it and finish, not babysit while it does its thing.

I know I'm repeating myself but I used the same syntax with Dropbox and it works fine. This one though. Grrrr....

Originally Posted by harryhaller The "exit" is from the debugger - it signifies the exit from the while loop: man -P 'less +421' bash The "+" before the "exit" shows that it comes from the trace: man -P 'less +1029' bash The script never arrives at the user written "exit" statement in the bash script. I agree with NevemTeve that it looks like the error isn't in the bash script, but in the python script - it doesn't terminate. EDIT: please ignore my remark about the exit from the loop - testing by using exit with a return code (to identify the exit) shows that it is the user defined exit.

Jake - I get different results for bash and ash.

BASH

#!/bin/bash while ! ping -q -w5 -c1 127.0.0.1; do sleep 5 done echo "This line" & exit 3

bash -x ./test.exit.with.trace + ping -q -w5 -c1 127.0.0.1 PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data. --- 127.0.0.1 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 0.044/0.044/0.044/0.000 ms + exit 3

ASH

#!/bin/ash while ! ping -q -w5 -c1 127.0.0.1; do sleep 5 done echo "This line" & exit 3

ash -x ./test.exit.with.trace + ping -q -w5 -c1 127.0.0.1 PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data. --- 127.0.0.1 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 0.037/0.037/0.037/0.000 ms + echo This line + exit 3

Originally Posted by harryhaller Jake - I get different results for bash and ash.

Because ash's Trace gives different results to bash's trace. Running bash trace with the ash program produces the same result as the bash program. Running the programs without trace, they all run the same - including dash.

It's kind of an apples & oranges comparison though. I mean I think it's becoming apparent that it's not so much a Bash issue as a Python3 issue. For some reason MWI isn't getting into the background. ps STAT says it's Sl which means it's: S: interruptible sleep (waiting for an event to complete), and l: is multi-threaded (using CLONE_THREAD, like NPTL pthreads do).

At this point I don't think I'm going to find a Bash answer unless someone has a way to launch this thing (and its output) into the background.

Originally Posted by harryhaller Jake - I get different results for bash and ash. BASH ASH

I GOT IT!! It took a lot of research, but I finally figured it out!! Woo Hoo!!

#!/bin/bash
while ! ping -q -w5 -c1 www.google.com;
   do
       sleep 5
   done
dtach -n /tmp/mydtachsocket -z bash -c /opt/extras.ubuntu.com/my-weather-indicator/bin/my-weather-indicator &
exit

It turns out 'dtach' was what I needed. I looked at 'screen', but I think dtach runs a little lighter on resources and the options made more sense for what I was trying to do.

Testing it; I made sure MWI wasn't running, dropped my WiFi connection, and ran the script. It pinged the designated site once every 5 seconds. I connected to my WiFi network and once a Google ping was successful MWI launched and the script finished. ps -ax shows only dtach and My-Weather-Indicator running.

Besides the problem being a quirk that you wanted to understand and resolve, how bad is it really? You open a terminal window, run it and it restricts that particular terminal. Are you running a window manager? Just open another terminal window if this is the case.

I had two problems I was addressing. Both were related to turning on my netbook in a place where there was no immediate or any WiFi Internet connection.

If, for example, I go to a Peet's Coffee I manually connect to their WiFi Internet access, open Firefox, navigate to www.peets.com, and click an Accept button for their terms of service. After that I have an active WiFi Internet connection.

But before I had that active WiFi Internet connection I had to deal with;

First, My Weather Indicator crashed, and an annoying popup would ask what I wanted to do about it. Sometimes it would do this several times.

Second, once I did have an Internet connection Dropbox was non-responsive to very slow to respond. It often took up to 15 minutes to even start to sync and sometimes it just wouldn't start syncing at all.

This solution lets me replace the My Weather Indicator entry in my Startup Applications with this Bash script. Oh, and the variation of this Bash script I use for Dropbox didn't have the problems the MWI script had.

So these solutions were about addressing misbehaving apps in untraditional environments. Now everything works seamlessly in the background. No crashes, no popups, fast syncs. It's all good.

Originally Posted by rtmistler Besides the problem being a quirk that you wanted to understand and resolve, how bad is it really? You open a terminal window, run it and it restricts that particular terminal. Are you running a window manager? Just open another terminal window if this is the case.

I wanted to take a moment to thank everyone who offered ideas, comments, and questions!!

Cheers!!

Jake