I'll have to test it out but yes I'm pretty sure.

-- 
 Jason Hellenthal
 Voice: 95.30.17.6/616
 JJH48-ARIN

> 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>

Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply via email to