From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jesse Gibbons Subject: Re: 01/01: services: Add =?UTF-8?Q?=E2=80=98=2Fusr=2Fbin=2Fenv=E2=80=99?= special file. Date: Sun, 08 Sep 2019 17:53:02 -0600 Message-ID: <9e1dcc180080285cf826b88bb14fb1f1f70435f0.camel@gmail.com> References: <20190906102509.28951.2772@vcs0.savannah.gnu.org> <20190906102510.002BE21324@vcs0.savannah.gnu.org> <87d0gdbtji.fsf@cbaines.net> <87mufhwhc6.fsf@nckx> <874l1p80zr.fsf@netris.org> <87imq4whtt.fsf@nckx> <875zm231do.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:39277) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i76zV-0007D7-Ob for guix-devel@gnu.org; Sun, 08 Sep 2019 19:53:10 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1i76zU-0004sK-E9 for guix-devel@gnu.org; Sun, 08 Sep 2019 19:53:09 -0400 In-Reply-To: <875zm231do.fsf@gnu.org> 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: Ludovic =?ISO-8859-1?Q?Court=E8s?= Cc: guix-devel@gnu.org Hello, On Sun, 2019-09-08 at 23:48 +0200, Ludovic Courtès wrote: > Hi, > > Jesse Gibbons skribis: > > > If I might chip in here to try to make this discussion a little > > more > > productive, a user suggested /usr/bin/env should be added by > > default[0] > > to solve a problem[1]. In summary, the user wanted to have a > > standard > > for scripting in guile and other common GNU distros. If including > > /usr/bin/env by default is not the best solution to the problem, > > perhaps we can find a better solution. > > > > I suggest we add the "guix shebang" command, which takes a script > > and > > returns a script with a shebang pointing to the proper source, like > > what 'patch-shebangs build phase does to all the scripts in the > > build > > source. It could replace the input script (perhaps when given the > > -- > > replace option) or it could put the resulting script in the store > > and > > accept the --root= option. > > Would “guix shebang” modify the script, or would it be used as the > shebang? I suppose it could work either way. Since the scripts are intended to be modified by the audience[1], it would be easier to have a command to run as little as possible. On GuixSD, that would be as often as "guix pull && guix upgrade" updates the program that runs the script; on other systems it would be unnecessary. So modifying the script itself would make the process simpler. [1]https://lists.gnu.org/archive/html/help-guix/2019-09/msg00001.html > > Either way, I’m not sure it’d really solve the initial use case very > well (the initial request was to be able to run scripts unmodified, > AIUI.) I see two solutions to the problem: 1. Run the scripts unmodified (ideal). This can only be accomplished if the shebang can rely on a program in a standard location (i.e. /usr/bin/env). Adding /usr/bin/env by default currently is up for debate in this thread. 2. Patch the shebang with a command that can be run as rarely as possible, ideally only once. If we keep /usr/bin/env out of %standard- services or %de then this is the last solution I can think of. It could be an inline awk or sed script (like the scripts throughout LFS), which would have to be pulled out every time a user has new script, or a guix command which would always be available to all users with this particular problem. Guix package is an immediate choice, but was rejected because it would make things more commplicated[1], not to mention simpler scripts are probably shorter than a package definition. The simplest solution here would be something like "guix shebang". [1] https://lists.gnu.org/archive/html/help-guix/2019-09/msg00001.html I have no preference which solution is used, but if /usr/bin/env is not available in a build environment, and we can find a way to detect calls to programs in standard locations and patch them when we build them, I know of no reason not to include /usr/bin/env by default. If anyone has a fourth solution, I would love to see it. > Thanks, > Ludo’. -- -Jesse