From: Digestifier To: Linux-Development@senator-bedfellow.mit.edu Reply-To: Linux-Development@senator-bedfellow.mit.edu Date: Wed, 1 Dec 93 17:13:17 EST Subject: Linux-Development Digest #281 Linux-Development Digest #281, Volume #1 Wed, 1 Dec 93 17:13:17 EST Contents: Re: How many BogoMips on a washing machine? (Frederic PIERRE) Re: 0.99pl14: scsi slow? (Eric Youngdale) Re: Further Linux 680x0 developement? (Systemkennung Linux (noalias)) Re: copy-image-to-partition dd.exe wanted (Andreas Helke) patches for term for alpha/osf1.3 (Craig I. Hagan) Re: Free Software and Motif (was: Re: Don't use Motif for free sw: ...) (Chris Flatters) Re: Appletalk under LINUX? (Alan Cox) Re: Zooming a bitmap/pixmap (Harald Milz) Re: Don't use Motif for free sw: it now requires runtime royalties! (Peter Mutsaers) Re: Further Linux 680x0 developement? (Hamish Macdonald) Re: Free Software and Motif (was: Re: Don't use Motif for free sw: ...) (A. Bryan Curnutt) Re: Auto port detection for a 3c501? (Jason Cash) Sample generic SCSI code (Lawrence Foard) Re: Comments from the "TAMU Crap" author (H. Peter Anvin N9ITP) Re: Free Software and Motif (was: Re: Don't use Motif for free sw: ...) (Peter Mutsaers) Re: Creeping featuritis (post --rant --flame) (D. J. Bernstein) ---------------------------------------------------------------------------- From: fred@sobel.u-strasbg.fr (Frederic PIERRE) Subject: Re: How many BogoMips on a washing machine? Date: 1 Dec 1993 15:33:03 GMT Ronald van Loon (rvloon@cv.ruu.nl) wrote: : In a09878@giant.rsoft.bc.ca (Curt Sampson) writes: : |"rabe@akela.informatik.rwth-aachen.de (Ralf G. R. Bergs) writes: : |" : Mine gets 15.32, LL HW HW Bogomips. (light load, hot wash, hot water). ^^^ ^^^ in c.o.l.d. you're kidding, I guess # ## ### # # # ##### # # # ### # # ## : -- : Ronald van Loon / More computing sins are committed in the name : Maintainer of Motif++ / of efficiciency (without necessarily achieving it) than : Job offers welcome / for any other single reason - including blind stupidity. : (rvloon@cv.ruu.nl) / -- attributed to W.A. Wulf -- , , Frederic. ==,=,===========================================,========================== Frederic PIERRE. ENSPS/LSIT 7 rue de l'universite F-67000 Strasbourg FRANCE Tel: (33) 88 35 80 84 Fax: (33) 88 35 31 76 e-mail: fred@sobel.u-strasbg.fr ==================HamRadio: F1HFD (back to one letter prefix!)============= ------------------------------ From: eric@tantalus.nrl.navy.mil (Eric Youngdale) Subject: Re: 0.99pl14: scsi slow? Date: Wed, 1 Dec 1993 15:45:04 GMT In article <2di2j2$46f@sun8.ruf.uni-freiburg.de> suettpet@sun1.ruf.uni-freiburg.de (Peter Suetterlin) writes: >Hi there > >Yesterday, I upgraded to the new kernel version 0.99pl14. (I have installed >Slackware 1.1.0). As I have read in the announcement, there has been some >work on the scsi-drivers. So, I tested the performance of the new version >using bonnie (posted on the net some days ago). This is what I got: There has been some work, but the performance of pl14 should be very close to the performance of pl13. >The new version seems remarkably slower, at least in sequential block IO. >Is this due to some 'improvements' of the new driver, or what's going on? >Anyway, the performace isn't very well at all (the drive is a 512Mb SCSI-2 >Fujitsu, Buslogic BT-445s controller), allthough you don't really recognize it >when working due to the good cache of linux (I have 16Mb RAM) Again, I do not know why the perofrmance dropped. I am not familiar with bonnie - could someone email me the source code? There is clustering code out there which dramatically improves the datarates for scsi disks. I hope to have a fresh version of the patches for pl14 in a day or two - I am waiting to hear whether a patch that I made actually fixed a hanging problem that one person saw. -Eric -- "The woods are lovely, dark and deep. But I have promises to keep, And lines to code before I sleep, And lines to code before I sleep." ------------------------------ From: linux@informatik.uni-koblenz.de (Systemkennung Linux (noalias)) Subject: Re: Further Linux 680x0 developement? Date: 1 Dec 1993 15:57:08 GMT |> 1) How many people are working on Linux 680x0? As Linux is no commercial product of a company which can count their employes, I wouldn't even dare to guess a number. But I still hope the number of developers to increase, as Linux 680x0 reaches a state which makes it useable for more people than just some 'hardcore kernel coders'. |> 2) Is there a special newsgroup? Not yet. But there is a channel named '680x0' on the internet mailing list. And there is already a Fido news group named LINUX-68K.GER available. If you can't get this Area, write to Gero Horstmann@2:245/5618. |> 3) Which graphic cards will be or are going to be supported (Amiga?) Currently there is only support for the built in chipset. The A2024 and the AGA chipset are already being supported, but that code hasn't been released yet. |> 4) Will there be an EGS-support (is it possible?) ? No. EGS is a AmigaDOS standard and useless for another OS. --Ralf -- Ralf Baechle Internet: linux@informatik.uni-koblenz.de Fido: Ralf Baechle 2:245/5618.2 Mud: arrow@Mythos ------------------------------ Crossposted-To: comp.os.msdos.misc From: andreas@orion.mgen.uni-heidelberg.de (Andreas Helke) Subject: Re: copy-image-to-partition dd.exe wanted Date: Wed, 1 Dec 93 16:21:19 GMT ps@ocisgi7 wrote: : With plain vanilla DOS, you can do it a hard way: re-read your : debug manual (hint: pay special attention to r and w commands ;), and : you'll see how to do it... I wanted to use this trick to share my swap partition between Linux and MS-Windows. I had one big problem: Debug did not want to restore my bootsektor, fat and rootdirecotry, because it did not find the MSDOS filesystem which was destroyed by it's use as Linux swap, and should have been recreated by debug. This means I have to waste 10 or 20 seconds to create a new filesystem with format first. :-( And I have not yet found the proper place to insert a dd command into the shutdown sequence on a non sysv init using Linux system. (/etc/brc does not exist on my system) Andreas -- Andreas Helke Institut fuer molekulare Genetik, Universitaet Heidelberg Im Neuenheimer Feld 230 69122 Heidelberg ------------------------------ From: hagan@opine (Craig I. Hagan) Subject: patches for term for alpha/osf1.3 Date: 1 Dec 1993 16:33:26 GMT Reply-To: hagan@opine.cs.umass.edu Hi, here are my patches to get term to compile under OSF1.3 on an alpha: add the lines #if defined(__OSF1__) || defined(__OSF__) || defined(__osf__) #define USE_FCNTL #define USE_TCATTR #define ERR_BLOCK EWOULDBLOCK #define USE_SETPGRP #define USE_SIGWI #undef USE_VHANGUP #endif to config.h -- craig ------------------------------ Crossposted-To: comp.infosystems.www,comp.windows.x,comp.windows.x.i386unix From: cflatter@nrao.edu (Chris Flatters) Subject: Re: Free Software and Motif (was: Re: Don't use Motif for free sw: ...) Date: 01 Dec 1993 17:27:23 GMT In article ellis@nova.gmi.edu (R. Stewart Ellis) writes: Actually Sun and AT&T bid OpenLook, but the whole point of OSF was to put roadblocks in front of Sun and AT&T. HP, DEC and IBM recognized the threat of the new juggernaut. Motif was chosen partially because of its resemblance to the OS/2 windows and HP's OO addon to Windows (what was it called?). Sun and AT&T submitted an early version of what is now OLIT which did not have the look and feel of the OPEN LOOK UI that eventually developed. The appearence was pretty shoddy in the early stages and there were some problems with the relative immaturity of the OPEN LOOK toolkit. In addition I believe that the ground rules for Motif required CUA compatibility (I'm not 100% sure of this) so OPEN LOOK may have lost out even if a mature form were available at the time. The development of Motif was stimulated by a widely held belief that the lack of an easy to use graphical interface was holding up the spread of UNIX in non-technical application areas. This turned out to be simplistic but there was an attitude that this needed to be fixed and quickly. Sun/AT&T were known to be developing a "standard" GUI for SVr4 but it wasn't yet ready so it is possible that some members of OSF may have wanted Motif to have a high priority so that they could head the Sun/AT&T alliance off at the pass. However this probably wasn't the overriding factor in what happened and certainly wasn't a big influence on the technical committee that put Motif together out of the bits and pieces that were submitted (and who, after all, had to present a rationale for their decisions). In retrospect, the results of the Motif RFT process were almost inevitable given the state of things at the time that it was done and the rules under which the committee was operating (which were not specific to the Motif project). Chris Flatters cflatter@nrao.edu ------------------------------ From: iiitac@swan.pyr (Alan Cox) Subject: Re: Appletalk under LINUX? Date: Wed, 1 Dec 1993 17:17:51 GMT In article <1993Nov30.130114.29466@sun0.urz.uni-heidelberg.de> hare@mathi.uni-heidelberg.de (Hannes Reinecke) writes: >Michael Griffith (grif@ucrengr.ucr.edu) wrote: >: In article <2ddnh9$dhf@tamuts.tamu.edu>, >: Troy Thoele wrote: >: Easy. Get CAP (the Columbia Appletalk Package). It does this type of >: stuff and more. > >Oh Really ? Did you got it RUNNING ? If so, I'd be HIGHLY interested in the >port of the /dev/nit or /dev/enetfilter for linux. SOCK_PACKET is in pl14 and does what you want and more cleanly that the enetfilter bogosity. > >Sorry for the sarcasm. Until now I didn't see any way to get it ported to >Linux because it needs network devices that operates in promiscous mode, Its in pl14... >i.e. that fetches all packets on the network and not only the packets addressed >to it. From what I've learned, Linux Network Code didn't support it yet. >And I'm not sure if it does it ever, since it is a hardware function and the >common cards didn't support this feature. Garbage. Some cards aren't too hot om multicast but all do promiscuous mode, not that that is even the problem with CAP. Alan iiitac@pyr.swan.ac.uk ------------------------------ Crossposted-To: comp.windows.x.motif From: hm@seneca.ix.de (Harald Milz) Subject: Re: Zooming a bitmap/pixmap Date: Wed, 1 Dec 1993 07:09:46 GMT Reply-To: hm@seneca.ix.de Anna Hondroudakis (ah@dcs.ed.ac.uk) wrote: : > Dear Netters, : > I am looking for a program or utility to zoom in and out of a bitmap or : > a pixmap for a Motif application. Ideally I would have a pixmap on a : > Drawing Area that could be enlarged or reduced upon the user's request. : > Any help would be very welcome. While this is no question for c.o.l.d. :-(, there's the pbmplus package, xv and ImageMagick. Hope this helps. Ciao, hm -- _ _ _ _ __ __ _ _ E-Mail: hm@seneca.ix.de | |_| |__ _ _ _ __ _| |__| | | \/ (_) |___ | _ / _` | '_/ _` | / _` | | |\/| | | |_ / |_| |_\__,_|_| \__,_|_\__,_| |_| |_|_|_/__| ------------------------------ Crossposted-To: comp.infosystems.www,comp.windows.x,comp.windows.x.i386unix,comp.windows.x.motif,gnu.misc.discuss,comp.sources.d From: muts@compi.hobby.nl (Peter Mutsaers) Subject: Re: Don't use Motif for free sw: it now requires runtime royalties! Date: Tue, 30 Nov 1993 19:16:30 GMT >> On Mon, 29 Nov 1993 06:00:59 GMT, aad@dvorak.amd.com (Anthony >> A. Datri) said: AAD> One of things that bothers me about both 386BSD and Linux is AAD> that there appear to be a near infinite number of variations, AAD> and nobody will so much as explain what "SLS" is supposed to AAD> mean. Linux is pretty consistent. But there are many distributions. The core however: the kernel and the C library, are maintained by one person each, and are the same everywhere. Also most other base packages, like gcc, X11 etc. come in standard releases. The combination of everything, including all tools, differs each time however. -- _______________________________________________________________ Peter Mutsaers, Bunnik (Ut), the Netherlands. ------------------------------ From: Hamish.Macdonald@bnr.ca (Hamish Macdonald) Subject: Re: Further Linux 680x0 developement? Date: 1 Dec 1993 18:11:03 GMT >>>>> On 01 Dec 1993 10:57:08 EST, >>>>> In message <2dieskINNcp7@mailhost.uni-koblenz.de>, >>>>> linux@informatik.uni-koblenz.de (Systemkennung Linux (noalias)) wrote: |> 2) Is there a special newsgroup? Linux> Not yet. But there is a channel named '680x0' on the internet Linux> mailing list. That's the "linux-activists" mailing list. There is also some activity in the comp.unix.amiga newsgroup. Linux> |> 3) Which graphic cards will be or are going to be supported (Amiga?) Linux> Currently there is only support for the built in chipset. The Linux> A2024 and the AGA chipset are already being supported, but that Linux> code hasn't been released yet. The best answer is that graphics cards/systems that people write support for will be supported. That will include ECS. ------------------------------ Crossposted-To: comp.windows.x,comp.windows.x.i386unix From: bryan@Stoner.COM (A. Bryan Curnutt) Subject: Re: Free Software and Motif (was: Re: Don't use Motif for free sw: ...) Date: Tue, 30 Nov 1993 07:36:06 GMT In article rhealey@sirius.aggregate.com (Rob Healey) writes: > I still can't believe the industry was suckered in to swallowing a > proprietary L&F for something as fundemental as a user interface. B^(. The L&F isn't proprietary. Only the implementation is. The situation seems very similar to Sun's ONC (which includes NFS), which nearly everyone licensed from Sun rather than writing their own implementation. That didn't stop a few people from writing their own implementation based on the open specification. -- Bryan Curnutt Stoner Associates, Inc. bryan.curnutt@stoner.com (713)626-9568 voice (713)622-7832 fax ------------------------------ From: cash@stimpy.eecis.udel.edu (Jason Cash) Subject: Re: Auto port detection for a 3c501? Date: 1 Dec 1993 19:24:12 GMT In article <1993Dec1..ch> nieuwhzn@dxgsia.cern.ch (Gerrit Nieuwenhuizen) writes: >davem@extro.ucc.su.OZ.AU (David Monro) writes: [discussion of 3c501 deleted] > >Does this mean that the 3c501 is supported by Linux? >When I looked in the supported hardware I saw that only >its 16bit brother (3c503 or similar) was in the kernel >device drivers. From the Ethernet-howto: 3c501 Too brain-damaged to use. Available surplus from many places. Avoid it like the plague. Again, do not purchase this card, even as a joke. It's performance is horrible, and it breaks in many ways. It seems as if Donald Becker wants to discourage the use of this card under any circumstances, but he also admits to writing some "_really_ unsupported" drivers for it. See the Ethernet-howto for the details. > > Gerrit J. van Nieuwenhuizen > nieuwhzn@dxgsia.cern.ch > (or NIEUWHZN@VXWA80.CERN.CH) Jason Cash cash@udel.edu ------------------------------ From: entropy@world.std.com (Lawrence Foard) Subject: Sample generic SCSI code Date: Wed, 1 Dec 1993 19:27:31 GMT Sample generic scsi code that several people have requested follows: Run this shell script first setupsg: #!/bin/sh mknod /dev/sga c 21 0 mknod /dev/sgb c 21 1 mknod /dev/sgc c 21 2 mknod /dev/sgd c 21 3 mknod /dev/sge c 21 4 mknod /dev/sgf c 21 5 mknod /dev/sgg c 21 6 mknod /dev/sgh c 21 7 #Could be more if LUN's used ln -s /usr/src/linux/drivers/scsi/sg.h /usr/include/linux =================END=========================================== scsi.h: /* list of SCSI commands taken from kernel code */ #define TEST_UNIT_READY 0x00 #define REZERO_UNIT 0x01 #define REQUEST_SENSE 0x03 #define FORMAT_UNIT 0x04 #define READ_BLOCK_LIMITS 0x05 #define REASSIGN_BLOCKS 0x07 #define READ_6 0x08 #define WRITE_6 0x0a #define SEEK_6 0x0b #define READ_REVERSE 0x0f #define WRITE_FILEMARKS 0x10 #define SPACE 0x11 #define INQUIRY 0x12 #define RECOVER_BUFFERED_DATA 0x14 #define MODE_SELECT 0x15 #define RESERVE 0x16 #define RELEASE 0x17 #define COPY 0x18 #define ERASE 0x19 #define MODE_SENSE 0x1a #define START_STOP 0x1b #define RECEIVE_DIAGNOSTIC 0x1c #define SEND_DIAGNOSTIC 0x1d #define ALLOW_MEDIUM_REMOVAL 0x1e #define READ_CAPACITY 0x25 #define READ_10 0x28 #define WRITE_10 0x2a #define SEEK_10 0x2b #define WRITE_VERIFY 0x2e #define VERIFY 0x2f #define SEARCH_HIGH 0x30 #define SEARCH_EQUAL 0x31 #define SEARCH_LOW 0x32 #define SET_LIMITS 0x33 #define PRE_FETCH 0x34 #define READ_POSITION 0x34 #define SYNCRONIZE_CACHE 0x35 #define LOCK_UNLOCK_CACHE 0x36 #define READ_DEFECT_DATA 0x37 #define COMPARE 0x39 #define COPY_VERIFY 0x3a #define WRITE_BUFFER 0x3b #define READ_BUFFER 0x3c #define READ_LONG 0x3e #define CHANGE_DEFINITION 0x40 #define LOG_SELECT 0x4c #define LOG_SENSE 0x4d #define MODE_SELECT_10 0x55 #define MODE_SENSE_10 0x5a /* command packets */ struct inquiry { struct sg_header header; unsigned char cmd; unsigned char lun; unsigned char junk1[2]; unsigned char ttf; unsigned char junk2; }; ====================================END========================= Compile this program, it will list the scsi devices on your machine using the inquiry SCSI command. scsi.c: /* Simple sample program for generic scsi devices written by Lawrence Foard this code is distributed as is, and may be used in anyway you wish, however you must accept full responsibility for any and all problems resulting from its use. */ #include #include #include #include "scsi.h" do_inquiry(int fd) { struct inquiry inquiry; struct sg_header header; char rbuff[300],*result; int i; inquiry.cmd=INQUIRY; inquiry.lun=0; inquiry.junk1[0]=inquiry.junk1[1]=inquiry.junk2=0; inquiry.ttf=255; inquiry.header.pack_len=sizeof(struct inquiry); inquiry.header.reply_len=300; /* printf("writting packet\n"); fflush(stdout);*/ if (-1==write(fd,&inquiry,sizeof(inquiry))) { perror("write"); exit(1); } /* printf("waiting for response\n"); fflush(stdout);*/ if (-1==read(fd,rbuff,300)) { perror("read"); exit(1); } result=rbuff+sizeof(struct sg_header); memcpy(&header,rbuff,sizeof(struct sg_header)); /* printf("%d %d\n",header.pack_len,header.reply_len);*/ printf("Type: %d\n",result[0]); printf("Vendor: "); for(i=8;i<16;i++) { if ((result[i]>=20) && i=20) && i==--< | act I have programmed a computer. . . \ / You are ~1,000,000,000,000,000 .1ms NAND gates have a nice day. . . . \/ The true theory of everything will run on a finite turing machine. . . . ------------------------------ Crossposted-To: comp.windows.x.i386unix From: hpa@ahab.eecs.nwu.edu (H. Peter Anvin N9ITP) Subject: Re: Comments from the "TAMU Crap" author Reply-To: hpa@nwu.edu (H. Peter Anvin) Date: Wed, 1 Dec 1993 19:46:46 GMT In article <1993Nov30.171408.4161@kf8nh.wariat.org> of comp.os.linux.development, bsa@kf8nh.wariat.org (Brandon S. Allbery) writes: > > ...only if it's for a supported chipset. Check the OS/2 Installation Guide. > And in any case, while you might be able to do it with Linux dosemu, > you can't > do it *portably* with *every* *ix that XFree86 runs on. XFree86 is > NOT Linux-specific! I think it (or its predecessor, X386) existed > before Linux did. > Well, *OF COURSE* it is only for supported chipsets. So is XFree86; you would be hard-pressed to use it with a chipset that's not in the list of supported ones (unless you're talking running it in VGA-only mode). Also, there is a portable way to get into real mode on *every* *single* *OS* running on the 386/486 platform, it is called a boot floppy. You could boot from a floppy with a program that would simply probe the video board, write the info to the floppy, then reboot the real OS. Voila, no compatibility problems, since as far as I know every *ix running on 386/486 machines let you access a floppy without a filesystem as a /dev-ice. I only mentioned the Linux VM86 mode as a simplification; it doesn't seem that difficult to implement a program that could work either way. On a related note I greatly thank the XFree86 team for their work (the result of which I use on a daily basis in my job), and I think their policy of maintaining maximum portability between platforms is a very good idea. /hpa -- INTERNET: hpa@nwu.edu FINGER/TALK: hpa@ahab.eecs.nwu.edu IBM MAIL: I0050052 at IBMMAIL NeXTMAIL: hpa@speedy.acns.nwu.edu FIDONET: 1:115/511 or 1:115/989.4 HAM RADIO: N9ITP or SM4TKN Have you kissed your Swede today? ------------------------------ Crossposted-To: comp.infosystems.www,comp.windows.x,comp.windows.x.i386unix From: muts@compi.hobby.nl (Peter Mutsaers) Subject: Re: Free Software and Motif (was: Re: Don't use Motif for free sw: ...) Date: Tue, 30 Nov 1993 19:33:31 GMT >> On Mon, 29 Nov 1993 18:49:10 GMT, rhealey@sirius.aggregate.com (Rob >> Healey) said: RH> to the UNIX(tm) market you MUST use OSF Motif L&F, you have NO RH> other choice. Historically MONOPOLYS are usually bad news for RH> everyone except the MONOPOLY itself. This is the real issue here. As I mentioned before, there are alternatives, e.g. Tcl/Tk. Industry often (not even always) requests Motif *look and feel*, but they don't give a d*mn about the implementation. We made a custom application for a company who required Motif look and feel. We used Tk, and they were pleased with the result (and surprised about the quality of public domain software; they use it now for in house use as well). There are also some shrink wrapped commercial packages on the market that were built with Tk. Since the Motif spec is in the public domain now, it is legal to promote your application as a Motif application, even when OSF's libraries were not used to make it. RH> Hopefully a Free implementation of the L&F will come out in the RH> near future to provide a "balance of terror" so to speak against RH> OSF's wild and wacky licensing. That would add to the good news, but is maybe superflous since Tk is already there. -- _______________________________________________________________ Peter Mutsaers, Bunnik (Ut), the Netherlands. ------------------------------ From: djb@silverton.berkeley.edu (D. J. Bernstein) Crossposted-To: gnu.misc.discuss Subject: Re: Creeping featuritis (post --rant --flame) Date: 1 Dec 93 04:00:22 GMT In article mib@geech.gnu.ai.mit.edu (Michael I Bushnell) writes: > In article <1993Nov3004.29.31.28914@silverton.berkeley.edu> djb@silverton.berkeley.edu (D. J. Bernstein) writes: > UNIX makes it so easy to avoid writing the same code again and again and > again. Why don't you take advantage of that? > The splitting program also needs to tell tar where the splits occur, > because each tape has to have a volume header. Use your imagination, Mike. It took me about five seconds to come up with a workable solution. (Hint: tar can produce more output than will end up being stored.) I'm sure that we can keep playing this game for a while: you bring up more and more complex features that tar just _has_ to have, and I point out why they don't have to be part of tar itself. > Moreover, the user interface is now *much* more complex. Red herring. You really think it's the job of every single software tool to provide the user interface du jour? I don't. Make a tar wrapper if you're desperate. > Almost all of the complexity of the tar code volume splits is bent > around making sure that each archive is nearly independent, but that a > file can be split across the boundary The user can replace a big file FOO with a whole bunch of little files FOO/0 FOO/32768 etc. (the numbers indicating byte markers). Why, oh why, if this feature _had_ to be in tar, wasn't it implemented just like this? What ``complexity'' is necessary? if (FOO is too big) for (each piece) archive(reading from FOO at startbyte,archiving as FOO/startbyte,length) else archive(reading from FOO,archiving as FOO/0,entire length). Guess what? This is compatible with normal tar! Of course somebody who expands this sort of archive with a normal tar will have to run a separate utility to combine all the files back together. Otherwise he'll have to do a lot of mv FOO/0 FOO0; rmdir FOO; mv FOO0 FOO. But such a utility wouldn't take more than thirty lines of code. Guess what else? You can handle sparse files in exactly the same way! Now, this is sort of tangential to the issue of writing the same code for both tar and cpio. But it does illustrate the same basic problem: somebody failed to _think_ before adding a feature to a GNU utility. ---Dan ------------------------------ ** FOR YOUR REFERENCE ** The service address, to which questions about the list itself and requests to be added to or deleted from it should be directed, is: Internet: Linux-Development-Request@NEWS-DIGESTS.MIT.EDU You can send mail to the entire list (and comp.os.linux.development) via: Internet: Linux-Development@NEWS-DIGESTS.MIT.EDU Linux may be obtained via one of these FTP sites: nic.funet.fi pub/OS/Linux tsx-11.mit.edu pub/linux sunsite.unc.edu pub/Linux End of Linux-Development Digest ******************************