Date: Sat, 4 Jan 2014 11:25:12 +0000 From: "Teske, Devin" <Devin.Teske@fisglobal.com> To: Jason Hellenthal <jhellenthal@dataix.net> Cc: "rc@freebsd.org" <rc@freebsd.org>, "Teske, Devin" <Devin.Teske@fisglobal.com>, "net@freebsd.org" <net@freebsd.org> Subject: Re: network.subr _aliasN handling Message-ID: <AFFFCC9A-8C21-4C0B-A8D9-457E4C26DDA3@fisglobal.com> In-Reply-To: <A15FAFBD-4597-4D8D-A014-0D486573894C@dataix.net> References: <20131228055324.GA72764@aim7400.DataIX.local> <A7699871-A170-4AD5-B740-ED8BE17C7107@fisglobal.com> <9498BE8E-8090-4E7A-8317-18D29B1DDC08@dataix.net> <7DBA7D58-E925-47BC-967C-F653348426A6@fisglobal.com> <A15FAFBD-4597-4D8D-A014-0D486573894C@dataix.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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 sa= y 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. 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 s= orted. 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). --=20 Devin > On Jan 4, 2014, at 5:29, "Teske, Devin" <Devin.Teske@fisglobal.com> 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 >>=20 >> Sounds like I need to add some numerical sorting. >> --=20 >> Devin >>=20 >>=20 >>=20 >>>=20 >>> On Dec 28, 2013, at 23:24, "Teske, Devin" <Devin.Teske@fisglobal.com> w= rote: >>>=20 >>>>=20 >>>> On Dec 27, 2013, at 9:53 PM, <jhellenthal@dataix.net> 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-sequentia= l 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 inter= nal" >>>>> *_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 th= e 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 addresse= s 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 in= terface 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 o= f 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 functi= ons 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? >>>> --=20 >>>> Devin >>>>=20 >>>> _____________ >>>> The information contained in this message is proprietary and/or confid= ential. If you are not the intended recipient, please: (i) delete the messa= ge and all copies; (ii) do not disclose, distribute or use the message in a= ny 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. >>>> <patch.txt> >>=20 >> _____________ >> The information contained in this message is proprietary and/or confiden= tial. 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 aw= are that any message addressed to our domain is subject to archiving and re= view by persons other than the intended recipient. Thank you. _____________ The information contained in this message is proprietary and/or confidentia= l. 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 ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AFFFCC9A-8C21-4C0B-A8D9-457E4C26DDA3>