Thanks Chris :-)
Thanks for the heads up. Conventions are helpful.
I have replied on-list to elicit a wider view of your suggestions -- and my
Response by annotations below, prefixed with =>.
From: Chris Jones [mailto:cjns1989@...]
Sent: 05 April 2009 22:47
To: need help compiling or using dar ? This mailing list is for you.
Subject: Re: [Dar-support] [OFF-LIST] A bash backup script using dar
On Sun, Apr 05, 2009 at 06:33:30AM EDT, dar-support@... wrote:
> Hello :-)
> Here is version 0.2 of the MyBackup.sh script in case anyone is using
> it and ready for distribution with dar as a sample (if the copyright
> and licence are judged adequate).
> The changes are bugfixes and tidying up; no new features:
OFF-LIST, since this has nothing to do with dar per se:
1. I would try to find a more distinctive name than "MyBackup.sh" - and
make the name easily searchable via Google.
[Good point; I'll start thinking of a new name.
2. Long lines are harder to read. It looks like a lot of work but I
would try to limit the length of each line to something like 80
columns. There are probably lots of ways to achieve that but one I
thought of was that the code could be made a lot more compact by
limiting indentation to e.g. two columns
=> Were you viewing with tab stops set to 4?
[80 is conventional wisdom and was important when many displays were limited
to 80 character width. Now screens are bigger and graphical, the practical
limit is whether the eye can easily locate the beginning of the next line.
Personally I find the present arrangement the most usable. That's why I
=> I've tried various indentations and find 4 the optimum.
3. I had never really noticed this but it looks like vim's highlighting
does not handle files with mixed syntax correctly, and as a result
all the "awk" code appears as comments. Not sure what's the best way
to handle this or if it's possible to move that to a seprate file.
=> vim is behaving correctly if it shows almost all the awk code as bash
=> It's possible to put the awk program in a separate file but I judged the
balance of pros and cons favoured having it within the bash script.
4. I would suggest moving some of the comments at the top of your
script to separate files that are pretty much standard in the gnu
environment (README .. CHANGELOG .. etc.)
=> If it were a package, so all the files would be kept together, then yes.
As it is, not packaged and proposed as one script of many distributed in a
package, I judge the benefit of shortening the script is outweighed by a)
the danger of the script being separated from its documentation files and b)
the confusion of multiple READMEs and CHANGELOGs.
5. I believe it is customary in the gnu world to provide flags such as
-v | --version and -h | --help. The latter is particularly useful
provided you follow a few conventions, since it makes it possible to
generate a man page semi-automatically from your script via a utility
named "help2man". Not only does it save time but it also guarantees
that they are in sync'..!!
=> Version option added to the wish list. -v is also widely used for verbose
so there's a design decision coming up.
=> -h option already present. --help will come if change code to use full
facilities of recent getopt(1).
=> Thanks for pointing out help2man.
I am neither a bash or gnu programming standards expert, far from it.
As a matter of fact, I learned a few things abuot this quite recently
while writing my own bare-bones backup script!
I benefited from the advice of someone who does know what he is talking
about :-) ..
Amazingly he took the trouble to provide me with a "template" - for lack
of a better word.. that I now use with a few obvious changes whenever I
need to write a bash script.. usually a good start since I don't have to
worry about the "housekeeping" part while I'm struggling with the
"creative" part of the programming.
Since this skeleton was provided on a public mailing list, and since I
have not altered any of the copyright information, I believe that I can
attach the original version to this message for your review.
=> Thanks for the template. Using getopt(1) instead of the bash built-in
getopts has the advantage of allowing long options at the cost of more
complex code. Added to the wish list.
=> What does this line do?
: debug: $1