03-15-2016
1,416,
266
Join Date: Sep 2013
Last Activity: 13 January 2021, 9:37 AM EST
Location: Swissh
Posts: 1,416
Thanks Given: 328
Thanked 266 Times in 239 Posts
In your run.sh you refer to function/cleanup, where it actually is functions/actions/cleanup.
Also, your function-script 'server' sources itself, which should result in an endless loop.
I'd assume, the 2 function/s folders, and each their realted 'actions' folders might be the cause of your issue.
Furthermore, your cleanup script is executed upon sourcing.
Only the user check obviously, but if only that part needs root access, you should put that check inside the cleanup functon (so it only reports that if it is executed/called), or put the root check in the top script if it is a valid check for all of it.
Sourcing a file 'executes' it in the current shell/terminal/instance.
So all the echos not beeing within a function will be shown, and all the if-blocks be executed.
Serving a function possible means that the script only contains functions, so after sourcing they're available in the 'top-script'.
This allows to use the same variables within the sourced script as in the top script, without the need to re-define them.
Hope my 2 cents help.
On my own behalf, and to offer an alternative in case you do not like whiptail.
[url]https://savannah.nongnu.org/projects/tui/[/url]
[url]https://plus.google.com/u/0/communities/100234551346652779244[/url] ([I]the bg image gives a glimpse how it will look[/I])
Since you already have a project heavy relying on files, here's a TUI example based on files/folder structure:
Hint: (note the .sh extension is merly to indicate it is a file, and not a folder)
prj/setup/
prj/setup/run.sh
prj/setup/functions/ (provides files containing functions (& variable definitions) ONLY, so they may be called from scripts anywhere below ./menu/*)
prj/setup/menu
prj/setup/menu/default.info (content: "Please choose an item to work with:" ;; to inform the user about the context of this folder)
prj/setup/menu/birdie
prj/setup/menu/birdie/install.sh
prj/setup/menu/birdie/uninstall.sh
[U]./run.sh[/U] (simplified, absolute minimum)
[CODE]tui-browser -s ./functions -p ./menu ${@}[/CODE]
The -s functions would source all files found in ./functions
And open the 'browser' at ./menu showing the content of that directory.
If there were arguments passed to run.sh, it will work them through and pass remaining arguments to the dir/script found in the dir ./menu.
[U]./menu/birdie/install.sh[/U]
[CODE]functon_to_make_sure_birdie_is_in_the_repo
tui-asroot "tui-install -y birdie"[/CODE]
This would install 'birdie' on Arch, RH (based), Deb (based), Gentoo, *BSD and Solaris, if it is found in the regarding repositries, using either sudo if installed and user is in sudoers, or su if sudo is not installed or user not in sudoers.
If properly installed, and using absolute path names, or using localy with relative path names, one could call in the [U]terminal[/U]:
[CODE]run.sh birdie install.sh[/CODE]
Would execute ./menu/birdie/install.sh
Or browse there by calling [ICODE]run.sh[/ICODE] alone, and then type 1,1 (using the first menu entries each time (folder birdie, file install.sh)).
This would enable your users to either use the nice menu (incl location bar) or do the tasks straight from the cli.
Understand, this example is based on your current situation/provided info.
Last edited by sea; 03-15-2016 at 03:14 PM..