pkgsrc-Bugs archive

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

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

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

From: Julio Merino <>
To: David Holland <>
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 <> wrote:
 > On Sun, Jul 03, 2016 at 02:41:13AM +0000, 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
 * 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 --

Home | Main Index | Thread Index | Old Index