puppyluvr wrote:
OK, really, probably a noob question, but if I write scripts using
alias`s on my system, they will not run on other systems???
Since the days of Moses, Puppy started using BusyBox extensions for
its common command utilities.
I like using genuine utilities.
This can cause some differences which need adjusting when porting.
I recently setup 5.20 and ported my mountcontrol script to Puppy. It
wouldn't mount an NTFS partition. An on screen failure about not
understanding a -f or something.
My script was written for the true mount command. Puppy's mount
command is a script written by Barry.
The real mount command in Puppy is called mount-FULL
I did a search and replace. Replaced all instances of mount with
mount-FULL
~~~~~~~~~~~~~~
When we make our scripts, we want them portable. I already knew
about Puppy's mount-FULL, because of this I could have made the
'control center' automatically portable with a couple simple
commands at the top of the script by using a variable for the
command 'mount'. Very simple, as shown below.
Code: Select all
mntcmd=mount
[ -f /bin/mount-FULL ] && mntcmd=mount-FULL
The 'control center' would have adjusted itself with no user
intervention.
Where I often have problems when porting scripts is directories
don't exist on the new setup which existed on the old one.
This is why we want to keep in mind conditional checks and
branches when writing scripts.
Here is an example:
Code: Select all
[ ! -d $destdir ] && echo "$destdir doesn't exist, exiting" && exit
Note here how a potentially damaging script becomes safe.
I check the condition, branch to a message, branch to quit.
Ideally you would use so much care, you could hand your script to
another Puppy user and have it work.
If you wish to share scripts, you must think of a lot of things, far
beyond your individual setup. Also, that a script might be floating
around for years.
Here is an example of conditional checks and branching. We want to
make sure the user is advised, if he is not using 5.20
Code: Select all
grep DISTRO_VERSION=520 /etc/DISTRO_SPECS>/dev/null
if [ "$?" -ne "0" ] ; then
echo " This script was written and tested for Puppy version 5.20"
echo " You are "not" using this version, there may be unexpected"
echo -n " problems, do you wish to continue (y,n)? "
read a
if [ "$a" != "y" ] ; then
echo;echo " You choose not to continue, no changes made"
exit
fi
fi
Please note how we indent and nest our statements and commands.
It makes reading much easier.
On second thought, I'll explain. If you are working in a group, your
friends won't like it if you don't indent. And in a group do things by
convention, such as variables in UPPERCASE.
if begins our if statement, fi ends it.
By indenting everything inside it, we can easily see where the if
statement begins and ends. Simply look straight down the column
for the end of the statement.
I put an if statement inside an if statement and indented again.
Look at the difference in readability with and without indenting.
Code: Select all
grep DISTRO_VERSION=520 /etc/DISTRO_SPECS>/dev/null
if [ "$?" -ne "0" ] ; then
echo " This script was written and tested for Puppy version 5.20"
echo " You are "not" using this version, there may be unexpected"
echo -n " problems, do you wish to continue (y,n)? "
read a
if [ "$a" != "y" ] ; then
echo;echo " You choose not to continue, no changes made"
exit
fi
fi
Code: Select all
grep DISTRO_VERSION=520 /etc/DISTRO_SPECS>/dev/null
if [ "$?" -ne "0" ] ; then
echo " This script was written and tested for Puppy version 5.20"
echo " You are "not" using this version, there may be unexpected"
echo -n " problems, do you wish to continue (y,n)? "
read a
if [ "$a" != "y" ] ; then
echo;echo " You choose not to continue, no changes made"
exit
fi
fi
This example is a
very small snippet. You can run into statements
that begin and end a hundred lines later. More lines than can be
viewed in the editor at one time.
~