Shell Programming and Scripting

One comment about set -x
If set in function, its scope does not end at the end of the function.
If there is a set +x at the end of a function, a return will bypass it.
The same applies for a loop. A break or continue bypasses a set +x at the end of the loop.

Thank you Drl!

MIG, Yes...
I didnt post this output before - because I was too upset to, therefor you could not have known, sorry for that.

Code:

[~/prjs/SWARM] 0 $ time ./runtime 
.........SWARM 0.4-18
 
  | 2020-04-17 / 18:37:38\033[0m


\033[7mWelcome to a short introduction\033[0m


SWARM is not supposed to be called directly like this.



Instead it is to be sourced by your script to get access to it's functions.




\033[7m\033[0m


When calling SWARM like you just did, you should provide arguments.



They are:



./runtime config

To configure SWARM, either as user or as root

./runtime help

Lets you browse through all provided functions.

./runtime tarball

Dev-Tool to repack SWARM to /home/sea/swarm-18.tar.gz





/home/sea/prjs/SWARM/data/libs/util.enduser: Zeile 417: [: : Ganzzahliger Ausdruck erwartet.




/home/sea/prjs/SWARM/data/libs/util.enduser: Zeile 417: [: : Ganzzahliger Ausdruck erwartet.
0) Back



/home/sea/prjs/SWARM/data/libs/util.enduser: Zeile 417: [: : Ganzzahliger Ausdruck erwartet.
1) one



/home/sea/prjs/SWARM/data/libs/util.enduser: Zeile 417: [: : Ganzzahliger Ausdruck erwartet.
2) two



/home/sea/prjs/SWARM/data/libs/util.enduser: Zeile 417: [: : Ganzzahliger Ausdruck erwartet.
3) three



/home/sea/prjs/SWARM/data/libs/util.enduser: Zeile 417: [: : Ganzzahliger Ausdruck erwartet.
4) four



/home/sea/prjs/SWARM/data/libs/util.enduser: Zeile 417: [: : Ganzzahliger Ausdruck erwartet.
5) five



6) six



 > '^\[\['++ [[ -z ' ]]

And that line 417 (if [ "$sum" -lt "$COLUMNS" ]) is of the printlist function.
Neither pick nor printlist are required to use printe, title and/or header -> yet that's been the only thing (pick) I was working on that day....
To where your set -x reference goes to.

But even with that error... the output is correct (at least the number-value thing).
Just 1 or 2 posts before the visual interface was working - but pick wasnt..
Now, none of the visual-output works.

It's exactly these kind of ('repeating') errors that are annoying and specialy frustrating when you had thought (and believed) you made it more robust....
Just to figure that it only worked within a bubble...

It was similar with TUI...
But there, it was the installation process.... which worked fine on all my machines when I had git-push'd it.
Just to then be non-working when I did try to install it a week later...
Over and over and over again....

My only mental-sanctuary on this topic is, that this time it is runtime only, so I wont need to use an 'installing' method per basic requirement.
Meanwhile, to my understanding/'feeling', this also makes it more 'vulnerable'...

I guess I wanted too much, too fast.
Yet, as soon the 'theme' is working again, I know everything will look nice again.

Thought, big part of my frustration comes from the memory of those 5 years working on this as TUI.
What I've achieved within the past ~2 months is not that bad.
Sure, there are still missing some parts, but as a whole, the CORE is (at least I thought so) working, and I do have alot of the nice-to-have functions ready.
And with 1 or 2 exceptions, those that are missing are done quite easily

Lets be 'honest', asRoot and pick are alot easier than a multiple-background-job-manager and a file-and-dir-browsing function that may use 'select' or 'read' and execute passed arguments to match dirs and files and arguments left to pass to the passed file, while reading and showing 'reserved keyword files' (the actual key-feature of SWARM -> the function swarm, which I havent even started yet to rework, because it relies on all other functions to be working stable.

Though, I might 'reserve' the background-job-manager for script-tools....

Also, I dont even know if other people are actualy interested in.
With TUI, I had ALOT of initial excitement at hand to compensate 'against' that uncertainty and keep motivation up.

Now I had started again, mostly because I still want 'it' working.
*nix to me, is scripting.
And scripting is what I love since my first i386 after I got aware of batchfiles and qbasic on MSDOS 5.
However, knowing that other people actualy would be interested to use it -> you know, making it more than just an ego-self-use-project <- would help to keep motivation up.

Or even better, would want to help me with the ACTUAL project I want to do -> Script-Tools.
SWARM is "just" a a 'side-product' of that project - so it (script-tools) can be realized as I imaged it.

Geez... it all started so simple and easy.
But the longer I 'worked' with *nix, the more complex my own 'demands and requirements' became.

On the other hand....
If I would be told by some people that this actualy IS a challenging task,
even for people with several years of coding and scripting experience, I would feel ALOT better about too.

I mean, I like to tell myself that it is.
As I'm not aware of other theme-able, multi-language supporting scripted project that support TTY and GUI support and have a 3-way interface between enduser, OS/machine and script-author -> then again, when properly done, 'one' (me) would not reckognize the difference (to compiled binary).
But as long nobody else says so, it feels like a self-induced-made-up-image.

Ok with just a text-code block it's not as 'impressive'...

So, here's an image:


Here's codeline 248-310 to illustrate that both 'output's are at the 'same location'.
Which is the absolute end of file of ./runtime
Go figure, to me its 100% unclear.

EDIT:
As you (dont) see, all functions were loaded before the code segment above.
This is the source of my confusion, because both if-blocks come after all functions and variable definitions, regardless, when executed directly, the 'theme' seems not to work....
Unless it was also previously sourced, but it cant source itself, because this ends in an endless loop.
--> And that is exactly what I had thought to have just solved. <--

On the good side, I can keep trying to get pick working as intended, allthough I'll need to source the runtime first, once.
Writing this, brought up the idea of yet another 'improper' variable handling..
Maybe I'll need to check a variable check.
Question is, which one?
Theme's... again... seems kinda like it...
Maybe that parts needs a different handling wether it is sourced or executed?

It also indicates, in hindsight, that some 'left overs' have survived the 'cleanup' trap.

Good news!
Figured, all I missed was the swarm.update.geometry after the swarm.theme.init.

However, what I still dont understand is WHY.
Because swarm.update.geometry is called from within printe, which is used for most visual outputs.
Thus, to my understanding, it should not matter whether I call swarm.update.geometry there as well or not... Right?

And pick is working now too

I just need to start getting the help menu sorted....
Its a big mess as of now.. dont you think?
Specialy as the main functions (header, title printe, etc...) are not listed yet....


Next step is the input function and getting the help menu sorted.
After that, I hope it'll be ready for some test runs.

Oh well, was slightly too eager to say pick was done yesterday....
It's been a 'long story' frustrating issue as you could read here, and at "False positive grep?"

However, today we *cough* figured the cause of those issues and could fix it.
But, there was something more, because I had missed to redirect swarm.print.border >&2 and because of that, the returned value (as variable) contained empty spaces.

Some small preps for the help menu was all that i could achieve.


As it is WIP the 'look' (structure, approach) might change.
For today, lets see if I can get this to be more appealing to users.

I'm getting somewhere with the help menu - handling.

Meanwhile, figured, I need to add better support for 'variable string lengths'
Wide, is no issue...


But small, looks slightly weird with all these over- and underlappings


But that is for later, now I want to stay focused on the core help functionality and get all the 'usage-strings' for all the functions done.

EDIT:
Just seen now, there is one header too many, but that one has the better text.

Since preparing 'translatable' strings for functions is boring, I thought I'd implement some more functions from TUI.

What does one need, when one wants cross-platform-compatible scripts?
A way to reckognize and differ them of course!

Code:

	swarm.os.desktop() { #
	# Returns the name of the DE/WM or terminal application name
	# Assigned to: $DESKTOP
		$PRINTF '%s\n' "${XDG_CURRENT_DESKTOP:-${DESKTOP_SESSION:-${TERM:-TTY}}}"
	}
	swarm.os.distro() { #
	# Returns the name of the distro
	# Assigned to: $DISTRO
        	# This /etc is not as dynamic as I'd like
        	# but its THE absolute standard - as far as I'm aware
        	if [[ ! -f "/etc/os-release" ]] || ! $GREP -E  ^NAME= "/etc/os-release"  | $SED s,"NAME=","",g >&1 
		then	local e=/etc
			local SF="release version"    # Search For

			local results=$(for a in $SF;do \ls "$e"|"$GREP" "$a";done)
			local resultsFiles=$(for each in $results;do [[ -f "$e/$each" ]] && $PRINTF "$each ";done)

			for each in $resultsFiles
			do      strcat="$($GREP -i ^NAME= $e/$each)"
				[[ -n "$strcat" ]] && break
				strcat="$($GREP -i ^id= $e/$each)"
				[[ -n "$strcat" ]] && break
			done
			$PRINTF "${strcat/*=}"|$SED s,'\"','',g
		fi
	}
	swarm.os.based() { #
	# Returns arch, debian, redhat or unknown
	# Assigned to: $BASED
    		out=""
		if [[ -f /etc/redhat-release ]]
		then	out=redhat
		elif [[ -f /etc/arch-release ]]
		then	out=arch
		elif [[ -f /etc/debian_version ]]
		then	out=debian
		else	out=unknown
			# Do further checking
			# Changes according to: https://github.com/icy/pacapt/blob/ng/pacapt (153-180)
			swarm.util.which cave   1>/dev/null 2>/dev/null && out=exherbo
			swarm.util.which emerge 1>/dev/null 2>/dev/null && out=gentoo
			swarm.util.which port   1>/dev/null 2>/dev/null && out=mac
			swarm.util.which brew   1>/dev/null 2>/dev/null && out=mac
			swarm.util.which zypper 1>/dev/null 2>/dev/null && out=opensuse
			# Not sure if i handle these 2 properly
			swarm.util.which pkg 1>/dev/null 2>/dev/null && out=openbsd
			swarm.util.which pkgng 1>/dev/null 2>/dev/null && out=freebsd
		fi
		builtin echo "$out"
	}
	DISTRO="$(swarm.os.distro)"
	DESKTOP="$(swarm.os.desktop)"
	BASED="$(swarm.os.based)"

If you happen to have any recomended additions or changes, please, let me know so.
Have fun!