Alright that's what I thought was going on or at least seemed like it when I read the output of ifconfig but didn't delve to deep into it.
When I hear sort(1) particular circumstances come to mind from experience that hit me in the past so just for clarity wanted to see if I was on the same page with what you were thinking. Thanks Devin much appreciated and sure it will be by the rest of the community as well. -- Jason Hellenthal Voice: 95.30.17.6/616 JJH48-ARIN > On Jan 4, 2014, at 6:25, "Teske, Devin" <[email protected]> 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). > -- > Devin > > >>> On Jan 4, 2014, at 5:29, "Teske, Devin" <[email protected]> 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. >>> >>> Sounds like I need to add some numerical sorting. >>> -- >>> Devin >>> >>> >>> >>>> >>>>> On Dec 28, 2013, at 23:24, "Teske, Devin" <[email protected]> >>>>> wrote: >>>>> >>>>> >>>>>> On Dec 27, 2013, at 9:53 PM, <[email protected]> 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? >>>>> -- >>>>> 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. >>>>> <patch.txt> >>> >>> _____________ >>> 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. > > _____________ > 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.
smime.p7s
Description: S/MIME cryptographic signature
