>From: "Armistead, Jason" <[EMAIL PROTECTED]>
>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.
OK, a long time ago there was something like sysexits.h In these times,
errno was between 1 & 32 ;-) and math error started at 33 so they decided
to use 64 as base for meaningful exit codes os an application (in this
case this started with UUCP somewhewre arouns 1975...).
Let's see: errno is currently in the range between 1 & 151 so let's assume
that it takes some time to reach 255 (note that the exit code is really
a char).
We then could define some error codes from -1 ... -10 or -20 to get some
meaningful values. The important ones should be close to -1.
What do you think about this solution?
>>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,
while -scanbus & -inq really might go into a separate program,
-toc needs to know secret things about the device which is only present
inside cdrecord. Do you really want me to duplicate the driver structure
of cdrecord for the sake of having -toc in a separate program?
>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:
>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.
Did you check the remote SCSI interface of cdrecord?
cdrecord may be run on a machine different to that which holds the drive.
This works even from Win32!
J�rg
EMail:[EMAIL PROTECTED] (home) J�rg Schilling D-13353 Berlin
[EMAIL PROTECTED] (uni) If you don't have iso-8859-1
[EMAIL PROTECTED] (work) chars I am J"org Schilling
URL: http://www.fokus.gmd.de/usr/schilling ftp://ftp.fokus.gmd.de/pub/unix
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
