sysrc(8) -- a sysctl(8)-like utility for managing rc.conf(5)

[Cyrille Lefevre]

Le 06/11/2010 04:16, Devin Teske a écrit :
> On Sat, 2010-11-06 at 02:32 +0100, Cyrille Lefevre wrote:
>> Le 05/11/2010 18:40, Devin Teske a écrit :
>>> On Fri, 2010-11-05 at 03:59 +0100, Cyrille Lefevre wrote:
>>>> Le 05/11/2010 02:09, Devin Teske a écrit :

> Ah, I was also confused by "parentheses" -- I've always referred to
> those as braces (of the "curly" persuasion).

well, english isn't my natural language, so, sometimes, I used the wrong
word... :-)

>>>> # ... | ... doesn't need a final \ when wrapped after the |
>>>> local awk_new_value="$( echo "$new_value" |
>>>> 	awk '{ gsub(/\\/, "\\\\"); gsub(/"/, "\\\""); print }' )"
>>>
>>> Wrong. Fail. And here's why...
>>>
>>> You are correct that a $( ... ) block can traverse newlines.
>>>
>>> However, what $( ... ) functional performs is a sub-shell. Each line
>>> within the $( ... ) syntax is taken as a single-line of shell to be
>>> executed.
>>>
>>> Therefore, by deleting the back-slash at the end of the line, you've
>>> turned one statement into two.
>>
>> no, no, no, did you tried it ?
>>
>> your syntax :
>> x=$(echo x \
>>   | sed s,x,y,)
>> echo $x
>>
>> the usual syntax :
>> x=$(echo x |
>>     sed s,x,y,)
>> echo $x
>>
>> both should print y or the shell is buggy ?
>>
>> so, as I told you, the \ isn't needed after a |.
> 
> no, no, no, did YOU try it?

well, you're not undertandnig me, again :-)
I am talking about putting the pipe to the end of the first line, not to
the begin of following the line. your examples doesn't show this case,
so, try it again :-)

> In this case, I argue that I don't need quotes around $file, because the
> operating system itself (as you can see above; notably lines 1, 3, 7 and
> 8) does not support values of rc_conf_files that contain spaces.

may be the operating system is wrong :-)
it's a usual habit to protect everything (files, parameters, etc) w/ "
in case of spaces except the exception where you want to do word
splitting, which is a rare case finally.
also, it is to be concistent w/ the rest of the script where evrery
occurence of a file is " protected, so, why not here !
in this case, why do you protect $tmpfile which is generated bu mktemp
(probably w/o spaces), etc.

>>>> # you may want to use printf "%s" "$new_contents" instead of echo
>>>> # to avoid \ sequences interpretation if any

about echo vs printf :

echo 'x\tx' => x	x
vs
printf '%s' "x\tx' => x\tx

the usual problem is that printf isn't a builtin, this imply performance
degradation... alternatively, you may want to use the -E option to echo
if supported (freebsd seems to support it, so, use it).
same remark about read, always use the -r option...

for the history, echo is one of the more unportable command of the unix
universe !

http://www.in-ulm.de/~mascheck/various/echo+printf/

> Make sure you use bourne-shell for your tests.
> 
> No shell system-level scripts within FreeBSD use bash (and rightly so,
> as it's not part of the base distribution).

I'm not talking bash in any case, I hate bash for many reasons, ksh is
one of the best shell, except maybe zsh, but I don't know this one, but
I'm talking posix shell w/o any problem :-)

> Well... I have to say thank you.
> 
> I'm somewhat new to marrying awk(1) w/ sh(1). I do have to say that `-v
> key=value' is very handy!
> 
> The most important thing is that this now allows me to assign the
> literal awkscript to a variable outside the function, meaning that the
> script doesn't need to be regenerated everytime the function is called.
> Essentially performing a caching of sorts. This should further enhance
> the performance of my script -- thanks!

you're welcome.

Regards,

Cyrille Lefevre
-- 
mailto:Cyrille.Lefevre-lists at laposte.net