From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?utf-8?Q?Ludovic_Court=C3=A8s?= Subject: Re: 01/01: services: Add =?utf-8?Q?=E2=80=98=2Fusr=2Fbin=2Fenv?= =?utf-8?Q?=E2=80=99?= special file. Date: Mon, 09 Sep 2019 00:07:10 +0200 Message-ID: <87h85m1lyp.fsf@gnu.org> References: <20190906102509.28951.2772@vcs0.savannah.gnu.org> <20190906102510.002BE21324@vcs0.savannah.gnu.org> <87d0gdbtji.fsf@cbaines.net> <87mufhwhc6.fsf@nckx> <87d0gcgodz.fsf@devup.no> <8736h8uh05.fsf@elephly.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:53986) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i75Kz-0004LB-T2 for guix-devel@gnu.org; Sun, 08 Sep 2019 18:07:14 -0400 In-Reply-To: <8736h8uh05.fsf@elephly.net> (Ricardo Wurmus's message of "Sat, 07 Sep 2019 19:56:58 +0200") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Ricardo Wurmus Cc: guix-devel@gnu.org Hi, Ricardo Wurmus skribis: > Using a custom script with a /usr/bin/env shebang is pretty common. You > don=E2=80=99t need to be a power user for that, and certainly not a *Guix= * power > user. Like I wrote in and in the message it refers to, although I was initially mildly reluctant to having /usr/bin/env by default, I=E2=80=99ve come to think that lack of /usr/bin/env is a gratuitous annoyance=E2=80=94not to me of course, but to newcomers as we=E2=80=99ve seen repeatedly, be they seasoned GNU/Linux user= s or not. With that in mind, adding /usr/bin/env by default is probably a good move. Now, we can add a snippet in the manual with the =E2=80=98modify-services= =E2=80=99 trick to remove /usr/bin/env. :-) > 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=E2=80=99t = 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). Yeah. Well anyway, if we take a step back, we=E2=80=99re talking about a really t= iny issue in the grand scheme of things, and it=E2=80=99s certainly not worth l= osing our hair over it. :-) Thanks, Ludo=E2=80=99.