From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 98BCE1381F3 for ; Sun, 14 Apr 2013 11:26:34 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 00B54E0A01; Sun, 14 Apr 2013 11:26:29 +0000 (UTC) Received: from foo.stuge.se (foo.stuge.se [212.116.89.98]) by pigeon.gentoo.org (Postfix) with ESMTP id C0520E09B5 for ; Sun, 14 Apr 2013 11:26:27 +0000 (UTC) Received: (qmail 6223 invoked by uid 501); 14 Apr 2013 11:26:26 -0000 Message-ID: <20130414112626.6222.qmail@stuge.se> Date: Sun, 14 Apr 2013 13:26:26 +0200 From: Peter Stuge To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] [PATCH eutils] Support recursive operation in edos2unix. Mail-Followup-To: gentoo-dev@lists.gentoo.org References: <1365864260-1606-1-git-send-email-mgorny@gentoo.org> <20130414103705.1744.qmail@stuge.se> <20130414124640.667de0e3@pomiocik.lan> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="9hshNW4m6zn79FF/" Content-Disposition: inline In-Reply-To: <20130414124640.667de0e3@pomiocik.lan> X-Archives-Salt: 767070c7-c274-49fc-8840-b868b6ac9581 X-Archives-Hash: e5af1e153fee3d624b9ea03641be35d4 --9hshNW4m6zn79FF/ Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Micha=C5=82 G=C3=B3rny wrote: > > > Any thoughts? > >=20 > > If doing this at all I think it should take an -r option to enable > > the new recursion, for symmetry with the do* functions and for > > backwards compatibility. >=20 > Backwards compatibility with what? With the old non-recursive behavior of edos2unix that could only operate on a single file. Arguably, all old users *should* have refered to single files, but I would still prefer adding a -r just to be sure to avoid collateral damage. //Peter --9hshNW4m6zn79FF/ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iD8DBQFRapJihR3Q0dhIfEgRAsAvAJoCZyljo1yKBHqKFW6XI/WIe/rUVgCffYlz vFFIe5NX5GCYeAgDSBhK4dU= =OP5P -----END PGP SIGNATURE----- --9hshNW4m6zn79FF/--