(old)Puppy Linux Discussion Forum

Posted: **Mon 18 Jun 2012, 13:59**

sunburnt wrote: At least not any more broken than Puppy and Linux are already.

...except the problem isn't Puppy or Linux

Posted: **Mon 18 Jun 2012, 14:22**

Is /bin/sh pointing to bash or busybox and do you have stock puppy bash, because bash can be configured to have different behavior when called as sh.

Posted: **Mon 18 Jun 2012, 14:59**

technosaurus wrote:Is /bin/sh pointing to bash or busybox and do you have stock puppy bash, because bash can be configured to have different behavior when called as sh.

Yes i noticed this at the prompt .
Though autologin/login the prompt semms to be different on / and on /root .

Also using vi or vim keyboard behavior acts different . To get tab auto completion i need to type bash at the prompt, otherwise i get

# ls--->
instead of
# ls
ls
lspci

Posted: **Mon 18 Jun 2012, 23:54**

Hi jpeps; Do you know what the problem is?
I figured it was something in the env handling that didn`t like what it thought were dups.
It seems to be the case anyway.

Yo... technosaurus; Stock Lucid Puppy528-005 bash, and /bin/sh => /bin/bash

I`ll look at configuring bash, we`ve been trying to do that in another thread.
Wanted 3 CLI behaviors, mime, run RoxApps, and a multi. link junction.
All currently use a script, but all have to be built-in bash behaviors.

Hey Karl; Different behaviors at different times shows there`s a lot going on. Simplify!

Posted: **Tue 19 Jun 2012, 00:35**

APP_DIR is eaten by Rox. From ROX changelog:

Code: Select all

21-Jul-2000
~~~~~~~~~~~
In the path entry minibuffer, an exact match is favoured over any other
match. So, if you enter '.xsession' and press Return you'll get it, not
'.xsession-errors' or whatever!

The filer now clears APP_DIR from the environment so that child processes
don't get it. Fixed a bug which caused problems when using a small version
of the 'missing image' image.

If you launch terminal (rxvt) *NOT* from Rox, but from elsewhere (e.g. from JWM / menu) by choosing JWM menu --> terminal, you will see your APP_DIR is still there

Posted: **Tue 19 Jun 2012, 00:44**

sunburnt wrote:Hi jpeps; Do you know what the problem is?

You have to use unique variable names. APP_DIR is probably used by something else. If people gives examples that work, it's a good idea to try the posted code.

Posted: **Tue 19 Jun 2012, 01:28**

jpeps; I think jamesbond has nailed it... Kinda what I was saying.

jamesbond; I figured APP_DIR still existed, just a different shell than rxvt.

Goes along with my statement that there`s lots going on.

Posted: **Tue 19 Jun 2012, 02:31**

APP_DIR will work as an alias in .bashrc, but doesn't work as a variable name in the /etc/init.d folder. It doesn't matter how or what terminal you load, or what shell you are in. To me, that means it's a reserved variable name.

"Variable names

Since all reserved variables are UPPERCASE, the safest way is to only use lowercase variable names. This is true for reading user input, loop counting variables, etc., … (in the example: file)

prefer lowercase variables
if you use UPPERCASE names, do not use reserved variable names (see SUS for an incomplete list)
if you use UPPERCASE names, at best prepend the name with a unique prefix (MY_ in the example below"

http://wiki.bash-hackers.org/scripting/style

Posted: **Tue 19 Jun 2012, 05:05**

Makes sense, I usually use leading capitals, so that works well.

This is the first time I`ve run into a name space problem like this.

Posted: **Tue 19 Jun 2012, 07:55**

In order for any variable to be available in the environment in which a program runs, it has to be exported properly, or passed on the command line before the call to the program:

Code: Select all

unset APP_DIR
export APP_DIR
program-to run
# or:
APP_DIR=/path/to/somewhere program-to-run

Unsetting cleans up any existing APP_DIR value. APP_DIR is not a 'proprietary' enivronmental variable.

Why don't you simply get and use APP_DIR as the current directory. When an AppRun script is run it can find out where it is at:

Code: Select all

# Check for links and get APP_DIR
if [ ! -L "$0" ] ; then
	APP_DIR=`dirname "$0"`
	APP_DIR=`cd "$APP_DIR";pwd`
elif [ ! -z `which readlink 2> /dev/null` ] ; then
	APP_DIR=`readlink -f "$0"`
	APP_DIR=`dirname "$APP_DIR"`
else
	echo "$PROG: Can't get real path to AppRun!" 1>&2
fi
export APP_DIR

Posted: **Tue 19 Jun 2012, 10:17**

Hi amigo; That`s what I`m doing for AppDir, but AppLib is different.
It contains all the shared libs. for the AppDir apps.
It`s just adding a few more variables to the config. file to have AppDir.
There can be many AppDir dirs. for apps., but only one AppLib so far.

I renamed APP_DIR to AppDir as the ROX-Filer uses $APP_DIR.

Reading the config. file for each app. start isn`t so bad. But not good...

# I`m still trying to find a "one method fits all" for no-install apps.
The chroot idea is interesting, but I`m a little confused on how to do it.

Posted: **Tue 19 Jun 2012, 12:32**

"The beautiful thing about standards is that there so many to choose from."

Posted: **Tue 19 Jun 2012, 14:30**

amigo wrote: APP_DIR is not a 'proprietary' enivronmental variable.

It doesn't work from /etc/init.d. Unsetting it first doesn't work either. There's no problem using it as a local variable.

edit: I got it to work by getting out of my user shell into root. Interestingly, my unset command also only works from root shell. If running from root, the unset command isn't even needed.

Posted: **Tue 19 Jun 2012, 18:56**

jamesbond found it...

ROX-Filer sets: APP_DIR='' when it`s started.

So in the ROX desktop env APP_DIR gets trashed.

Posted: **Tue 19 Jun 2012, 20:01**

sunburnt wrote:
So in the ROX desktop env APP_DIR gets trashed.

May be one example of the dangers of running in /root.

Posted: **Wed 20 Jun 2012, 02:51**

I`m not sure how being root affects this.

Root or not, Rox will set the variable, so it probably doesn`t matter.

But there may be other considerations I haven`t accounted for.

Posted: **Wed 20 Jun 2012, 13:49**

sunburnt wrote:I`m not sure how being root affects this.

Root or not, Rox will set the variable, so it probably doesn`t matter.

But there may be other considerations I haven`t accounted for.

Sure, in the case of /init.d/, if the variable doesn't work I could always choose to use it anyway, or more generally, I can always attempt to force something when an obvious conflict arises.

(old)Puppy Linux Discussion Forum

"env" variable problem? [ Solved ]