Hi.
I sympathize with with your frustration. My work trail is littered with abandoned projects, and I have about 100 items on my current design / coding / testing / organizing list. Every now and then I see, hear, or otherwise come across something that allows me to push a project ahead. Time separation often seems to help me.
I hope that perhaps someday you and I and everyone else can come back to such projects and move forward.
Best wishes ... cheers, drl
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.
[~/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
#
# Starting SWARM now
#
source "$SWARMRC"
swarm.update.lang
swarm.update.lang.status
swarm.init.theme
#
# Initiate Interface
#
if [[ "./runtime" = "${0##/}" ]] || [[ "runtime" = "${0##/}" ]]
then # First time caller or arguments
if [[ -z "$1" ]]
then # First Time // No arguments
header --default
title "$SWARM_MSG_WELCOME_TITLE"
printe "$SWARM_MSG_WELCOME_INFOLINE1"
printe "$SWARM_MSG_WELCOME_INFOLINE2"
title "" # Separator
$ECHO "$SWARM_MSG_WELCOME_CONTENT" | printe -2 -- # "TODO: Visuals, then explain, configure and stuff..."
#status $? "one"
#init.countdown "Weee"
else # Has arguments, lets parse
case "$1" in
"basic")
shift
swarm.eu.show.basics
;;
"config")
shift
swarm.eu.show.config
;;
"help")
#echo hallo
shift
# Lets show a basic menu
swarm.eu.help.menu "${@}"
#break 2
;;
"tarball")
(
cd "${SWARM_DIR_ROOT}/.."
tar -acf "$HOME/swarm-${SWARM[BUILD]}.tar.gz" "${SWARM_DIR_ROOT##*/}"
)
;;
*) # Exit the loop
break
;;
esac
fi
fi
#
# Develeoper testings
#
if [[ "bash" = "${0/-}" ]]; then
#$ECHO " ----------- TEST AREA START -----------"
printe "Now it will work"
#set -x
# pick -m one two three four five six
#set +x
#$ECHO " ----------- TEST AREA END -----------"
fi"
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 "https://www.unix.com/shell-programming-and-scripting/284100-false-positive-grep-2.html\#post303045953"
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!
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! 
Get your daily dose of code here!
How to make a simple 'press enter to continue' - "complex"?
You add options 
press() { # [-c -l -r] [STR]
# Requires the user to press [Enter/Return] before script continues
# c=center ,l=left , r=right
# Vars
local mode=""
# Catch arguments
for opt in "${@}"
do if [[ "-" == "${opt:0:1}" ]]
then case "${opt/-}" in
"c") mode="center"
shift
;;
"l") mode="left"
shift
;;
"r") mode="right"
shift
;;
esac
fi
done
# Display
case "$mode" in
"center")
printl "" "${1:-$SWARM_MSG_PRESS_ENTER}" ""
;;
"left")
printl "${1:-$SWARM_MSG_PRESS_ENTER}"
;;
"right")
printl "" "" "${1:-$SWARM_MSG_PRESS_ENTER}"
;;
*)
printl "${1:-$SWARM_MSG_PRESS_ENTER}" "" "${1:-$SWARM_MSG_PRESS_ENTER}"
;;
esac
# Action :p
builtin read
}
Oh it will be so fun when/once I add/ed 'kiosk'-mode to several functions
Ok, so while we're testing SWARM for cross-platform abilities, I had figured that 'different theme for root' didnt apply.
So I fixed that.
Issue is....
as a regular user - everything looks good:
as root user, not so much...
This is going to be fun to figure out.
Strange...
'All' I had to do was to remove some echos of a bool function...
From:
swarm.util.isDir() { # /path/to/dir
# Returns true if passed string is a directory
# This function is assigned to: $isDir
swarm.protect "$FUNCNAME" "${@}" && exit 1
[[ -d "$1" ]] && \
RET=0 && \
$ECHO true || \
$ECHO false
return ${RET:-1}
}
To:
swarm.util.isDir() { # /path/to/dir
# Returns true if passed string is a directory
# This function is assigned to: $isDir
swarm.protect "$FUNCNAME" "${@}" && exit 1
[[ -d "$1" ]] && RET=0
return ${RET:-1}
}
But why it was showing those 'true' and 'false' echos only as root, but not as normal user... idk...
As I'm currently waiting on some feedback about systems I cannot test, such as MacOS or Solaris, I could improve the system detection slightly.
Big thanks to @Chubbler_XL for testing SWARM on Cygwin.
Thanks to his test I hope to have this function finalized:
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 strcat="" # Init empty variable
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)
# Basic detection
for each in $resultsFiles
do strcat="$($GREP -i ^NAME= $e/$each)"
[[ -n "$strcat" ]] && break
strcat="$($GREP -i ^id= $e/$each)"
[[ -n "$strcat" ]] && break
done
# Prepare easy printable result
local result="$(builtin echo ${strcat/*=} |$SED s,'\"','',g )"
# 'Advanced' (aka backup) detection if empty
if [[ -z "$result" ]]
then
# This works for Cygwin...
result=$(uname -s)
# TODO: any other exceptions un-dis-covered?
# Or further actions required?
fi
# Print output
$PRINTF "${result}"
fi
}
In the meantime I'll write, well adjust, the manpages.
You might wonder why I waited 'so long' to do so.
Simply because I wanted to have most functions 'done', so the according function is 'up to date' and I can rely - and "link" (missing better wording) to/with the function.
Also, in some situations I knew I had to drop some options and for others I had to add new ones - due to the re-writing as a process / whole.
This said, I just figured that I had missed to write an option for a function.
Thanks to this 'late' approach, I can focus on just adding this single option - rather than to remember to implement "this" and "that" when writing the function.
Allthough I've spent like 4 hours this morning trying to get my USB (or at least the iso of it) reckognized by FreeBSD via a VM, I didnt manage it...
Even with the help of RudiC, thank you, we were not able to figure where the usb.iso was listed as in /dev.
Another 4 hours later, around 4:30pm, I stumpled about an old and forgotten man console_codes (4) while rewriting/adjusting the old TUI manpages to/for SWARM.
I wonder if I can figure how to get COLUMNS and LINES out of that - as the tput guy did.
What do you think, could I actualy save time by using console codes over tput?
Would they read 'from memory' instead of calling a physical file?
Basicly I just wanted to get rid of a dot - now I wonder if I should add some more variables...
At least I'm in the 'Lets write some manpages mood' now
EDIT
And to add a 'current time' joke:
Figured there is a pandemic going around, so I thought it is a good time for doc-days
Oh riiiiiiight... just so you know...
We're talking about ~50'ish manpages in total...
Oh well, just done like 14 manpages during the weekend (w/o sunday).
But could fix some small display issues instead
After watching an interview with Linus from last year, I decided to change the license to GPLv2.
Uhh... just figured I missed to add a little disclaimer how to customize SWARM without breaking the license.. I did thought of that in advance (not for the license, but the required functionality)
Anyway, I'm happy with the current 'time - differences' when creating the rc file on first run and afterwards:
I think for the 'all these visual effects' and background checks (required to make it run in runtime) it's a pretty good time.
Also, by now one can call manpages by: ./runtime help header
NOTE:
SWARM will be version 1.0 as soon the last function is converted.
That is also the time when itll be available on github.
Thought, its still ~35'ish manpages, 2 'big' functions and some smaller ones.
But having manpages starts to give a 'somewhere near completion' feeling
EDIT:
If someone would translate this to say, french, german or spanish, it would show the according manpage instead, if you would have 'this' language as shell locale.
Just saying - all prepared
/* this said, I wonder how it would behave with crylic, 'arabic "letters"', chinese and/or other sanscrit alike.
Should work though, I mean, it's just strings... (or files in case of manpages) */
Almost done with the manpages and according code adjustments...
I've been busy, but still, the bigger ones remained TODO...
Here's the git log from the last 4 days
The remaining functions and manpages slowly become an overseeable amount.
Wants to post this some time back already, but decided otherwise until someone else posted such things.
Well.. and I wanted to fix something first: Get Dir Size - #5
[~/prjs/SWARM] 130 $ ./runtime stats
########################################
Project stats for "SWARM"
########################################
20908 Bytes in .
28672 Bytes in data
4096 Bytes in data/lang
18593 Bytes in data/lang/en_GB
48068 Bytes in data/lang/en_GB/man
8192 Bytes in data/templates
876 Bytes in data/templates/scripts
3728 Bytes in data/templates/conf
1274 Bytes in data/themes
759 Bytes in data/lists
0 Bytes in data/ramdisk.tmp
2297 Bytes in data/conf
86865 Bytes in data/libs
32719 Bytes in docs
14 folders with a total of 251.022 kbytes
########################################
Spread across 97 files, there are:
Lines Total: 7566
Comment lines: 518
Blank lines: 8
Avrg lines p. file: 78
The according code looks like:
#
# Vars
#
LINER="########################################"
COMMENTS=0
LINES=0
BLANKS=0
#
# Action
#
$ECHO "$LINER"
$ECHO -e "\tProject stats for \"${PWD##*/}\""
# Size
$ECHO "$LINER"
cd "$SWARM_DIR_ROOT"
swarm.str.dirlist . | swarm.str.dirsize -- | \
$AWK '{print $0;SUM=SUM+$1} END {print NR" folders with a total of "SUM/1024" kbytes"}' | $SED s,"${SWARM_DIR_ROOT}\/",'',g
cd "$OLDPWD"
# Files
$ECHO "$LINER"
FILES=$($FIND|$GREP -ve ".git" | $WC -l)
$ECHO "Spread across $FILES files, there are:"
# Lines
for F in $($FIND|$GREP -ve ".git" -ve ".jpg")
do if [[ -f "$F" ]]
then
val_num=$(\cat "$F"|$WC -l)
COMMENTS=$(( $COMMENTS + $($GREP ^"#" "$F" | $WC -l) ))
LINES=$(( $LINES + $val_num ))
BLANKS=$(( $BLANKS + $($GREP ^[[:space:]]$ "$F" | $WC -l) ))
fi
done
$ECHO -e "Lines Total: \t\t $LINES"
$ECHO -e "Comment lines: \t\t $COMMENTS"
$ECHO -e "Blank lines: \t\t $BLANKS"
$ECHO -e "Avrg lines p. file: \t $(( $LINES / $FILES ))"
Such fun and nerdy things in betwen definitly help to keep spirits up
Talking about 'big functions', I'm currently nervous about 'bar', allthough I described that as 'medium' 
While keeping that on the long bench, I reduced the loading time (back on the desktop) on the sdd from ~0.3s to about ~0.225, despite the fact that I changed some loops to use some new list files (so more hardware/physical interaction).
The TODO list gets shorter and shorter, day by day...
Thats all that is left from/for the 1.0 mandatory core functions.
Despite the fact that for almost all non-visual function I could rely on copy-paste-replace for the most part - with more of just an occasional rewrite, which so far took about 2 months, I still just needed like 3 months for the core visual functions and the init procedure.
But still, just about 5-6 months for something that initialy took took me something like 4-5 years, though that included a 'day job'.
But as of now, I'm just happy again about the time:
I think for that all beeing bash based, using the full width of a fulhd resolution and with this amount of 'formatted' text, and creating the ~/.swarmrc file and ~/.config/swarm dir and subdirs, I believe it's an acceptable time.
What do you think?
I always have a positive opinion for people who develop solutions or create applications by writing code.
Keep up the great work and thanks for documenting your adventure(s) here.
So during the past 18 days, I've had a little break and built some vaults in Fallout 4 for a change
But I was not completely inactive, mostly just some small things:
I'm currently trying to rewrite bar in a way to NOT use tempfiles for the animations, this not only reduces disk-usage, thus improving performance, but it will make SWARM also work properly on RO-systems. (thought if using a progressbar, you're probably writing something somewhere somehow....)
My intention is to write the following in a way that it is array based, should not be too difficult.
function reset_tmp() { # ID
# Resets the counter according to passed ID
# Needs to be one, otherwise last item is too low
if "$hasID"
then cfg.set "${TMPFILE}.id" "$ID" 1
else builtin echo 1 > "$TMPFILE"
fi
#echo was here
}
function save_tmp() { # VAL
# Saves VAL in the temp file according to passed id
#
[ -z "$1" ] && return 1
if "$hasID"
then cfg.set "${TMPFILE}.id" "$ID" "$1"
else builtin echo "$1" > "$TMPFILE"
fi
}
function read_tmp() {
# Reads VAL in the temp file according to passed id
# Returns VAL
if "$hasID"
then cfg.get "${TMPFILE}.id" "$ID"
return "$?"
else $CAT "$TMPFILE"
return "$?"
fi
}
As I assumed, that specific task was not that much of a challenge
function bar.reset_tmp() { # ID
# Resets the counter according to passed ID
# Needs to be one, otherwise last item is too low
if "$hasID"
then SWARM_PROGRESS_BAR_IDS[$ID]=1
else SWARM_PROGRESS_BAR_IDS[$ID_CUR]=1
fi
export SWARM_PROGRESS_BAR_IDS
}
function bar.save_tmp() { # VAL
# Saves VAL in the temp file according to passed id
#
[ -z "$1" ] && return 1
if "$hasID"
then SWARM_PROGRESS_BAR_IDS[$ID]="$1"
else SWARM_PROGRESS_BAR_IDS[$ID_CUR]="$1"
fi
export SWARM_PROGRESS_BAR_IDS
}
function bar.read_tmp() {
# Reads VAL in the temp file according to passed id
# Returns VAL
if "$hasID"
then builtin echo "${SWARM_PROGRESS_BAR_IDS[$ID]}"
else builtin echo "${SWARM_PROGRESS_BAR_IDS[$ID_CUR]}"
fi
}
Now the nice part of this is, that BASH can handle associated arrays, meaing, while using numbers as ID is recomended, on/for custom ID's one could use a string as well.
(ID_CUR is actualy just $$, as defined prior in the function)
Now i need to 'enlarge' the actual progress bar, and fix the aligments for -B num and -B dash options.
But how it looks now.. I guess I have to focus on the remaining fine-tuning (and fixing) for printl
EDIT:
Haha, when you write code and forget that your internal functions work slightly different than those others shall use
Guess I can now focus on word (well, string) splitting in case output is too long.
EDIT 2:
We're getting somewhere.. here's the... animation... 
Now (back again to) enlarge the actual bar... and... I'm fearing this part a bit...
Make it 'color-able'... yikes... 
