UNIX for Advanced & Expert Users

If you can limit your status values 0-127, with 0 for success, then you can do return "$status" and remove all your special return cases.

Also, you shouldn't do if [ $? -eq 1 ] since any code besides zero can mean error. You should do if [ $? -ne 0 ] to check if it's not zero, to catch every possible error value.

You could also do the precisely equivalent statement of

Code:

if ! KEYBOARD
then
        break
fi

for the exact same effect in something short and straightforward. Or even KEYBOARD || break

Hi Corona688...

(Will be back off holidays tomorrow for quicker replies.)

I like your 'return' method and it is now already coded for inside the next upload.
I researched the range of user available RCs and ended up using return 10 .

I used the number '1' in the example as proof of concept, no other reason.

I also checked any other of my break situations and all are valid.

Trust me to use a potential _exploit_ that I thought was valid. I knew Python was very strict, even from Version 1.4.0, (I still currently use this in AMIGA OS), but after using my getout method in bash I thought it was a_feature_ -- my bad. It has taught me to research deeper before commiting...

Thanks for that.

I am surprised however in all the years 'bash' has been around no-one has picked this up until some weeks ago...

'ksh' is fine as is 'dash' so I will test any ideas I get with those first before modifying to bash...

EDIT:
Just noticed your return $status and I like, very much. It will take a while to re-arrange but this will be added as I use statuses from 0 up to 255...

There's only two "predefined", as it were:
Anything else can mean whatever error you want it to mean. Some specific programs might have a traditional meaning for certain codes, but since audioscope is not any of those specific traditional programs, it doesn't matter.

By convention, there are five classes of exit codes:

Code:

0		success
1-125		unspecified failure of some type
126		utility to be invoked found, but is not executable
127		utility to be invoked not found
128+signo	process terminated or stopped by signal number sig

The standards require the 0 exit status to mean successful termination for most standard utilities. And they require 126 and 127 as described above for the command, env, nice, nohup, time, and xargs utilities. A process killed by a signal will exit with the above mentioned exit status, but there is nothing that keeps a process from exiting with an exit code greater than 128 (up to 255) even if it was not terminated by a signal.

On UNIX systems, a process killed by a SIGTERM signal would exit with exit code 143 and a process killed by a SIGKILL signal would exit with exit code 137. On other systems, the standards do not specify the signal numbers assigned to the various signals defined by the standards.

As always, there are exceptions to these conventions. (For example, the false utility's successful exit code is an unspecified non-zero value; not 0.)

Hi Don...

What I found from the mighty WWW was what you put, plus, an exit code of '1' was a general case reserved number too. I only needed one exit code so '10' was easy to remember.

'QUIT' and 'EXIT' are not the same in the AudioScope.sh code anymore.
'QUIT' requires Corona688's return 10 whereas 'EXIT' uses exit 0 .
They both do different things now...
(AudioScope.sh with my major __bash_feature__ error corrected, is now ready for upload.)

Trust me to find a possible exploit that I thought was a feature.
It still surprises me it has taken this long to become apparent however.