sysrc -- a sysctl(8)-like utility for managing /etc/rc.conf et. al.

[Jilles Tjoelker]

On Sat, Oct 09, 2010 at 03:39:44PM -0700, Devin Teske wrote:
> On Oct 9, 2010, at 1:25 PM, Garrett Cooper wrote:
[...]
> The second usage (": function") aids in finding the function
> declaration among the usages. See, in Perl, I can simply search for
> "sub" preceding the function name. In C, I tend to split the return
> type from the function name and ensure that the function name always
> starts in column-1 so I can search for "^funcname" to go to the
> declaration opposed to the usages/references. In BASH, `function' is a
> valid keyword and you can say "function funcname ( ) BLOCK" but
> unfortunately in good ol' bourne shell, "function" is not an
> understood keyword, ... but really liking this keyword, I decided to
> make use of it in bourne shell by-way-of simply making it a
> non-executed-expression (preceded it with ":" and terminated it with
> ";").

I think function f() { ... } is a despicable bashism. In POSIX, an empty
pair of parentheses is an unambiguous indication of a function
definition; although FreeBSD sh also accepts () as a subshell containing
an empty command, there is no reason to use that.

In ksh, function f { ... } is different from f() { ... }, so there is a
reason to use it, and function f() { ... } does not exist.

> I originally had been programming in tests for '!' and 'in', but in
> POSIX bourne-shell, they aren't defined (though understood) in the
> keyword table (so type(1) balks in bourne-shell while csh and bash do
> respond to '!' and 'in' queries).

> Since you've pointed out command(1)... I now have a way of checking
> '!'. Though unfortunately, "command -v", like type(1), also does not
> like "in" (in bourne-shell at least).

The type builtin in the original Bourne shell does not know keywords.
The type builtin in FreeBSD sh knows them, but unlike most shells "in"
is not a keyword -- it is only recognized at the appropriate places in a
case or for command (this is probably a POSIX violation and may change
in the future).

> > "x$fmt" != x ? It seems like it could be simplified to:

> > if [ $# -gt 0 ]
> > then
> >    local fmt=$1
> >    shift 1
> >    eprintf "$fmt\n" "$@"
> > fi
> 
> I never understood why people don't trust the tools they are using...
> 
> `[' is very very similar (if not identical) to test(1)
> 
> [ "..." ] is the same thing as [ -n "..." ] or test -n "..."
> [ ! "..." ] is the same things as [ -z "..." ] or test -z "..."
> 
> I'll never understand why people have to throw an extra letter in there and then compare it to that letter.
> 
> If the variable expands to nothing, go ahead and let it. I've traced
> every possible expansion of variables when used in the following
> manner:

> [ "$VAR" ] ...

> and it never fails. If $VAR is anything but null, the entire
> expression will evaluate to true.

Right, except in very old implementations if VAR is -t, but those should
be extinct and are not worth coding for.

However, in some fairly recent implementations [ "$A" = "$B" ] does not
work as expected for all values of A and B. For example, FreeBSD 7.0
returns true for A='(' and B=')' because it applies the POSIX rules in
the wrong order (certainly, [ '(' "$X" ')' ] is true for most non-empty
values of X, but this does not apply if X is an operator).

> >> # depend $name [ $dependency ... ]
> >> #
> >> # Add a dependency. Die with error if dependency is not met.
> >> #
> >> : dependency checks performed after depend-function declaration
> >> : function ; depend ( ) # $name [ $dependency ... ]
> >> {
> >>        local by="$1" arg
> >>        shift 1
> >> 
> >>        for arg in "$@"; do
> >>                local d

> > Wouldn't it be better to declare this outside of the loop (I'm not
> > sure how optimal it is to place it inside the loop)?

> I'm assuming you mean the "local d" statement. There's no restriction
> that says you have to put your variable declarations at the beginning
> of a block (like in C -- even if only within a superficial block { in
> the middle of nowhere } ... like that).

> Meanwhile, in Perl, it's quite a difference to scope it to the loop
> rather than the block. So, it all depends on whichever _looks_ nicer
> to you ^_^

Although this works, I do not recommend it. It makes the impression that
the variable is scoped to the do block, which is not the case as there
is only function scope. Also, FreeBSD sh will register another local
variable record if you make the same variable local again (but it will
reset the variable to the correct value later).

> > I'd say that you have bigger fish to try if your shell lacks the
> > needed lexicon to parse built-ins like for, do, local, etc :)...

local might be worth checking for as the original Bourne shell and ksh93
don't know it.

-- 
Jilles Tjoelker