@dimkr :-
Hallo, Dima. Let's see if we can run through these in order, shall we?
Vanilla DPup 9.2.21 (32-bit). I grabbed this from GitHub just last night.
I'm talking about my self-contained, portable applications, which can be run from anywhere.....though usually outside the 'save'.
How did you install them?
They don't "install" as such. They come packed as a tarball; you unpack it, move it anywhere you want, then enter the directory and click on the 'LAUNCH' script. Doing this keeps all config files within the portable directory. An option is provided to add a Menu entry from wherever it's located, if required.
Do these applications work as root in other Puppy releases or must run as spot?
The majority run as root. Some are set to run-as-spot where the application refuses to run any other way.
When you say that some portable applications misbehave - which ones and how do you run them?
It's only the internet-facing ones that misbehave.....at least, the two I've tried so far; Thunderbird & Slimjet.
I share these portables between multiple Puppies, as far as possible. When I try any portable in a new Puppy for the first time, I always do so from the terminal, to get an idea of what happens.....if it'll 'play nice' or not, and if it needs any more 'tweaking'.
What do you mean by "LAUNCH scripts"?
This is invariably the script which will launch the application.
With browsers, the LAUNCH script will set the "read-link" variable, create the profile directory, then the profile & everything else is created internally to the portable directory. With many of the others, I determine where in the file system the app in question would normally expect to either find - or if not already existing, where it would then look to create those files.
In the latter case, the LAUNCH script will set the "read-link" variable, then create config directories/files within a sub-directory. These are then sym-linked to where the app would expect to find them prior to launching the app. At close, the sym-links are removed.....and because they're sym-links, anything the app writes to what it THINKS is its standard config file location actually gets written back to the portable directory again.
Sometimes, a number of specific dependencies will be packaged with the app, and the LAUNCH script will reference these via LD_LIBRARY_PATH immediately prior to the exec line.
In the case of Thunderbird-portable32, this:-
Code: Select all
#!/bin/sh
#
# Launcher for 'portable' Thunderbird....
#
HERE="$(dirname "$(readlink -f "$0")")"
#
mkdir "$HERE/profile" 2> /dev/null
#
LD_LIBRARY_PATH=$HERE/:$HERE/extralibs${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH} "$HERE/thunderbird32/thunderbird" "$@" -profile "$HERE/profile"
.....is rewritten into this after the first run:-
Code: Select all
#!/bin/ash
# generic wrapper to run as ${XUSER} (when currently running as root)
# (C) James Budiono 2012, 2017
# License: GPL version 3 or later
#
#set -x
XUSER=spot
case $0 in *run-as|*run-as-user)
if ! [ "$1" ] ; then
echo "$0: Specify user"
exit 1
fi
XUSER=$1
shift
esac
CWD=$PWD
CMD=/mnt/sda3/SYSTEM/BROWSERS/32-bit/Thunderbird-portable32/LAUNCH.bin
while [ "$1" ]; do
CMD="$CMD \"$1\""
shift
done
[ "$CMD" ] || exit
USER_HOME=$(awk -F: '$1=="'"${XUSER}"'" {print $6}' /etc/passwd)
if ! [ "${USER_HOME}" ] ; then
echo "$0 ERROR: could not HOME dir for user $XUSER"
exit 1
fi
CURDIR=$PWD
if [ $(id -u) -eq 0 ]; then
[ $XAUTHORITY ] && cp $XAUTHORITY ${USER_HOME}/.Xauthority 2>/dev/null
touch ${USER_HOME}/.Xauthority
export XAUTHORITY=${USER_HOME}/.Xauthority
# replace all occurences of /root in XDG_* with /home/spot, because we don't
# run a login shell and source /etc/profile.d/*
OLD_HOME="$HOME"
while IFS='=' read NAME VAL; do
case "$NAME" in
XDG_*) export $NAME="`echo "$VAL" | sed -e s~^$OLD_HOME~$USER_HOME~ -e s~:$OLD_HOME~:$USER_HOME~g`" ;;
esac
done << EOF # hack for old busybox, which doesn't understand <() and <<<
`env`
EOF
export XDG_CONFIG_HOME=${USER_HOME}/.config
export XDG_CACHE_HOME=${USER_HOME}/.cache
export XDG_DATA_HOME=${USER_HOME}/.local/share
for i in ${XDG_CONFIG_HOME} ${XDG_CACHE_HOME} ${XDG_DATA_HOME}
do
if ! [ -d $i ] ; then
mkdir -p $i
chown ${XUSER} $i
fi
done
if [ "${XDG_RUNTIME_DIR}" ] ; then
export XDG_RUNTIME_DIR=/tmp/runtime-${XUSER}
if [ ! -d ${XDG_RUNTIME_DIR} ] ; then
mkdir -p ${XDG_RUNTIME_DIR}
chmod 0700 ${XDG_RUNTIME_DIR}
chown ${XUSER} ${XDG_RUNTIME_DIR}
fi
fi
if [ -s /tmp/.spot-session-bus ]; then
. /tmp/.spot-session-bus
export DBUS_SESSION_BUS_ADDRESS
export DBUS_SESSION_BUS_PID
fi
# close all file descriptors except std{in,out,err}, in case one of
# them points to a file under /root
for FD in /proc/self/fd/*; do
FD="${FD##*/}"
[ $FD -gt 2 ] && eval "exec ${FD}<&-"
done
exec su ${XUSER} -s /bin/ash -c '
# try to switch to original directory, unless it is /root
if [ "'"$CURDIR"'" = /root ]; then
cd "'"$USER_HOME"'"
else
cd "'"$CURDIR"'"
fi
exec '"$CMD"'
'
else
exec ash -c "exec $CMD"
fi
### END ###
Now it will refuse to run any more, insisting it's already running and must first be closed. But where is it? It can't be found, neither by searching manually through the workspaces OR via the LX task manager; according to the latter, the process doesn't exist!
So how can you close something which never started? Even a re-boot yields no joy; every subsequent attempt to start the app in question insists it's already running.......rinse & repeat.
It's the same with Slimjet-portable32. The original LAUNCH script:-
Code: Select all
#!/bin/sh
#
# Launcher for 'portable' Slimjet browser
#
HERE="$(dirname "$(readlink -f "$0")")"
#
mkdir "$HERE/PROFILE" 2> /dev/null
#
if [ -d "$HERE/slimjet/PROFILE" ]
then
rm -rf $HERE/slimjet/PROFILE
ln -s $HERE/PROFILE $HERE/slimjet/PROFILE
else
ln -s $HERE/PROFILE $HERE/slimjet/PROFILE
fi
#
"$HERE/slimjet/flashpeak-slimjet" "$@"
#
rm -rf $HERE/slimjet/PROFILE
.....becomes:-
Code: Select all
#!/bin/ash
# generic wrapper to run as ${XUSER} (when currently running as root)
# (C) James Budiono 2012, 2017
# License: GPL version 3 or later
#
#set -x
XUSER=spot
case $0 in *run-as|*run-as-user)
if ! [ "$1" ] ; then
echo "$0: Specify user"
exit 1
fi
XUSER=$1
shift
esac
CWD=$PWD
CMD=/mnt/sda3/SYSTEM/BROWSERS/32-bit/Slimjet-portable32/LAUNCH.bin
while [ "$1" ]; do
CMD="$CMD \"$1\""
shift
done
[ "$CMD" ] || exit
USER_HOME=$(awk -F: '$1=="'"${XUSER}"'" {print $6}' /etc/passwd)
if ! [ "${USER_HOME}" ] ; then
echo "$0 ERROR: could not HOME dir for user $XUSER"
exit 1
fi
CURDIR=$PWD
if [ $(id -u) -eq 0 ]; then
[ $XAUTHORITY ] && cp $XAUTHORITY ${USER_HOME}/.Xauthority 2>/dev/null
touch ${USER_HOME}/.Xauthority
export XAUTHORITY=${USER_HOME}/.Xauthority
# replace all occurences of /root in XDG_* with /home/spot, because we don't
# run a login shell and source /etc/profile.d/*
OLD_HOME="$HOME"
while IFS='=' read NAME VAL; do
case "$NAME" in
XDG_*) export $NAME="`echo "$VAL" | sed -e s~^$OLD_HOME~$USER_HOME~ -e s~:$OLD_HOME~:$USER_HOME~g`" ;;
esac
done << EOF # hack for old busybox, which doesn't understand <() and <<<
`env`
EOF
export XDG_CONFIG_HOME=${USER_HOME}/.config
export XDG_CACHE_HOME=${USER_HOME}/.cache
export XDG_DATA_HOME=${USER_HOME}/.local/share
for i in ${XDG_CONFIG_HOME} ${XDG_CACHE_HOME} ${XDG_DATA_HOME}
do
if ! [ -d $i ] ; then
mkdir -p $i
chown ${XUSER} $i
fi
done
if [ "${XDG_RUNTIME_DIR}" ] ; then
export XDG_RUNTIME_DIR=/tmp/runtime-${XUSER}
if [ ! -d ${XDG_RUNTIME_DIR} ] ; then
mkdir -p ${XDG_RUNTIME_DIR}
chmod 0700 ${XDG_RUNTIME_DIR}
chown ${XUSER} ${XDG_RUNTIME_DIR}
fi
fi
if [ -s /tmp/.spot-session-bus ]; then
. /tmp/.spot-session-bus
export DBUS_SESSION_BUS_ADDRESS
export DBUS_SESSION_BUS_PID
fi
# close all file descriptors except std{in,out,err}, in case one of
# them points to a file under /root
for FD in /proc/self/fd/*; do
FD="${FD##*/}"
[ $FD -gt 2 ] && eval "exec ${FD}<&-"
done
exec su ${XUSER} -s /bin/ash -c '
# try to switch to original directory, unless it is /root
if [ "'"$CURDIR"'" = /root ]; then
cd "'"$USER_HOME"'"
else
cd "'"$CURDIR"'"
fi
exec '"$CMD"'
'
else
exec ash -c "exec $CMD"
fi
### END ###
.......and henceforh refuses to run again.
While it's appreciated that you're attempting to make Puppy as friendly and easy-to-use as possible, especially for Windows refugees, I DO feel it's a bit cheeky to automatically assume that you "know what's best" for the user. Windows users neither know nor expect any different; they're used to having important decisions/choices made for them by Microsoft. My point is that experienced Linux users may well get snotty over not even being given the chance to decide differently, y'know? 
I realise that the /home/user model is standard throughout the ecosphere, and that Puppy has up till now been very definitely out on a limb with regards to the way it runs.......and needs to change somewhat in this respect (or at least provide a usable alternative that allows proper operation as merely "a user", which is expected by a lot of software). I also appreciate that the original reason for Puppy's existence has changed somewhat over the years.....and that very few people still run the kind of resource-starved hardware that existed when Puppy first came onto the scene. Most of it's already died!
For myself, I do a ton of things that horrify 'traditional' users. Running as root is just one of them. I also share these portable applications between as many Puppies as I can. I couldn't care less whether or not everything is "just so" or not, much less whether things like themes/icons have a uniform look. Life is for living, not for "nitpicking"! And in several years of accessing the internet as the root user, I have never, EVER had any issues.
------------------------------------------------
Please don't feel that my post is just a litany of complaints. It's not. I AM 'being nice'.....but at the same time trying to raise what I see as valid points..? 
In our community, you're one of the very few individuals for whom I have always had a real & genuine respect. If it weren't for you - and but a handful of others - the rest of us wouldn't even have the opportunity to play around with Puppy the way we do, much less enjoy it as much. Most of the time, you toil in relative obscurity, yet your work makes so much difference to the rest of us. In my book, that makes you a community hero. 
You're definitely one of the "good guys", mate. I just regret not being able to contribute back more than I do, but when it comes to the nitty-gritty of what makes things work, I just don't have the interest......nor - increasingly these days - the time.
We all have our strengths.....and weaknesses. It's perhaps a good thing that we're not all interested in exactly the same stuff, or the community wouldn't have lasted for as long as it has.
Mike. 
