...except the problem isn't Puppy or Linuxsunburnt wrote: At least not any more broken than Puppy and Linux are already.
"env" variable problem? [ Solved ]
- technosaurus
- Posts: 4853
- Joined: Mon 19 May 2008, 01:24
- Location: Blue Springs, MO
- Contact:
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.
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].
Yes i noticed this at the prompt .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.
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
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!
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!
APP_DIR is eaten by Rox. From ROX changelog:
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
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.
Fatdog64 forum links: [url=http://murga-linux.com/puppy/viewtopic.php?t=117546]Latest version[/url] | [url=https://cutt.ly/ke8sn5H]Contributed packages[/url] | [url=https://cutt.ly/se8scrb]ISO builder[/url]
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
"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
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:
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
unset APP_DIR
export APP_DIR
program-to run
# or:
APP_DIR=/path/to/somewhere program-to-run
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
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.
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.
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.amigo wrote: APP_DIR is not a 'proprietary' enivronmental 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.
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.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.