Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.

Bug 154395

Summary: zsh referenced to /usr/ ..
Product: [Fedora] Fedora Reporter: Mario Mikocevic <mario.mikocevic>
Component: zshAssignee: Colin Walters <walters>
Status: CLOSED RAWHIDE QA Contact: Mike McLean <mikem>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: dqarras, d.yu.bolkhovityanov, mattdm
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-09-11 22:32:53 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description Mario Mikocevic 2005-04-11 14:07:20 UTC
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 08:18:43 UTC
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 23:28:04 UTC
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 10:10:10 UTC
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 10:13:50 UTC
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 10:17:23 UTC
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 13:32:12 UTC
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 04:51:48 UTC
(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 19:35:29 UTC
FWIW, I reported this at:

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

Comment 9 Daniel Qarras 2006-09-11 15:22:30 UTC
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 22:32:53 UTC
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)