Hi Jörg
Thanks for the response to my request.
My motivations, while perhaps a bit selfish (to solve my own problems), also
have broad application too, which I'm sure all users of cdrecord who want to
use it in an automated, script-driven way would appreciate.
Regarding error codes, cdrecord is smart enough to detect a wide range of
error / status conditions. Why not give a more meaningful return value ?
At most points in the code you know what the error condition is (e.g. no
disk in drive, disk finalised, not enough space on disk for another track,
etc)
I was unaware of readcd (initially I just used the pre-built RedHat RPM
which doesn't appear to include it). Thanks for the pointer to it. I've now
compiled it from the source tar.gz distribution.
I agree that I could use readcd to detect the CD in the drive (using the
method you indicated), but it is just one more thing that is needed. For
the sake of having one executable which does it all, how about just
including the functionality I am suggesting into cdrecord ?
Similarly, I *could* use cdrecord -toc in a script and then write something
which reviews the output using sed/awk/grep or similar and searches for the
track list information. However, I am then reliant on each successive
version of cdrecord doing it in *exactly* the same way, or it will break my
script.
To summarise:
1. I believe people want to use cdrecord in scripts, to automate the whole
CD creation process (as it is they're probably already running a simple
script to use mkisofs beforehand)
2. Using multiple different exit status values from cdrecord makes error
handling in a script much easier, and less prone to breaking if and when
cdrecords textual error messages to stderr/stdout get changed (for example,
if facilities for output of status messages in different languages are
added). The test for exit status is much easier to do than the parsing of
stdout/stderr to determine what happened.
3. Testing for media in the drive, and testing for blank media are two
reasonable functions that people would use if automating the cdrecord
process. And cdrecord *already* has most of the functionality built in to
do just that ! It could likewise be argued that getting the ATIP and TOC
information with the -atip and -toc switches is also not part of the "core
functionality" of cdrecord, and perhaps they should be handled separately
too. All I'm asking is that similarly useful CD-ROM functions are also
considered as being a worthwhile part of cdrecord.
Jörg, would you be happy enough if I made the changes to the cdrecord source
code myself, and you then integrated them back into cdrecord ? Or are you
outright saying "NO" to my proposal ?
Regards
Jason Armistead
Senior Systems and Software Engineer
OTIS Minto, Australia
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Thursday, 18 January 2001 01:57
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: Request for change to cdrecord to provide status return
codes
>From: "Armistead, Jason" <[EMAIL PROTECTED]>
>I'd like to know if cdrecord could be easily modified to return some
>meaningful status codes when things go wrong, but more particularly,
whether
>cdrecord could return an exit value when there is no disk in the drive.
The
>man pages don't really indicate that there are specific error codes
returned
>in specific circumstances, and a quick look at the source would tend to
>suggest that basically either 0 or -1 are returned by the exit() calls.
Cdrecord returns errno on errors if available (else -1).
>It would be good if cdrecord could have an extra couple of command line
>switches that allowed the following (of course "dev=x,y,z" is assumed, or
>the environment strings are set already):
>cdrecord -diskindrive : Returns 0 if there is a disk in the drive, or -1
if
>the drive is empty
readcd dev=6,0 sectors=0-0 f=/dev/null 2>&1 > /dev/null
returns 0 if a disk is present.
>cdrecord -diskempty : Returns 0 if there is a disk in the drive and it's
>empty, -1 if there's a disk in the drive and it has no TOC written, and -2
>if there's a disk in the drive with a TOC written (and maybe -3 if there's
a
>disk in the drive with a TOC written but is finalised so no more data can
be
>added anyhow).
If there is a disk and cdrecord -toc gives no track list, then the disk is
empty.
Jörg
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
