network.subr _aliasN handling

[dteske at FreeBSD.org]

> -----Original Message-----
> From: Hiroki Sato [mailto:hrs at FreeBSD.org]
> Sent: Friday, February 21, 2014 9:20 PM
> To: jhellenthal at dataix.net; dteske at FreeBSD.org
> Cc: lists at jnielsen.net; rc at FreeBSD.org
> Subject: Re: network.subr _aliasN handling
> 
> <dteske at freebsd.org> wrote
>   in <11c101cf2f6b$e3aee5d0$ab0cb170$@FreeBSD.org>:
> 
> dt>
> dt>
> dt> > -----Original Message-----
> dt> > From: John Nielsen [mailto:lists at jnielsen.net]
> dt> > Sent: Friday, February 21, 2014 9:06 AM
> dt> > To: Devin Teske
> dt> > Cc: Jason Hellenthal; rc at freebsd.org; net at freebsd.org
> dt> > Subject: Re: network.subr _aliasN handling
> dt> >
> dt> > On Jan 4, 2014, at 4:25 AM, Teske, Devin
> dt> > <Devin.Teske at fisglobal.com>
> 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.