From owner-freebsd-current Thu Nov 23 21:39:15 2000 Delivered-To: freebsd-current@freebsd.org Received: from guru.mired.org (okc-65-26-235-186.mmcable.com [65.26.235.186]) by hub.freebsd.org (Postfix) with SMTP id 81A3137B4CF for ; Thu, 23 Nov 2000 21:39:13 -0800 (PST) Received: (qmail 10987 invoked by uid 100); 24 Nov 2000 05:39:07 -0000 From: Mike Meyer MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14877.65275.744127.863828@guru.mired.org> Date: Thu, 23 Nov 2000 23:39:07 -0600 (CST) To: Alfred Perlstein Cc: current@FreeBSD.ORG Subject: Re: Confusing error messages from shell image activation In-Reply-To: <20001123110828.V18037@fw.wintelcom.net> References: <14876.48112.785320.465213@guru.mired.org> <20001123110828.V18037@fw.wintelcom.net> X-Mailer: VM 6.75 under 21.1 (patch 10) "Capitol Reef" XEmacs Lucid X-face: "5Mnwy%?j>IIV\)A=):rjWL~NB2aH[}Yq8Z=u~vJ`"(,&SiLvbbz2W`;h9L,Yg`+vb1>RG% *h+%X^n0EZd>TM8_IB;a8F?(Fb"lw'IgCoyM.[Lg#r\ Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Alfred Perlstein types: > * Mike Meyer [001122 22:41] wrote: > > Could I get some feedback on > http://www.freebsd.org/cgi/query-pr.cgi?pr=22755 >? It's just a > > one-line kernel patch with some attendant updates in the kernel and > > libc, but it makes dealing with broken #! scripts *much* saner, and no > > one has even seen fit to comment on it yet :-(. Thank you for taking time to look at it. > This patch may break compliance, ENOEXEC is the proper error code, Um - compliance with what, exactly? I know it breaks compliance with Unix standards for user friendliness, but that was the point. I also agree that ENOEXEC is the best currently existing error code - but for this it pretty much sucks. Exec returns other codes providing more informative error messages; adding one more shouldn't be a problem. > the shell should try to be a bit smarter about explaining why > ENOEXEC was returned. Um - not "the" shell; all of them. Given that the authors of some of them are worried about portability, doing so portably is probably important as well. That's why I decided it belonged in the kernel. Doing this means that all shells get the benefit of it without a source change, and the only change other than better error messages was if there is an executable with the same name behind a broken script in the path - and I *couldn't* convince myself that was a problem!