On Friday, 19 January 2001 at 00:54 Jörg wrote:
>All my programs use the comerr() family for error reporting for more than
16
>years. I see no reason to change this.
I also see no reason to move away from the comerr() and would agree that if
it works fine after 16 years, then you of course should keep on using it
(besides, I have no right to force people to change their own software
writing style !). That's what "code re-use" is all about (and you ought to
be congratulated for being able to do it). Since the _comerr function calls
the standard C exit() function when the exflg is TRUE, as is the case when
it is called from comerrno() or comerr(), then its err parameter *is* passed
to exit().
The few comerr() calls that exist in cdrecord are already returning error
codes taken straight from standard C's errno variable anyhow. That's
perfect as it is (and the values which are returned vary according to the
error the O/S generates).
Since most calls to comerrno() from cdrecord simply use EX_BAD (value
#defined as -1) as the value for the err parameter, all I want is for it to
be passed some other non-zero values to give the returned status code a bit
more meaning, rather than a pass/fail. So, changing some of the values
passed into comerrno() should be easy to do.
Not so long ago on this list I saw someone say "It didn't work", and I
remember that the first reply was along the lines of "Well, saying "It
doesn't work" is not enough information, tell us more". That's *EXACTLY*
what I want cdrecord to do also. I believe people and code both need to be
informative when things go wrong (Micro$oft Windoze applications are the
perfect example of what NOT to do).
>cdrecord is source ware....
Yep, I always knew this, but since I got a full RedHat 7.0 distribution and
it already had the pre-compiled cdrecord-1.9 RPM, I didn't really delve
into the source RPM from RedHat or the latest tar.gz from your web site.
What I knew was that my old and dying Linux box had cdwrite-2.0, which is
now old and unsupported, and that cdrecord was the "latest and greatest". I
personally blame RedHat ! LOL !
>UNIX does not have binaries that support all you need (except emacs ;-)
Understood. I'm certainly not a Unix newbie, and have been dabbling with
computers of all kinds since the Apple II and Sinclair ZX80 way back in
1980. Since then it's been PCs, VAX/VMS, Alpha/VMS, HP-UX, Linux, Win
3.1/95/NT4, SunOS and Solaris, plus embedded systems in elevators for over
11 years. 6502, 6805, 6303, 6809, 8085, 80x86, C, Pascal, PL/M, VB - I've
used them all.
>Instead UNIX uses a philosophy of small programs that fit a special need.
True of Unix in general, but disproven by cdrecord as a case in point. A
number of cdrecord's options aren't "core functionality" and could easily be
split off into separate programs. For example, the -scanbus, -inq, -atip
and -toc options have nothing to do with the process of actually burning a
CD-ROM. Playing devil's advocate and following through on this philosophy,
maybe they should be removed and made into small programs too ? Their
functionality is however used during the process to determine various
specifics about the CD writer and the disk in the drive. Maybe I'm
splitting hairs, but being able to test for a disk in the drive, and more
specifically a blank disk, are also equally useful, and 99% of the code is
already built into cdrecord.
Maybe I'm splitting hairs, but cdrecord on my machine is only 168828 bytes
in size, and changing the error status and doing those few extra tests might
only increase it by a few kB at most.
>>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)
>Other people are already doing this (e.g. in GUI's).
I realise this. But no-one it appears is also using a Samba connected PC to
drive the process like I am. My requirements are to have a CD-ROM burner
which can:
(a) Be driven from Linux directly
(b) Be driven from remote Unix systems running NFS, who only need the
ability to create some info files, copy files into a temp directory for
mkisofs and put the CDs into the drive
(c) Be driven from a Windows system via Samba, again where the users only
need the ability to create some info files, copy files into a temp directory
for mkisofs and put the CDs into the drive
(d) Be able to either create the ISO image using mkisofs or by copying from
a source cd using "dd /if=/dev/cdrom /of=", again from Linux/Unix/Windows.
(e) Use the same basic file-driven interface for (a), (b), (c) and (d)
rather than have to educate people in how to drive it all via a GUI on the
Linux box (which necessitates a Linux login, etc).
(f) Provide some simple GUI status messages on the Linux X-Windows desktop
using xmessage and xterm screens, so that any passerby can see that, for
example, someone has the CD "locked" for their use, the status of mkisofs /
cdrecord, and requests for new blank media (when making multiple copies of
an ISO image).
All of the GUI front-ends I've seen (refer to
http://sites.inka.de/~W1752/cdrecord/frontend.en.html) are designed with a
distinctly "log in and run this on the machine with the CD burner" focus,
which isn't what I want.
>There is a strong NO for anything that would force me not to use
>comerr() anymore.
Once again, let me re-emphasise that I'm not at all against the use of
comerr() or comerrno(), as my points above indicate. And there's no way I
would try to force you to change - it *is* after all your software in the
first place.
Does anyone out there in cdrecord userland also have any comments in support
of or against my proposal ?
I think I will make the required changes to cdrecord 1.9, publish them on
the list as diffs, and let you decide what to do with them. Naturally I'd
prefer if they were integrated back into the main cdrecord code base, since
that means it's not necessary to apply them forever and a day to each new
version that comes out.
Regards
Jason Armistead
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
