From owner-freebsd-hackers Tue Jan 30 7:41:16 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from modemcable101.200-201-24.mtl.mc.videotron.ca (modemcable140.61-201-24.mtl.mc.videotron.ca [24.201.61.140]) by hub.freebsd.org (Postfix) with SMTP id 03C1037B4EC for ; Tue, 30 Jan 2001 07:40:59 -0800 (PST) Received: (qmail 73850 invoked from network); 30 Jan 2001 15:40:58 -0000 Received: from cognac.local.mindstep.com (HELO cognac) (192.168.10.9) by jacuzzi.local.mindstep.com with SMTP; 30 Jan 2001 15:40:58 -0000 From: "Patrick Bihan-Faou" To: , Cc: Subject: RE: Bash2 removes SSH_CLIENT from the environment Date: Tue, 30 Jan 2001 10:42:18 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <1010130150609.AA70020.SM@nike.INS.CWRU.Edu> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi, > Bash uses the presence of SSH_CLIENT to decide whether or not to run the > shell startup files for a non-interactive shell (like it attempts to do > for rsh). The problem is that if the variable is exported, subsequent > invocations of non-interactive shells will source the startup files. A > lot of users find the former behavior desirable, and the latter > undesirable. > The tradeoff bash makes is to remove the export attribute from SSH_CLIENT > if it exists in the shell's initial environment. Users may always export > it explicitly. This is what I figured from reading the code, however not exporting SSH_CLIENT is not enough to really achieve this goal: bash looks for either SSH_CLIENT or SSH2_CLIENT to determine if it should run the startup scripts, but only SSH_CLIENT is cleared. Also the content of SSH_CLIENT may be of intereset (namely the remote IP) and I don't know how to retrieve that information after SSH_CLIENT has been clobbered. It seems to me that this is a hack that could have been easily avoided by using the value of SHLVL: if it is greater than 1, there is no need to re-execute the startup script... I'd be willing to implement this fix if people are interested in it. (note the discussion is only on freebsd-hackers from now on) Patrick. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message