How to make things GLOBAL in Puppy Linux

[LazY Puppy]

Hi.

To easily get access to my external Files, Scripts, RoxApps, RunScripts, Linux & Wine Portables etc.pp. from within a bash script I used to use a simple code section in almost all of my scripts - therefor I hold multiple templates in /root/Choices/Templates like this one (marked up code is the mean part).

#!/bin/bash -a
#------------------------------------------------------------------------------
# Empty Script for LazY Puppy
# 2012-12-28 RSH for LazY Puppy
#------------------------------------------------------------------------------

# Get Application Directory
#--------------------------
APPDIR="`dirname "$0"`" # Application Directory
APPDIRAPP="`basename "$0"`" # Application Name
APPDIRDIR="`dirname "$APPDIR"`" # Directory of Application Directory
[ "$APPDIR" = "." ] && APPDIR="`pwd`"
export APPDIR="$APPDIR"
export APPDIR=`dirname "$0"`
[ "$APPDIR" = '.' ] && export APPDIR=`pwd`

# Get Boot Directory and $LPED definition File (LazY Puppy, L.A.S.S.I.E.)
if [ -f /usr/sbin/ceelab/tools/get_lped ]; then
[ ! -f /tmp/my_lped ] && /usr/sbin/ceelab/tools/get_lped
read LPED < /tmp/my_lped
[ ! -f "$LPED" ] && /usr/sbin/ceelab/tools/get_lped
. /usr/sbin/ceelab/lp2_sys_data/LP2_BootDir
[ -f "$LPED" ] && . "$LPED"
[ -f "$LPED" ] && LPEDFOUND="true" || LPEDFOUND="false"
else
LPEDFOUND="false"
echo "Note: File '/usr/sbin/ceelab/tools/get_lped' not found"
echo "Could not examine System Boot Directory"
echo "Also could not examine external Configurations File (e.g.: lped.cfg)."
echo "Hopefully, it's not needed for this OS/Script/Application..."
NOLPEDMSG="\n Note: File '/usr/sbin/ceelab/tools/get_lped' not found \n
Could not examine System Boot Directory \n
Also could not examine external Configurations File (e.g.: lped.cfg). \n
Hopefully, it's not needed for this OS/Script/Application... \n"
Xdialog --title "$AppTitle $AppVersion" --timeout 10 --icon "/usr/share/pixmaps/pads.png" --no-buttons --no-ok-label --no-cancel-label --msgbox "$NOLPEDMSG" 0 0 0 &
fi
# Now ready to use all external Scripts, RoxApps, Directories and Files

exit 0

#------------------------------------------------------------------------------
# End
#------------------------------------------------------------------------------

I'm using this to e.g. send .cpt files directly from a JWM Menu Pipe to the Corel Photopaint Application installed into a Wine SFS which loads automatically then.

While developing my T.O.P.L.E.S.S. I felt in Love with some Idea and then I've successfully tried to get the results of these special scripts (called in code above) into some global Environment Variables.

Instead of using above marked code I can use now a global Environment Variable to get access to Files, Programs and Directories.

List of my new Global Environment Variables:

Code: Select all

$MYBOOTDIR                                            $MYPAR2PRT
$MYBOOTPRT                                            $MYPIKONAPRG
$MYEXTERNALRUNSCRIPTS                    $MYROXAPPS
$MYEXTERNALSFSPLUSSCRIPTS             $MYRSHROXAPPS
$MYFILES                                                   $MYRSHSCRIPTBOX
$MYIMAGEMAGICKSFS                             $MYSARARSD
$MYIMAGICKSFS                                       $MYSARASCRIPTBOX
$MYJDKSFS                                                $MYSCRIPTS
$MYJRESFS                                                 $MYSYMLINKSTARGET
$MYLINUXAPPS                                          $MYWINEAPPS
$MYLPED                                                     $MYWINEAPPSSTARTER
$MYMODULES                                             $MYWINEINSTALLS
$MYPAR1PRT                                               $MYWINESFS

$MYBOOTDIR will return /mnt/sdc1/Tahr602CE if boot drive is sdc1
$MYBOOTDIR will return /mnt/sde1/Tahr602CE if boot drive is sde1

$MYMODULES will return /mnt/sde1/Module (depends on what directory is declared in the $LPED file in code above)
$MYWINESFS will return LP2_WineCorelSuite.sfs (depends on what SFS is declared in the $LPED file in code above)

So I'm loading the Wine SFS just by executing:

Code: Select all

lazy_sfs_load --cli --skip-fixmenus --quiet $MYMODULES/$MYWINESFS

No matter what my boot drive will be, it always finds and loads the wanted Wine SFS. No need to define or to declare anything else in the script for this!

To start Corel Photopaint 8 and to send the .cpt file to it I'm just using a second line in the script.

Code: Select all

exec wine start /Unix "/root/.wine/drive_c/Corel/Graphics8/Programs/photopnt.exe $@"

Tonight it reminds me to an much earlier question of mine in the forum about how to make functions global, but could not get any useful help on this. So after these global Environment Variables now in use for some months I thought about to give it a try tonight to create global Functions also using the same way doing this for the new global Environment Variables.

And, whooossshhhh...

...it worked out of the box!

Since I'm able here to let a pupmode=5 Puppy execute content of an external Script from a sub-directory of boot directory to be executed then in /etc/profile.local I just added a function to the external Script file. Just letting it play the 2barks.wav file in /usr/share/audio.

Code: Select all

function playme(){
	aplay "/usr/share/audio/2barks.wav"
} # playme
export -f playme

After adding the above code to the mentioned Script, I just rebooted again into pupmode 5. After X appeared on the screen I executed the terminal and typed just playme into it.

Hit enter and file /usr/share/audio/2barks.wav was immediately played by aplay!

So as you might already assume by the above function: the "secret" is to export anything at boot up that you want to get for a GLOBAL and EASY use.

I'm doing this in /etc/profile.local as $PATH is made global in /etc/profile and /etc/profile.local is next step after /etc/profile. I'm not sure about it, but some of this probably could be made also in /etc/rc.d/rc.local.

[LazY Puppy]

Ok.

As I'm doing the use of global made functions for the first time tonight (it's now 09:18 German local time) I have made some testings.

Making a function global that will only play 2barks.wav or executing a program etc. is quiet easy. To make a function global that will return useful values to the script used, is another, a different thing. And it wasn't quiet easy to achieve for a (still) newbie like me.

However, following some new "invented" small "rules" for creating such functions, I was successful to make functions global and to return useful values from them for the use in my scripts.

Therefor I will present here two short examples and list the rules I'm following.

The functions to be included into /etc/profile.local:

Code: Select all

# Get Width of Screen
function ScreenWidth(){
	export ScreenWidth_return=`xrandr | grep current | awk '{print $8}'`
} # ScreenWidth
export -f ScreenWidth

# Get Height of Screen
function ScreenHeight(){
	export ScreenHeight_return=`xrandr | grep current | awk '{print $10}' | tr -cd '[[:digit:]]'`
} # ScreenHeight
export -f ScreenHeight

As the examples show pretty well, the variable for the return value is named after the functions name plus adding _return to it.

Rules:
- use a unique name in Capitals and Non-Capitals for the functions name
- add _return to the functions name for the use of the return variable
- export the return variable

I have another function that returns multiple values. For this I'm following some similar rules to create the functions etc.

Rules:
- add _rt to the functions name plus number of returned values (e.g.: _rt4 to return 4 values from the function)
- add _return plus number of the value (e.g. _return1, _return2 ...) to the functions name for the use of the return variable
- export each used return variable

Checking the results:

After the functions are added to /etc/profile.local and the system was rebooted just open a terminal. Type into the Terminal:

Code: Select all

ScreenWidth; echo $ScreenWidth_return

and the terminal output should be somewhat like 1280.

Type into the Terminal:

Code: Select all

ScreenHeight; echo $ScreenHeight_return

and the terminal output should be somewhat like 1024.

Note: the above codes need to be typed into a single line of the terminal!

I can think of creating something like a bash library to make the programmers life some easier. Interested newbies like me, missing any overview about bash programming can't do things like `xrandr | grep current | awk '{print $8}'` by entering code into the text editor. Interested newbies like me are just happy to find such code, to understand what it does and to use it when necessary but one day getting tired searching scripts to make copy and paste from that script to the current working on.

So creating some functions to make them global in a Puppy and to make any interested newbie able to use more complicated bash codes by a simple unique and clear function's name and its logical return variable could also ease the advanced programmers life a bit.

[greengeek]

Hi RSH - I remember reading somewhere that "export" is a bashism and can compromise later attempts to enhance system speed if bash scripts are later ported to ash etc.

Maybe I'm thinking of something totally different? Just a thought that popped into my head...

[LazY Puppy]

Hi RSH - I remember reading somewhere that "export" is a bashism and can compromise later attempts to enhance system speed if bash scripts are later ported to ash etc.

Thanks for the info.

Though I usually start my Scripts with #!/bin/bash -a this special mods do use #!/bin/sh (if I'm correct and it doesn't change somewhere in init, /etc/profile or /etc/rc.d/rc.sysinit etc.) - so I'll keep my eyes opened if some problems may there rise up its ugly heads.

Any links on this for more specific information how to avoid the issue or how to separate / make sure code will work in sh, bash & ash?

[musher0]

Hi RSH - I remember reading somewhere that "export" is a bashism and can compromise later attempts to enhance system speed if bash scripts are later ported to ash etc.

Maybe I'm thinking of something totally different? Just a thought that popped into my head...

I'm for bashisms if you're using bash as I'm for anglicisms if your language is
English and frenchisms if your language is French. It's very logical: you're supposed
to use the proper "-isms" of your language.

Think about it in reverse, from the point of view of bash: ash uses "ashims": limited
string manipulations, skimpy for..do..done's, no HERE function.

Ah. Who would have known?

BFN.