LibreOffice : 64-bit and 32-bit 'portables' - AppImage-based...

[mikewalsh]

Afternoon, gang.

This was one of the very first non-browser portables I put together, almost 2 years ago.....and until now, I still haven't got around to publishing it.

Based around the LibreOffice AppImages, it follows the same format as all the others; keeps everything self-contained within a single directory, instead of the AppImages creating multiple config files and just leaving them scattered around all over the place, which they tend to do......even when you've removed the AppImage from your system.

Config items are sym-linked to expected locations at run-time, and removed again at close; because they ARE sym-links, changes are written directly back to the portable directory.

-----------------------------------------------------

This particular build is v7.0.3. If you ever want to update to a newer version, it's very simple. Just visit the AppImage downloads page at the LibreOffice website, and select the AppImage you want:-

https://www.libreoffice.org/download/appimage/

Once you've downloaded the build you want, re-name it to just "LibreOffice64" to match the existing AppImage in the portable; no extension, no ".AppImage", nothing like that. Just "LibreOffice64"; this is one good thing about AppImages.....you can re-name them to anything you like, and they will still run, because the act of clicking on the AppImage's outer 'shell' transfers the executable action to the AppRun script within. The actual name of the outer 'shell' is completely irrelevant, and many who build them give them insanely long, complicated names; totally unnecessary, because it makes it harder to get it right when you're scripting for them.

Short & sweet is the name of the game, gang.

Then; just swap it over with the existing one. That's all there is to it.

-------------------------------------------------

Anybody who might fancy trying these, you can find the downloads here:-

https://mega.nz/folder/mCgARJAB#gghmc7g04hbytdKncci-eQ

As always; d/l; unzip; move the portable anywhere you like, preferably outside the 'save'. Click to enter, click 'LAUNCH' to fire it up.

Scripts allow the addition/removal of a linked menu entry, if one should be required.

Enjoy.

Mike.

[ndujoe2]

programming elegance from the hand of Mike again

[xenial]

Superb free office suite.
Many thanks to you mike.

[mikewalsh]

@ndujoe2 :-

programming elegance from the hand of Mike again

Credit doesn't really lie with me, mate. TBH, it goes to the LibreOffice team.....for building the AppImage properly in the first place. So many packagers don't, y'see; they'll take an existing .deb or .rpm package and turn that into an AppImage.....with the result that the thing is still hunting around the system for its dependencies.

A correctly-assembled AppImage should contain absolutely everything it requires to run, even if that does mean duplication of system files.

My "magic" merely consists of trying to stop these things from scattering their files all over the place & just leaving them there. Which strikes me as incredibly untidy.....and if you run them in more than one Puppy, you simply duplicate the same config files, over & over again. And that's rather pointless, n'est-ce pas?

@xenial :-

You're very welcome, as always. Hope it's useful!

Mike.

[user1111]

Full circle in many respects.

"Let's take common functions used by many programs and port them into a dll or lib so that the same functionality isn't being replicated many times". BUT variations/changes in those common libs could introduce obscure errors/bugs in individual programs/applications (and any bug is a potential security risk).

Back around to let each program/application keep/maintain its own functions, internally. Rather than repeated reinvesting the wheel the common libs functions can be used as a template, or even directly copied, and where (ideally) the perfect match is used, and that wont get updated by some other program having induced changes in the libs - that were good for that program, but might have introduced problems into other programs.

I haven't directly adopted AppImages, but have been doing similar for many years now. Fatdog boot system for admin/data, a container for general desktop use, where what data it can see/store is subject to what the main system level permits. In my case where that contained system uses the same main sfs as the main system - where that's loaded/stored in ram. kvm/qemu to boot OpenBSD, for servers such as ssh/http, in effect another 'core'. So in a way, very much three AppImages

Now if only Linux might consolidate on common standards, for instance rather than some programs using -h for help, --help for others. And the array of manuals. Linux users tend to search the broader web for how to do things and be presented with many variations, where maybe even none are correct. OpenBSD considers errors in its man pages to be bugs, the same as program bugs - wrong/incorrect guidance could introduce problems (potential security risks). Where each version/release has its own man pages refined precisely for that release/version. I love that about OpenBSD. In contrast when looking around for Linux guidance its much more hit and miss, try it this way, no that didn't work, well try it this other way then ... no still didn't work. Ahh this yet other way worked - great, but where someone elsewhere looks and thinks - yep that seems to work but its not the correct way, but can't be bothered to register/create a userid etc. on the site where that thread was posted/discussed just to inform them of such.

Thanks @mikewalsh (in my case for nothing on the AppImage side as I wont be using it ) you'e become a AppImage star and your repeated help/posts are a great value add. One of the attractors to Puppy. Many other OS boards are much more confrontational. People are after all part of an overall Operating System.

[mikewalsh]

Morning, gang.

I've added some extra builds for LibreOffice-portable. In addition to the 7-series, there's now a 64-bit 4-series build (4.2.0.4).....mostly because in all honesty, I prefer the look of the older LibreOffice suites. From LibreOffice 6 onwards, they adopted the modern 'flat-look'.....which I personally detest. AND they began adding all sorts of side-bars'n'stuff. Yeeuch.

There's also now a pair of 32-bit L.Office portables; one is a 4-series (4.3.2), and t'other is an early 6-series (6.0.0.3).

For these, I took the contents of the particular SFS packages & used Fred's marvellous AppImage scripts to produce 32-bit AppImages of these two. I then modified one of the other L.Office portables as a 'template', and soon had them up-and-running sweetly. These definitely run A-OK in Tahrpup 6.0.6, and should run happily in newer 32-bit Pups.

All of the above will handle .docx, for those who need this ability.

--------------------------------------------------------------

You can find these additional builds at the main link in post #1. Usual procedure applies:-

• Download

• Unzip

• Move the extracted portable directory anywhere you like.....preferably, outside the 'save'

• Click to enter

• Click the 'LAUNCH' script directly to run entirely AS a 'portable' app. If so desired, scripts will permit the addition/removal of a Menu entry, if greater system integration is preferred...

Enjoy. Hope some of you find them useful.

Mike.

[mikeslr]

The portable MikeWalsh published included the 64bit AppImage of LibreOffice 7.18. As of this post, LibreOffice has continued to improve and is @ 7.5. If only to save Mike the use of some bandwidth provides Mike's framework without any AppImage.

LibreOffice-portable64-FrameWork.tar.xz

(138.5 KiB) Downloaded 75 times

To use, download the tar.xz and extract it. Place the extracted folder where ever you want: /mnt/home is a good location to conserve the use of RAM; /opt if you want to run your Puppy entirely in RAM.

The above tar.xz has been revised to provide the modification by Burunduk, set forth here, https://www.forum.puppylinux.com/viewto ... 921#p85921 to its previously provided LAUNCH script, Thanks, Burunduk for the script and MochiMoppel for the insight and analysis which lead to it. And, of course, Thanks again MikeWalsh for 'getting the ball rolling' and all your hard work that went into its initial presentation. Cheers to the power of a do-ocracy.

The user also will have to download an AppImage --currently available from here, https://www.libreoffice.org/download/appimage/-- give it the name LibreOffice64, make it executable and place it in your extracted libreoffice folder.

See Mike's OP for instructions on how to use the included LAUNCH, Menu-Add and Menu-Remove scripts.

See this thread, especially Burunduk's post, https://www.forum.puppylinux.com/viewto ... 591#p85591, for a pet to provide menu entries for libreoffice calc, draw, impress and writer. Tip: within the libreoffice-portable folder makes it easy to locate when you want to add them to a Puppy.

Thanks again MikeWalsh, MochiMoppel and Burunduk.

[Burunduk]

@mikewalsh:

I've downloaded the package provided by @mikeslr . Here is the LAUNCH script from it:

Code: Select all

#!/bin/sh
#
# Launcher for 'portable' LibreOffice...
#
HERE="$(dirname "$(readlink -f "$0")")"
#
mkdir "$HERE/config" 2> /dev/null
mkdir "$HERE/config/libreoffice" 2> /dev/null
#
if [ -d "/root/.config/libreoffice" ]
then 
	rm -rf /root/.config/libreoffice
	ln -s $HERE/config/libreoffice /root/.config/libreoffice
else
	ln -s $HERE/config/libreoffice /root/.config/libreoffice
fi
#
"$HERE/LibreOffice64" "$@"
#
rm -rf /root/.config/libreoffice

Sorry, Mike, rm -rf /root/.config/libreoffice?! Really? I don't use your portables but if I would I wouldn't appreciate your script doing rm -rf on my files without even asking for a permission. And your portables are quite popular. It's not impossible that some people will have their libreoffice profiles already in place. A user profile may contain extensions, dictionaries, clip-art, etc. Deleting it carelessly doesn't seem like a good idea. Please consider changing the script. A portable application shouldn't mess with the existing settings.

Only a small modification is needed to avoid possible problems. Simply use rm instead of rm -rf. This will remove a symlink but not a directory and the existing (not portable) profile will be used. The wrapper actually creates only a link, so only a link has to be removed.

A bit more complex variant temporarily renames the configuration directory if it exists and uses a portable profile:

Code: Select all

#!/bin/sh
#
# Launcher for 'portable' LibreOffice...
#
HERE="$(dirname "$(readlink -f "$0")")"
# make both ./config and ./config/libreoffice
mkdir -p "$HERE/config/libreoffice"
# remove if it's a symlink
[ -L ~/.config/libreoffice ] && rm ~/.config/libreoffice
# rename if it's a directory
[ -d ~/.config/libreoffice ] && mv ~/.config/libreoffice ~/.config/libreoffice-renamed-by-portable

ln -s "$HERE/config/libreoffice" ~/.config/libreoffice
#
"$HERE/LibreOffice64" "$@"
# remove the link
rm ~/.config/libreoffice
# restore (rename back) the user profile (if any)
[ -d ~/.config/libreoffice-renamed-by-portable ] && mv ~/.config/libreoffice-renamed-by-portable ~/.config/libreoffice

[mikewalsh]

@Burunduk :-

Mm. You're right, of course. It's something I've been meaning to address for quite a while.....but somehow, it doesn't seem of the greatest importance, and I seem to have less & less time to myself (and Puppy!) these days.....and when I do, there's always a ton of things that are MORE important (and it gets forgotten, and drops to the back of the queue)...

Etc., etc., etc.

I vaguely recall using 'rm -rf' because 'rm' by itself simply wasn't working for me. Thinking about it now, of course I needed to use a '-f' in there somewhere, because a sym-link will not, under normal circumstances, over-write an existing file.....and, as you say, if a 'profile' already exists, we either want to use it, or else 'protect it' in some way. I think I wanted to attempt summat like that when I first built the L.Office portable, but some of the mechanism was a bit beyond me at the time - this was one of the first I assembled, yet it was one of the last to get published!

So far as office suites are concerned, personally I only use them for the odd document here & there; I don't use one at all regularly, so the concept of saving an existing profile just didn't occur to me.

Technically, a nicer course of action would be that, if an existing profile is detected, to ask the user if they want to use that profile. Then, if 'Yes', do they want to copy that into the portable, or simply create a new, fresh one?

The only profiles I've ever attempted to keep are browser profiles, because my collection of bookmarks - and the way my browsers are set up - have been years in the making. The same, of course, may well apply to users of other apps..... Decisions, decisions. Um...

--------------------------------------

I think your suggestion of keeping 'portable' & 'permanent' separate is probably the best course of action. Users are perfectly free to copy/move an existing profile into the portable if they want to.

Fredx181 has mentioned on here before a method for creating - and using - a profile in the same location as an AppImage (which many of these are based around). It does, however, only work FOR AppImages. If I'm packaging something up that will ONLY work in the 'unpacked' format (which is sometimes the case), then usually it will insist on using hard-coded, default locations.

Need to look into Fred's method. For LibreOffice, at any rate, it's probably the better solution. Eeh; well, I always know I can count on YOU to keep me on my toes!!

Mike.

[MochiMoppel]

@mikewalsh @Burunduk Why tinker with the /root/.config/libreoffice directory at all?
I agree with Burunduk that it should never be removed without consent, but needs it to be symlinked either?

I have downloaded LibreOffice-7.2.6.2.basic-x86_64.AppImage from the official download site and saved it to a local directory.
In the directory I created this LAUNCH script

Code: Select all

#!/bin/ash
# Launcher for 'portable' <application>.AppImage
HERE=$(dirname "$(readlink -f "$0")")
XDG_CONFIG_HOME="$HERE"
"$HERE"/*.AppImage "$@"

That's it.
When running the script LibreOffice will create a new libreoffice/7.2.6 configuration directory in the LAUNCH directory, not in /root/.config.
Since execution command will execute whatever .AppImage it finds I can later exchange the app file with a newer one without changing the script.

[mikewalsh]

@MochiMoppel :-

The premise behind the sym-link trickery was prompted by one thing, really.

Any time an AppImage is used in a different Puppy, it then creates, and leaves behind, a new 'profile'. Even if that AppImage is never used again in that particular Puppy, the /root/.config/libreoffice directory remains behind.....'just in case'.

I wanted a method whereby just one single profile was created.....and then 'shared' with any Puppy where the portable was used. That's all it was. There didn't seem much point in duplicating the same thing, over & over again.

When I first started building these things, I had a lot less RAM & storage to play with.....all I was trying to do was to save wasted space. With this new rig, it's no longer really relevant.......32GB RAM & 5+ TB of storage means I don't need to save space any longer, but I was trying to consider other Puppians who didn't have such resources.

Perhaps it's unnecessary 'over-complication'. That view is always going to be down to the individual user. It works for me.....and I've always maintained you should use whatever works for you.

(*shrug*)

Mike.

[MochiMoppel]

I wanted a method whereby just one single profile was created.....and then 'shared' with any Puppy where the portable was used. That's all it was.

I understand this. And this is why for many browsers you use the -profile option to create the profile directly in the LAUNCH directory, right? This makes perfect sense and IIRC in these cases you don't create symlinks to the default profile location because this location is not created in the first place. I also understand that some applications provide no way to change their default config locations, in wich case symlinks become necessary.

So my point is that LibreOffice in not one of the latter and that it lets you save its config files directly in the LAUNCH directory. After all that's where you want them to be, right?

You seem to be annoyed and I don't know why....

[Burunduk]

... use the -profile option to create the profile directly ...

I've searched for a similar option in LibreOffice but haven't found one. Thank you for the tip. XDG_CONFIG_HOME works and the launcher is really simple. I propose to call it LOL - the Libre Office Launcher.

Fredx181 has mentioned on here before a method for creating - and using - a profile in the same location as an AppImage (which many of these are based around). It does, however, only work FOR AppImages. If I'm packaging something up that will ONLY work in the 'unpacked' format (which is sometimes the case), then usually it will insist on using hard-coded, default locations.

It seems that LO is not fussy in this regard. The old 6.4 version I have on my Fossapup (not an appimage) is creating its profile in the location XDG_CONFIG_HOME points to.

[mikewalsh]

@MochiMoppel :-

Annoyed? Nah; not 'annoyed', so much as 'miffed' (with myself, nobody else! ).....because I've tried various options for creating the profile in a location of MY choice (and so far, none of them seem to work for me. Grrr...)

Either I'm trying the wrong methods.....or I'm doing something wrong. I'm betting it's the latter..!

@Burunduk :-

Um.....o-kay. "XDG_CONFIG_HOME", huh? Fair enough. Where - or how - do we set/specify this? XDG has always been something of a mystery to me....

Mike.

[mikewalsh]

@MochiMoppel / @Burunduk :-

Well, now. A leetle bit of head-scratching, and a quick peruse about XDG on the Arch wiki, annnd.....that was easy!

So; the 'LAUNCH' script now looks like this:-

Code: Select all

#!/bin/sh
#
# Launcher for 'portable' LibreOffice...
#
HERE="$(dirname "$(readlink -f "$0")")"
XDG_CONFIG_HOME="$HERE"
#
"$HERE/LibreOffice64" "$@"

.....and it creates - and henceforth uses - the 'libreoffice' profile directory within the portable itself. Super!

-----------------------------------------------

That XDG $PATH variable is a useful hack. It'll probably work for some of the other portables, but not all of them. Not by a long chalk. I'll explain...

Some portable apps create a single config directory. Some create two.....and a select few create three.

• Where one is created, it's invariably $HOME/.config. The above 'hack' will work in this instance.

• Where two are created, we're usually looking at $HOME/.config AND $HOME/.cache. It's not that XDG_CACHE_HOME wouldn't work, but in these cases both .config & .cache directories tend to have the exact same name. So you couldn't specify the portable directory as both XDG_CONFIG_HOME and XDG_CACHE_HOME, since you get a naming conflict. (I thought about creating a sub-directory to get round that, but the XDG specifications are clever enough to know that you don't HAVE sub-directories within $HOME/.config or $HOME/.cache, so.....back it goes straight into the standard default location. AGAIN.)

• On the odd occasions when three are created, it's usually $HOME/.config, $HOME/.cache and also $HOME/.local/share. Again, the naming conflict comes into play and everything gets shunted to the default locations once more...

I can't see any alternative workaround except for the sym-linking gymnastics. "-profile" ONLY works for the 'zilla-based browsers. Nothing else. Unless either of you have any suggestions..?

Mike.

[MochiMoppel]

• Where one is created, it's invariably $HOME/.config. The above 'hack' will work in this instance.

No and no. "Invariably"? Some not so well behaved apps create their config file/directory in $HOME, e.g. mtPaint. And even if they create in $HOME/.config this doesn't mean that they observe XDG_CACHE_HOME.

• Where two are created, we're usually looking at $HOME/.config AND $HOME/.cache. It's not that XDG_CACHE_HOME wouldn't work, but in these cases both .config & .cache directories tend to have the exact same name. So you couldn't specify the portable directory as both XDG_CONFIG_HOME and XDG_CACHE_HOME, since you get a naming conflict. (I thought about creating a sub-directory to get round that, but the XDG specifications are clever enough to know that you don't HAVE sub-directories within $HOME/.config or $HOME/.cache, so.....back it goes straight into the standard default location. AGAIN.)

I don't know why you would want the cache in the $HERE directory but it's no problem either. What the application eventually does is something you have to find out by trial and error but I don't see why creating and using your own subdirectorie shouldn't work.

Example LibreOffice:
XDG_CONFIG_HOME=
XDG_CACHE_HOME="$HERE"
HOME="$HERE"

With XDG_CONFIG_HOME set to an empty string LibreOffice will try HOME and create $HERE/.config
Result: $HERE/.config/libreoffice

With XDG_CACHE_HOME set to "$HERE" LibreOffice will use it like /root/.cache
Result: $HERE/mesa_shader_cache
Even if LibreOffice would have named this cache directory "libreoffice" (as many browsers would do) there still would be no naming conflict
It would also work to create a subdirectory $HERE/.cache beforehand and then set XDG_CACHE_HOME="$HERE"/.cache

Which 'portable' defies all your attempts and can only be "portabilified" with symlinks?

[mikewalsh]

@MochiMoppel :-

Some not so well behaved apps create their config file/directory in $HOME, e.g. mtPaint.

Yes, I agree. Occasionally, some apps WILL put their config files directly into $HOME, though it's not quite so common nowadays. I can't comment as to whether such apps actually observe the XDG default rules, though.

Which 'portable' defies all your attempts and can only be "portabilified" with symlinks?

Heh. With your assistance, I don't think there will be any to speak of. I now understand the use of XDG in encouraging portable apps to create 'internal' directories, much better than I did a few hours ago. I now also know - again, with the help of the Arch wiki - that 'XDG_DATA_HOME' equates, by default, to $HOME/.local/share.....which was the last missing piece of the puzzle for me.

As an experiment, I've tried this stuff with a "2-directory" portable, in this case OnlyOffice. This normally creates

$HOME/.config/onlyoffice, and
$HOME/.local/share/onlyoffice

....when allowed to do its own thing. So; extrapolating from your example as given above, the 'LAUNCH' script for OnlyOffice now looks like this:-

Code: Select all

#!/bin/sh
#
# Launcher for 'portable' OnlyOffice
#
HERE="$(dirname "$(readlink -f "$0")")"
#
XDG_CONFIG_HOME=
XDG_DATA_HOME=
HOME="$HERE"
#
"$HERE/OnlyOffice64" "$@"

Works beautifully. I guessed that by also leaving 'XDG_DATA_HOME' 'unset'' it, too, should do the same thing and create the hidden directories as needed within the portable. And so it proved.

What can I say? Thanks, mate. This is all very much appreciated.....and has furnished me with yet another string to my bow, along with the ability to tidy up the portables still further. The Arch wiki is a brilliant resource, but you still can't beat someone who can explain things in a straight-forward way. Which you're rather good at, if I'm honest.

Cheers!

Mike.

[fredx181]

@mikewalsh Tested your latest 64-bit portable and (at least for me) it does not write configs to $HERE . Fix is to export the XDG_CONFIG_HOME variable:

Code: Select all

#!/bin/sh
#
# Launcher for 'portable' LibreOffice...
#
HERE="$(dirname "$(readlink -f "$0")")"
export XDG_CONFIG_HOME="$HERE"
#
"$HERE/LibreOffice64" "$@"

(or instead, just put it in front of the last line: XDG_CONFIG_HOME="$HERE" "$HERE/LibreOffice64" "$@")
Nice development, btw , much better without the symlinking !

EDIT: This works too for me (create LibreOffice64.home directory and get .config/libreoffice inside)

Code: Select all

#!/bin/sh
#
# Launcher for 'portable' LibreOffice...
#
HERE="$(dirname "$(readlink -f "$0")")"
#XDG_CONFIG_HOME="$HERE"
mkdir -p "$HERE/LibreOffice64.home"

"$HERE/LibreOffice64" "$@"

[mikewalsh]

@fredx181 :-

Morning, Fred.

I don't know why, but I've never been able to get the "$AppImageName.home" thing working on here.....and that IS the officially-recommended way of doing it, as used by the AppImage package guys....or so I believe?

Sorry you had issues with the available download earlier, but that wasn't the most recent modification; I hadn't yet uploaded THAT one. I was performing my usual trick last night, and working right at the edge of sleep.....heh. Hell, I'm doing too much of that these days. I find, as I age - disgracefully! - that sleep patterns go all over the place. Don't like getting old!

If ya can spare the bandwidth, try the most recent one & see what that does for you. I've now uploaded it.

-------------------------------------------

Nice development, btw , much better without the symlinking !

Um; well.....thanks! But credit really goes to Mochi, once again; it was he that opened my eyes last night. I'd been aware of the XDG stuff for years, of course - probably like many of us - but I didn't understand what it was about. Had no real desire to investigate, either. But it does, by default now, what I wanted all along.....without the sym-linking 'gymnastics' (as Mochi calls it).

It's "tidier".

Credit also goes to Burunduk, too, for kicking my lazy ass into gear and getting me to investigate a more efficient way of doing this. As he says (and he's right), portables shouldn't 'touch' installed stuff at all. After all, that's the idea of them, isn't it? And If the user wants to swap existing config directories into the portable, it's now much easier to do so, 'cos you just look for the matching directories.....

(And credit to you, of course, for starting me off down this path.....although the desire to do so dates back to XP days...)

Small, gradual improvements, little by little. Everything's shaping up very nicely, though it'll take me a long while to modify & re-upload every portable I've built. Some may never get done..... Some don't need it - mostly the browsers. They work fine as they are.

Ah, we'll see.

Mike.

[fredx181]

Hi Mike, FYI, just now I get "empty folder" at LibreOffice > 64-bit > 7-series on your Mega.
EDIT:

I don't know why, but I've never been able to get the "$AppImageName.home" thing working on here.....and that IS the officially-recommended way of doing it, as used by the AppImage package guys....or so I believe?

Strange... yes officially-recommended way, so if you create "LibreOffice64.home" directory it doesn't work ?
BTW, creating "LibreOffice64.config" works too for me, then I get:
LibreOffice64.config/libreoffice/7.0.3/

[mikewalsh]

@fredx181 :-

Whoops, my bad. I had the post pre-written before the upload went through.....and hit the "Submit" button BEFORE I intended to!

Try it now.

Mike.

[fredx181]

@fredx181 :-

Whoops, my bad. I had the post pre-written before the upload went through.....and hit the "Submit" button BEFORE I intended to!

Try it now.

Mike.

Yes, works OK now

[Burunduk]

@mikewalsh Tested your latest 64-bit portable and (at least for me) it does not write configs to $HERE . Fix is to export the XDG_CONFIG_HOME variable:

Code: Select all

#!/bin/sh
#
# Launcher for 'portable' LibreOffice...
#
HERE="$(dirname "$(readlink -f "$0")")"
export XDG_CONFIG_HOME="$HERE"
#
"$HERE/LibreOffice64" "$@"

(or instead, just put it in front of the last line: XDG_CONFIG_HOME="$HERE" "$HERE/LibreOffice64" "$@")

The new launcher works on my Fossapup without export but why? This question made me read a dozen of bash tutorials yesterday (thanks to MochiMoppel). And all of them state that export is needed. If someone is interested: if a variable is already set in the environment, export can be omitted. I thought XDG_CONFIG_HOME is set in every Puppy (in /etc/profile) but it seems it's not.

[fredx181]

The new launcher works on my Fossapup without export but why? This question made me read a dozen of bash tutorials yesterday (thanks to MochiMoppel). And all of them states that export is needed. If someone is interested: if a variable is already set in the environment, export can be omitted. I thought XDG_CONFIG_HOME is set in every Puppy (in /etc/profile) but it's seems it's not.

Ah. Thanks for the info, I should have mentioned that I tested on Debian (not on a Puppy), but didn't expect there's a difference (I see now that on Debian it's not set in the environment).
EDIT: The HOME variable (as used now in Mike's new portable) works for me without export, btw.

[Burunduk]

EDIT:

I don't know why, but I've never been able to get the "$AppImageName.home" thing working on here.....and that IS the officially-recommended way of doing it, as used by the AppImage package guys....or so I believe?

Strange... yes officially-recommended way, so if you create "LibreOffice64.home" directory it doesn't work ?
BTW, creating "LibreOffice64.config" works too for me, then I get:
LibreOffice64.config/libreoffice/7.0.3/

I usually convert appimages to sfs files and don't really know how they work. So basically a launcher is not needed at all, right? To save some bandwidth, I've downloaded the recent appimage runtime and made an appimage out of this single AppRun file:

Code: Select all

#!/bin/bash
touch "$HOME"/appimage-home-flag
touch "$XDG_CONFIG_HOME"/appimage-config-flag

It works on Fossapup. If test.appimage.home and test.appimage.config directories exist, the test flags are created in them. And the runtime itself can create the directories.

Code: Select all

root# ls -R
.:
test.appimage
root# ./test.appimage --appimage-portable-home
Portable home directory created at /root/appimage-testdir/test.appimage.home
root# ./test.appimage --appimage-portable-config
Portable config directory created at /root/appimage-testdir/test.appimage.config
root# ./test.appimage
Setting $HOME to /root/appimage-testdir/test.appimage.home
Setting $XDG_CONFIG_HOME to /root/appimage-testdir/test.appimage.config
root# ls -R
.:
test.appimage  test.appimage.config  test.appimage.home

./test.appimage.config:
appimage-test-flag

./test.appimage.home:
appimage-test-flag

When the appimage runs, it sets HOME and XDG_CONFIG_HOME variables automatically. And this is the only thing the current launcher does.

[fredx181]

When the appimage runs, it sets HOME and XDG_CONFIG_HOME variables automatically. And this is the only thing the current launcher does.

Yes, but then the user needs to run the appimage from terminal and add as argument e.g. --appimage-portable-home

Mike's setup automates that by just clicking the LAUNCH script (or run from Menu if done the Menu-add thing), more convenient IMO.

[mikewalsh]

When the appimage runs, it sets HOME and XDG_CONFIG_HOME variables automatically. And this is the only thing the current launcher does.

Yes, but then the user needs to run the appimage from terminal and add as argument e.g. --appimage-portable-home

Mike's setup automates that by just clicking the LAUNCH script (or run from Menu if done the Menu-add thing), more convenient IMO.

@Burunduk / @fredx181 :- If I'm right - and I'm no coding guru, as y'all are aware! - I believe the readlink 'trick' is what helps to accomplish that, by setting the current location AS a variable.....which Mochi's addition of the last line:-

Code: Select all

HOME="$HERE"

.....then confirms as the XDG 'base' directory for what we're trying to do here. Effectively, you set the $HOME directory AND create/populate the various config directories in their 'expected' locations at the same time.

I think that's right. This is now getting to be a bit over my head....!

Mike.

[MochiMoppel]

I usually convert appimages to sfs files

Why?

When the appimage runs, it sets HOME and XDG_CONFIG_HOME variables automatically. And this is the only thing the current launcher does.

Well, Mike's menu creating script aside, all that would be needed in the 'portable' directory would be the main appimage and a directory named appimage.config. To add some fun both could be even renamed to LAUNCH and LAUNCH.config. Works

The advantage of using appimage.config would be that appimage could be launched from a symlink (no readlink needed) and that no exporting of XDG_CONFIG_HOME needs to be considered. But that's about all.

Disadvantage:
1) works only for fairly new Type 2 appimages (and of course not at all for any other app types)
2) name and path of .config directory can't be changed
3) other directories like .cache can't be portabilified

I find that setting (and exporting) HOME and XDG variables before running an app provides greatest flexibility.

[mikeslr]

The attachment to this post, https://www.forum.puppylinux.com/viewto ... 684#p85684 has been updated.

[Burunduk]

Yes, but then the user needs to run the appimage from terminal and add as argument e.g. --appimage-portable-home

Mike's setup automates that by just clicking the LAUNCH script (or run from Menu if done the Menu-add thing), more convenient IMO.

There is no need to run it from terminal. As an example, here is a modified version of the @mikeslr's package. It has no launcher but works on my Fossapup. It includes a dummy appimage that can only show the content of some variables. To test it with LibreOffice put the real appimage (it's not necessary to make it executable nor rename) into the directory and run the SETUP script.

LO-portable-directory.tar.xz

For testing.

(117.34 KiB) Downloaded 59 times

---

I believe the readlink 'trick' is what helps to accomplish that, by setting the current location AS a variable.....which Mochi's addition of the last line:-

The appimage runtime knows that trick and is smart enough to set HOME to "HERE"/<exact_appimage_name>.home if this directory exists. So the HOME variable can be set by a launcher or the directory can trigger the internal appimage function. It works either way.

---

Why?

Probably because they are sfs files in essence. Only self-extracting, self-mounting more precisely. The fact that self-extracting archives do exist doesn't mean that we should stop using the simple ones. It's like attaching a viewer to every picture. And more importantly this is the only occasion so far to put dc in action. I've found a formula somewhere on the stackoverflow to calculate the size of an ELF executable. It used awk or bash for math but with dc it looks much better:
offset=$(readelf -h an.AppImage | sed -n '/section headers/s/[^0-9]//gp' | dc -e '???*+p')
(I saw a different approach in Puppy: split on a second occurrence of the magic "hsqs" string.)