From owner-freebsd-stable Sat Sep 15 17:43:26 2001 Delivered-To: freebsd-stable@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.22.40]) by hub.freebsd.org (Postfix) with ESMTP id ACBF937B405; Sat, 15 Sep 2001 17:43:15 -0700 (PDT) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.11.3/8.11.3) with ESMTP id f8G0h9t24496; Sat, 15 Sep 2001 20:43:09 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <20010915124611.A6536@titan.klemm.gtn.com> References: <20010915124611.A6536@titan.klemm.gtn.com> Date: Sat, 15 Sep 2001 20:43:05 -0400 To: Andreas Klemm , freebsd-stable@FreeBSD.ORG From: Garance A Drosihn Subject: Re: small bug in lpc's interactive mode when performing "restart all" Cc: freebsd-print@bostonradio.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG At 12:46 PM +0200 9/15/01, Andreas Klemm wrote: >If I use the interactive mode of lpc, then I get the syslog >message: > >Sep 15 12:44:12 titan lpd[6598]: unknown printer: xterm > >root@titan[ttyp2]{102} ~ lpc >lpc> restart all >xterm: > cannot open lock file >xterm: > couldn't start daemon > [...etc...] In a follow up message to me, Andreas writes; >After digging around more ... seems to be a csh/tcsh configuration >problem, since ... > >su - toor, which uses /bin/sh, doesn't show this effect. > >Hmm, a tcsh without my own .cshrc and .login doesn't have this >problem as well. It's not in .login .. its in .cshrc. >Well, have to go to bed now, seems to be my roots environment :-/ Well, I've done some digging of my own, and while I am not quite sure why this just because a problem, I do see the same behavior, and I do have a basic idea of what the problem is. When 'lpc' is in interactive mode, it calls EditLine so it can do history-processing. Something in that will call a routine called cgetset(), with the intention of adding a capability-database to *termcap* processing. However, the way these getcap-routines work, that cgetset() call will also effect printcap processing. I have a fix to lpc/lpc.c which adds a call to cgetset(NULL) after the call to el_source(...), and this fixes the problem you're seeing, and does not seem to break anything in interactive processing. I will commit this to current soon, unless someone knows of a reason I should not do that... -- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message