Hi, I just replaced my bash completion file with the git version and noticed it tries to execute /bin/seq and fails because seq is located at /usr/bin/seq. Since I could not find anything in coreutils' changelog file I guess the path was wrong right from the start and should be corrected. The other thing I wonder about (still the same commit[1]) is why the (slower) external echo command is preferred to bash's internal implementation. Thanks, Cedric [1] http://projects.archlinux.org/pacman.git/commit/?id=8b3f5f0ce6dca98ca14cc48f...
On Thu, Feb 25, 2010 at 1:28 AM, Cedric Staniewski <cedric@gmx.ca> wrote:
Hi, I just replaced my bash completion file with the git version and noticed it tries to execute /bin/seq and fails because seq is located at /usr/bin/seq. Since I could not find anything in coreutils' changelog file I guess the path was wrong right from the start and should be corrected.
The other thing I wonder about (still the same commit[1]) is why the (slower) external echo command is preferred to bash's internal implementation.
Thanks, Cedric
[1] http://projects.archlinux.org/pacman.git/commit/?id=8b3f5f0ce6dca98ca14cc48f...
No idea if these paths changed, but there are other tools which are in /usr/bin and not in /bin : expr,seq,sort,find And in /bin we have sed,grep,ls
On 25/02/10 10:50, Xavier Chantry wrote:
On Thu, Feb 25, 2010 at 1:28 AM, Cedric Staniewski<cedric@gmx.ca> wrote:
Hi, I just replaced my bash completion file with the git version and noticed it tries to execute /bin/seq and fails because seq is located at /usr/bin/seq. Since I could not find anything in coreutils' changelog file I guess the path was wrong right from the start and should be corrected.
The other thing I wonder about (still the same commit[1]) is why the (slower) external echo command is preferred to bash's internal implementation.
Thanks, Cedric
[1] http://projects.archlinux.org/pacman.git/commit/?id=8b3f5f0ce6dca98ca14cc48f...
No idea if these paths changed, but there are other tools which are in /usr/bin and not in /bin : expr,seq,sort,find
And in /bin we have sed,grep,ls
I am definite that none of the paths changed. I am to scared of breaking stuff to alter the file locations from that historically. However, this is not portable across distros. We should check which locations are mandated by the FHS and have configure fill in the rest. Allan
On Thu, Feb 25, 2010 at 11:31:41AM +1000, Allan McRae wrote:
No idea if these paths changed, but there are other tools which are in /usr/bin and not in /bin : expr,seq,sort,find
And in /bin we have sed,grep,ls
Of the 7 programs mentioned, only sed and ls are mandated to be in /bin. However, *every* program called from any distro-specific (i.e. not user-made) init script that runs prior to mounting /usr becomes mandated by necessity. Here is the exact rationale for these types of programs (from the FHS): <snip> /bin contains commands that may be used by both the system administrator and by users, but which are required when no other filesystems are mounted (e.g. in single user mode). It may also contain commands which are used indirectly by scripts. </snip> That last sentence leaves a lot of room for interpretation which is why Arch cannot conform to all other distros. They all do things slightly differently themselves.sed on how they wrote their init scripts. You can also determine this from the other perspective of what should be in /usr/bin instead of what should be in /bin. Here's the footnote in the FHS for /bin: <snip> Command binaries that are not essential enough to place into /bin must be placed in /usr/bin, instead. Items that are required only by non-root users (the X Window System, chsh, etc.) are generally not essential enough to be placed into the root partition. </snip> -- Jeff My other computer is an abacus.
I think I found a solution for this path issue: http://mailman.archlinux.org/pipermail/pacman-dev/2010-February/010449.html Cedric
participants (4)
-
Allan McRae
-
Cedric Staniewski
-
Jeff
-
Xavier Chantry