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
