Shell Programming and Scripting

Before you get too carried away with that, you can use the shell's ability to source files to do that simply. If you can print a file like this:

Code:

VAR1="value"
VAR2="value"
VAR3="value"
SOMEOTHERVAR="value"

then you can directly load it like . /path/to/configfile

Oh, and you can dump a lot of variables at once in a loop in BASH shell:

Code:

for VAR in A B C D E
do
        echo "$VAR=\"${!VAR}\""
done > ~/.scoperc

$VAR is the variable name, for example A. ${!VAR} is interpreted by the shell's name to mean the contents of variable A, as if you'd done ${A}.

Hi Corona688...

Thanks a mill' I will certainly take your advice.

FTTB here is the last of the timebase uploads, less _trigger_ modes, and including the first ultra-simple circuit for the MacBook Pro 13 inch as a comment right at the end of the script.

It includes an offset to allow for sound card midpoint bit error...

I intend to have eveything for basic calibration as part of the script, incuding ultra simple circuits, and matching code if required...

There is now a commented out sinewave generator for Linux machines with /dev/dsp to experiment with...

Although the circuit remains the same the people experimenting will have to work out the dual Stereo I/O plugs wiring for themselves...

Best viewed in plain text mode and watch for wordwrapping, etc...

Hi Corona688...

That small snippet that saves and loads a config file seems to work an absolute dream.
Simplicity at its best, _noise_ free to kids that might view it.

Test code "config.sh"; only tested on this Macbook Pro, assuming my Debian works too.

Code:

scan_start=0
scan_jump=1
zero_offset=0
speed="FASTEST"
> /tmp/AudioScope.config
chmod 777 /tmp/AudioScope.config
printf "scan_jump=12\n" >> /tmp/AudioScope.config
printf "scan_start=6\n" >> /tmp/AudioScope.config
printf "speed='10mS'\n" >> /tmp/AudioScope.config
printf "zero_offset=0\n" >> /tmp/AudioScope.config
. /tmp/AudioScope.config
sleep 1
printf "$scan_start $scan_jump $zero_offset $speed\n"

(Just shows how little I know compared to the big guns.)

I am a very quick learner...

I sure am glad you are _on_my_side_... ;o)

Thanks a lot matey...

WIll now see how it works in the main script...

777 is not the magic sledgehammer to fix all permissions problems. It's certainly not a habit I want to teach to kids. 660, or even 600, should do(executable permission is not needed for a script you source). Or just leave it alone.

The traditional location for user config files is ${HOME}, aka ~/, more appropriate than /tmp/

Hi Corona688...

Point taken, except I always do this whilst testing and back down when proven or leave if I want things _global_...

Again I always tend to use the default /tmp/; C:\Windows\Temp; T: and so on as these are usually definitive on any particular platform invovled and you can clear them out as you like.
I've no idea if WIndows 8 (TM) has the ability to allow any/all users to R/W globally to C:\Windows\Temp as I haven't got it, nor do I want it...

My methods may not be the done practice but my motto is "get it working first then improve on it" using the KISS method...

LBNL if anything looks like _noise_ to a kid then I do it longhand for them to understand.

I don't deny that I know little compared to professionals code wise but I sure know how to get things like this project working to give kids a chance to do, and experiment with, for themselves... :-)

Your input has been a great asset and saved me searching for things I don't know about, however, KISS is also extremely important to me...

HTH, G'Night...

...which is where this habit comes from. You see it used and see that it works, and eventually come to believe it's sometimes necessary. Others see it done in code you make, and come to believe this too.

600 or 700 is always enough to access your own file, by definition, and files you create are your own files, by definition.

660 or 770 is plenty for sharing. If it's not, it's not the file permissions but the group arrangement that's wrong.

777 allows anyone, including not just other users but system daemons and other such things which have no business being there. Someone could pervert a webserver into overwriting the file with their own code, since it's open to writing from anything, web daemon included.