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.
-- Jason Hellenthal Voice: 95.30.17.6/616 JJH48-ARIN > 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.
smime.p7s
Description: S/MIME cryptographic signature
