tcsh & nss_ldap problem

[Artem Kazakov]

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.