From owner-cvs-all Mon Oct 28 10:36:35 2002 Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6198E37B401; Mon, 28 Oct 2002 10:36:33 -0800 (PST) Received: from thuvia.demon.co.uk (thuvia.demon.co.uk [193.237.34.248]) by mx1.FreeBSD.org (Postfix) with ESMTP id B755D43E4A; Mon, 28 Oct 2002 10:36:31 -0800 (PST) (envelope-from mark@thuvia.demon.co.uk) Received: from dotar.thuvia.org (dotar.thuvia.org [10.0.0.4]) by phaidor.thuvia.org (8.12.3/8.12.3) with ESMTP id g9SIaTcF060482; Mon, 28 Oct 2002 18:36:29 GMT (envelope-from mark@thuvia.demon.co.uk) Received: from dotar.thuvia.org (localhost [IPv6:::1]) by dotar.thuvia.org (8.12.6/8.12.6) with ESMTP id g9SIaSH5071724; Mon, 28 Oct 2002 18:36:28 GMT (envelope-from mark@dotar.thuvia.org) Received: (from mark@localhost) by dotar.thuvia.org (8.12.6/8.12.6/Submit) id g9SIaSDW071723; Mon, 28 Oct 2002 18:36:28 GMT Date: Mon, 28 Oct 2002 18:36:28 GMT From: Mark Valentine Message-Id: <200210281836.g9SIaSDW071723@dotar.thuvia.org> In-Reply-To: <200210281630.g9SGUnMb040700@khavrinen.lcs.mit.edu> X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: Garrett Wollman Subject: Re: cvs commit: src/bin/expr expr.1 expr.y src/include unistd.h src/lib/libc/gen Makefile.inc check_utility_compat.3 check_utility_compat.c Cc: cvs-committers@freebsd.org, cvs-all@freebsd.org Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > From: Garrett Wollman > Date: Mon 28 Oct, 2002 > Subject: Re: cvs commit: src/bin/expr expr.1 expr.y src/include unistd.h src/lib/libc/gen Makefile.inc check_utility_compat.3 check_utility_compat.c > < said: > > > The /etc/compat-FreeBSD-4-util symlink feature of this function is too > > dangerous - it will break any scripts run anywhere on the system which > > expect the default behaviour. > > No, it will only break those scripts which *require* the POSIX > behavior. Uh, I thought that's what I said. Sorry if my language was imprecise. > As I have told you about ten times now, the intersection of > the two (in the case of `expr' in particular) is large enough, and the > syntax of `expr' so restricted, that most scripts should not care. If you need to use this compatibility feature, you've already wandered outside of that intersection. If nothing's going to use the POSIX functionality, why is it implemented, and why is it the default, unnecessarily breaking legacy scripts? This utility function changes nothing with respect to supporting legacy scripts. I've asked how I can use the current compatibility functionality to actually make legacy scripts work again, as I don't see a practical way to do so. I've implemented a scheme which I think does work, and addresses the sort(1) issue which is still unresolved. You've seen with sort(1) that moving to incompatible POSIX behaviour by default is just too painful. Sort(1) and expr(1) aren't going to be the end of the story either. My scheme (inspired by a proven implementation in Solaris) addresses both the legacy script issue and allows the introduction of full-blown POSIX.1 functionality. Your objection is that it means you have to take special steps to get a POSIX environment. That's regrettable, but I think necessary, and I am willing to put work in to document and encourage the use of the POSIX environment over the legacy environment. Cheers, Mark. -- Mark Valentine, Thuvia Labs "Tigers will do ANYTHING for a tuna fish sandwich." Mark Valentine uses "We're kind of stupid that way." *munch* *munch* and endorses FreeBSD -- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message