From owner-cvs-all@FreeBSD.ORG Mon Oct 4 12:15:50 2004 Return-Path: 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 758EC16A52E; Mon, 4 Oct 2004 12:15:50 +0000 (GMT) Received: from aiolos.otenet.gr (aiolos.otenet.gr [195.170.0.23]) by mx1.FreeBSD.org (Postfix) with ESMTP id AD7A343D41; Mon, 4 Oct 2004 12:15:49 +0000 (GMT) (envelope-from keramida@freebsd.org) Received: from orion.daedalusnetworks.priv (host5.bedc.ondsl.gr [62.103.39.229])i94CFlCW027192; Mon, 4 Oct 2004 15:15:47 +0300 Received: from orion.daedalusnetworks.priv (orion [127.0.0.1]) i94CFlJA005019; Mon, 4 Oct 2004 15:15:47 +0300 (EEST) (envelope-from keramida@freebsd.org) Received: (from keramida@localhost)i94CFlxW005018; Mon, 4 Oct 2004 15:15:47 +0300 (EEST) (envelope-from keramida@freebsd.org) Date: Mon, 4 Oct 2004 15:15:47 +0300 From: Giorgos Keramidas To: Max Laier Message-ID: <20041004121547.GB4888@orion.daedalusnetworks.priv> References: <200410041126.i94BQ273055417@repoman.freebsd.org> <200410041351.13214.max@love2party.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200410041351.13214.max@love2party.net> cc: cvs-src@freebsd.org cc: src-committers@freebsd.org cc: cvs-all@freebsd.org cc: Dag-Erling Smorgrav Subject: Re: cvs commit: src/bin/rm rm.1 rm.c X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2004 12:15:50 -0000 On 2004-10-04 13:51, Max Laier wrote: > On Monday 04 October 2004 13:26, Dag-Erling Smorgrav wrote: > > Modified files: > > bin/rm rm.1 rm.c > > Log: > > Find out how flame-proof my underwear really is. > Other than that, this seems to be an outcome of the *ongoing* thread > in hackers. If there is any consensus in that thread, then it's that > every such goof should be conditionalized by a environment variable. > > Any particular reason for this change? Any added value in this warning > (I fail to see)? I do respect Dag-Erling's technical expertise a lot of times every day, but since I was the one who kindled the flames of the particular thread, I'm not comfortable at all with this change. Most of the replies in the thread were against, not for, the change in the behavior of rm(1). Even to patches that made it conditionalized by an environment variable and OFF by default! - Giorgos