Re: Updated check-debian-cd
> I suggest it to be added to the pseudo-image toolkit, and to be
> mentioned in the FAQ as an easy way of checking a CD after having burned
> it.
The Pseudo-Image Kit is meant to be release-independent, so I don't really
like the idea of adding this script -- if only because then a new version of
the Kit must be released with every CD revision, and that's something I don't
have the time for.
Right.
I plan to add a way to read the MD5SUMS files, in addition to the
internal database. This way, do you think that it would be reasonable
to add it to the toolkit? I am not sure, really.
But if you can put it up on some website, I'll gladly link to it from
the FAQ.
I'll do that.
> #! /bin/bash
The Kit is often used on various *UXes;
If that's the case, then okay, I'm going to remove bashisms.
In the past, I worked with a true Bourne sh of the old days, and I am
able to cope with it. But now I see that the minimum denominator is
considered ash, which is much more powerful than that. It claims to
strive to be Posix compliant.
What is considered reasonable as of today? Be conservative, and go with
the Bourne shell (whose exact characteristics are currently difficult to
check, anyway), or is Posix enough?
> echo $cdversion; exit 0 ;;
echo Program version: $programversion
echo CD version: $cdversion
I completed the administrative part of options: now I have long and
short ones, --help, --version and so on. I do not support coalescing
short options, however, because I don't know whether the new getopt(1)
is commonly present on all Unixes, the Posix `getopts' builtin does not
support long options, and I don't want to write the code to do it :-)
> bs=2048
In my own experience, a bs of 50k to 100k is much much faster than 2048 (on
IDE drives at least). I use factor(1) to determine "optimal" bs's, but (still)
didn't write some automatic tool for that purpose.
Hm. I need some info here. As a first try, I had used factor, as you
suggest, and came up with a bs=98k. But that didn't spare kernel
messages saying that I was going out of bounds. Then I went down to
bs=2k, which as far as I understand is the CD's sector lenght.
Questions (which I may all answer by trial myself, by the way):
- what is the MCD of the lengths of all CDs (is it greater than 2k)?
- if I use factor(1), what else should I consider, given my bad
experience with bs=98k (maybe only powers of 2)?
> set - $(grep "^#Id-.*'$(dd if=$iso bs=1 skip=32808 count=32 2>/dev/null)'" "$0")
> comment=$1
> len=$2
> sum=$3
Bashism? I'd do something like
infoline=`grep ... "$0"`
comment=`echo "$infoline" | cut -d ' ' -f 1`
len=`echo "$infoline" | cut -d ' ' -f 2`
sum=`echo "$infoline" | cut -d ' ' -f 3`
id=`echo "$infoline" | cut -d ' ' -f 4-`
It works the way you suggest, but you end up repeatedly calling cut(1).
The way I did it is AFAIK the *only* perfectly safe, perfectly portable
way of parsing an output line without forking a process. It worked on
old SysV Bourne shells, apart from the $(), but you used backquotes.
> if ! type -t md5sum >/dev/null; then
Bashism? Maybe this works:
if ! md5sum --help >/dev/null ; then
I did something similar (md5sum does not support --help...), but in fact
`type' is a Posix builtin (without the -t option).
> if [ "$(dd if=$iso bs=$bs count=$len 2>/dev/null | md5sum)" = $sum ]; then
Ah that's your space problem ;-)
Yes, correcting that would require "creative" quoting, and probably the
use of `eval', and I am not sure I want to do that...
Be inventive with qoutes, and don't use that $(), like
"`dd if="$iso" bs="$bs" count="$len" 2>/dev/null | md5sum | cut -d ' ' -f 1`"
= "$sum"
Double quotes inside backquotes inside double quotes? If that works,
then I discovered a new trick :-) I'll try that out.
and the last cut is needed because some md5sum's put a '-' after the checksum
as filename when reading from stdin.
Hm. Nice to know that.
Ok, I'm going to repost it when I'm finished. Thanks a lot for your
comments and suggestions.
Reply to: