OK, that should have addressed most of the things in the scripts that do not work. The biggest thing was correcting the paths, but also allowing for the user-specific customizations, username, pass, network adapter, zip code. And fixing some other things.
Generic install:
So, now an "installer" like you mentioned.
A good installer would be generic enough so that most anybody can use it.
If a script is going to install other stand-alone software somewhere else on the system then it would be nice to give the option for the user to interact. Otherwise I don't know maybe it's a virus.
It should at least be a little bit specific to the system or have enough checks to be able to succeed. Like, is it even going to work? In my case, does the pip command even exist?
These parts are what could make a script very successful depending on how thorough and capable it is, or if it bombs out on line 3 leaving the user clueless.
Even if it's not very capable, like skipping a section when the user presses NO, then it's better to give verbose info to the user, and try to do good stuff.
The paths make a difference. If files are spread all over the system, that's not as good, and there's really no need for that in a situation like this one. If we force a path, then why not keep it very contained. I guess if there's an uninstall script then that's fine? Not as much.
Default conky config:
The default conky config is ~/.conkyrc
You can confirm that it does actually work as specified by just typing conky at terminal when you have a file in that location.
default user conky config official source:
https://github.com/brndnmtthws/conky/wi ... ne-Options
Code: Select all
-C, --print-config print the builtin default config to stdout
e.g. 'conky -C > ~/.conkyrc' will create a new default config
If you put a .conkyrc file in ~/.config/conky it will not process if you type the conky command.
Conky user path:
It could be whatever, but we can't assume what a user might want or if they don't care.
The 2 most obvious places, if they don't care, are:
~/.config/conky
~/.conky
We could go around the block trying to figure out what to do for a path.
But how about just asking for user input?:
Code: Select all
read -p 'Enter final path for haxOS_Conky:' upath
eval cd "$upath"
Or probing a bit to pick a good choice?:
Code: Select all
if [ -d "$HOME/.conky" ]; then
echo "You are using existing conky config $HOME/.conky"
echo "Following activity will be addressed to $HOME/.conky/haxOS_conky"
# do something
elif [ -d "$HOME/.config/conky" ]; then
echo "You are using existing conky config $HOME/.config/conky"
echo "Following activity will be addressed to $HOME/.config/conky/haxOS_conky"
# do something
else
echo "Could not find your conky user configuration directory."
if [ -d "/usr/bin/conky" ]; then
echo "But you do have conky installed".
else
echo "Do you even have conky installed?"
fi
# do something
fi
Or let them do what they want and follow their lead.
If a user receives a package and unzips it to their desired location and runs the included installer script from that location:
Code: Select all
thepath = echo $PWD
# do rest of installer stuff
But if they open a package and then run terminal at ~ , then the install script is going to have to deal with the wrong location.
So, in the end let's give the user an archive and let them choose the base directory, and they will have to call the install script. In this case they can call the script directly from the path or indirectly from their home, or wherever.
Code: Select all
thepath=$(cd $(dirname $0); pwd -P)
echo $thepath
# do rest of installer stuff based on $thepath being where this unzipped package is.
So, that's a good candidate for the first lines of the installer.
There could be so many choices in the installer.
Do you want all the modules? (y/n)
# add all the modules in a start script that the installer can write
otherwise:
Do you want to use the clock module?
# add line to the startup script
Do you want to use the calendar module?
# add line to the startup script
Do you want to use the speedtest module?
# add line to the startup script
..plus all the stuff in the previous posts.
So, now, where are we?