From owner-freebsd-hackers@FreeBSD.ORG Wed May 24 11:01:52 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D97FD16A41F for ; Wed, 24 May 2006 11:01:52 +0000 (UTC) (envelope-from kazakov@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.178]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6CAA843D49 for ; Wed, 24 May 2006 11:01:52 +0000 (GMT) (envelope-from kazakov@gmail.com) Received: by py-out-1112.google.com with SMTP id f28so2031970pyf for ; Wed, 24 May 2006 04:01:51 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:subject:from:to:content-type:date:message-id:mime-version:x-mailer:content-transfer-encoding; b=Jz6Ag62SKLYpFJ//0Eh7KQjRSg8ka5c6U2hyYd1Hrf37iAuU3c7IJy03mEFPKi+UZpGsWuMzPkBjbSSTtWZfqmWYTiYxzKfFIwQOSBJaMW2c0qmpFkBqP9VnEqjMDg3FmPvp3yqCOQiUIVYAIPsGfRDvmmEz2sxOnYv90AH0/rk= Received: by 10.35.81.10 with SMTP id i10mr919018pyl; Wed, 24 May 2006 04:01:42 -0700 (PDT) Received: from tyoma.kek.jp ( [130.87.161.100]) by mx.gmail.com with ESMTP id w66sm1553094pyw.2006.05.24.04.01.40; Wed, 24 May 2006 04:01:41 -0700 (PDT) From: Artem Kazakov To: FreeBSD Hackers Content-Type: text/plain Date: Wed, 24 May 2006 20:00:49 +0900 Message-Id: <1148468449.1745.27.camel@tyoma.linac.kek.jp> Mime-Version: 1.0 X-Mailer: Evolution 2.4.2.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Subject: tcsh & nss_ldap problem X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 May 2006 11:01:52 -0000 Dear All, I don't know if this should go here, point me to the right place. But it looks like a problem (bug?) in tcsh. The story started from this pr: http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/77574 While debugging I realized that the problem is because of the way tcsh manages descriptors. So, the problem is: when you use nss_ldap, and it has persistent connections enabled. You type somthing like : $ cd ~ab[tab] At this point a lookup through nss_ldap is made. At the moment descriptors 0,1,2 are free. So when nss_ldap makes a call to socket() it returns 1 (0 is used for logging if I get it right, and 2 is used too then). And as connection stays open the descriptor is still held and descriptor id = 1; So then you issue a command: $ cd ~abc[enter] at this point, tcsh makes call to doio() - as I understand this function should set proper descriptors for pipe, io-redirection etc. And here is the code: doio(t, pipein, pipeout) struct command *t; int *pipein, *pipeout; { .... (void) close(0); (void) dup(OLDSTD); .... (void) close(1); (void) dup(SHOUT); .... (void) close(2); if (flags & F_STDERR) { (void) dup(1); is2atty = is1atty; } else { (void) dup(SHDIAG); is2atty = isdiagatty; .... So, descriptors 1,2,3 were closed and then dup()ed. And after that a lookup through nss_ldap is done again (we issued a command cd ~abc) But it thinks that connection is still alive, and when it calls write() all the data goes to terminal, instead of socket. Which is definitely is not the result we wanted to get. Also shell error output goes to syslog instead of terminal, because descriptor no 2 was dup()ed against SHDIAG which is 0; and 0 descriptor was previosly used by nss_ldap for logging. Ok, what next? Current workaround exists, you just have not to use persistent connections with nss_ldap. But tcsh should be fixed, I suppose. I'm not familiar with tcsh code, so can't do that. Cheers, Artem Kazakov.