--- linuxgirlie
Ahh, I forgot to say so far it will only run on rpm based distros....maybe this was why you were having problems?!?
If you can send me some feedback it would be nice as we can then improve it!!
Ok. Well, it certainly is possible to standardise some aspects of Karoshi such that it is more portable against different distros. Admittedly there isn't a great deal of difference between RPM-based distros -- but there is enough difference to merit some work in changing certain aspects. I know I've mentioned that I wouldn't go near Mandrake -- that's just me. I'm a crufty-imbecile that would use anything but. I would imagine that for 99.9% of others, Mandrake would be fine, but this is Linux, and choice is everything, so... :) As to how much work is involved, I couldn't say. I didn't have to do *too* much work to get Karoshi to run on Debian. Most of it involved changing a lot of your bash scripts. Meaning no disrepect to you, the scripts are quite poor, and badly needed re-writing anyway. For instance, in your 'serverselection' script, it would be nice if you tested if the directory existed, rather then shunting a non-existing error to /dev/null, something like: [ -d $HOME/.tempdata ] || mkdir $HOME/.tempdata Other issues to consider, if you want to make it portable are not to rely on installing your version of Xdialog that you package with karoshi. What happens if I already have it installed? Ka-boom, it fails. Now, it might be that the descision was made because Karoshi is intended to be installed just after a base/minimal installation. Fine, but at least check to make sure, even something simple would help: [ -z "$(which Xdialog)" ] && XDIALOGVERSION="XDialog-foo.rpm || \ # don't both installing it. (I'll ignore the poor naming of the variable... :P) I noticed also that the script is not detecting whether it is running as root or not -- hence I got a lot of errors. If the assumption is made that the user will be running the script as root anyway (hmm, see my "Logging in as root? Alternatives exist" post about caveats) that's possibly OK, but still check to ensure, something like: [[ $UID = 0 ]] || { echo "You must be user root to run this script" exit 0 } Issues of portability -- you could make it more robust if you could determine which distro is running. Now, this isn't an easy task, but one way is to do something like the following: for i in {mandrake,fedora,SuSE,redhat,gentoo}-release do [ -e "/etc/$i" ] && DISTRO=${i/-release/} done case "$DISTRO" in mandrake) # do something specific ;; SuSE) # do something specific ;; fedora) # do something specific *) # default to Mandrake? ;; esac You can then almost certainly get the underlying distro to install its own verion of packages -- thus saving you the need to ship with version of packages many (if not all) distro use, anyway. Debian and Slackware will/might be the oddities here, but not to be seemingly arrogant, the majority of people using these distros will usually be able to know what to do to fix various things. Other factors I've seen that could be improved -- you have a *hell* of a lot of redundant code -- you should modularise this into separate scripts that the main script can then source. For instance the 'serverselection' script's code is repeated in at least three other scripts -- why? It would have been far easier from a maintainability point of view to have common functions in one script, source and used as needed. It's a sticking point, because in order for Karoshi to run on Debian (at least), I then had to change every single script. Luckily, awk came to the rescue, but.... :) Spaces in filenames -- opps. Try and avoid that, the shell hates them. And it just means you have to use excessive quoting where you wouldn't normally had you used underscores. Very old shells (sh on HPUX for instance) hates them a great deal more -- sh and bash on Linux are far more forgiving. :) There's probably other things as well I've forgotten about, but I hope that helps... -- Thomas Adam Send instant messages to your online friends http://uk.messenger.yahoo.com