Re: Updated check-debian-cd
External MD5SUMs will be quite hard to use with the autodetection,
and that's one feature I like very much. I think an always-up-to-date
program on some website will be the easiest concept for most people
to grasp ;-)
I have some ideas:
- the best thing would be to have the MD5SUMS files distributed with the
images to follow the format I used in the script. This would solve
most problems automatically, as people usually have the MD5SUMS file
in the directory where the image is or where the pseudo-image kit is.
This one is already implemented: check-debian-cd now looks in the
current and in the parent directories for MD5SUMS files and adds them
to its own internal database. It also has an option to specify a
given MD5SUMS file. To be clear, this feature is currently useless,
as the current MD5SUMS files do not have the right format.
- the second thing that I am going to implement is something like the
script saying: «I do not have this disk Id in my database, however I
have found some MD5SUMS files which contain several MD5 signatures,
and I can try to see if the image matches one of them, which usually
does the right thing: should I try?».
AFAIK every self-respecting *UX is (or wants to be) POSIX certified
today, so I suppose we can assume that /bin/sh is
POSIX-compliant.
Ok, I'll go with Posix and be sure that it works with both ash and bash.
By the way, one thing (about quoting) that works with ash, does not with
bash. I suspect a bash bug there.
> 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
I've never seen that kind of warning with any of the IDE drives I used, but
don't know about SCSI or old proprietary interfaces.
It's a fairly recent ATAPI drive. The reason why I used dd at all is
that using just md5sums on the image generates a kernel warning (instead
of just EOF). I see these:
Sep 28 13:13:26 pot kernel: hdc: command error: status=0x51 { DriveReady SeekComplete Error }
Sep 28 13:13:26 pot kernel: hdc: command error: error=0x54
Sep 28 13:13:26 pot kernel: end_request: I/O error, dev 16:00 (hdc), sector 1309084
Sep 28 13:13:26 pot kernel: ATAPI device hdc:
Sep 28 13:13:26 pot kernel: Error: Illegal request -- (Sense key=0x05)
Sep 28 13:13:26 pot kernel: Illegal mode for this track or
incompatible medium -- (asc=0x64, ascq=0x00)
In fact, knowing the size in advance and using dd only serves the
purpose of avoiding these messages. Anyway, apart form this, everything
should work even without knowing the size.
> > set - $(grep "^#Id-.*'$(dd if=$iso bs=1 skip=32808 count=32 2>/dev/null)'" "$0")
> 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.
I'd also call it a perfectly obfuscated way -- it looks much like self-
modifying code and that's generally considered a Bad Thing[tm] ;-)
I do not agree: it's a standard technique, well documented in the shell
manual. You do `set - arg1 arg2 arg3', then you have those in $1, $2,
$3. It is very handy and quick. It would be much nicer to just use
`read a b c', but unfortunately, when you use that in a pipe to read the
output of a command, the `read' often (and unpredictably around
different shells) gets executed in a different process, so the variables
are lost :-(
> I did something similar (md5sum does not support --help...), but in fact
> `type' is a Posix builtin (without the -t option).
Indeed, it "even" works in ash.. I can use that in make-pseudo-image to check
if ncftp2 is available...
Unfortunately, however, you have to redirect both stout and stderr, so
in fact it is questionable if it is clearer than doing the way you
suggested.
Reply to: