From owner-freebsd-rc@FreeBSD.ORG Sat Feb 22 06:10:22 2014 Return-Path: Delivered-To: rc@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CA9DCC85; Sat, 22 Feb 2014 06:10:22 +0000 (UTC) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 92B1E15D8; Sat, 22 Feb 2014 06:10:22 +0000 (UTC) Received: from smarthost.fisglobal.com ([10.132.206.191]) by ltcfislmsgpa04.fnfis.com (8.14.5/8.14.5) with ESMTP id s1M6AKrV027230 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 22 Feb 2014 00:10:20 -0600 Received: from THEMADHATTER (10.242.181.54) by smarthost.fisglobal.com (10.132.206.191) with Microsoft SMTP Server id 14.3.174.1; Sat, 22 Feb 2014 00:10:18 -0600 From: Sender: Devin Teske To: "'Hiroki Sato'" , References: <7EAEF3AC-DB1B-4D3E-A156-E1E76B765990@jnielsen.net> <11c101cf2f6b$e3aee5d0$ab0cb170$@FreeBSD.org> <20140222.141935.520275210006153242.hrs@allbsd.org> In-Reply-To: <20140222.141935.520275210006153242.hrs@allbsd.org> Subject: RE: network.subr _aliasN handling Date: Fri, 21 Feb 2014 22:10:11 -0800 Message-ID: <122101cf2f94$bfd81b30$3f885190$@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQD/oYVXD9SxlXRVLBWss2BXwatWbAMtJr/rAe22RW0B8JRzmJwniLLA Content-Language: en-us X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.87, 1.0.14, 0.0.0000 definitions=2014-02-22_01:2014-02-21,2014-02-22,1970-01-01 signatures=0 Cc: rc@FreeBSD.org, dteske@FreeBSD.org X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Feb 2014 06:10:22 -0000 > -----Original Message----- > From: Hiroki Sato [mailto:hrs@FreeBSD.org] > Sent: Friday, February 21, 2014 9:20 PM > To: jhellenthal@dataix.net; dteske@FreeBSD.org > Cc: lists@jnielsen.net; rc@FreeBSD.org > Subject: Re: network.subr _aliasN handling > > wrote > in <11c101cf2f6b$e3aee5d0$ab0cb170$@FreeBSD.org>: > > dt> > dt> > dt> > -----Original Message----- > dt> > From: John Nielsen [mailto:lists@jnielsen.net] > dt> > Sent: Friday, February 21, 2014 9:06 AM > dt> > To: Devin Teske > dt> > Cc: Jason Hellenthal; rc@freebsd.org; net@freebsd.org > dt> > Subject: Re: network.subr _aliasN handling > dt> > > dt> > On Jan 4, 2014, at 4:25 AM, Teske, Devin > dt> > > dt> wrote: > dt> > > dt> > > On Jan 4, 2014, at 2:59 AM, Jason Hellenthal wrote: > dt> > > > dt> > >> I believe I know what you mean by that but in a way scares me > dt> > >> when > dt> you say > dt> > sort as in mixing up the original order they appear in which I > dt> > would > dt> find to be > dt> > really unattractive to most. > dt> > > > dt> > > It's not as scary as it sounds. > dt> > > > dt> > > The issue is that the variables are sorted alphabetically, > dt> > > instead of numerically. > dt> > > > dt> > > Let's take four words: foo1, foo2, foo10, and foo20. > dt> > > If you sort them alphabetically, you get: > dt> > > > dt> > > foo1 > dt> > > foo10 > dt> > > foo2 > dt> > > foo20 > dt> > > > dt> > > You'll notice this when doing a directory listing, as that too > dt> > > is sorted alphabetically. > dt> > > > dt> > > This is why "alias14" is run before "alias8" and "alias9". > dt> > > Because they are processed in alphabetically sorted order. I > dt> > > didn't do anything to sort the values, they came pre-sorted in alphabetic > order. > dt> > > > dt> > > If I simply throw in a "| sort -n", then it will change it to > dt> numerically sorted. > dt> > > As you might expect, numerically sorting the above list would > dt> > > result > dt> in: > dt> > > > dt> > > foo1 > dt> > > foo2 > dt> > > foo10 > dt> > > foo20 > dt> > > > dt> > > Trivial really. I'll throw a patch at you when I get some cycles > dt> (soon). > dt> > > dt> > Hi Devin, Jason- > dt> > > dt> > I've been behind on my mailing list e-mail for a while, but I > dt> > really > dt> like the idea > dt> > and the patch proposed here. I don't see anything like it in head > dt> > yet, > dt> so ... Ping? > dt> > :) > dt> > > dt> > JN > dt> > > dt> [Devin Teske] > dt> > dt> *** this time with attached patch.txt *** > dt> > dt> Hi JN, here's a new patch that incorporates numerical sorting as > dt> well as what the original patch set out to do ... make "gaps" > dt> possible (so that you could comment out an alias without having to > dt> renumber all the ones following). > dt> > dt> Give it a look, let me know what you think. > > +list_vars() > +{ > + set | { while read LINE; do > + var="${LINE%%=*}" > + case "$var" in > + "$LINE"|*[!a-zA-Z0-9_]*) continue ;; > + $1) echo $var > + esac > + done; } > +} > > This can be inconsistent with normalization of $_if in get_if_var() when [.-/+] > is included. > [Devin Teske] I'm not sure what you mean by "when [.-/+] is included". The line of code that reads as follows: "$LINE"|*[!a-zA-Z0-9_]*) continue ;; causes any line that is returned by "set" to be ignored if: a. it does not contain an "=" NB: by way of comparing $var to $LINE; $var asks to remove =* b. it contains any character that is not a valid shell variable NB: In other words, contains one or more characters that do not match a-z or A-Z or 0-9 or underscore (_) Are you saying that there was a plan to change get_if_var in some way that would make this not work? Because such a change would also violate variable naming rules in sh(1). > I have no strong opinion about fixing the sequence gap issue but > ifconfig_IF_aliases was meant for that. This behavior is well-known for a very > long time, so I was reluctant to change it. > [Devin Teske] I identified heavily with the issue of having to rename entries after commenting out an entry, only to later have to re-shuffle after un- commenting the same entry moments later. So seemed like a good time to fix that injustice. Yeah, I think we've all just been living with that one for a long time. -- Devin _____________ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you.