Error encountered when $HOME is not set

[rgee0]

Expected Behaviour

When run in an environment where the $HOME environment variable isnt set the requested action should complete successfully.

Current Behaviour

When run in an environment where the $HOME environment variable isnt set an error is encountered. Issue was highlighted on faasd and triaged here

Are you a GitHub Sponsor yet (Yes/No?)

• [ ] Yes
• [x] No

Possible Solution

@alexellis suggested that Arkade could avoid the error by choosing a default when $HOME isn't set.

Steps to Reproduce (for bugs)

1. Install Arkade
2. rununset HOME
3. run arkade get --progress=false faas-cli
4. Observe the error:

   Downloading: faas-cli
   2022/06/08 20:34:00 Looking up version for faas-cli
   2022/06/08 20:34:01 Found: 0.14.2
   Downloading: https://github.com/openfaas/faas-cli/releases/download/0.14.2/faas-cli
   /tmp/faas-cli written.
   2022/06/08 20:34:02 Looking up version for faas-cli
   2022/06/08 20:34:02 Found: 0.14.2
   Error: env-var HOME, not set

Context

Whilst it hasn't affected me directly it has been observed when Arkade is used in cloud-init scripts on Lima. This issue is to either track progress of a resolution, or to provide detail / trail for others encountering a similar issue.

If requesting a CLI for "arkade get"

N/A

Your Environment

• What arkade version is this?

0.8.26

[jsiebens]

Just for the record: it's not Lima specific but more cloud-init in general, cloud-init startup script runs as root with no $HOME environment set up so this also effects running arkade during startup on cloud providers.

[alexellis]

I am thinking that pwd should be used when HOME isn't set. Temp could also be an option but we don't know how large it may be.

Any concerns with going forward with that?

[alexellis]

@rgee0 @jsiebens

[jsiebens]

When HOME is not available, installing packages with arkade get is more or less a system-wide install instead of in the context of a user. With the latest update, the faasd install scripts sets /usr/local as HOME (when necessary), which makes the tools available in /usr/local/.arkade. IMHO that seems a better fallback location than pwd or temp

Another idea is to add a flag or env var to arkade get to set a specific installation directory.

[rgee0]

I'd agree with /usr/local/.arkade, purely on grounds of consistency; its fixed whereas pwd could vary between runs / users / environments.

Not so keen on the flag / env var options as this is adding something that the user needs to configure. There is little difference to advising a user to add export HOME= when required.

[alexellis]

Arkade installs to a temporary staging area of $HOME/.arkade/bin, my vision for this is that it's ephemeral, purely a cache and any permanent CLIs must be moved intentionally.

So I would expect pwd to be where work is staged or held when HOME is not set.

Example in cloud-init:

arkade get kubectl
mv .arkade/bin/kubectl /usr/local/bin/

Whilst we're exploring this, I'm not sure if I remember what --stash was meant for?

      --stash            When set to true, stash binary in HOME/.arkade/bin/, otherwise store in /tmp/ (default true)

[alexellis]

Writing to /usr/bin/local would probably require root permissions.

@Shikachuu could you move ahead with a solution where if "HOME" is not specified, then the current working folder is used as the base path instead?

[rgee0]

Presumably the script/user might also then call the binary that has just been downloaded. How does this work in situations where pwd isn’t in the path?

Feels like the user now has to know a little bit more about decisions in get.sh in order to get going, or what am I missing?

[Shikachuu]

Presumably the script/user might also then call the binary that has just been downloaded. How does this work in situations where pwd isn’t in the path?

Feels like the user now has to know a little bit more about decisions in get.sh in order to get going, or what am I missing?

Atleast the user will know where the binary is downloaded and we could put a notification there like:

============================================================
The script was unable to write to write to the $HOME dir,
the binary has been downloadedto $PWD
which might not included in your path!
============================================================

or something like this. What do you think @rgee0 ?

[rgee0]

So in the script scenario the user writing the script needs to know ahead of time what decisions get.sh will take, or has to parse your output message in order to provide the base path to subsequent calls?

I don’t know, maybe I’m not fully understanding the use case.