Bug 105886 - tcsh shows garbage, loses prompt when attempting tilde (~) expansion using LDAP
Summary: tcsh shows garbage, loses prompt when attempting tilde (~) expansion using LDAP
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: nss_ldap (Show other bugs)
(Show other bugs)
Version: 4.4
Hardware: i686 Linux
Target Milestone: ---
: ---
Assignee: Nalin Dahyabhai
QA Contact: Kevin Baker
Depends On:
TreeView+ depends on / blocked
Reported: 2003-09-29 00:41 UTC by Alan
Modified: 2014-12-01 23:08 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2012-06-20 16:02:36 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Alan 2003-09-29 00:41:37 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703

Description of problem:
attempting to change directory to a user account that is served from an openLDAP
server (local or remote) causes tcsh to display garbage from the user's entry. 

[5:26pm] root@file:~> cd ~j2
`a``a``` (�
                       posixAccount�    cbuidcaj20icbuidc
0a`cB[5:26pm] root@file:~j2>

in order to restore the prompt a control-D must be given.  quite often the
terminal also needs to be reset (control-v,control-o).

Version-Release number of selected component (if applicable):
tcsh-6.12-4, openldap-2.0.27-8, nss_ldap-202-5

How reproducible:

Steps to Reproduce:
1.  use authconfig to authenticate some user accounts only to LDAP
2.  use a tcsh interactive shell (I did not test in scripts)
3.  attempt to cd to user's home directory using `cd ~username`

Actual Results:  Termincal shows 9-12 lines of garbage apparently retrieved from
the LDAP entry in question.  directory is changed but prompt is not restored.  

Expected Results:  change to user's directory without incident.

Additional info:

bash has never shown this behavior, so I take it to be a tcsh bug, though it
could also be a bug in the way tcsh interacts with nss_ldap.  

switching deeper into a user's home directory (say, ~user/public_html) almost
never causes this bug, only switching to the actual home directory.  

also, after a user has been accessed once it generally does not freak out again
with that user in the same session (caching?).

Comment 1 Miloslav Trmač 2004-09-15 01:55:11 UTC
tcsh-6.13-6 contains a bug fix that could cause such behavior.
I have not been able to reproduce the bug, nevertheless
please test tcsh-6.13-6 when it appears in rawhide, which
should happen after FC3t2 is released.

Comment 2 Alan 2006-02-22 04:03:57 UTC
I have tested this with tcsh-6.13-9 in a RHEL4 environment and it still exibihts
the same problem.  upgraded nss_ldap and openldap as well.

it only seems to happen once per interactive login session.  the problem seems
to be with retreiving the directory name itself, as it doesn't matter whether
the home directory is mounted or not for the bug to manifest.

Comment 3 Alan 2006-05-16 00:55:13 UTC
Upgraded to RHEL 4.3 on LDAP server and new client.  all newest patches (still
tcsh 6.13-9).  error has now changed:

free(86fb14d) bad block. (memtop = 879c000 membot = 86ed000)

and seems to produce terminal garbage less often.

Comment 4 Bill Nottingham 2006-08-05 03:02:47 UTC
Red Hat apologizes that these issues have not been resolved yet. We do want to
make sure that no important bugs slip through the cracks.

Red Hat Linux 7.3 and Red Hat Linux 9 are no longer supported by Red Hat, Inc.
They are maintained by the Fedora Legacy project (http://www.fedoralegacy.org/)
for security updates only. If this is a security issue, please reassign to the
'Fedora Legacy' product in bugzilla. Please note that Legacy security update
support for these products will stop on December 31st, 2006.

If this is not a security issue, please check if this issue is still present
in a current Fedora Core release. If so, please change the product and version
to match, and check the box indicating that the requested information has been

If you are currently still running Red Hat Linux 7.3 or 9, please note that
Fedora Legacy security update support for these products will stop on December
31st, 2006. You are strongly advised to upgrade to a current Fedora Core release
or Red Hat Enterprise Linux or comparable. Some information on which option may
be right for you is available at http://www.redhat.com/rhel/migrate/redhatlinux/.

Any bug still open against Red Hat Linux 7.3 or 9 at the end of 2006 will be
closed 'CANTFIX'. Again, if this bug still exists in a current release, or is a
security issue, please change the product as necessary. We thank you for your
help, and apologize again that we haven't handled these issues to this point.

Comment 5 Alan 2006-09-08 07:39:02 UTC
ok, I changed the product/version to RHEL4.4 and verified it exists yet today

Comment 6 Alan 2008-06-03 21:10:35 UTC
this bug is NOT present in RHEL5...

Comment 7 Dario Anzani 2008-10-03 10:13:44 UTC
A customer is complaining the same exact problem with RHEL 5.1 and an updated nss_ldap package (v 253-12.el5). The problem seems to don't appear with 5.1 iso package (v 253-5.el5).

Comment 9 Jiri Pallich 2012-06-20 16:02:36 UTC
Thank you for submitting this issue for consideration in Red Hat Enterprise Linux. The release for which you requested us to review is now End of Life. 
Please See https://access.redhat.com/support/policy/updates/errata/

If you would like Red Hat to re-consider your feature request for an active release, please re-open the request via appropriate support channels and provide additional supporting details about the importance of this issue.

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