Ease upgrade procedure

[paulo-ferraz-oliveira]

After #399, I thought an upgrade command would be useful, too.

@crownedgrouse, here's a shot at it. 😄

Assumptions:

1. wget is available in target system (no longer required, as we're using curl)
2. LATEST is available in the kerl repository (it would have to be maintained either manually or by some automated mechanism)
3. we want the default installation to go to /usr/local/bin (this is already mentioned in the README) default is $PWD, otherwise $KERL_APP_INSTALL_DIR (if set)

• also, shellcheck shows a lot of warnings, even if harmless. I can fix those, in a separate commit, if you want. (and then we could use it - shellcheck - in CI too 😄)

This also adds an option to kerl: KERL_APP_INSTALL_DIR so the consumer can decide on where to install kerl from kerl upgrade (a README.md update was in order, for this).

[paulo-ferraz-oliveira]

The goal is to have kerl upgrade install to:

1. (in case it isn't already) /usr/local/bin (e.g. ./kerl is run from the GitHub clone local repo, and kerl is not installed),
2. (in case it is already) whatever is the current path already, by overwriting it.

[crownedgrouse]

do not forget to update bash_completion and zsh_completion.

[paulo-ferraz-oliveira]

Oh, yeah. Let me get to those.

The option has no arguments, which made my life easier :)

[crownedgrouse]

I think there is no need of a LATEST file.
You can get the latest version number with wget --content-disposition https://github.com/kerl/kerl/releases/latest
as --content-disposition use the redirected filename (currently 2.2.4) .
Doing this in a temporary new directory will give you the last version number.

[paulo-ferraz-oliveira]

@crownedgrouse, wouldn't that assume that the latest release is always the highest numbered (version-wise) one?

I was thinking about the case where a support version is created for an older kerl version (it's latest, but not "THE latest"), but that might not be what the maintainers intend (?)

Maintaining LATEST gives certainty as a lock, but if the maintainers are Ok, we can do away with that, sure.

[crownedgrouse]

Kerl contains KERL_VERSION. Getting latest version using wget can simply tell if versions are same. If not, upgrade can be done.

[paulo-ferraz-oliveira]

I understand, but let's say tomorrow kerl releases patch 2.1.3 after releasing version 2.2.5 (let's assume there was an important security issue to deal with).

Now let's say you have 2.2.4 installed locally. If LATEST (as I expect) is 2.2.5 the upgrade procedure I'm proposing would update to that one. If there is no LATEST (as you propose) we'd be downloading 2.1.3 which is not the latest version, but the latest release, alone.

And this is where it'd get confusing. If maintainers of kerl do only release versions that increment on top of the latest one, sure, your strategy would work.

[paulo-ferraz-oliveira]

@jadeallenx, any change this gets looked at soon? Thanks.

[jadeallenx]

This should probably be its own environment variable or otherwise settable to a directory from the command line. (For example, I install my kerl at $HOME/bin/kerl)

[crownedgrouse]

Current kerl is $0 ?

[paulo-ferraz-oliveira]

@jadeallenx, agreed. If not set, would the current choice (/usr/local/bin) be acceptable as a default? Should we document this?

[paulo-ferraz-oliveira]

Current kerl is $0 ?

I didn't understand this, sorry. $0 is "current script".

Here (in this place in the code), we're covering the option where kerl is not yet "installed" anywhere (eg. local Git repo), so @jadeallenx's suggestion makes sense, but maybe I missed something (?)

[jadeallenx]

We use curl everywhere else in the script currently, can we please use it here too instead of adding a new dependency on wget.

[paulo-ferraz-oliveira]

Sure 👍

[paulo-ferraz-oliveira]

Done in 2d2912a

[jadeallenx]

Thanks!

[jadeallenx]

Really appreciate this. Thank you.

[paulo-ferraz-oliveira]

Thank you, @jadeallenx.