Comment 40 for bug 15051

I keep re-discovering this fundamental incompatibility between Ubunutu and other Linux distributions. I'd like to just clear up some items that are repeated several times by developers who have replied to this bug:

"Perl" is not involved here. PCRE is a broadly used RE library, and only happens to have started as an attempt to bring modern Perl RE features to other languages.

Also, while many tools exist which would allow users to search for PCRE-style patterns in text files, that does not address the problem, here: Ubuntu provides a command called "grep", but it fails to provide one of the most frequently used parameters to that command on other Linux platforms. This presents a fundamental incompatibility between Ubuntu and other Linux platforms.

The reason which was presented was one of decreasing the bloat in boot-time commands, but that doesn't hold any water; on the same machine, I have Fedora 9 and Ubuntu 8.04 installed. The Ubuntu /bin/grep is 99K. The fedora binary is 84K:

 $ ls -lh /bin/grep
 -rwxr-xr-x 1 root root 84K 2008-02-20 01:33 /bin/grep
 $ ldd /bin/grep
 linux-gate.so.1 => (0x00110000)
 libpcre.so.0 => /lib/libpcre.so.0 (0x009a8000)
 libc.so.6 => /lib/libc.so.6 (0x0083d000)
 /lib/ld-linux.so.2 (0x0081d000)

 $ ls -lh /bin/grep
 -rwxr-xr-x 1 root root 99K 2007-10-23 16:58 /bin/grep
 $ ldd /bin/grep
 linux-gate.so.1 => (0xb7f21000)
 libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7dc4000)
 /lib/ld-linux.so.2 (0xb7f22000)

Now, granted 1) this small difference is likely due to the version of grep under F9 being older than that under U8.04 and 2) libpcre is 165K, but that's less than 1/10th the size of the libraries we're already linking grep against, so again... what's the objection?

Another suggestion was having a /usr/bin/grep which supported the standard options, while /bin/grep could be a cut-down version for boot only. This was shot down because it would change behavior based on the ordering of PATH... which isn't quite accurate. What it would do is fail to meet the default expectation that the -P option would work when /bin was first in your path. If /usr/bin were first, then obviously all of the same commands that worked from /bin would continue to work. Picture, if you will, that this were the case. The confusion caused is exactly the same confusion that systems administrators and developers suffer when they attempt to use the same program from the same author in their shell scripts and Makefile on two distributions of the same operating system... If you feel that that situation is untenable, then you really have to feel that the current situation is as well, unless you're simply taking the provincial view that users should not expect core commands to behave the same between Linux distributions.

To circle back around to the question at hand: what breaks if libpcre is placed in /lib? Do we cross or even approach some critical threshold, or are we just resisting this change on the basis of a phantom concern?