As of now, the only way to avoid the default environment variables is by
setting them to another value. However, there are some cases in which
the variable being unset is desirable.

For instance, on `nixpkgs`, since it is not FHS compliant (no /usr/bin),
setting `HAREC` to `harec` makes hare not use the embedded absolute path
on the binary itself.

I'd like to know if you'd find acceptable a patch implementing an option
that disables setting the default environment variables.

Perhaps a better approach would be to have an option (or an environment
variable) that would make `haredo` set the default environment
variables. However, that would be a breaking change, while the former
option would not.

On 10 May 2024 23:03:28 BST, Coutinho de Souza <srht-n2c9ebas@onemoresuza.com> wrote:
>As of now, the only way to avoid the default environment variables is by
>setting them to another value. However, there are some cases in which
>the variable being unset is desirable.

can't you just use unset(1) ? it's in posix shell
<https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#unset>

>
> can't you just use unset(1) ? it's in posix shell
> <https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#unset>

I can on projects that I own, but not when packaging them downstream.
For instance, I use it on my rham project[0].

Another solution would be patching the `.do` files to include the unset
calls; I see, however, the following problem: It would require manual
patching of every package using haredo, while an option to disable
setting the env vars would require just passing a flag to it.

Also, I've came up with a possible patch for an `-e` flag[1].

[0]: https://git.sr.ht/~onemoresuza/rham/tree/87305f9a120f1a9f1e2aa7b46d489ce5c3000019/item/artifacts.do#L8
[1]: https://git.sr.ht/~onemoresuza/haredo/commit/01ded58c853ac3119cd6d9d2997fd9cf19dcdd0a