If emerging "sys-apps/grep", only /bin/grep is installed, no /usr/bin/grep. This is confusing, as all important (and text related) system utilities (sed, head, tail, ...) are found in /usr/bin. Additionally, in boot-time scripts /bin is not part of the search path, so all scripts that simply use "grep" instead of "/bin/grep" mysteriously fail. I think a symbolic link /usr/bin/grep --> /bin/grep should be added, as it is the case for cp, mv, cat, sed, head, ... Steps to reproduce: (1) emerge sys-apps/grep (2) ls /usr/bin/grep Actual result: ls: /usr/bin/grep: No such file or directory Expected result: /usr/bin/grep
Reopen with some error messages from your "mysteriously failing" init scripts and emerge --info. I have yet to see a single init script to fail bacause of this, besides the fact that my /usr is on LVM2 volume and there are people using NFS for this, where such symlink is completely useless until the boot is half over, yet their boxes boot just fine.
Sorry, I didn't make it clear enough what I'm concerned about. I thought about user-written shell scripts being started while booting; this includes, e.g., commands included into /etc/conf.d/local.start (I didn't mean to say "in runlevel 'boot'"). If you simply use "grep" in such a script it won't work. Dou you mean *all* scripts that *might* be used while loading daemons (e.g. in /etc/conf.d/local.*) have to *fully qualify* all the tools they use (bin/rm, /bin/cat, /bin/sed, /bin/grep etc.), to make sure they are found? Or do you propose something like "export PATH=/bin:$PATH" at the very start of such scripts? I simply encountered this situation with my own scripts and wondered why there is /usr/bin/sed but not /usr/bin/grep.
user-written scripts = user responsibility; don't see why we should be symlinking stuff to /usr/bin because of this.
The sed-4.1.4-ebuild has: rm -f "${D}"/usr/bin/sed dosym /bin/sed /usr/bin/sed what means that explicit symbolic links *are* provided for other basic packages. So why not for grep?
removed /usr/bin/sed symlink
