this file should not live in /usr/bin/. i'd suggest /usr/share/eix/ instead.
Since it is meant to be used also from user scripts, it should be in the standard PATH for the same reason as in bug 416911: Unfortunately, POSIX requires "." to look up only in PATH, so the natural . eix-functions.sh works in scripts only in this case; I do not want to force users to do ugly hacks about guessing the location e.g. for prefix installs when they write wrappers for eix using functions from this file.
that is true that doing `. foo` will search $PATH only. however, it is still wrong. $PATH is for executable files not random sourcable shell scripts. you're right that push too is broken then.
(In reply to SpanKY from comment #2) > $PATH is for executable files not random sourcable shell scripts. Shell has only the concept of sourcing files but not a concept of a library. According to POSIX description, PATH is obviously the intended location to store files which are going to be sourced. Everything else would break usage.
(In reply to Martin Väth from comment #3) > (In reply to SpanKY from comment #2) > > $PATH is for executable files not random sourcable shell scripts. > > Shell has only the concept of sourcing files but not a concept of a library. > According to POSIX description, PATH is obviously the intended location to > store files which are going to be sourced. Everything else would break usage. Maybe adding env.d file for eix with adding /usr/share/eix path to PATH(and moving script there, of course) would fit? Although it's a bit hackish IMO.
(In reply to Sergey Popov from comment #4) > Maybe adding env.d file for eix with adding /usr/share/eix path to PATH The idea of PATH is that it should be only a few directories (better for caching); this is one of the reasons why all executables are usually in /usr/bin, and even huge projects like X and kde eventually decided to not add an extra directory. It would certainly be overkill to have a separate PATH component for a single script.
(In reply to Martin Väth from comment #5) > (In reply to Sergey Popov from comment #4) > > Maybe adding env.d file for eix with adding /usr/share/eix path to PATH > > The idea of PATH is that it should be only a few directories (better for > caching); this is one of the reasons why all executables are usually in > /usr/bin, and even huge projects like X and kde eventually decided to not > add an extra directory. It would certainly be overkill to have a separate > PATH component for a single script. Yep, you are right, my bad. So, maybe some switch to eix itself? Like for using such thing in scripts: . $(eix --script-path)/eix-functions.sh
(In reply to Sergey Popov from comment #6) > . $(eix --script-path)/eix-functions.sh Horribly slow and no solution for push. One could place a separate command in /usr/bin whose only purpose is to output the path ;) Or one could just leave eix-functions.sh|push.sh in /usr/bin. Seriously, we are not talking about inflating PATH with hundreds of commands (like it was the case with earlier versions of git [git-*]) in which case a wrapper of some sort might be appropriate but about very few distinct scripts. Moreover, what is so special about these scripts? That they are not meant to be called directly by the user but usually only indirectly by means of other scripts or programs (perhaps with the exception of testing some special things)? There exist several such files in /usr/bin (X being a prominent example). IMHO the only valid reason for putting eix-functions.sh in /usr/lib instead of PATH is that one _might_ consider it as some sort of library - but since shell does not know the concept of a library this is an invalid interpretation either (at least, it is only an interpretation of the human mind as an afterthought, not a library in the technical sense of a specific programming language). There are not so many examples which we can look at (some others like set_prompt.sh or archwrap.sh are from myself) and probably none is in portage, but I found at least one other: http://sourceforge.net/projects/pipestatus/ also recommends to put the "library" into PATH.
(In reply to Martin Väth from comment #7) you've lost me as to how `eix --script-path` could possibly be "horribly slow". $ time eix --help >/dev/null real 0m0.020s user 0m0.016s sys 0m0.004s the status of other packages is irrelevant. eix is misbehaving and putting things into $PATH that do not belong there. /usr/lib is also wrong. this is a architecture-independent hence it belongs in /usr/share.
(In reply to SpanKY from comment #8) > you've lost me as to how `eix --script-path` could possibly be "horribly > slow". You load a file of several megabytes without any technical need - only to put another file at a questionable location. > eix is misbehaving I read the fhs again and found quite the opposite: 1. /usr/bin is for binaries and scripts - there is no restriction about the intepreter for these scripts. 2. /usr/lib is for binaries and scripts *not* meant to be used by the user or by user scripts. 3. /usr/share is for system-independent data meant to be used *by the installed programm*. eix-functions.sh is a script meant to be used by user scripts (and not only by the installed program). So from the above 3 locations, the first is the only possible choice - by exclusion principle as well as by the description. Moreover, the POSIX standard clearly suggests that such particular type of sripts as eix-functions.sh are to be treated as all other scripts. > /usr/lib is also wrong. this is a architecture-independent According architecture-independency is only a necessary but not a sufficient condition for /usr/share: It is not forbidden that /usr/lib contains architecture-independent libraries - in fact, if this would be forbidden, perl and python would all install into the wrong directory. The fhs states only the opposite implication: If it is in /usr/share then it *must not* be architecture-dependent.
(In reply to Martin Väth from comment #9) An important word was forgotten which made the sentence not understandable: s/According/According to FHS/ > According architecture-independency is only a necessary but not a sufficient > condition
commit 55d027a30d72a06c6d3dc87aefc4f1793a1f2dc5 Author: Michael Weber <xmw@gentoo.org> Date: Fri Feb 10 10:38:43 2017 +0100 app-portage/eix: Move eix-functions.sh into /usr/share/eix (bug 493000). Package-Manager: Portage-2.3.3, Repoman-2.3.1 app-portage/eix/eix-0.32.5-r1.ebuild
