Re: pkg/51152 (pkg_alternatives via shebang won't continue and will use previous shell)

[Julio Merino <julio%meroh.net@localhost>]

The following reply was made to PR pkg/51152; it has been noted by GNATS.

From: Julio Merino <julio%meroh.net@localhost>
To: David Holland <dholland-pbugs%netbsd.org@localhost>
Cc: gnats-bugs%netbsd.org@localhost
Subject: Re: pkg/51152 (pkg_alternatives via shebang won't continue and will
 use previous shell)
Date: Mon, 4 Jul 2016 23:14:26 -0400

 On Mon, Jul 4, 2016 at 9:38 PM, David Holland <dholland-pbugs%netbsd.org@localhost> wrote:
 >
 > On Sun, Jul 03, 2016 at 02:41:13AM +0000, jmmv%NetBSD.org@localhost wrote:
 >  > Yup... This was years ago, so if I had to guess as to why this problem
 >  > exists, it's probably because I did not know that shell scripts could
 >  > not act as full-blown interpreters back then.
 >  >
 >  > Rewritting the wrapper in C is a good answer and should be relatively
 >  > straightforward; it's a pretty rudimentary program.
 >
 > Unfortunately it looks like it needs to be recompiled on the fly
 > outside the pkgsrc compilation environment... that or the whole thing
 > needs to be restructured so there can be one binary wrapper compiled
 > in advance and a way to look up what's currently baked into the script
 > file at creation time.
 >
 > That or do some kind of binary patching horror.
 
 From a second look... I see these three classes of "settings" in wrapper.sh:
 
 * ID, ROOT_USER: These are static variables defined at "configure
 time" so they can just be baked into the binary.
 
 * WRAPPER: The name of the actual wrapper. Could possibly just be
 derived from "basename of argv[0]" (?), in which case the wrapper
 binary would suit any alternative.
 
 * DB_FILE, CONFFILE: Paths to files. These are built from a static
 setting determined at "configure time" (e.g. path to the system-wide
 configuration directory, or a path to a home directory), and a dynamic
 piece. The latter seems to be just the value of WRAPPER. If that's
 correct, then the same as in the previous applies.
 
 In other words: if the wrapper code is changed to rely on the contents
 of argv[0], it should be possible to reuse the exact same binary for
 all alternatives.
 
 -- 
 Julio Merino -- http://julio.meroh.net/