Date: Wed, 24 May 2006 20:00:49 +0900 From: Artem Kazakov <kazakov@gmail.com> To: FreeBSD Hackers <freebsd-hackers@freebsd.org> Subject: tcsh & nss_ldap problem Message-ID: <1148468449.1745.27.camel@tyoma.linac.kek.jp>
next in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1148468449.1745.27.camel>