Date: Mon, 1 Jun 1998 19:44:00 +0200 (MET DST) From: Joerg Schilling <schilling@fokus.gmd.de> To: mike@smith.net.au, schilling@fokus.gmd.de Cc: dufault@hda.com, freebsd-current@FreeBSD.ORG Subject: Re: cdrecord trouble on currnet Message-ID: <199806011744.TAA17106@sherwood.gmd.de>
next in thread | raw e-mail | index | archive | help
>From mike@antipodes.cdrom.com Mon Jun 1 18:34:21 1998
>> >Only if you promise not to give me trouble about errx - as a FreeBSD
>> >utility their coding standard says to use that, and when
>> >in Rome do as the Romans do.
>> =
>> To make it portable, I'll need to replace them with my routines
>> comerr() comerrno() errmsg() and errmsgno() wich I am using since 1982 =
>- =
>> long before BSD intruduced things like that.
>> =
>> I have no problems with these functions as I believe that it neccessary=
> to =
>> have readable error messages and perror() don't makes good error messag=
>es.
>Great. Replace a set of standard error reporting functions with older, =
>nonstandard ones. 8) This really sinks most of the rest of your argument,=
>unfortunately.
You are right from the view of a *BSD user but from the view of a mainstream UNIX
user the BSD functions are non standard too and in addition non portable.
My functions are portable though.
>> I believe the suing with AT&T has been won and there is no need to mak=
>e
>> programs look like they are not from a UNIX system.
>Bear in mind that BSD is half of the Unix family tree. The BSD libc =
>API is at least as valid as any other. The err() family of functions =
>are mainstream from 4.4BSD, so they are shared with all the current BSD =
>family.
As long as err() is not portable, I prefer my functions which are even older
then the *BSD ones.
Around 1990 the number of pure BSD users did go dramatically down because
many vendors switched over to SVr4. No commercial UNIX incorporated things
from 4.4BSD (if I rememer correctly) in contrary to the former behaviour of
these companies.
I believe that > 80% of all UNIX users have no access to err().
So I cannot call 4.4BSD mainstream or half the UNIX tree.
>> - Put all non standard library extensions into a separate
>> libbsd and make this library portable.
>> ( you may add this library to the default library list of the
>> compiler on *BSD so there will be no need to change makefiles)
>What you are suggesting you want here is a portable "libbsd". This =
>will need more than just "non-standard" library extensions, as the =
>alternative would be to put almost all of the BSD library in here.
>Rather, what needs to be done is for someone that wants to port BSD =
>programs to other platforms to take the BSD libc and extract all those =
>components which are a superset of the desired target platform(s) APIs =
>and build a libbsd suited to each of the deficient targets.
>There is not likely to be much support for political emasculation of =
>the BSD API.
No doubt, there is a need for UNIX utilities with better error printing
and standardized bahaviour and many ideas from 4.4 BSD are not bad, but
they are not available outside *BSD.
As one exaple, I now have my own termcap library that implements the
exellent idea of the TERMPATH environment. The 4.4BSD version could
not be used because it relies on the nonstandard BSD database system.
OK, I already started my termcap library in 1986 so there was no need for
the full effort of the complete implementation. BTW: I am using enhanced
versions of tgoto() and tputs() because these functions are portable.
I would not be able to log into diffrent UNIX systems if I would not
use my own portable editor that uses native termcap. Terminfo is binary
and non portable. If I log in and the local vi screws up my terminal
I would be lost. Unfortunately nearly all UNIX systems screw up your
terminal if you log in from a Sun.
I hope you see, that I am sad to see that the BSD folks writes good software
that cannot be shared without using the *BSD operating system. From my point
of view this is not the right idea of free software.
>> P.S.
>> I believe that the real problem might be that your program comes with a=
> BSD
>> license while my software comes with GPL.
>This is never a problem; BSD code can always be incorporated into a GPL =
>product without having any significant impact on the GPL. The reverse =
>is, regrettably, not the case.
>> In any case, it seems to be a good idea to have a combination of a
>> command line interpreter which allows easy sending of arbitrary command=
>s
>> and a portable SCSI transport library.
>No kidding. This would be a very useful tool, especially if it were =
>basically a library which could be linked with either a simple =
>line-reading frontend or an application program...
For disk formatting / analyze or repair, I would suggest my 'sformat'
program. I wrote it starting from 1986 and SunOS 3.0.
It was even the first SCSI disk formatting program that runs on SunOS
(before Sun introduced their format program) before standalone programs
have been used.
I just finished 99% of the new version 3.4. It incorporates most of the
portability know how from the actual cdrecord and it has much special
knowledge how to handle disks.
For other applications, I find a SCSI command line interpreter very useful
for all operating systems.
So please tell me whether you so called scsinew is the actual /sbin/scsi
I found on the FreeBSD ftp server.
Jörg
EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
js@cs.tu-berlin.de (uni) If you don't have iso-8859-1
schilling@fokus.gmd.de (work) chars I am J"org Schilling
URL: http://www.fokus.gmd.de/usr/schilling ftp://ftp.fokus.gmd.de/pub/unix
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199806011744.TAA17106>