From owner-freebsd-current Fri Dec 20 15:00:08 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id PAA13964 for current-outgoing; Fri, 20 Dec 1996 15:00:08 -0800 (PST) Received: from skynet.ctr.columbia.edu (skynet.ctr.columbia.edu [128.59.64.70]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id PAA13950 for ; Fri, 20 Dec 1996 15:00:02 -0800 (PST) Received: (from wpaul@localhost) by skynet.ctr.columbia.edu (8.6.12/8.6.9) id RAA01382; Fri, 20 Dec 1996 17:57:45 -0500 From: Bill Paul Message-Id: <199612202257.RAA01382@skynet.ctr.columbia.edu> Subject: Re: tcsh NIS strangeness To: kuku@gilberto.physik.rwth-aachen.de Date: Fri, 20 Dec 1996 17:57:44 -0500 (EST) Cc: current@freebsd.org In-Reply-To: <199612202231.XAA05368@gilberto.physik.rwth-aachen.de> from "Christoph Kukulies" at Dec 20, 96 11:31:01 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Of all the gin joints in all the towns in all the world, Christoph Kukulies had to walk into mine and say: > [ yplib.c patch] > > > I compiled a new tcsh with a replacment yplib.o that has this patch and > > put in in place of the old one on ftp.ctr.columbia.edu:/pub/misc/freebsd. > > If you can test it for me and confirm that it works, or apply the patch > > I just downloaded it, and copied it over to the machine in question. > Logged in (with old tcsh - the ports compiled one), ls ~jolitz - nothing. > ./tcsh.6.07.02 > bach> ls ~jolitz > > yep foo baz > > everything there. So did the 'un-ported' version of tcsh.6.07.02 as of > yesterday which I grabbed from your site. Hm, I'm confused. Are you saying it works or are you saying it's still broken? :) The correct way to test it is to log in using the patched tcsh binary that I gave you as the default login shell. When I first reproduced the bug, I did it by logging in and typing ~ls someuser immediately before issuing any other commands. This pattern always held: each time I logged in, the bug would manifest. (As you noted, it goes away if you do a cd ~someuser later.) I tested the patched version by moving the broken /bin/tcsh to /bin/tcsh.bad and putting the new tcsh in place as /bin/tcsh. Then I logged out and logged back in again and tried to do an ls ~someuser again to duplicate the bug. With the patched version, the bug didn't show up and ls worked correctly. In other words, you need to really install the new tcsh and log in again in order to test the patch correctly: if you log in with the old broken tcsh and then run the same broken binary again, the bug will _appear_ to go away, but will really still be there and it will show up again the next time you log in. > > and build a new libc.so, I would appreciate it. I have already committed > > this patch to -current, but I want to make sure it fixes your problem > > before I put it in the 2.2 branch. > > I will build a new libc.so.3.0 right now and I'll put it up to the > machine (which is 3.0 also and that NIX client machine I tested on). > BTW, the tcsh.6.07.02 is a shared version, so it ran against the unpatched > version of libc in the test above. > In the patched version I gave you, I linked yplib.o directly into the executable which overrides the yplib.o in libc.so, so this binary should work no matter what. Once you generate a patched libc.so.3.0, then the other binary which you compiled (and the first binary I gave you via FTP) should also work correctly. -Bill -- ============================================================================= -Bill Paul (212) 854-6020 | System Manager, Master of Unix-Fu Work: wpaul@ctr.columbia.edu | Center for Telecommunications Research Home: wpaul@skynet.ctr.columbia.edu | Columbia University, New York City ============================================================================= "It is not I who am crazy; it is I who am mad!" - Ren Hoek, "Space Madness" =============================================================================