From owner-freebsd-rc@FreeBSD.ORG Mon Feb 17 11:06:55 2014 Return-Path: Delivered-To: freebsd-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 9307EDF6 for ; Mon, 17 Feb 2014 11:06:55 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7516411D3 for ; Mon, 17 Feb 2014 11:06:55 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id s1HB6tPY033198 for ; Mon, 17 Feb 2014 11:06:55 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s1HB6t46033196 for freebsd-rc@FreeBSD.org; Mon, 17 Feb 2014 11:06:55 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 17 Feb 2014 11:06:55 GMT Message-Id: <201402171106.s1HB6t46033196@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-rc@FreeBSD.org Subject: Current problem reports assigned to freebsd-rc@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: Mon, 17 Feb 2014 11:06:55 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o conf/185429 rc [rc.subr] ${name}_chroot does not work when there's a o conf/184355 rc [rc.firewall] [patch] ipfw failed to restart if tables o conf/181625 rc [patch] add rc.d/ script for freebsd-update o conf/180183 rc [rc.d] rc.d allows scripts without rcvar set to start o conf/179828 rc [rc.d] [PATCH] rc.d/syslogd link socket to /dev/log fa o conf/177217 rc [patch] rc.d/ddb -- squelch warning when ddb_enable=ye o conf/177089 rc ntpd startup script does not work well o conf/176347 rc [rc.conf] [patch] Add support for firewall deny lists o conf/176181 rc [rc.subr] rc.subr emitting warnings for non-defined xx o conf/175311 rc [patch] add "dump" fs type support to rc.d/dumpon o conf/175105 rc /etc/rc.d/* and more: syntax 'return_boolean_cmd && do o conf/175079 rc [rc.subr] [patch] rc.subr poorly handles recursive run o bin/173153 rc [rc.d] [patch] $netwait_ip should be more parallel o conf/172787 rc [rc.conf] FreeBSD 9.x broken alias syntax on vlan inte o conf/172532 rc [rc] [patch] service routing restart always fails o conf/169047 rc [rc.subr] [patch] /etc/rc.subr not checking some scrip p bin/168544 rc [patch] [rc]: addswap-mounted swapfiles cause panic on o conf/167566 rc [rc.d] [patch] ipdivert module loading vs. ipfw rc.d o o conf/166484 rc [rc] [patch] rc.initdiskless patch for different major o conf/165769 rc [rc][jai][ipv6] IPv6 Initialization on external iface o conf/164393 rc [rc.d] restarting netif with static addresses doesn't o conf/163508 rc [rc.subr] [patch] Add "enable" and "disable" commands o conf/163488 rc Confusing explanation in defaults/rc.conf o conf/163321 rc [rc.conf] [patch] allow _fib syntax in rc.conf o conf/162642 rc .sh scripts in /usr/local/etc/rc.d get executed, not s o conf/161107 rc [rc] stop_boot in mountcritlocal usage is incorrect. o conf/160403 rc [rc] [patch] concurrently running rc-scripts during bo o conf/160240 rc rc.d/mdconfig and mdconfig2 should autoset $_type to v o conf/159846 rc [rc.conf] routing_stop_inet6() logic doesn't handle ip o conf/158557 rc [patch] /etc/rc.d/pf broken messages o conf/158127 rc [patch] remount_optional option in rc.initdiskless doe o conf/153666 rc [rc.d][patch] mount filesystems from fstab over zfs da o conf/153200 rc post-boot /etc/rc.d/network_ipv6 start can miss neighb o conf/153123 rc [rc] [patch] add gsched rc file to automatically inser o conf/150474 rc [patch] rc.d/accounting: Add ability to set location o o conf/149867 rc [PATCH] rc.d script to manage multiple FIBS (kern opti o conf/149831 rc [PATCH] add support to /etc/rc.d/jail for delegating Z o conf/148656 rc rc.firewall(8): {oip} and {iip} variables in rc.firewa o conf/147685 rc [rc.d] [patch] new feature for /etc/rc.d/fsck o conf/147444 rc [rc.d] [patch] /etc/rc.d/zfs stop not called on reboot o conf/146053 rc [patch] [request] shutdown of jails breaks inter-jail o conf/145399 rc [patch] rc.d scripts are unable to start/stop programs o conf/145009 rc [patch] rc.subr(8): rc.conf should allow mac label con o conf/143637 rc [patch] ntpdate(8) support for ntp-servers supplied by o conf/143085 rc [patch] ftp-proxy(8) rc(8) with multiple instances a conf/142973 rc [jail] [patch] Strange counter init value in jail rc o conf/142434 rc [patch] Add cpuset(1) support to rc.subr(8) o conf/142304 rc rc.conf(5): mdconfig and mdconfig2 rc.d scripts lack e o conf/141909 rc rc.subr(8): [patch] add rc.conf.d support to /usr/loca o conf/141678 rc [patch] A minor enhancement to how /etc/rc.d/jail dete o conf/140440 rc [patch] allow local command files in rc.{suspend,resum o conf/140261 rc [patch] Improve flexibility of mdconfig2 startup scrip p conf/138208 rc [rc.d] [patch] Making rc.firewall (workstation) IPv6 a o conf/137271 rc [rc.d] Cannot update /etc/host.conf when root filesyst o conf/136624 rc [rc.d] sysctl variables for ipnat are not applied on b o conf/134918 rc [patch] rc.subr fails to detect perl daemons o conf/134660 rc [patch] rc-script for initializing ng_netflow+ng_ipfw o conf/134333 rc PPP configuration problem in the rc.d scripts in combi o conf/133890 rc [patch] sshd(8): add multiple profiles to the rc.d scr o conf/128299 rc [patch] /etc/rc.d/geli does not mount partitions using o conf/126392 rc [patch] rc.conf ifconfig_xx keywords cannot be escaped o conf/124747 rc [patch] savecore can't create dump from encrypted swap o conf/124248 rc [jail] [patch] add support for nice value for rc.d/jai o conf/123734 rc [patch] Chipset VIA CX700 requires extra initializatio o conf/123222 rc [patch] Add rtprio(1)/idprio(1) support to rc.subr(8). o conf/122968 rc [rc.d] /etc/rc.d/addswap: md swapfile multiplication a o conf/122477 rc [patch] /etc/rc.d/mdconfig and mdconfig2 are ignoring o conf/122170 rc [patch] [request] New feature: notify admin via page o o kern/121566 rc [nfs] [request] [patch] ethernet iface should be broug a conf/119874 rc [patch] "/etc/rc.d/pf reload" fails if there are macro o conf/119076 rc [patch] [rc.d] /etc/rc.d/netif tries to remove alias a o bin/118325 rc [patch] [request] new periodic script to test statuses f conf/118255 rc savecore never finding kernel core dumps (rcorder prob f conf/117935 rc [patch] ppp fails to start at boot because of missing f conf/113915 rc [ndis] [patch] ndis wireless driver fails to associate o conf/108589 rc rtsol(8) fails due to default ipfw rules o conf/106009 rc [ppp] [patch] [request] Fix pppoed startup script to p f conf/105689 rc [ppp] [request] syslogd starts too late at boot f conf/105145 rc [ppp] [patch] [request] add redial function to rc.d/pp f conf/104549 rc [patch] rc.d/nfsd needs special _find_processes functi o conf/102700 rc [geli] [patch] Add encrypted /tmp support to GELI/GBDE o conf/93815 rc [patch] Adds in the ability to save ipfw rules to rc.d f conf/92523 rc [patch] allow rc scripts to kill process after a timeo o conf/89870 rc [patch] [request] make netif verbose rc.conf toggle a conf/88913 rc [patch] wrapper support for rc.subr o conf/85819 rc [patch] script allowing multiuser mode in spite of fsc o kern/81006 rc ipnat not working with tunnel interfaces on startup o conf/77663 rc Suggestion: add /etc/rc.d/addnetswap after addcritremo o conf/73677 rc [patch] add support for powernow states to power_profi a conf/58939 rc [patch] dumb little hack for /etc/rc.firewall{,6} f conf/56934 rc [patch] rc.firewall rules for natd expect an interface f conf/13775 rc multi-user boot may hang in NIS environment 92 problems total. From owner-freebsd-rc@FreeBSD.ORG Fri Feb 21 17:05:41 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 91882CA5; Fri, 21 Feb 2014 17:05:41 +0000 (UTC) Received: from secure.freebsdsolutions.net (secure.freebsdsolutions.net [69.55.234.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6C6B8156D; Fri, 21 Feb 2014 17:05:38 +0000 (UTC) Received: from [10.10.1.198] (office.betterlinux.com [199.58.199.60]) (authenticated bits=0) by secure.freebsdsolutions.net (8.14.4/8.14.4) with ESMTP id s1LH5MB7069039 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 21 Feb 2014 12:05:22 -0500 (EST) (envelope-from lists@jnielsen.net) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Subject: Re: network.subr _aliasN handling From: John Nielsen In-Reply-To: Date: Fri, 21 Feb 2014 10:05:50 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7EAEF3AC-DB1B-4D3E-A156-E1E76B765990@jnielsen.net> References: <20131228055324.GA72764@aim7400.DataIX.local> <9498BE8E-8090-4E7A-8317-18D29B1DDC08@dataix.net> <7DBA7D58-E925-47BC-967C-F653348426A6@fisglobal.com> To: Devin Teske X-Mailer: Apple Mail (2.1827) X-DCC-x.dcc-servers-Metrics: ns1.jnielsen.net 104; Body=4 Fuz1=4 Fuz2=4 X-Virus-Scanned: clamav-milter 0.97.8 at ns1.jnielsen.net X-Virus-Status: Clean Cc: Jason Hellenthal , "rc@freebsd.org" , "net@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: Fri, 21 Feb 2014 17:05:41 -0000 On Jan 4, 2014, at 4:25 AM, Teske, Devin = wrote: > On Jan 4, 2014, at 2:59 AM, Jason Hellenthal wrote: >=20 >> I believe I know what you mean by that but in a way scares me when = you say sort as in mixing up the original order they appear in which I = would find to be really unattractive to most. >=20 > It's not as scary as it sounds. >=20 > The issue is that the variables are sorted alphabetically, instead > of numerically. >=20 > Let's take four words: foo1, foo2, foo10, and foo20. > If you sort them alphabetically, you get: >=20 > foo1 > foo10 > foo2 > foo20 >=20 > You'll notice this when doing a directory listing, as that too is = sorted > alphabetically. >=20 > This is why "alias14" is run before "alias8" and "alias9". Because = they > are processed in alphabetically sorted order. I didn't do anything to = sort > the values, they came pre-sorted in alphabetic order. >=20 > If I simply throw in a "| sort -n", then it will change it to = numerically sorted. > As you might expect, numerically sorting the above list would result = in: >=20 > foo1 > foo2 > foo10 > foo20 >=20 > Trivial really. I'll throw a patch at you when I get some cycles = (soon). Hi Devin, Jason- I've been behind on my mailing list e-mail for a while, but I really = like the idea and the patch proposed here. I don't see anything like it = in head yet, so ... Ping? :) JN >> On Jan 4, 2014, at 5:29, "Teske, Devin" = wrote: >>=20 >>>=20 >>> On Jan 3, 2014, at 10:28 PM, Jason Hellenthal wrote: >>>=20 >>>> Alright something is a little off about this from a running = standpoint it did what it is meant to do. >>>>=20 >>>> Bug1: it seems to have looped back over itself reissuing two = addresses from the top of the list. >>>>=20 >>>> Test case: >>>> I have aliases 0-14 used numbered as such. >>>> Aliases 0-7 are ipv6 >>>> Aliases 8-14 are ipv4 >>>>=20 >>>> I commented out alias 2 and 6 to break up consecutive order. >>>>=20 >>>> Alias 8 & 9 appeared to have been run after alias 14. >>>>=20 >>>>=20 >>>> Something is awry but I can't quite pick out what it is yet. >>>=20 >>>> On Dec 28, 2013, at 23:24, "Teske, Devin" = wrote: >>>>=20 >>>>> On Dec 27, 2013, at 9:53 PM, wrote: >>>>>=20 >>>>>> Curious what everyone's opinion would be on modifying the = handling of _aliasN functions or providing a wrapper around it to handle = non-sequential ordering. >>>>>>=20 >>>>>> My goal on this is simple and based around groupings similiar to = that of the way user id(1)'s in passwd and group are handled or denoted = for use on modern systems. >>>>>>=20 >>>>>> I.e.: I would like to achieve this... >>>>>>=20 >>>>>> *_alias[1-99] =3D System type addresses "Importand addresses or = internal" >>>>>> *_alias[100-199] =3D Aliases for interface 1 >>>>>> *_alias[200-299] =3D Aliases for interface 2 >>>>>> etc... >>>>>>=20 >>>>>> NOt looking to achieve some sort of prefered naming convention = for the interface aliases, but loosen them so they may be defined by the = user in whatever means neccesary to their benefit. >>>>>>=20 >>>>>> In a scheme similiar to above I attempted to set an address on = every other 4th alias leaving 3 space rule room for insertion of further = addresses but was surprised when the processing of the aliases ceased at = the first non-sequential space. >>>>>>=20 >>>>>> So why not just grab every _aliasN no matter of what it is for = the interface and shove them into an arrary to be processed by a "for" = statement ? the order would still be kept without having to inspect = every defintion of alias and incrementing prehistorically. >>>>>>=20 >>>>>> As well this could provide early loading of the addresses into = their respective arrays so they may be processed and provided to any = other functions that may need to access them earlier on in script = fallthrough. >>>>>>=20 >>>>>> Looking at _alias'N' sequentialy feels like a neucense. >>>>>=20 >>>>> You mean something like the attached? From owner-freebsd-rc@FreeBSD.ORG Fri Feb 21 17:16:18 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 9BD92344; Fri, 21 Feb 2014 17:16:18 +0000 (UTC) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EB6FA167E; Fri, 21 Feb 2014 17:16:17 +0000 (UTC) Received: by mail-lb0-f179.google.com with SMTP id l4so2513947lbv.38 for ; Fri, 21 Feb 2014 09:16:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8/3GiCUps9suVtxRZ6+6AN7qHJnb9M510gNWLiSLLqU=; b=TcqO+5I7EH99mKcxeYZC/f6y45CKVa/SAREmRsvCyM2MC6FpmK2WwDdW+l4Gq8wq8L L3PU7doTG5P5QV1sy0uTUJBYr96Ev/PjkwVpOKH8p9got+NBImxY61ruiSWM44Qz612T CvZXaFgukTWw1zCKBPXfORcGNNukCSmQU6wYbZqL11rxns7v7yXhh1WCIvGJxQANh6Xe f8/jnnonl9FE4DtZuyxqdgXPfmWTEnPoKqDMKSIK6EUBTJKsiI01tyPduNkhc774BCaq Ic0SzZUu9fhU7SPP9xOHaKIjQpxKgHKMLvQtIuOsiSVw+KuAkS9pMZseSzUYaGLWrZF7 b68g== MIME-Version: 1.0 X-Received: by 10.152.44.225 with SMTP id h1mr4888805lam.71.1393002975027; Fri, 21 Feb 2014 09:16:15 -0800 (PST) Received: by 10.112.35.167 with HTTP; Fri, 21 Feb 2014 09:16:14 -0800 (PST) In-Reply-To: References: <20131228055324.GA72764@aim7400.DataIX.local> <9498BE8E-8090-4E7A-8317-18D29B1DDC08@dataix.net> <7DBA7D58-E925-47BC-967C-F653348426A6@fisglobal.com> Date: Fri, 21 Feb 2014 17:16:14 +0000 Message-ID: Subject: Re: network.subr _aliasN handling From: Tom Evans To: Devin Teske Content-Type: text/plain; charset=UTF-8 Cc: "rc@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: Fri, 21 Feb 2014 17:16:18 -0000 On Sat, Jan 4, 2014 at 11:25 AM, Teske, Devin wrote: > On Jan 4, 2014, at 2:59 AM, Jason Hellenthal wrote: > >> I believe I know what you mean by that but in a way scares me when you say sort as in mixing up the original order they appear in which I would find to be really unattractive to most. >> > > It's not as scary as it sounds. > > The issue is that the variables are sorted alphabetically, instead > of numerically. > > Let's take four words: foo1, foo2, foo10, and foo20. > If you sort them alphabetically, you get: > > foo1 > foo10 > foo2 > foo20 > > You'll notice this when doing a directory listing, as that too is sorted > alphabetically. > > This is why "alias14" is run before "alias8" and "alias9". Because they > are processed in alphabetically sorted order. I didn't do anything to sort > the values, they came pre-sorted in alphabetic order. > > If I simply throw in a "| sort -n", then it will change it to numerically sorted. > As you might expect, numerically sorting the above list would result in: > > foo1 > foo2 > foo10 > foo20 > > Trivial really. I'll throw a patch at you when I get some cycles (soon). Wouldn't "|sort -n" sort foo10 before foo2? Cheers Tom From owner-freebsd-rc@FreeBSD.ORG Sat Feb 22 00:56:02 2014 Return-Path: Delivered-To: rc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 801BA664; Sat, 22 Feb 2014 00:56:02 +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 467E310E8; Sat, 22 Feb 2014 00:56:01 +0000 (UTC) Received: from smarthost.fisglobal.com ([10.132.206.193]) by ltcfislmsgpa02.fnfis.com (8.14.5/8.14.5) with ESMTP id s1M0ts06001150 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 21 Feb 2014 18:55:54 -0600 Received: from THEMADHATTER (10.242.181.54) by smarthost.fisglobal.com (10.132.206.193) with Microsoft SMTP Server id 14.3.174.1; Fri, 21 Feb 2014 18:55:52 -0600 From: Sender: Devin Teske To: "'Tom Evans'" References: <20131228055324.GA72764@aim7400.DataIX.local> <9498BE8E-8090-4E7A-8317-18D29B1DDC08@dataix.net> <7DBA7D58-E925-47BC-967C-F653348426A6@fisglobal.com> In-Reply-To: Subject: RE: network.subr _aliasN handling Date: Fri, 21 Feb 2014 16:55:46 -0800 Message-ID: <11b901cf2f68$d334f080$799ed180$@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: AQHDFDC1SCdF87KsAOMxpeOC5ZIl9wGCXs+0Atrl8x0A2Y7j4AImADvJAP+hhVcBgFtDBpqJwhfQ 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-21_06:2014-02-21,2014-02-21,1970-01-01 signatures=0 Cc: rc@freebsd.org, 'Devin Teske' 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 00:56:02 -0000 > -----Original Message----- > From: Tom Evans [mailto:tevans.uk@googlemail.com] > Sent: Friday, February 21, 2014 9:16 AM > To: Devin Teske > Cc: rc@freebsd.org > Subject: Re: network.subr _aliasN handling > > On Sat, Jan 4, 2014 at 11:25 AM, Teske, Devin > wrote: > > On Jan 4, 2014, at 2:59 AM, Jason Hellenthal wrote: > > > >> I believe I know what you mean by that but in a way scares me when you say > sort as in mixing up the original order they appear in which I would find to be > really unattractive to most. > >> > > > > It's not as scary as it sounds. > > > > The issue is that the variables are sorted alphabetically, instead of > > numerically. > > > > Let's take four words: foo1, foo2, foo10, and foo20. > > If you sort them alphabetically, you get: > > > > foo1 > > foo10 > > foo2 > > foo20 > > > > You'll notice this when doing a directory listing, as that too is > > sorted alphabetically. > > > > This is why "alias14" is run before "alias8" and "alias9". Because > > they are processed in alphabetically sorted order. I didn't do > > anything to sort the values, they came pre-sorted in alphabetic order. > > > > If I simply throw in a "| sort -n", then it will change it to numerically sorted. > > As you might expect, numerically sorting the above list would result in: > > > > foo1 > > foo2 > > foo10 > > foo20 > > > > Trivial really. I'll throw a patch at you when I get some cycles (soon). > > Wouldn't "|sort -n" sort foo10 before foo2? > [Devin Teske] "| sort -R" seems to work. Though I'm less than pleased with the explanation from the man-page... -R, --random-sort sort by random hash of keys but... say what? Produces foo1, foo2, foo10, foo20 -- as-is desired -- but, is this really what we want? I'm not sure I understand the above description -- can someone explain this a bit more? -- 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. From owner-freebsd-rc@FreeBSD.ORG Sat Feb 22 00:58:12 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 DA4667C3; Sat, 22 Feb 2014 00:58:11 +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 A0CB410F8; Sat, 22 Feb 2014 00:58:11 +0000 (UTC) Received: from smarthost.fisglobal.com ([10.132.206.192]) by ltcfislmsgpa06.fnfis.com (8.14.5/8.14.5) with ESMTP id s1M0wA2c007735 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 21 Feb 2014 18:58:10 -0600 Received: from THEMADHATTER (10.242.181.54) by smarthost.fisglobal.com (10.132.206.192) with Microsoft SMTP Server id 14.3.174.1; Fri, 21 Feb 2014 18:58:09 -0600 From: Sender: Devin Teske To: "'Tom Evans'" References: <20131228055324.GA72764@aim7400.DataIX.local> <9498BE8E-8090-4E7A-8317-18D29B1DDC08@dataix.net> <7DBA7D58-E925-47BC-967C-F653348426A6@fisglobal.com> <11b901cf2f68$d334f080$799ed180$@FreeBSD.org> In-Reply-To: <11b901cf2f68$d334f080$799ed180$@FreeBSD.org> Subject: RE: network.subr _aliasN handling Date: Fri, 21 Feb 2014 16:58:03 -0800 Message-ID: <11bb01cf2f69$2492dd70$6db89850$@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: AQHDFDC1SCdF87KsAOMxpeOC5ZIl9wGCXs+0Atrl8x0A2Y7j4AImADvJAP+hhVcBgFtDBgGyymkYmnwsnUA= 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-21_06:2014-02-21,2014-02-21,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 00:58:12 -0000 > -----Original Message----- > From: dteske@FreeBSD.org [mailto:dteske@FreeBSD.org] > Sent: Friday, February 21, 2014 4:56 PM > To: 'Tom Evans' > Cc: rc@freebsd.org; 'Devin Teske' > Subject: RE: network.subr _aliasN handling > > > > > -----Original Message----- > > From: Tom Evans [mailto:tevans.uk@googlemail.com] > > Sent: Friday, February 21, 2014 9:16 AM > > To: Devin Teske > > Cc: rc@freebsd.org > > Subject: Re: network.subr _aliasN handling > > > > On Sat, Jan 4, 2014 at 11:25 AM, Teske, Devin > > > > wrote: > > > On Jan 4, 2014, at 2:59 AM, Jason Hellenthal wrote: > > > > > >> I believe I know what you mean by that but in a way scares me when > > >> you > say > > sort as in mixing up the original order they appear in which I would > > find > to be > > really unattractive to most. > > >> > > > > > > It's not as scary as it sounds. > > > > > > The issue is that the variables are sorted alphabetically, instead > > > of numerically. > > > > > > Let's take four words: foo1, foo2, foo10, and foo20. > > > If you sort them alphabetically, you get: > > > > > > foo1 > > > foo10 > > > foo2 > > > foo20 > > > > > > You'll notice this when doing a directory listing, as that too is > > > sorted alphabetically. > > > > > > This is why "alias14" is run before "alias8" and "alias9". Because > > > they are processed in alphabetically sorted order. I didn't do > > > anything to sort the values, they came pre-sorted in alphabetic order. > > > > > > If I simply throw in a "| sort -n", then it will change it to > numerically sorted. > > > As you might expect, numerically sorting the above list would result in: > > > > > > foo1 > > > foo2 > > > foo10 > > > foo20 > > > > > > Trivial really. I'll throw a patch at you when I get some cycles (soon). > > > > Wouldn't "|sort -n" sort foo10 before foo2? > > > [Devin Teske] > > "| sort -R" seems to work. Though I'm less than pleased with the explanation > from the man-page... > > -R, --random-sort > sort by random hash of keys > > but... say what? Produces foo1, foo2, foo10, foo20 -- as-is desired -- but, is this > really what we want? I'm not sure I understand the above description -- can > someone explain this a bit more? HAH!, I should have re-executed the command to get the joke (on me). Just by chance, I gave it a go and it spat out (first run) foo1, foo2, foo10, foo20 (LoL). Second run of course gave something entirely different (gee, almost... random, LoL). Disregard ;D (LoL again) > -- > 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. From owner-freebsd-rc@FreeBSD.ORG Sat Feb 22 01:02:23 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 5CCE881E; Sat, 22 Feb 2014 01:02:23 +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 200C51180; Sat, 22 Feb 2014 01:02:22 +0000 (UTC) Received: from smarthost.fisglobal.com ([10.132.206.192]) by ltcfislmsgpa05.fnfis.com (8.14.5/8.14.5) with ESMTP id s1M12MM2008383 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 21 Feb 2014 19:02:22 -0600 Received: from THEMADHATTER (10.242.181.54) by smarthost.fisglobal.com (10.132.206.192) with Microsoft SMTP Server id 14.3.174.1; Fri, 21 Feb 2014 19:02:20 -0600 From: Sender: Devin Teske To: "'Tom Evans'" References: <20131228055324.GA72764@aim7400.DataIX.local> <9498BE8E-8090-4E7A-8317-18D29B1DDC08@dataix.net> <7DBA7D58-E925-47BC-967C-F653348426A6@fisglobal.com> In-Reply-To: Subject: RE: network.subr _aliasN handling Date: Fri, 21 Feb 2014 17:02:14 -0800 Message-ID: <11bd01cf2f69$ba7d5040$2f77f0c0$@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: AQHDFDC1SCdF87KsAOMxpeOC5ZIl9wGCXs+0Atrl8x0A2Y7j4AImADvJAP+hhVcBgFtDBpqJxCCg 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-21_06:2014-02-21,2014-02-21,1970-01-01 signatures=0 Cc: rc@freebsd.org, 'Devin Teske' 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 01:02:23 -0000 > -----Original Message----- > From: Tom Evans [mailto:tevans.uk@googlemail.com] > Sent: Friday, February 21, 2014 9:16 AM > To: Devin Teske > Cc: rc@freebsd.org > Subject: Re: network.subr _aliasN handling > > On Sat, Jan 4, 2014 at 11:25 AM, Teske, Devin > wrote: > > On Jan 4, 2014, at 2:59 AM, Jason Hellenthal wrote: > > > >> I believe I know what you mean by that but in a way scares me when you say > sort as in mixing up the original order they appear in which I would find to be > really unattractive to most. > >> > > > > It's not as scary as it sounds. > > > > The issue is that the variables are sorted alphabetically, instead of > > numerically. > > > > Let's take four words: foo1, foo2, foo10, and foo20. > > If you sort them alphabetically, you get: > > > > foo1 > > foo10 > > foo2 > > foo20 > > > > You'll notice this when doing a directory listing, as that too is > > sorted alphabetically. > > > > This is why "alias14" is run before "alias8" and "alias9". Because > > they are processed in alphabetically sorted order. I didn't do > > anything to sort the values, they came pre-sorted in alphabetic order. > > > > If I simply throw in a "| sort -n", then it will change it to numerically sorted. > > As you might expect, numerically sorting the above list would result in: > > > > foo1 > > foo2 > > foo10 > > foo20 > > > > Trivial really. I'll throw a patch at you when I get some cycles (soon). > > Wouldn't "|sort -n" sort foo10 before foo2? > [Devin Teske] Looks like what the OP wanted was "| sort -nk1.4" where the "4" is specific to "foo" prefix (we want sort to start on the 4th character of field 1; where the number starts). -- 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. From owner-freebsd-rc@FreeBSD.ORG Sat Feb 22 01:13:54 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 2EB31D58; Sat, 22 Feb 2014 01:13:54 +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 E4AD01270; Sat, 22 Feb 2014 01:13:53 +0000 (UTC) Received: from smarthost.fisglobal.com ([10.132.206.192]) by ltcfislmsgpa06.fnfis.com (8.14.5/8.14.5) with ESMTP id s1M1DqnW023534 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 21 Feb 2014 19:13:52 -0600 Received: from THEMADHATTER (10.242.181.54) by smarthost.fisglobal.com (10.132.206.192) with Microsoft SMTP Server id 14.3.174.1; Fri, 21 Feb 2014 19:13:50 -0600 From: Sender: Devin Teske To: "'John Nielsen'" References: <20131228055324.GA72764@aim7400.DataIX.local> <9498BE8E-8090-4E7A-8317-18D29B1DDC08@dataix.net> <7DBA7D58-E925-47BC-967C-F653348426A6@fisglobal.com> <7EAEF3AC-DB1B-4D3E-A156-E1E76B765990@jnielsen.net> In-Reply-To: <7EAEF3AC-DB1B-4D3E-A156-E1E76B765990@jnielsen.net> Subject: RE: network.subr _aliasN handling Date: Fri, 21 Feb 2014 17:13:44 -0800 Message-ID: <11bf01cf2f6b$5596b520$00c41f60$@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: AQHDFDC1SCdF87KsAOMxpeOC5ZIl9wGCXs+0Atrl8x0A2Y7j4AImADvJAP+hhVcDLSa/65p8YIxQ 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-21_06:2014-02-21,2014-02-21,1970-01-01 signatures=0 Cc: 'Jason Hellenthal' , rc@freebsd.org, 'Devin Teske' 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 01:13:54 -0000 > -----Original Message----- > From: John Nielsen [mailto:lists@jnielsen.net] > Sent: Friday, February 21, 2014 9:06 AM > To: Devin Teske > Cc: Jason Hellenthal; rc@freebsd.org; net@freebsd.org > Subject: Re: network.subr _aliasN handling > > On Jan 4, 2014, at 4:25 AM, Teske, Devin wrote: > > > On Jan 4, 2014, at 2:59 AM, Jason Hellenthal wrote: > > > >> I believe I know what you mean by that but in a way scares me when you say > sort as in mixing up the original order they appear in which I would find to be > really unattractive to most. > > > > It's not as scary as it sounds. > > > > The issue is that the variables are sorted alphabetically, instead of > > numerically. > > > > Let's take four words: foo1, foo2, foo10, and foo20. > > If you sort them alphabetically, you get: > > > > foo1 > > foo10 > > foo2 > > foo20 > > > > You'll notice this when doing a directory listing, as that too is > > sorted alphabetically. > > > > This is why "alias14" is run before "alias8" and "alias9". Because > > they are processed in alphabetically sorted order. I didn't do > > anything to sort the values, they came pre-sorted in alphabetic order. > > > > If I simply throw in a "| sort -n", then it will change it to numerically sorted. > > As you might expect, numerically sorting the above list would result in: > > > > foo1 > > foo2 > > foo10 > > foo20 > > > > Trivial really. I'll throw a patch at you when I get some cycles (soon). > > Hi Devin, Jason- > > I've been behind on my mailing list e-mail for a while, but I really like the idea > and the patch proposed here. I don't see anything like it in head yet, so ... Ping? > :) > > JN > [Devin Teske] Hi JN, here's a new patch that incorporates numerical sorting as well as what the original patch set out to do ... make "gaps" possible (so that you could comment out an alias without having to renumber all the ones following). Give it a look, let me know what you think. -- Devin NB: Below for context only. > >> On Jan 4, 2014, at 5:29, "Teske, Devin" wrote: > >> > >>> > >>> On Jan 3, 2014, at 10:28 PM, Jason Hellenthal wrote: > >>> > >>>> Alright something is a little off about this from a running standpoint it did > what it is meant to do. > >>>> > >>>> Bug1: it seems to have looped back over itself reissuing two addresses > from the top of the list. > >>>> > >>>> Test case: > >>>> I have aliases 0-14 used numbered as such. > >>>> Aliases 0-7 are ipv6 > >>>> Aliases 8-14 are ipv4 > >>>> > >>>> I commented out alias 2 and 6 to break up consecutive order. > >>>> > >>>> Alias 8 & 9 appeared to have been run after alias 14. > >>>> > >>>> > >>>> Something is awry but I can't quite pick out what it is yet. > >>> > >>>> On Dec 28, 2013, at 23:24, "Teske, Devin" > wrote: > >>>> > >>>>> On Dec 27, 2013, at 9:53 PM, wrote: > >>>>> > >>>>>> Curious what everyone's opinion would be on modifying the handling of > _aliasN functions or providing a wrapper around it to handle non-sequential > ordering. > >>>>>> > >>>>>> My goal on this is simple and based around groupings similiar to that of > the way user id(1)'s in passwd and group are handled or denoted for use on > modern systems. > >>>>>> > >>>>>> I.e.: I would like to achieve this... > >>>>>> > >>>>>> *_alias[1-99] = System type addresses "Importand addresses or > internal" > >>>>>> *_alias[100-199] = Aliases for interface 1 *_alias[200-299] = > >>>>>> Aliases for interface 2 etc... > >>>>>> > >>>>>> NOt looking to achieve some sort of prefered naming convention for > the interface aliases, but loosen them so they may be defined by the user in > whatever means neccesary to their benefit. > >>>>>> > >>>>>> In a scheme similiar to above I attempted to set an address on every > other 4th alias leaving 3 space rule room for insertion of further addresses but > was surprised when the processing of the aliases ceased at the first non- > sequential space. > >>>>>> > >>>>>> So why not just grab every _aliasN no matter of what it is for the > interface and shove them into an arrary to be processed by a "for" statement ? > the order would still be kept without having to inspect every defintion of alias > and incrementing prehistorically. > >>>>>> > >>>>>> As well this could provide early loading of the addresses into their > respective arrays so they may be processed and provided to any other functions > that may need to access them earlier on in script fallthrough. > >>>>>> > >>>>>> Looking at _alias'N' sequentialy feels like a neucense. > >>>>> > >>>>> You mean something like the attached? > > _______________________________________________ > freebsd-rc@freebsd.org mailing list > https://urldefense.proofpoint.com/v1/url?u=http://lists.freebsd.org/mailman/ lis > tinfo/freebsd- > rc&k=%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0A&r=LTzUWWrRnz2iN3PtHD > ubWRSAh9itVJ%2BMUcNBCQ4tyeo%3D%0A&m=a%2FXSurQc9zrgW0CMePYdCc > aPq2wsx%2FFfMyb4Wfq6%2B1g%3D%0A&s=7592611709212c7674b7be5b549a > fc9e19012de4ed100174b8a719795614d131 > To unsubscribe, send any mail to "freebsd-rc-unsubscribe@freebsd.org" _____________ 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. From owner-freebsd-rc@FreeBSD.ORG Sat Feb 22 01:17:52 2014 Return-Path: Delivered-To: rc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BF6BE170; Sat, 22 Feb 2014 01:17:52 +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 80037129A; Sat, 22 Feb 2014 01:17:52 +0000 (UTC) Received: from smarthost.fisglobal.com ([10.132.206.193]) by ltcfislmsgpa03.fnfis.com (8.14.5/8.14.5) with ESMTP id s1M1HoSu016924 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 21 Feb 2014 19:17:50 -0600 Received: from THEMADHATTER (10.242.181.54) by smarthost.fisglobal.com (10.132.206.193) with Microsoft SMTP Server id 14.3.174.1; Fri, 21 Feb 2014 19:17:48 -0600 From: Sender: Devin Teske To: "'John Nielsen'" References: <20131228055324.GA72764@aim7400.DataIX.local> <9498BE8E-8090-4E7A-8317-18D29B1DDC08@dataix.net> <7DBA7D58-E925-47BC-967C-F653348426A6@fisglobal.com> <7EAEF3AC-DB1B-4D3E-A156-E1E76B765990@jnielsen.net> In-Reply-To: <7EAEF3AC-DB1B-4D3E-A156-E1E76B765990@jnielsen.net> Subject: RE: network.subr _aliasN handling Date: Fri, 21 Feb 2014 17:17:42 -0800 Message-ID: <11c101cf2f6b$e3aee5d0$ab0cb170$@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_11C2_01CF2F28.D58BA5D0" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQHDFDC1SCdF87KsAOMxpeOC5ZIl9wGCXs+0Atrl8x0A2Y7j4AImADvJAP+hhVcDLSa/6wFNnotj 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-21_06:2014-02-21,2014-02-21,1970-01-01 signatures=0 Cc: 'Jason Hellenthal' , rc@freebsd.org, 'Devin Teske' 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 01:17:52 -0000 ------=_NextPart_000_11C2_01CF2F28.D58BA5D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > -----Original Message----- > From: John Nielsen [mailto:lists@jnielsen.net] > Sent: Friday, February 21, 2014 9:06 AM > To: Devin Teske > Cc: Jason Hellenthal; rc@freebsd.org; net@freebsd.org > Subject: Re: network.subr _aliasN handling > > On Jan 4, 2014, at 4:25 AM, Teske, Devin wrote: > > > On Jan 4, 2014, at 2:59 AM, Jason Hellenthal wrote: > > > >> I believe I know what you mean by that but in a way scares me when you say > sort as in mixing up the original order they appear in which I would find to be > really unattractive to most. > > > > It's not as scary as it sounds. > > > > The issue is that the variables are sorted alphabetically, instead of > > numerically. > > > > Let's take four words: foo1, foo2, foo10, and foo20. > > If you sort them alphabetically, you get: > > > > foo1 > > foo10 > > foo2 > > foo20 > > > > You'll notice this when doing a directory listing, as that too is > > sorted alphabetically. > > > > This is why "alias14" is run before "alias8" and "alias9". Because > > they are processed in alphabetically sorted order. I didn't do > > anything to sort the values, they came pre-sorted in alphabetic order. > > > > If I simply throw in a "| sort -n", then it will change it to numerically sorted. > > As you might expect, numerically sorting the above list would result in: > > > > foo1 > > foo2 > > foo10 > > foo20 > > > > Trivial really. I'll throw a patch at you when I get some cycles (soon). > > Hi Devin, Jason- > > I've been behind on my mailing list e-mail for a while, but I really like the idea > and the patch proposed here. I don't see anything like it in head yet, so ... Ping? > :) > > JN > [Devin Teske] *** this time with attached patch.txt *** Hi JN, here's a new patch that incorporates numerical sorting as well as what the original patch set out to do ... make "gaps" possible (so that you could comment out an alias without having to renumber all the ones following). Give it a look, let me know what you think. -- 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. ------=_NextPart_000_11C2_01CF2F28.D58BA5D0 Content-Type: text/plain; name="patch.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="patch.txt" Index: etc/network.subr=0A= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A= --- etc/network.subr (revision 255712)=0A= +++ etc/network.subr (working copy)=0A= @@ -1027,9 +1027,10 @@ ifalias_af_common()=0A= _action=3D$3=0A= =0A= # ifconfig_IF_aliasN which starts with $_af=0A= - alias=3D0=0A= - while : ; do=0A= - ifconfig_args=3D`get_if_var $_if ifconfig_IF_alias${alias}`=0A= + for alias in `list_vars ifconfig_${_if}_alias[0-9]\* |=0A= + sort -nk1.$((9+${#_if}+7))`=0A= + do=0A= + eval ifconfig_args=3D\"\$$alias\"=0A= _iaf=3D=0A= case $ifconfig_args in=0A= inet\ *) _iaf=3Dinet ;;=0A= @@ -1051,15 +1052,15 @@ ifalias_af_common()=0A= warn "\$ifconfig_${_if}_alias${alias} needs " \=0A= "\"inet\" keyword for an IPv4 address."=0A= esac=0A= - alias=3D$(($alias + 1))=0A= done=0A= =0A= # backward compatibility: ipv6_ifconfig_IF_aliasN.=0A= case $_af in=0A= inet6)=0A= - alias=3D0=0A= - while : ; do=0A= - ifconfig_args=3D`get_if_var $_if ipv6_ifconfig_IF_alias${alias}`=0A= + for alias in `list_vars ipv6_ifconfig_${_if}_alias[0-9]\* |=0A= + sort -nk1.$((14+${#_if}+7))`=0A= + do=0A= + eval ifconfig_args=3D\"\$$alias\"=0A= case ${_action}:"${ifconfig_args}" in=0A= *:"")=0A= break=0A= @@ -1071,7 +1072,6 @@ ifalias_af_common()=0A= "instead."=0A= ;;=0A= esac=0A= - alias=3D$(($alias + 1))=0A= done=0A= esac=0A= =0A= Index: etc/rc.subr=0A= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A= --- etc/rc.subr (revision 255712)=0A= +++ etc/rc.subr (working copy)=0A= @@ -54,6 +54,20 @@ JID=3D`$PS -p $$ -o jid=3D`=0A= # functions=0A= # ---------=0A= =0A= +# list_vars pattern=0A= +# List vars matching pattern.=0A= +# =0A= +list_vars()=0A= +{=0A= + set | { while read LINE; do=0A= + var=3D"${LINE%%=3D*}"=0A= + case "$var" in=0A= + "$LINE"|*[!a-zA-Z0-9_]*) continue ;;=0A= + $1) echo $var=0A= + esac=0A= + done; }=0A= +}=0A= +=0A= # set_rcvar_obsolete oldvar [newvar] [msg]=0A= # Define obsolete variable.=0A= # Global variable $rcvars_obsolete is used.=0A= ------=_NextPart_000_11C2_01CF2F28.D58BA5D0-- From owner-freebsd-rc@FreeBSD.ORG Sat Feb 22 03:35:55 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 61CC4C4F for ; Sat, 22 Feb 2014 03:35:55 +0000 (UTC) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 186E311BB for ; Sat, 22 Feb 2014 03:35:55 +0000 (UTC) Received: by mail-ie0-f181.google.com with SMTP id rl12so1982044iec.12 for ; Fri, 21 Feb 2014 19:35:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dataix.net; s=rsa; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=3mImDE76yes6Yok1AA4IG3Yq7ojvL2s5v+eKsn8XprU=; b=GOqtKXjWdgxbd4+jV0kHPhtkp1L6Gg2dPJYVmHmoZ/Pfs0m4jrV4ZMK2D1fG9G9xyy phh6svqL2B9tKBryD76pyjdVBDamAi/PQXy4c63Kk7YM/7ZpAyMeE/QBsw1+BhjZE+fd WDBzenDVC/WfMnJ8WzJBi8/Vfp94oKlD0RTJs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=3mImDE76yes6Yok1AA4IG3Yq7ojvL2s5v+eKsn8XprU=; b=OrsMfF13IwwtBC8zhGoq0mppBrZRZz0CfZn6TFCWu4gByHbQhCElAtkryVLZofC1nj 5GqhO7R4jjUBLW5Rg+fQ3xFzHfXZMjrJ35GiTL2qEsTlclqtlE5UcbbNL2oOskWQeCeC HPP2sYvMuNRMvXZd1qyloMdXQOW8mo8mP/+SFLTj55v1oHsFXwNPT/oxabpAfBaTXjiy jy0g6rjs+tFijGoUCZWf/iL1t0CKmjhZTkdEglhwj8XUMNF/peDZ4cOlITrbo6eCzuwN ejPedyz2zsXrEu9rHvv6mv8BjYHc3a2FsiSqxuA7/9HL9TVc9RZ4dJLQqKhcxBtIPwtS Xjag== X-Gm-Message-State: ALoCoQmSki3t9hiVlEmqU8BXbvI89ezhHXIaUwTLRQuySljqthZuTGD84QHO3itBzRh7sqoRxBVO X-Received: by 10.50.143.69 with SMTP id sc5mr3120426igb.2.1393040154306; Fri, 21 Feb 2014 19:35:54 -0800 (PST) Received: from [172.31.35.2] (75-128-101-59.dhcp.sgnw.mi.charter.com. [75.128.101.59]) by mx.google.com with ESMTPSA id rj10sm1346786igc.8.2014.02.21.19.35.51 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 21 Feb 2014 19:35:51 -0800 (PST) References: <20131228055324.GA72764@aim7400.DataIX.local> <9498BE8E-8090-4E7A-8317-18D29B1DDC08@dataix.net> <7DBA7D58-E925-47BC-967C-F653348426A6@fisglobal.com> <7EAEF3AC-DB1B-4D3E-A156-E1E76B765990@jnielsen.net> <11c101cf2f6b$e3aee5d0$ab0cb170$@FreeBSD.org> Mime-Version: 1.0 (1.0) In-Reply-To: <11c101cf2f6b$e3aee5d0$ab0cb170$@FreeBSD.org> Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-DB51D874-C521-44AD-8D86-6E95D4A63CF6; protocol="application/pkcs7-signature" Content-Transfer-Encoding: 7bit Message-Id: <6D23F10D-14E0-4812-A0B5-3D3D4BE66953@dataix.net> X-Mailer: iPhone Mail (11B554a) From: Jason Hellenthal Subject: Re: network.subr _aliasN handling Date: Fri, 21 Feb 2014 22:35:47 -0500 To: "" X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "" , Devin Teske 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 03:35:55 -0000 --Apple-Mail-DB51D874-C521-44AD-8D86-6E95D4A63CF6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable I'll get on testing this on 10-STABLE in the morning. Thanks Devin --=20 Jason Hellenthal Voice: 95.30.17.6/616 JJH48-ARIN > On Feb 21, 2014, at 20:17, wrote: >=20 >=20 >=20 >> -----Original Message----- >> From: John Nielsen [mailto:lists@jnielsen.net] >> Sent: Friday, February 21, 2014 9:06 AM >> To: Devin Teske >> Cc: Jason Hellenthal; rc@freebsd.org; net@freebsd.org >> Subject: Re: network.subr _aliasN handling >>=20 >>> On Jan 4, 2014, at 4:25 AM, Teske, Devin >> wrote: >>=20 >>>> On Jan 4, 2014, at 2:59 AM, Jason Hellenthal wrote: >>>>=20 >>>> I believe I know what you mean by that but in a way scares me when > you say >> sort as in mixing up the original order they appear in which I would > find to be >> really unattractive to most. >>>=20 >>> It's not as scary as it sounds. >>>=20 >>> The issue is that the variables are sorted alphabetically, instead of >>> numerically. >>>=20 >>> Let's take four words: foo1, foo2, foo10, and foo20. >>> If you sort them alphabetically, you get: >>>=20 >>> foo1 >>> foo10 >>> foo2 >>> foo20 >>>=20 >>> You'll notice this when doing a directory listing, as that too is >>> sorted alphabetically. >>>=20 >>> This is why "alias14" is run before "alias8" and "alias9". Because >>> they are processed in alphabetically sorted order. I didn't do >>> anything to sort the values, they came pre-sorted in alphabetic order. >>>=20 >>> If I simply throw in a "| sort -n", then it will change it to > numerically sorted. >>> As you might expect, numerically sorting the above list would result > in: >>>=20 >>> foo1 >>> foo2 >>> foo10 >>> foo20 >>>=20 >>> Trivial really. I'll throw a patch at you when I get some cycles > (soon). >>=20 >> Hi Devin, Jason- >>=20 >> I've been behind on my mailing list e-mail for a while, but I really > like the idea >> and the patch proposed here. I don't see anything like it in head yet, > so ... Ping? >> :) >>=20 >> JN > [Devin Teske]=20 >=20 > *** this time with attached patch.txt *** >=20 > Hi JN, here's a new patch that incorporates numerical sorting as well as > what > the original patch set out to do ... make "gaps" possible (so that you > could > comment out an alias without having to renumber all the ones following). >=20 > Give it a look, let me know what you think. > --=20 > Devin >=20 > _____________ > The information contained in this message is proprietary and/or confidenti= al. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any man= ner; and (iii) notify the sender immediately. In addition, please be aware t= hat any message addressed to our domain is subject to archiving and review b= y persons other than the intended recipient. Thank you. > --Apple-Mail-DB51D874-C521-44AD-8D86-6E95D4A63CF6 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUOTCCBjAw ggUYoAMCAQICAwaijjANBgkqhkiG9w0BAQsFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB MB4XDTEzMDUxODA4NTA0OFoXDTE0MDUxOTIyMDk0N1owSDEfMB0GA1UEAwwWamhlbGxlbnRoYWxA ZGF0YWl4Lm5ldDElMCMGCSqGSIb3DQEJARYWamhlbGxlbnRoYWxAZGF0YWl4Lm5ldDCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBALgnYFS1bWZr3KhKBzWAdRwrY+En+RRV8nCaYubqrMG+ YJbuenaIKSbIuFiDWipW4RHYTpE28pKaSnaVTG9WtAZvsWj0gYN9g2fYCnCOUceES2Yvi3RavxpB hsuzKIfsHb8iNNSEuczLu6gn4mQyaHwE4x6xSUKmbK8njR+YoF522F60wjsnq5dlOJdTrhDfObE5 5P23279WbRp8azgZX1VRB66wdKRDuSI1vBts4Nsha2paXd6HUUduHrPACBQREJTGXN8XtEKVwo63 aKUhRgtUwHNEuSWck/xwVl7PBUWH2dORAWTCqHjNuCKNOQ1/0LMiyMj7FdsBjN4dgL4YZpsCAwEA AaOCAtwwggLYMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDAdBgNVHQ4EFgQU29qUrmZtgQ7ZVoDKogfpJOSfk+YwHwYDVR0jBBgwFoAUU3Ltkpzg 2ssBXHx+ljVO8tS4UYIwIQYDVR0RBBowGIEWamhlbGxlbnRoYWxAZGF0YWl4Lm5ldDCCAUwGA1Ud IASCAUMwggE/MIIBOwYLKwYBBAGBtTcBAgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29y ZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRD b20gQ0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBj b21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCug KaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSB gTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGll bnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFz czEuY2xpZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJ KoZIhvcNAQELBQADggEBAHsw8/Hw07gsNTKYnld74NBFtHnQOPkXYuccWx3j0PGQe9nqNxeingBf 2yvx+xBQzBoi4J1u84Jbrbe8Ii3+LLD/QMW9cN0SBIgRStPQLVee4STdjeabGmpXQa7omC02wYYO 83qh6CgJEIbmrsBSZH8ZSVrjkC4UmZS8wAQMS3qTWAPF0ZQGWx2+Gks2fXuacyt2LpNR+p9ogjAZ 1/rmUKjNhQZLswytaLRUdwAwSfQ3+TNs68h6Kv1LC3bNGBT3NEtr2q/nzzb5MzuFcDE6f9exroAC 4BHmokAprhna/vZdb6BrPjpXgRAlWAh3wEMxw75M9S/Nbzj/jNp+I+lvUJYwggY0MIIEHKADAgEC AgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBT dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQy MTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQDHCYPMzi3YGrEppC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6E RKKnu8zPf1Jwuk0tsvVCk6U9b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1 PKHG/FaR/wpbfuIqu54qzHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvur yGaC/o2/ceD2uYDX9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSM TGKkDiXm6/3/4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNV HRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4 UYIwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nmc2Nh LmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3 LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4ICAQAKgwh9eKssBly4Y4xerhy5 I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8pyTUnFsukDFUI22zF5bVHzuJ+GxhnS qN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMmCeUTyMyikfbUFvIBivtvkR8ZFAk22BZy +pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIzuQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4Yj Cl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVmz/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586 YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3 a0LwZrp8MQ+Z77U1uL7TelWO5lApsbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0q ZW2Niy/QvVNKbb43A43ny076khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjx kJh8BYtv9ePsXklAxtm8J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV 27ioRKbj/cIq7JRXun0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCB8kwggWxoAMCAQICAQEw DQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzAp BgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0 Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA2MDkxNzE5NDYzNloXDTM2MDkxNzE5NDYz NlowfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3Vy ZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAwYjbCbxsRnx4 n5V7tTOQ8nJi1sE2ICIkXs7pd/JDCqIGZKTMjjb4OOYj8G5tsTzdcqOFHKHTPbQzK9Mvr/7qsEFZ Z7bEBn0KnnSF1nlMgDd63zkFUln39BtGQ6TShYXSw3HzdWI0uiyKfx6P7u000BHHls1SPboz1t1N 3gs7SkufwiYv+rUWHHI1d8o8XebK4SaLGjZ2XAHbdBQl/u21oIgP3XjKLR8HlzABLXJ5+kbWEyqo uaarg0kd5fLv3eQBjhgKj2NTFoViqQ4ZOsy1ZqbCa3QH5Cvhdj60bdj2ROFzYh87xL6gU1YlbFEJ 96qryr92/W2b853bvz1mvAxWqq+YSJU6S9+nWFDZOHWpW+pDDAL/mevobE1wWyllnN2qXcyvATHs DOvSjejqnHvmbvcnZgwaSNduQuM/3iE+e+ENcPtjqqhsGlS0XCV6yaLJixamuyx+F14FTVhuEh0B 7hIQDcYyfxj//PT6zW6R6DZJvhpIaYvClk0aErJpF8EKkNb6eSJIv7p7afhwx/p6N9jYDdJ2T1f/ kLfjkdLd78Jgt2c63f6qnPDUi39yIs7Gn5e2+K+KoBCo2fsYxra1XFI8ibYZKnMBCg8DsxJg8nov gdujbv8mMJf1i92JV7atPbOvK8W3dgLwpdYrmoYUKnL24zOMXQlLE9+7jHQTUksCAwEAAaOCAlIw ggJOMAwGA1UdEwQFMAMBAf8wCwYDVR0PBAQDAgGuMB0GA1UdDgQWBBROC+8apEBbpRdphzDKNGhD 0EGu8jBkBgNVHR8EXTBbMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2EtY3Js LmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydGNvbS5vcmcvc2ZzY2EtY3JsLmNybDCCAV0GA1Ud IASCAVQwggFQMIIBTAYLKwYBBAGBtTcBAQEwggE7MC8GCCsGAQUFBwIBFiNodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvcG9saWN5LnBkZjA1BggrBgEFBQcCARYpaHR0cDovL2NlcnQuc3RhcnRjb20u b3JnL2ludGVybWVkaWF0ZS5wZGYwgdAGCCsGAQUFBwICMIHDMCcWIFN0YXJ0IENvbW1lcmNpYWwg KFN0YXJ0Q29tKSBMdGQuMAMCAQEagZdMaW1pdGVkIExpYWJpbGl0eSwgcmVhZCB0aGUgc2VjdGlv biAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3ku cGRmMBEGCWCGSAGG+EIBAQQEAwIABzA4BglghkgBhvhCAQ0EKxYpU3RhcnRDb20gRnJlZSBTU0wg Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkwDQYJKoZIhvcNAQEFBQADggIBABZsmfRmDDT10IVefQrs 2hBOOBxe36YlBUuRMsHoO/E93UQJWwdJiinLZgK3sZr3JZgJPI4b4d02hytLu2jTOWY9oCbH8jmR HVGrgnt+1c5a5OIDV3Bplwj5XlimCt+MBppFFhY4Cl5X9mLHegIF5rwetfKe9Kkpg/iyFONuKIdE w5Aa3jipPKxDTWRFzt0oqVzyc3sE+Bfoq7HzLlxkbnMxOhK4vLMR5H2PgVGaO42J9E2TZns8A+3T mh2a82VQ9aDQdZ8vr/DqgkOY+GmciXnEQ45GcuNkNhKv9yUeOImQd37Da2q5w8tES6x4kIvnxywe SxFEyDRSJ80KXZ+FwYnVGnjylRBTMt2AhGZ12bVoKPthLr6EqDjAmRKGpR5nZK0GLi+pcIXHlg98 iWX1jkNUDqvdpYA5lGDANMmWcCyjEvUfSHu9HH5rt52Q9CI7rvj8Ksr6glKg769LVZPrwbXwIous NE4mIgShhyx1SrflfRPXuAxkwDbSyS+GEowjCcEbgjtzSaNqV4eU5dZ4xZlDY+NN4Hct4WWZcmkE GkcJ5g8BViT7H78OealYLrnECQF+lbptAAY+supKEDnY0Cv1v+x1v5cCxQkbCNxVN+KB+zeEQ2Ig yudWS2Xq/mzBJJMkoTTrBf+aIq6bfT/xZVEKpjBqs/SIHIAN/HKK6INeMYIDbzCCA2sCAQEwgZQw gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFBy aW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBqKOMAkGBSsOAwIaBQCgggGvMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE0MDIyMjAzMzU0OVowIwYJKoZIhvcN AQkEMRYEFKnIvbf2z6xYf0dru7XKjMGmtQFpMIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNV BAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBD ZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50 ZXJtZWRpYXRlIENsaWVudCBDQQIDBqKOMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCBjDELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENl cnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRl cm1lZGlhdGUgQ2xpZW50IENBAgMGoo4wDQYJKoZIhvcNAQEBBQAEggEABnz86+Y20YOzZvyxa+Dy KcGcKXOe0bHR+JqsP0oJKTX77DEGQUp11acaWRV0JNyCFw1axry2IFb/tWqXr5OZO7OP4wlixITS ur0+z3M/lyUxCpVLPCjwkUWWtQWQM+vdEqpW3QII6HRoIqTQgYp76SepolwJ7WMz9HpqOl2idFCe 8H0rKhO1WQe7bgOWiuTJkqgwyOtxurV9BJngJUh6rQxJAMuHhi+Rc9llzMy2fWOTXKeGBMVrdGC1 uLj3pRU3YsNnmWOGGfqTuiIvf7KHk7GOQ9ST7iSKq+eMKmzEN3psw80s6jqT9gaVmXAH+4P5TAPH eChaQ8zx74sKM9xr8gAAAAAAAA== --Apple-Mail-DB51D874-C521-44AD-8D86-6E95D4A63CF6-- From owner-freebsd-rc@FreeBSD.ORG Sat Feb 22 05:20:45 2014 Return-Path: Delivered-To: rc@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E40BA603; Sat, 22 Feb 2014 05:20:45 +0000 (UTC) Received: from mail.allbsd.org (gatekeeper.allbsd.org [IPv6:2001:2f0:104:e001::32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8581E11CD; Sat, 22 Feb 2014 05:20:41 +0000 (UTC) Received: from alph.d.allbsd.org (p2106-ipbf2009funabasi.chiba.ocn.ne.jp [114.146.169.106]) (authenticated bits=128) by mail.allbsd.org (8.14.5/8.14.5) with ESMTP id s1M5KJkd015821 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 22 Feb 2014 14:20:29 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.d.allbsd.org (8.14.7/8.14.7) with ESMTP id s1M5KGRm004012; Sat, 22 Feb 2014 14:20:18 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Sat, 22 Feb 2014 14:19:35 +0900 (JST) Message-Id: <20140222.141935.520275210006153242.hrs@allbsd.org> To: jhellenthal@dataix.net, dteske@FreeBSD.org Subject: Re: network.subr _aliasN handling From: Hiroki Sato In-Reply-To: <11c101cf2f6b$e3aee5d0$ab0cb170$@FreeBSD.org> References: <7EAEF3AC-DB1B-4D3E-A156-E1E76B765990@jnielsen.net> <11c101cf2f6b$e3aee5d0$ab0cb170$@FreeBSD.org> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Sat_Feb_22_14_19_35_2014_788)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.4 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender DNS name whitelisted, not delayed by milter-greylist-4.2.7 (mail.allbsd.org [133.31.130.32]); Sat, 22 Feb 2014 14:20:31 +0900 (JST) X-Spam-Status: No, score=-94.3 required=13.0 tests=CONTENT_TYPE_PRESENT, RCVD_IN_PBL,RCVD_IN_RP_RNBL,SPF_SOFTFAIL,USER_IN_WHITELIST autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on gatekeeper.allbsd.org Cc: rc@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 05:20:46 -0000 ----Security_Multipart(Sat_Feb_22_14_19_35_2014_788)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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> 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 when dt> you say dt> > sort as in mixing up the original order they appear in which I 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, instead of dt> > > 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 is dt> > > sorted alphabetically. dt> > > dt> > > This is why "alias14" is run before "alias8" and "alias9". Because dt> > > they are processed in alphabetically sorted order. I didn't do dt> > > 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 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 really dt> like the idea dt> > and the patch proposed here. I don't see anything like it in head 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 well as dt> what dt> the original patch set out to do ... make "gaps" possible (so that you dt> could dt> comment out an alias without having to 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. 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. -- Hiroki ----Security_Multipart(Sat_Feb_22_14_19_35_2014_788)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEABECAAYFAlMIM2cACgkQTyzT2CeTzy01DACglBRihkVaqZfdhQaN6xg2fWO2 8tkAn1cPDwsR81E64f2eLebORd4YuhJE =7hvi -----END PGP SIGNATURE----- ----Security_Multipart(Sat_Feb_22_14_19_35_2014_788)---- 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.