Re: 01/01: services: Add ‘/usr/bin/env’ special file.

[Ricardo Wurmus <rekado@elephly.net>]

Hey Marius,

> If you are on Guix System and find that you need /usr/bin/env, you are
> already a "power user": you are venturing outside of what is provided by
> Guix alone.

I don’t follow this argument.

Using a custom script with a /usr/bin/env shebang is pretty common.  You
don’t need to be a power user for that, and certainly not a *Guix* power
user.

On the other hand I’d like to point out that pretty much all defaults we
provide in system services can be overridden — and that’s where it helps
being an advanced user.  This is true for things like the desktop
services (which aim to make setting up a generic desktop system easy and
non-surprising), but also for every other service.

Personally, I think it’s a good idea to default to having /usr/bin/env
shebangs just work on Guix Systems.

The argument that /usr/bin/env could make software work by accident when
testing on a Guix System is not very convincing to me.  We don’t have
/bin/sh or /usr/bin/env in the build environment.  Software behaviour is
also affected by the presence of /usr, /lib, /bin, etc, and these can
all exist at runtime.  We assume that building in an isolated
environment is usually sufficient; and yet we sometimes find that
applications behave differently when run inside of containers
(e.g. applications that call out to coreutils that are usually available
in a normal system).

With the same reasoning we could argue against having coreutils on PATH.
This is not an exaggeration: R depended on coreutils to be on PATH at
runtime and we only found out when we ran it in a container without
coreutils.

Am I missing something?

--
Ricardo