From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041111 Firefox/1.0 Description of problem: The 'bash' executable shipped with FC3 uses its internal readline. As a consequence, it uses the termcap database and it ignores the terminfo database. This is a bug: no program should only rely on termcap. To fix this problem, it suffices to link bash against the external readline library (with the --with-installed-readline configure option). Note that bash doesn't want to link against a libreadline older than 5.0; the libreadline shipped with FC3 is 4.3, so it should be upgraded first. Example of real-life problem caused by this bug: in a rxvt-unicode with the default installation options, the "Ctrl-l" key combination doesn't work as expected if you're running bash. Note that it works fine with zsh, which relies on terminfo rather than termcap. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: n/a Additional info:
You need bash to install readline, since that's how RPM scriptlets are run.
Created attachment 161819 [details] shared readline build; nothing interesting here.
Bug 253431 should implement readline without the `/bin/sh' dependency. I hope bash would get rebuilt with the shared readline afterwards.
The fix for bug #253431 will be pretty easy if bash is really going to use the system readline. An entry for readline will be added to info/dir file in the info package so post and preun scripts in readline package don't need to call install-info. Also, the library will have to be moved to /lib. However, there are performance reasons to not use the system readline. IIRC, the library has many relocations (impossible to fix without breaking API) and causes noticeable slowdown.
Created attachment 161911 [details] time(1) with a better precision. The problem is not due to the relocations. Relocations could be reduced by wrapping some of the libreadline function references into a wrapper: static int local_rl_newline (int a, int b) { return rl_newline (a, b); } cmap[x].function = rl_newline; -> change to -> cmap[x].function = local_rl_newline; Still the slowdown is due to the general kernel overhead of loading another shared object: runtime linker statistics: - total startup time in dynamic loader: 593808 clock cycles - time needed for relocation: 21576 clock cycles (3.6%) + total startup time in dynamic loader: 919908 clock cycles + time needed for relocation: 69444 clock cycles (7.5%) number of relocations: 0 - number of relocations from cache: 26 + number of relocations from cache: 652 number of relative relocations: 0 - time needed to load objects: 391356 clock cycles (65.9%) + time needed to load objects: 654432 clock cycles (71.1%) runtime linker statistics: final number of relocations: 15 -final number of relocations from cache: 26 +final number of relocations from cache: 652 Relocations cause those approx. 40000 clock cycles but still the 300000 clock cycles are spent due to the kernel syscalls overhead for another 3 libraries (libreadline + libhistory + libtinfo). The overall end-to-end run stats: prelinked static readline: 0.00271 sec prelinked shared readline: 0.00294 sec Tested on: bash -c 'exit' with a complete fork()/execlp()/waitpid(). This is the worst ever slowdown which can happen and it is 8.487%. As the user may notice only 0.2+ sec slowdown you would have to run empty bash 869+ times to make the user notice anything. It would run 2.35 sec with the original static-readline bash. Sure many commands could be sped up a bit by static builds but we are the Defining technology Company of the 21st Century. ;-)
Based on the date this bug was created, it appears to have been reported against rawhide during the development of a Fedora release that is no longer maintained. In order to refocus our efforts as a project we are flagging all of the open bugs for releases which are no longer maintained. If this bug remains in NEEDINFO thirty (30) days from now, we will automatically close it. If you can reproduce this bug in a maintained Fedora version (7, 8, or rawhide), please change this bug to the respective version and change the status to ASSIGNED. (If you're unable to change the bug's version or status, add a comment to the bug and someone will change it for you.) Thanks for your help, and we apologize again that we haven't handled these issues to this point. The process we're following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp We will be following the process here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this doesn't happen again.
This bug has been in NEEDINFO for more than 30 days since feedback was first requested. As a result we are closing it. If you can reproduce this bug in the future against a maintained Fedora version please feel free to reopen it against that version. The process we're following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp
Reopening. Though current bash uses terminfo, not termcap I still think our bash should use system readline. Thanks to Jan's profiling in comment #5, we may rest assured that there is no performance problem with that.
Jakub Jelinek has toldme this: The radline API uses lots of global variables, which make linking against it to expensive. The impact on /bin/bash startup might not be neglectable. Since bash is executed many times during startup and even when processing a more complicated shell script, one would have to be very careful about performance impact before dynamic link against readline. This convinces me that the potential gain is not worth the price of the investigation, so I'm undoing my yesterday reopen. Please note that the original reason for the suggestion was that bash used termcap back then, which is no longer true; it uses terminfo as all civilized citizens of todays Fedora world.