On 27/05/2016 12:31, Remko Tronçon wrote:
> Some of the 'built-in' binaries of execline conflict with binaries that
> already exist on the system.
As far as I'm aware of, it's only import. Are there other binaries that
conflict with other packages?
> For example, on a system with imagemagick installed, its 'import' gets
> precedence over the 'import' from execline. I know this is expected
> behavior, and can call '/bin/import' in all my scripts instead of 'import'
> (assuming that I know execline is installed in /bin, which I don't), but
> that makes it hard to create portable scripts.
>
> It feels like it would be expected that 'import' from execline to take
> precedence over any other 'import' binary in execlineb scripts (like
> builtins taking precedence in shells over binaries in the path).
>
> Are there any thoughts on this?
It's a problem that's bound to happen sooner or later, in the absence of
a centralized registry for command names; I doubt execline and ImageMagick
are the only pieces of software with a conflicting command name.
And yes, there are many thoughts on this - but unfortunately, there aren't
many satisfactory solutions. Ultimately, the problem is that the FHS does
not allow a program to unambiguously call a binary from a given package;
the namespace it provides isn't package-wide, but system-wide. (It's an old,
poorly thought out standard, and improving it requires overcoming *a lot*
of inertia.)
Here are a few things that work, by decreasing order of preference, but they
all have drawbacks:
1. Use slashpackage. Unambiguous command identification is one of the
benefits of slashpackage: instead of "import", you'd use
"/package/admin/execline/command/import" to be sure to call execline's import
binary.
The drawback is that your script will only be portable to systems that also
use slashpackage. And if you are working for a distribution or anything
bigger than your own machine, other people will be *very* reluctant to use
slashpackage, even though it has very tangible benefits; that's part of the
aforementioned inertia.
2. Don't use import. Instead of "import VAR", use "importas VAR VAR". This
will prevent the conflict.
The drawback, obviously, is that it's a workaround, not a solution: it
solves nothing, and it amounts to completely removing execline's "import"
command.
3. Play around with your PATH. If you know that execline binaries are in
/bin and ImageMagick binaries are in /usr/bin, temporarily swap /bin and
/usr/bin in your PATH before calling an execline script.
The drawback is that it's also an ugly workaround and relies on absolute
paths, which FHS does not guarantee - but there's no real way around it.
Some people think of putting all the execline binaries into their own
directory, and make execlineb a wrapper that prepends PATH with that
directory. That's not a bad idea, *but* s6, s6-rc, and potentially other
future packages, rely on execline binaries being accessible via PATH, so
excluding the execline directory from the normal PATH will break things;
it also makes execline binaries second-class citizens, which I obviously
do not like.
--
Laurent
Received on Fri May 27 2016 - 11:04:38 UTC