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

Devin Teske dteske at vicor.com
Sat Nov 6 18:14:46 UTC 2010


On Nov 6, 2010, at 7:37 AM, Cyrille Lefevre wrote:

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

Ah-so,... I am the grasshopper (not the walrus).

A trailing-pipe appears to be a method of getting the shell to continue the read to the next line. Quite novel and nice, indeed! Thank you for that pearl.

This does work:

$ /bin/sh -c 'x=$(echo x |^V^J
sed s,x,y,)^V^J
echo $x'
y



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

Therein lies the reasoning... it's a reminder for me. I'm still determining whether this is truly a bug [in FreeBSD] -- and worth filing a PR -- or not.

Should we take the stance that somebody would have to be insane to do something like this:

1. Edit /etc/defaults/rc.conf
2. change the rc_conf_files variable
3. to some value that breaks either the:
- for-loop
- the case statement
- `-r' test-case
- or the `.' source statement of the source_rc_confs function

or do we just patch the OS?

Just been sleeping on that one for a few days.



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

I think you meant this:

$ /bin/sh -c "type echo; echo 'x\\tx'"
echo is a shell builtin
x\tx
$ /bin/sh -c "type echo; echo -e 'x\\tx'"
echo is a shell builtin
x	x

The echo built-in will not expand escape-sequences unless -e is passed.

And echo(1) (/bin/echo) is dumb -- it doesn't support escape-sequences nor `-e' at all.

For the record, bash works the same as sh. and csh/tcsh work like /bin/echo

So, there should be no concern about expanding escape-sequences unless all of the following is true:

a. You're using sh, bash, or something similar (not csh or tcsh)
b. You pass `-e' as the first positional argument


> 
> the usual problem is that printf isn't a builtin,

Wow, it changed... (I guess we were stuck under a rock)

$ uname -spr
FreeBSD 4.11-STABLE i386
$ /bin/sh -c 'type printf'
printf is a shell builtin
$ strings /bin/sh | grep '\$FreeBSD:' | grep printf
$FreeBSD: src/usr.bin/printf/printf.c,v 1.12.6.7 2004/03/12 23:33:10 cperciva Exp $
$FreeBSD: src/lib/libc/stdio/asprintf.c,v 1.6 1999/08/28 00:00:55 peter Exp $

to

$ uname -spr
FreeBSD 8.1-RELEASE i386
$ /bin/sh -c 'type printf'
printf is /usr/bin/printf

====================
http://www.freebsd.org/cgi/cvsweb.cgi/src/bin/sh/Makefile.diff?r1=1.31;r2=1.32;hideattic=0;f=h

src/bin/sh/Makefile,v1.32 Tue Nov 20 18:33:58 2001 UTC (8 years, 11 months ago) by knu
Remove the printf builtin command from sh(1), which command is not
used so often that it's worth keeping it as a builtin.

Now that all the printf invocations from within the system startup
scripts, we can safely remove it.

Urgef by:       sheldonh  :)

No MFC is planned so far because it may break compatibility and violate POLA.
====================

Of course agreed that invoking an external printf would cause a performance-hit.



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

I think you meant `-e', I'm not familiar with `-E', is that the opposite of `-e' (as in, "don't expand escape-sequences")?

Use of `-r' depends. I find that it's not enough to say "always use it". 50% of the cases I've come across should not use it while the other half should. It really depends on whether you want to pick up the contents of the next line should there be a trailing back-slash at the end of the first line read.


> 
> for the history, echo is one of the more unportable command of the unix
> universe !
> 
> http://www.in-ulm.de/~mascheck/various/echo+printf/

That's a great page!

But alas (both by experience and if I'm reading the tables you provided correctly)... all of the BSD's (that is, since BSD-based OSes are the only OSes that would need rc.conf(5) type management provided by this script) all agree on the echo built-in functionality... escape-sequences are ignored unless -e is passed.


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

I see the light!!! This finally explains a lot.

Yes, ksh switches the echo built-in functionality to expand escape-sequences by default. To reverse the default functionality, you pass `-E' (to _not_ expand escape-sequences).

You're right, I hadn't considered that portability issue because the script is programmed in sh(1), not ksh(1). Thanks for lookin' out though.



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

--
Cheers,
Devin Teske

-> CONTACT INFORMATION <-
Business Solutions Consultant II
FIS - fisglobal.com
510-735-5650 Mobile
510-621-2038 Office
510-621-2020 Office Fax
909-477-4578 Home/Fax
devin.teske at fisglobal.com

-> LEGAL DISCLAIMER <-
This message  contains confidential  and proprietary  information
of the sender,  and is intended only for the person(s) to whom it
is addressed. Any use, distribution, copying or disclosure by any
other person  is strictly prohibited.  If you have  received this
message in error,  please notify  the e-mail sender  immediately,
and delete the original message without making a copy.

-> FUN STUFF <-
-----BEGIN GEEK CODE BLOCK-----
Version 3.1
GAT/CS d(+) s: a- C++(++++) UB++++$ P++(++++) L++(++++) !E--- W++ N? o? K- w O
M+ V- PS+ PE Y+ PGP- t(+) 5? X+(++) R>++ tv(+) b+(++) DI+(++) D(+) G+>++ e>+ h
r>++ y+ 
------END GEEK CODE BLOCK------
http://www.geekcode.com/

-> END TRANSMISSION <-



More information about the freebsd-rc mailing list