Jyri Virkki wrote:
> Roland Mainz wrote:
> > Please use [...]
>
> I'd find it useful it you could state comments in terms of the
> reasoning behind them, not just the end result. That would convey more
> info and be a lot more educational..
>
> Instead of "Please use ____", I'd prefer to see something along the
> lines of "Your current code _____ will break when _____ and _____
> happens, you can fix this by using ______ instead" or some such explanation.
> TIA..
Erm... Ok...
- The quoting of variables is mainly for robustness, e.g. hardening the
scripts to limit the damage if any part of the script "goes wild". A
Boune/POSIX/ksh/bash-like shell will split variables based on the
content of the IFS variable (see sh(1) and ksh93(1) for explanations),
e.g. if the variable "foo" contains one of the charatcers listed in IFS
the expension will be split into a new "words" for each of these "field
delimiters". For example imagine something like this $ x="hello.txt" ;
rm -rf $x # - which will work perfectly "fine" to delete the file
"hello.txt". However if "x" contains something like "Error: Can't write
to file /etc/passwd" then "rm -rf" will attempt to delete the files
"Error:", "Can't", "write", "to", "file" and "/etc/passwd" (the result
will be... erm... "interesting" ...).
The whole mess can be prevented by either putting variable expansions
into quotes (e.g. $ ... rm -rf "$x" # in the example above) or setting
IFS to an empty string (e.g. '') ... however this is only reliable in
POSIX-like shells (e.g. ksh93+bash... I'm not sure about ksh88
(=/usr/bin/ksh) ) and not the old Bourne shell
- The "dot ('.') vs. 'source'"-issue is explained in
http://www.opensolaris.org/os/project/shell/shellstyle/#use_source_not_dot
- "function foo { ... }" v. "foo() { ... }" is explained in
http://www.opensolaris.org/os/project/shell/shellstyle/#use_ksh_style_function_syntax
- for ksh88 (=/usr/bin/ksh)-style scripts there is no difference between
the two types of functions while ksh93 (=/usr/bin/ksh93) follows the
POSIX standard and doesn't provide a seperate scope (e.g. local vars,
local traps etc.) for Bourne-style functions (as a result ksh93 is much
more compatible to the original Bourne shell than ksh88 or bash). The
issue hits back when we want to migrate /usr/bin/ksh to ksh93 (see
Indiana) where we have to make sure that the old ksh scipts which use
local vars/traps/etc. with Bourne-style function syntax doesn't trip
over this issue. That's why it may be better to use the ksh-style
function usage for ksh88/ksh93 scripts because it's guranteed to work
the same way in both types of shells.
- 'Please remove the extra "cat" ...' means you're create an extra
process in a pipe chain which isn't neccesary (e.g. the operation is a
"no operation").
- "Please combine both redirections into one" was about the detail that
things like...
-- snip --
echo "foo0" >x.txt
echo "foo1" >>x.txt
echo "foo2" >>x.txt
echo "foo3" >>x.txt
echo "foo4" >>x.txt
echo "foo5" >>x.txt
-- snip --
... are very inefficinet since each redirection (e.g. either ">" or ">>"
in this case) will trigger an |open()|, |write()|, |close()|-sequence
for each "echo".
The number of |open()|+|close()| calls can be reduced to two by putting
the redirection into a shell "block", e.g.
-- snip --
{
echo "foo0"
echo "foo1"
echo "foo2"
echo "foo3"
echo "foo4"
echo "foo5"
} >x.txt
-- snip --
(and see
http://www.opensolaris.org/os/project/shell/shellstyle/#group_identical_redirections_together)
- The "... please put quotes around variable expenansions when followed
by a dot ('.') ..." is based on the problem that some shells like ksh93
allow the dot in variable names - and without the brackets it's
disambigous how to proceed in this case (from the shell parsers point of
view... the current shell implementations stop at dot if the name is not
surrounded by curly brackets but that doesn't gurantee anything...).
- The 'Please bundle multiple "rm" calls'-thing is to avoid unneccesary
|fork()|+|exec()| calls (based on the behaviour what happens if you do
some adjustments to the OS/Net tree - just cleaning this up saves a few
hundred |fork()|s).
... erm... is there anything else which needs explanations (and "yes"
... I'm slowly moving into the direction of a "shlint" utilty which
should do this kind of checks automagically ("shcomp" added with
http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6561901 will
form the basis for such a tool...)) ?
> > General note for this type of script: Please add a $ set -o errexit # at
> > the beginning that the script - the "errexit" flag causes the shell to
> > immediately abort the script when it hits a command which returns a
> > failure instead of continuing operation (and maybe running amok (or
> > worse) ...)
>
> There was some discussion on this topic back in:
> http://www.opensolaris.org/jive/thread.jspa?threadID=44599&tstart=0
> but it appears inconclusive. Instead of every build piece doing something
> different, there needs to be consistency.
AFAIK Danek used "ksh -e" for his script which has the same effect as
"set -o errexit" (I prefer the longer options with a comment, that's why
I stuff the seperate lines into the scripts)
> Is there an existing rule or convention for SFW here?
AFAIK there isn't such a rule... and sometimes I'm tempted to file a bug
and then just fix all the SFWNV scripts... the question is whether there
is anyone willing to sponsor such a monster patch...
... erm... are there any volunteers ?
> If not, we
> should discuss and decide on one.
Ok...
... who is the gatekeeper for SFWNV ?
----
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland.mainz at nrubsig.org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
