Path: utzoo!attcan!uunet!lll-winken!indri!dogie.macc.wisc.edu!csd4.milw.wisc.edu!uxc!uxc.cso.uiuc.edu!m.cs.uiuc.edu!s.cs.uiuc.edu!carroll From: carroll@s.cs.uiuc.edu Newsgroups: comp.unix.questions Subject: Re: Unusual (?) problem with cd in ksh Message-ID: <216000014@s.cs.uiuc.edu> Date: 11 May 89 15:46:00 GMT References: <456@ics.COM> Lines: 27 Nf-ID: #R:ics.COM:456:s.cs.uiuc.edu:216000014:000:1609 Nf-From: s.cs.uiuc.edu!carroll May 11 10:46:00 1989 This is a problem with ksh-i. I fixed this a years or two ago, so my memory is a little shaky (I don't do sysadm'ing anymore, so I don't have access to the source anymore). There is a procedure called "comsubst" which does command substitution, which gets called during evaluation of `stuff`. It returns a pointer to a structure that describes the result. The bug is that when comsubst is called on the empty string (``), it returns a NULL pointer, which the routine which calls it doesn't check for - it just immediately de-references it. What happens then depends on the machine architecture. On the 3b family, location 0 is system memory but readable, so it just gets garbage, (always the same garbage), which ends up not doing anything (acceptable). On other systems (e.g., Sun's) location 0 is either not mapped or un-readable, so the dereference causes a core dump. The solution we came up with was to put a hack into comsubst that checked for the empty string, and changed it to ":" (a ksh-command that does nothing). I have no idea if this has been fixed in ksh-88 or not. I will try to persuade the current sysadmins to let me look and see what the fix was (we wrote all the details down when we fixed it). You can try email to them at bogia@m.cs.uiuc.edu or walquist@m.cs.uiuc.edu P.S. I sent Mr. Krell some email about this, but it must have sounded very incoherent - sorry about that. Alan M. Carroll "And there you are carroll@s.cs.uiuc.edu Saying 'We have the Moon, so now the Stars...'" CS Grad / U of Ill @ Urbana ...{ucbvax,pur-ee,convex}!s.cs.uiuc.edu!carroll