network.subr _aliasN handling

[dteske at FreeBSD.org]

> -----Original Message-----
> From: Hiroki Sato [mailto:hrs at FreeBSD.org]
> Sent: Sunday, March 30, 2014 8:18 PM
> To: dteske at FreeBSD.org
> Cc: jhellenthal at dataix.net; lists at jnielsen.net; rc at FreeBSD.org
> Subject: Re: network.subr _aliasN handling
> 
> <dteske at FreeBSD.org> wrote
>   in <04f701cf4c85$d1929680$74b7c380$@FreeBSD.org>:
> 
> dt> But that wouldn't have deterred me. 30+ days of silence is
> dt> equivalent to acceptance -- just that I had noticed that the patch
> dt> could be expanded to include mdconfig{,2} scripts. Was going to wait
> dt> a full day to see if anyone balked at the expansion to include
> dt> mdconfig{,2} and then move forward.
> 
>  I like the direction in general, but there are two more comments:
> 
>  1. sort(1) cannot be used [snip]

Problem solved. I just wrote a mini-sort(1) in shell that uses only
shell built-ins (now it doesn't matter what's mounted). See attached
patch.txt (added sort_lite() function to rc.subr).

> 
>  2. Please put the normalization part into a function and use it in
>     get_if_var(), too.  Adding another code for the same functionality
>     makes maintenance difficult.

There is already a function for doing the normalization ... ltr()
and it is already used by get_if_var.

However, I am not using ltr() because it itself degrades performance.
Because ltr() produces its result on stdout, it requires the use of a
sub-shell to capture the result.

NB: I think a good approach would be to fix ltr() and use it instead of
creating some new function and changing get_if_var() to use it instead
of ltr().

>  It degrades the performance a bit
>     but I think maintainability is more important for that.
> 

Negative. The 3-lines of code you're talking about operate about 1000
times faster than calling ltr() in a sub-shell to perform the same action.

That being said... let's do this... let's give ltr() a new argument that can
be used to set a variable in the caller's name-space rather than requiring
me to call it in a sub-shell to cull the answer.

See attached patch wherein I also modify ltr() to fit our needs.

However, while we're here, let's not point a finger at this
glaringly obvious problem with ltr():

dteske at scribe9.vicor.com etc $ sh -c '. /etc/rc.subr; echo "IFS=[$IFS]"; ltr
foo.bar . _; echo "IFS=[$IFS]"'
IFS=[
]
foo_bar
IFS=[.]

It modifies IFS and doesn't restore it. Let me fix that while I'm here. Oh,
and let's quote those positional arguments too so that *maybe* someone
could pass whitespace into the IFS (among other things).

Oh look, while we're here let's make get_if_var() more efficient. Because
the following is just plain silly...

	        _punct=". - / +"
	        for _punct_c in $_punct; do
	                _if=`ltr ${_if} ${_punct_c} '_'`
	        done

Should instead be...

	_punct=".-/+"
	_if=`ltr ${_if} "${_punct}" '_'`

But of course, with the new ltr() syntax, we could get rid of all the
sub-shells:

	_punct=".-/+"
	ltr "$_if" "$_punct" '_' "_if"

Please see attached patch.
-- 
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.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch.txt
URL: <http://lists.freebsd.org/pipermail/freebsd-rc/attachments/20140331/9bef185e/attachment.txt>