guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: thesis: guixsd should provide /usr/bin/env


From: Jookia
Subject: Re: thesis: guixsd should provide /usr/bin/env
Date: Wed, 17 Feb 2016 18:52:14 +1100
User-agent: Mutt/1.5.24 (2015-08-30)

On Wed, Feb 17, 2016 at 03:31:42PM +0800, 宋文武 wrote:
> Someone (sorry, I forget who) mentioned in #guix that we can use
> binfmt_misc to handle the shebang.

I might have been me since I thought this would be a neat idea.

> I tried coding it in C, and it seems to working fine.
> Here it is: <https://github.com/iyzsong/duang>.
> 
> Try it with care:
> --8<---------------cut here---------------start------------->8---
> $ sudo mount -t binfmt_misc binfmt_misc /proc/sys/fs/binfmt_misc
> $ git clone https://github.com/iyzsong/duang.git
> $ cd duang
> $ make
> $ sudo make install
> $ sudo make register
> --8<---------------cut here---------------end--------------->8---
> 
> This will install the handler into `/libexec/@', and register it in
> `/proc/sys/fs/binfmt_misc/duang'.  With it activated, intepreter in
> the shebang doesn't need to be absolute path, and can handle multiple
> arguments, eg: `#!emacs -Q --script'.  And when the interpreter in
> absolute path is not exist, it will fallback to be searched in the PATH,
> so `#!/usr/bin/perl -w' equals to `#!perl -w'.  On GuixSD, this means
> if we remove the `/bin/sh' symlink, the sh-scripts will fallbacked to
> use `sh' in PATH, so we can remove /bin.
> 
> I dunno if it's a good idea though :-)

Does this handle /usr/bin/env though? ;)

That said, I think it's the wrong approach since it's automated, invisible and
hides the issues of /usr/bin/env. Instead we need to do two things:

Write some scripts to ease migration and documentation on how to use Autotools
or other tools to fix shebangs. This is portable and will work on all systems.
Basically, find all shebangs, replace them with a macro that expands to the
binary, move the file from 'name.sh' to 'name.in.sh' and then use './configure'
or 'make' to build the 'name.sh' scripts with fixed shebangs.

Write a script that patches shebangs in a directory tree and has support for
unpatching them. This is useful for developing or running unpatched third party
trees where you want to change the source code and submit patches without
actually fixing the problem.

Both of these solutions can help destroy /usr/bin/env upstream and downstream.

Jookia.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]