Linux install script is doing some strange things

[Tcaws]

So, this relates to the script installofficenx, which is extracted from the tarball softmaker-office-nx-1417-amd64.tgz, which is downloaded from https://www.softmaker.net/down/softmake ... -amd64.tgz

Running the script, as usual, it notices I am not running it as sudo, and asks if I want to install it only for this user, and I confirm yes.

And as usual, it asks where to install it, and suggests ~/officenx, and I say, no, please install in ~/.opt/officenx instead.

Then...

It tries to install hundreds of icons into /usr/share/icons/ and gets refused permission each time; this is even though it already knows it is not being run as sudo, and this hasn't happened when I've installed it previously.

And it installs it into BOTH ~/officenx AND ~/.opt/officenx (i.e. both where it suggested and also where I requested.

At the end, it does work, but it has taken up over 600MB more room.

Can I safely delete the install that I didn't want, or are they in some way both necessary? It feels like these are scripting errors?

[Tcaws]

Two postscipts:

(1) It also places the launch scripts in duplicate, both where it suggested and where I requested;

(2) It does seem to be safe to delete the duplicate installation, I've now tried! (Was aware I could always run the script to reinstall if necessary!)

[bernado82]

As you might expect, the two installation scripts for versions NX-1234 and the NX-1417 beta are different. Could this be due to the following new feature in SoftMaker Office 2026?

‘Linux: The installation no longer associates SoftMaker Office with all supported document types without asking. Instead, this is now only done optionally when the programmes are launched.’

Which Linux distribution do you use? My system runs on Tumbleweed, so I install RPM packages from the official SoftMaker repository. I also believe that an application such as SoftMaker Office 2026/NX needs to be installed in root mode, with each user then having access to their own settings in their user folder. Perhaps this is the source of your problem: not wanting to install the program as root or by using sudo?

[Tcaws]

(1) Before 1417 I was on 1415, then 1414, 1413 etc, so I am describing a regression between Beta versions, not a regression since 1234, which was last stable version.

(2) ‘Linux: The installation no longer associates SoftMaker Office with all supported document types without asking. Instead, this is now only done optionally when the programmes are launched.’ - this was already the case in previous Beta versions, wasn't introduced with 1417 and this error.

(3) As described in OP, the script itself recognises that not being installed as root. It is allowed. Indeed, it works and is working right now as OP said. Screenshot of script, highlighting install locally as suggested way forward:

[bernado82]

It seems that few other users have also encountered a permission denied error with the latest (1417) beta version.

https://forum.softmaker.com/viewtopic.php?t=30417

I've started testing the SoftMaker Office NX 2026 beta with build 1415. It also makes sense to install a beta version ONLY for the current user and NOT for all the system. You're right, the installation script of the beta version differs between builds 1417 and 1415, it should be almost identical.

[SuperTech]

Thank you for your post and discussion. I have forwarded the details.

Meanwhile, please install using Sudo.

[JayHades]

Hello,

It's my first installation of the beta version, build 1417, and I've been trying to debug this script for the past two hours after it tried to touch/copy system-wide files despite having being launched as a normal user and installation paths being in $HOME.

Not much comments so start by figuring out what SCRIPT=0 or 1 means...

Code: Select all

copy_icons()
#	for UPDDIR in /usr/share/icons/$THEME/mimes/ /usr/share/icons/$THEME/mimetypes/ ; do
UPDDIR="/usr/share/icons/$THEME/"

if [ -d $UPDDIR ] ; then
# now there should not be any .old files. Let's check and remove them if they exist
	OLD1=$(get_tmpname 1 txt)
	OLD2=$(get_tmpname 2 txt)

	find $UPDDIR* -name *.old > $OLD1
	cat $OLD1 | sed 's/.old//g' > $OLD2
	OLDFILES=`cat $OLD2 | sort | uniq`
	for i in $OLDFILES ; do
		for j in `grep "$i" $OLD1 | sort` ; do
#			echo "moving $j -> $i"
			mv $j $i
		done
	done
	rm $OLD1
	rm $OLD2

Given that UPDDIR is a system-wide folder, should not the 'mv $j $i' command fail if SCRIPT=1 / LOCALINSTALL=1 ?

Code: Select all

	copy_icons()
		APPICONSIZES="16 24 32 48 64 128 256 512 1024"
		DOCICONSIZES="16 24 32 48 64 128 256"
	...
		for THEME in $ALLTHEMES ; do
			if [ -d "$ICONSDIR/$THEME" ] ; then
			...
				if [ -d $UPDDIR ] ; then                                                         ### Question 1
				...
					for ICON in $DOCICONSIZES ; do
						if [ "$LOCALINSTALL" != "1" ] ; then
						..
						else
							cd
							if [ -d .local/share/icons/$THEME ] ; then
								cd .local/share/icons/$THEME
								LDIR=`pwd`
								if [ ! -d $UPDDIR/$ICON ] ; then               ### Question 2
									if [ ! -f index.theme ] ; then 
										if [ -f /usr/share/icons/$THEME/index.theme ] ; then 
											cp /usr/share/icons/$THEME/index.theme .
											echo "index.theme copied"
										fi
									fi

Question 1
$UPDDIR/$ICON = "/usr/share/icons/hicolor/24" -- as an example of a theme folder.
This folder does not exist here, does it elsewhere, or should it be "$ICON"x"$ICON", which exist ?

Question 2
What should be $UPDDIR at this point, for a user/localinstall?

/usr/share/icons/$THEME
or
$HOME/.local/share/icons/$THEME

There is merit to read the system folder and create the user theme tree, but recreate the theme index for the user if the system-wide $ICON folder does not exist?

Code: Select all

copy_icons()
	...
	insert_icon_in_theme apps $THEME /usr/share/icons/$THEME/ $SIZE $APP application-x-"$APP""nx" 0 nx

insert_icon_in_theme()
	local DESTDIR=$3
	...
	mkdir -p "$DESTDIR"$SIZE"x"$SIZE"@2"/$CONTEXT
	...
	ln -s $SRCPATH/icons/$FILE"_"$DBLSIZE$FILE_ADDITIONAL.png "$DESTDIR"$SIZE"x"$SIZE"@2"/$CONTEXT/$ICON.png
	...
	insert_icon_in_theme mimetypes $THEME "$UPDDIR" $ICON tmd $VAR 0
[ Manual break from the execution]

The hardcoded system-wide DESTDIR, both from "/usr/share/icons", resulted in an avalanche of...

mkdir: cannot create directory ‘/usr/share/icons/breeze/16x16@2’: Permission denied
ln: failed to create symbolic link '/usr/share/icons/breeze/16x16@2/mimetypes/application-x-tmd.png': No such file or directory

In create_mime() I added an icons folder specific variable, as:
ICONSDIR="$DATADIR/icons"
THEMEDIR="$ICONSDIR/hicolor"
which I think would work for both system and user context, especially in the last quote, as "$ICONSDIR/$THEME" for both calls.

I'm still trying to make it work, although I'm puzzled over those questions.