On Wed, Oct 24, 2007 at 08:02:01AM +0200, Roland Mainz wrote:
> As far as I can remeber our "squid" setup the standard "configure"
> scripts assume as minimum level at least something based on the POSIX
> shell spec, e.g. something like "ksh" or "bash" which understands things
> like x="$(foo)" &co.
Huh. So they don't use an autoconf-based configure script?
> bash, ksh } (<-- in that order)) instead of trying it and then cleanup
> after possible problems... IMO it's not worth the trouble...
Definitely don't clean up the script. I was just curious about this.
> > > Quotes missing, e.g. please change this to
> > > [ ! -f "${CONF_FILE}" ] && exit $SMF_EXIT_ERR_CONFIG
> >
> > I'd really rather not see an overabundance of quotes where none are
> > necessary. If there aren't any spaces and all values are non-null, there's
> > no need. And in such a straightforward script, where that's easily
> > checked, you really shouldn't need them at all.
>
> I have to disagree _STRONGLY_. The problem with using 1) the original
> bourne shell and then 2) no quotes is the major reason why most shell
> scripts in Solaris are _insecure_ and can easily be cheated into doing
> whatever a malicious user wants (e.g. using characters from ${IFS} or
> some globbing tricks etc.).
For the method script, I can see being excessively careful, sure, though
I'd be curious to see how you'd go about changing IFS in that context. As
for the install script, I really don't see the point. It seems unlikely to
me that anyone would target a build for a malicious attack, and we know all
the inputs.
> > That's install.subr, which is sourced. It's baked, but feel free to rework
> > it (and all the gate scripts which use it) if you want to spend the time.
>
> Where can I find that script (URL) ?
It's in the sfw gate, in usr/src/tools somewhere. You can probably find it
on src.opensolaris.org.
> less heavywheight tools are available or (as in this case) using a
> "grep" pipeline for filtering a amount of data which is significantly
> below the size of the "grep" utilty itself, e.g. when the
> |fork()|+|exec()|-overhead significantly outwheights the amount of data
> processed
Perspective, please. This'll amount to at most a few seconds over the
course of a multi-hour build. The overhead of fork/exec is most definitely
not an issue here. Readability and maintainability are far more important,
and if the maintainer is more comfortable with grep or sed than some shell
construct, and the construct they've written is reasonably readable to
others, then there's no reason to change it. Stylistic advice is always
welcome -- it's possible that the author wasn't aware of other
possibilities, and may prefer them -- but advice is all it is.
Danek
