Date: Tue, 18 Aug 2026 14:24:50 -0700
From: Jason Thorpe <[email protected]>
Message-ID: <[email protected]>
| Does -s also ensure that it's a regular file?
No -- if you need that, test both of them.
test -f "$f" && test -s "$f" && ...
(test is built into sh, so there is very little cost to that).
Use the [ ] form of test if you prefer.
| Why is that?
In case something sets a weird value. Adding the quotes is cheap,
harmless, and avoids problems - in general the first instinct should
be to always quote all expansions, and only not do so when it can be
shown they either are not needed (like the x=$y case), or the code
would not work as desired (like "for f in ${allf}" where the ${allf}
value needs to be field split - that's not really safe, but the
alternative is messy).
[On the other hand, quoting strings that are not from expansions, and
contain no shell operator, meta, white space, or quoting characters,
(and are not empty) is never needed. Though people still write quotes
around simple words like in things like
[ "${ans}" = "yes" ]
The quotes in "${ans}" are needed, those around yes are silly.
]
| I'll note that similar sorts of usage in /etc/rc
| is not quoted (look for ${rcd} and $_rc_elem).
Those should be quoted as well.
The half good explanation for these (including yours) not being quoted
is because they come from the expansion of a value that must be unquoted
to work, so the expectation is that any splitting or filename expansion
that would happen has already happened. That's actually incorrect when
the value came from a rc.conf.d/* expansion (for example) those aren't
field split, or filename expanded again, but if re-used (as $f for example),
would be, and in any case is relying upon the initial expansion being done
cheaply (rather than safely).
| The assumption I was making is that copying over the top of an existing
| rc.d script will not radically change its behavior vis a vis useful-work.
Probably mostly it won't, but for this, "probably" isn't really good enough.
| However, adding or removing a script will obviously update
| the directory mtime.
Yes.
| I guess the real question is: how much does checking every rc.d script's
| mtime negate the performance gain
Yes.
| I'll have to run some additional experiments, I suppose.
I guess so, I don't have anything (still working, I have a 3/60 in storage
in Melb that has been sitting unused for > 2 1/2 decades now...) slow enough
for any test I might run to be meaningful.
| In my experience, the pkgsrc-sourced scripts often also ship with an
| /etc/rc.conf.d/ file that contains defaults that can be edited by the
| user.
And "often" is going to be good enough?
| Yes, a test for ctime would probably be better.. and I would happily use
| it if it were available.
If no-one objects, I can add that easily. It would mean that this new
code would only work in -12 (11.99.*) and above however, that kind of change
wouldn't really be suitable for a pullup.
| Oh, is printf(1) a shell built-in these days?
Yes, for a very long time. Even in SMALL shells. Only TINY ones, which
as best I can tell, we never build, have it excluded.
| No problem, I can do that. I blame muscle memory.
Understood ... I often find myself writing "echo" when I shouldn't as well.
kre
