Bug 154395 - zsh referenced to /usr/ ..
zsh referenced to /usr/ ..
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: zsh (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Colin Walters
Mike McLean
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-04-11 10:07 EDT by Mario Mikocevic
Modified: 2007-11-30 17:11 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-09-11 18:32:53 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Mario Mikocevic 2005-04-11 10:07:20 EDT
Description of problem:

# ldd /bin/zsh
        libdl.so.2 => /lib/libdl.so.2 (0x00be8000)
        libnsl.so.1 => /lib/libnsl.so.1 (0x03c37000)
        libncurses.so.5 => /usr/lib/libncurses.so.5 (0x005c5000)
Eh ??                      ^^^^^

        libtermcap.so.2 => /lib/libtermcap.so.2 (0x00d56000)
        libm.so.6 => /lib/tls/libm.so.6 (0x00bc3000)
        libc.so.6 => /lib/tls/libc.so.6 (0x00a97000)
        /lib/ld-linux.so.2 (0x00a7e000)

with this zsh is unuseable as rescue shell ..
Comment 1 Dmitry Bolkhovityanov 2005-07-26 04:18:43 EDT
I'll second that.

First, /*bin*/zsh should NOT depend on /*usr*/... -- this violates the
principles of separation between / (/{bin,sbin,lib}) and /usr (/usr/{bin,sbin,lib}).

Second, if zsh is set as root's shell (chsh -s /bin/zsh root), which is quite
legitimate, the "repair shell" stops working, since root's shell is started for
repair, not /bin/sh.  (Yes, I know about init=/bin/sh, but that's not an option
for a "typical" user.)

Version is zsh-4.2.0-3
Comment 2 Matthew Miller 2006-07-10 19:28:04 EDT
Fedora Core 3 is now maintained by the Fedora Legacy project for security
updates only. If this problem is a security issue, please reopen and
reassign to the Fedora Legacy product. If it is not a security issue and
hasn't been resolved in the current FC5 updates or in the FC6 test
release, reopen and change the version to match.

Thank you!
Comment 3 Dmitry Bolkhovityanov 2006-07-12 06:10:10 EDT
Yes, this IS STILL AN ISSUE in FC5:

% uname -a
Linux zzz.zzz.nsk.su 2.6.17-1.2139_FC5smp #1 SMP Fri Jun 23 13:12:06 EDT 2006
i686 i686 i386 GNU/Linux
%cat /etc/fedora-release 
Fedora Core release 5 (Bordeaux)
% ldd /bin/zsh
        linux-gate.so.1 =>  (0x00354000)
        libdl.so.2 => /lib/libdl.so.2 (0x004a7000)
        libnsl.so.1 => /lib/libnsl.so.1 (0x006fb000)
        libncurses.so.5 => /usr/lib/libncurses.so.5 (0x0055b000)
                           ^^^^
        libtermcap.so.2 => /lib/libtermcap.so.2 (0x00206000)
        libm.so.6 => /lib/libm.so.6 (0x004ad000)
        libc.so.6 => /lib/libc.so.6 (0x00372000)
        /lib/ld-linux.so.2 (0x00355000)
Comment 4 Dmitry Bolkhovityanov 2006-07-12 06:13:50 EDT
BTW, why Bugzilla barks when I'm just trying to add a comment -- "You tried to
change the Keywords field from no value to FutureFeature, but only the owner or
submitter of the bug, or a sufficiently empowered user, may change that field."?
Somehow the FutureFeature appeared in "Keywords" field, but I wasn't allowed to
commit a comment without deleting that "default" value!
Comment 5 Dmitry Bolkhovityanov 2006-07-12 06:17:23 EDT
And, BTW, please somebody "enough empowered" change the version from fc3 to fc5
-- an "ordinary commenter" isn't allowed to.
Comment 6 Matthew Miller 2006-07-12 09:32:12 EDT
This is still the case in rawhide as well. I'm going to move this to devel,
because with FC6 imminent it's more likely to be fixed there than in FC5. The
Core package maintainer can put out updates for FC5 and FC4 if they judge it's
warranted.

While I agree this is a problem -- nothing in /bin should have dependencies in
/usr -- I think it's also pretty reasonable to declare that root's shell must
always be a Bourne shell derivative and that zsh as root's shell is unsupported.

(You want zsh with root powers? Use sudo....)

I took a quick look, and this may not really be trivial to fix, as there isn't a
simple "--disable-ncurses" configure option.
Comment 7 Dmitry Bolkhovityanov 2006-07-13 00:51:48 EDT
(In reply to comment #6)
> While I agree this is a problem -- nothing in /bin should have dependencies in
> /usr -- I think it's also pretty reasonable to declare that root's shell must
> always be a Bourne shell derivative and that zsh as root's shell is unsupported.
> 
> (You want zsh with root powers? Use sudo....)

NO!!! "sudo" is irrelevant here.
We (in our institute) ALWAYS set zsh to be root shell on our computers. Zsh is
way more smart than Bash, and it IS bash-compatible (it can be thought of as a
"superset of bash").
So, declaring that Zsh is unsupported as root shell is nonsense (and would be a
bit bill-gates'ish -- "you don't need this feature" :-).
This would cut functionality FOR NO GOOD REASON.

Please, please, please -- just FIX the bug.

(BTW, zsh-4.0.4 in RedHat-7.3 worked fine without curses (no surprise -- simple
termcap access is enough for a readline-like editing), so that's definitely a
way to go.)
Comment 8 Daniel Qarras 2006-09-05 15:35:29 EDT
FWIW, I reported this at:

http://www.zsh.org/mla/users/2006/msg00877.html
Comment 9 Daniel Qarras 2006-09-11 11:22:30 EDT
And, FWIW, probably as expected, this is said to a distribution problem:

http://www.zsh.org/mla/users/2006/msg00879.html

So we need to get RH's zsh/ncurses fixed. Thanks.
Comment 10 Christopher Aillon 2006-09-11 18:32:53 EDT
Appears fixed.

% rpm -q zsh
zsh-4.2.5-2
% ldd /bin/zsh
        linux-gate.so.1 =>  (0xb7f5e000)
        libdl.so.2 => /lib/libdl.so.2 (0x00c2d000)
        libnsl.so.1 => /lib/libnsl.so.1 (0x00235000)
        libtermcap.so.2 => /lib/libtermcap.so.2 (0x00880000)
        libm.so.6 => /lib/libm.so.6 (0x00c33000)
        libc.so.6 => /lib/libc.so.6 (0x00aee000)
        /lib/ld-linux.so.2 (0x00ad1000)

Note You need to log in before you can comment on or make changes to this bug.