cmcmanis%pepper@Sun.COM (Chuck McManis) (05/11/88)
Pat, if my mail message didn't get through to you please let me reiterate. My feeling is that the source news groups are for sources and zoo archives are binaries period. Some P, CP (Point, Counter Point) P: Sources are big and often don't come to us as shar files. CP: True, this is why they have their own group and are moderated. If you put them into some encoded binary format over half your "customers" will no longer be able to use them. P: Using zoo increases reliability. CP: Baloney, when unsharing source code, if I get an error I can often correct the line noise in the source and recompile. In an archive file the whole file is often irretriveably blown away. There are more, but this is not meant to be a flame, just a _vigorous_ request that the sources groups remain 'human readable' thank you. --Chuck McManis uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com These opinions are my own and no one elses, but you knew that didn't you.
dillon@CORY.BERKELEY.EDU (Matt Dillon) (05/11/88)
>Pat, if my mail message didn't get through to you please let me >reiterate. My feeling is that the source news groups are for sources >and zoo archives are binaries period. Some P, CP (Point, Counter Point) > >There are more, but this is not meant to be a flame, just a _vigorous_ request >that the sources groups remain 'human readable' thank you. We should discuss this, actually. This is my opinion: (1) The outer layer of source/binaries postings should ALWAYS BE A SHAR. Period. What the SHAR contains can be anything... uuencoded files, zoo + uuencoded files, arc + uuencoded files, text files, whatever, BUT MAKE THAT OUTER LAYER A SHAR! Reason#1: most unshar programs are intelligent ... so much so that they ignore garbage at the beginning (the header) and end (the signature). Thus, there is no need to VI the file before decoding ... just run it through unshar. Reason#2: if uuencoded files are shar'd, there are no blank lines after you unshar, and you can simply cat the segments together and pipe it through uudecode. simple. Reason#3: It becomes obvious if a posting is truncated. This is a precursor to discussing the possible changeover from moderated to unmoderated. The lag time is simply too great as it is (sorry moderators... classes or not, 2 months is ridiculous) I think we can do it... if everybody agrees on a standard (maybe the one I suggested above?). -Matt
cmcmanis%pepper@Sun.COM (Chuck McManis) (05/12/88)
In article <8805110255.AA21249@cory.Berkeley.EDU> (Matt Dillon) writes: > We should discuss this, actually. This is my opinion: > > (1) The outer layer of source/binaries postings should ALWAYS BE > A SHAR. Period. What the SHAR contains can be anything... > uuencoded files, zoo + uuencoded files, arc + uuencoded files, > text files, whatever, BUT MAKE THAT OUTER LAYER A SHAR! I agree with this, except that I still assert that source code should be source code and not "zooed" or "arced" when distributed. It should always be shar'd and somethings like .info files will have to be uuencoded. --Chuck --Chuck McManis uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com These opinions are my own and no one elses, but you knew that didn't you.
papa@pollux.usc.edu (Marco Papa) (05/12/88)
In article <52841@sun.uucp> cmcmanis@sun.UUCP (Chuck McManis) writes: >In article <8805110255.AA21249@cory.Berkeley.EDU> (Matt Dillon) writes: >> We should discuss this, actually. This is my opinion: >> >> (1) The outer layer of source/binaries postings should ALWAYS BE >> A SHAR. Period. What the SHAR contains can be anything... >> uuencoded files, zoo + uuencoded files, arc + uuencoded files, >> text files, whatever, BUT MAKE THAT OUTER LAYER A SHAR! > >I agree with this, except that I still assert that source code should be >source code and not "zooed" or "arced" when distributed. It should always >be shar'd and somethings like .info files will have to be uuencoded. I second Chuck's point: sources should be SOURCES, binaries should be BINARIES. Both should be SHARed. Binaries should be UUENCODED and not ARCed or ZOOed, at least in general since EVERYBODY has uuencode/uudecode (on both UNIX and Amiga) while the same is not true fo the other two programs. -- Marco Papa 'Doc' -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= uucp:...!pollux!papa BIX:papa ARPAnet:pollux!papa@oberon.usc.edu "There's Alpha, Beta, Gamma and Diga!" -- Leo Schwab [quoting Rick Unland] -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
backstro@silver.bacs.indiana.edu (05/12/88)
>I agree with this, except that I still assert that source code should be >source code and not "zooed" or "arced" when distributed. It should always >be shar'd and somethings like .info files will have to be uuencoded. > >--Chuck > >--Chuck McManis >uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com >These opinions are my own and no one elses, but you knew that didn't you. I also agree that source files should be left in human readable form. Becuase if the source IS still in human readable form most likely any errors could be corrected. Also it would be nice to be able to download sources for other types of computers. This would be much simpler than having to download some source and then have to send it to the computer it was written for and then transfer the uncompressed version of the source back to your machine. After all that you can now begin work... Well that's my $0.02 worth. If you've got any opinions, keep 'em! ;^) +----------------------------------------------------------------------------+ | James Colyer | #define LIFE (?) | AMIGA! //// | Running his 1 Meg Amiga | |---------------------------------| //// | 1000 from a Lobby (!) | | ARPA: backstro@silver.bacs. | //// |---------------------------| | indiana.edu | //// | "There is no dark side on | | USSnail: 4755 N. Kinser Pike, | \\\\//// | the moon, really. Matter | | Bloomington, IN, 47401 | \\XX// | of fact it's all dark." | |----------------------------------------------------------------------------| | The opinions expressed are those of a sick and deranged maniac. Poor sod. | +----------------------------------------------------------------------------+
david@ms.uky.edu (David Herron -- One of the vertebrae) (05/13/88)
In article <52841@sun.uucp> cmcmanis@sun.UUCP (Chuck McManis) writes: ... >I agree with this, except that I still assert that source code should be >source code and not "zooed" or "arced" when distributed. It should always >be shar'd and somethings like .info files will have to be uuencoded. Requiring the source to be un-coded (i.e. in clear) assumes that news articles pass through the system unmunged. But they often don't. Weeell.. "often" is relative at least to this site. We have a news neighbor that's an IBM mainframe, and news which passes through there undergoes a number of interesting transformatsions. Further ... The news article format is purposely compatible with mail message format so that news feeds could be made via mail if necessary. Mail doesn't gaurantee unmunged delivery. Source files are particularly sensitive to slight mungings. A common munging is tab interpretation (conversion to spacing, and sometimes in differing styles). Later patches fail mysteriously because the patch has tabs and the source has spaces (or the other way around). Or you've got a shell script which has a grep pattern which includes a hard tab, and the tab gets translated to a bunch of spaces and doesn't work again. If the source is uuencoded (especially if done with the newer versions of uuencode that do checksums) it will survive better in it's way through the networks. Usenet is growing beyond it's Unix starting points. We have IBM mainframes which are full news partners/participants, nntp based news readers for tops-20, vms, and symbolics lisp machines, and a number of other developments. We can't continue to assume that the situations will continue as they have been in the past. As we interconnect with other types of systems, each new "foriegn" system brings its own problems along. -- <---- David Herron -- The E-Mail guy <david@ms.uky.edu> <---- or: {rutgers,uunet,cbosgd}!ukma!david, david@UKMA.BITNET <---- Windowing... The Amiga has windowing. The Mac has windowing (echoes of <---- Jonathan Livingston Seagull: "Just flying? A mosquito can do that much!").
dillon@CORY.BERKELEY.EDU (Matt Dillon) (05/13/88)
>I second Chuck's point: sources should be SOURCES, binaries should be >BINARIES. Both should be SHARed. Binaries should be UUENCODED and not >ARCed or ZOOed, at least in general since EVERYBODY has uuencode/uudecode >(on both UNIX and Amiga) while the same is not true fo the other two programs. I agree with one exception. When the distribution requires a directory structure to be maintained, or has lots of files with long filenames, ZOO should be used... Look at the ARP distribution? It took me hours to fix up all those ARC'd segments.... This is why DNET is being distributed on sources as a uuencoded ZOO archive... There is no other way to maintain the directory structure and I wasn't about to hand-generate the ARCs or split everything into a thousand singular-directory files and provide a script to restore it. And I'm a convert, BTW. A month ago I didn't like ZOO. But now.... -Matt
peter@sugar.UUCP (Peter da Silva) (05/13/88)
I like to do some unpacking on UNIX before shipping stuff down. But if it's arced or zooed I'm out of luck. No source to zoo, and ironically the UNIX version of arc is allergic to braindamaged intel architectures! On another line, my big complaint with the Mac sources group was all the hexbinned stuff in it. Some non-Mac people like to look at other guy's stuff now and then. -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- "Have you hugged your U wolf today?" ...!bellcore!tness1!sugar!peter -- Disclaimer: These aren't mere opinions, these are *values*.
scott@applix.UUCP (Scott Evernden) (05/13/88)
In article <8805130331.AA29993@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: > ... When the distribution requires a > directory structure to be maintained, or has lots of files with > long filenames, ZOO should be used... Look at the ARP distribution? I have no problem with this except: Is there a version of ZOO for unix? I really hate it when I dload a 400K .zoo file to my amiga (via 1200 baud modem) only to discover 1) that it contains stuff I don't want, or 2) that the "(FL4m{{i{i"R$``!>0<" on line 5293 in the .uu file should have been a "(FL48-!@2B"R$``!>0<". At lease I can unwrap .arc files on my sun... -scott
grwalter@watcgl.waterloo.edu (Fred Walter) (05/14/88)
In article <698@applix.UUCP> scott@applix.UUCP (Scott Evernden) writes: >In article <8805130331.AA29993@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: >> ... When the distribution requires a >> directory structure to be maintained, or has lots of files with >> long filenames, ZOO should be used... Look at the ARP distribution? > >I have no problem with this except: > > Is there a version of ZOO for unix? ZOO was originally written for unix. If you have the amiga distribution of zoo then you presumably have the docs and somewhere in there it indicates this fact. ZOO for unix was recently (18 Aug 87) reposted to comp.sources.unix by its author iuvax!bsu-cs!dhesi@seismo.CSS.GOV (Rahul Dhesi) and if your site doesn't archive comp.sources.unix a site near you probably does. As you can probably tell, I vote for using zoo when pathnames/directory structures need to be preserved. fred
lphillips@lpami.van-bc.UUCP (Larry Phillips) (05/15/88)
In <8805130331.AA29993@cory.Berkeley.EDU>, dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: > I agree with one exception. When the distribution requires a > directory structure to be maintained, or has lots of files with > long filenames, ZOO should be used... Look at the ARP distribution? > It took me hours to fix up all those ARC'd segments.... Yes, I like to be able to use long names in archives, and to preserve the directory structure too, so I have a present for you at the end of this posting. > This is why DNET is being distributed on sources as a uuencoded > ZOO archive... There is no other way to maintain the directory > structure and I wasn't about to hand-generate the ARCs or split > everything into a thousand singular-directory files and provide > a script to restore it. > And I'm a convert, BTW. A month ago I didn't like ZOO. But now.... > > -Matt Up to a few days ago, I hated ZOO with a vengeance. There were a few reasons for this, like the distribution policy which virtually ensured that it would be useless to me as a sysop on Compuserve's Amigaforum. A few days ago, we received an upload of the latest version of ZOO to the Amigaforum from the author himself, and it did not have the restrictions it previously had. There remains only one small problem. ZOO does not work on any device that uses the new file system, meaning that I have to ZOO things in VD0: or RAM: It would seem that extracting files is fine, but that it must go a little too 'close to the hardware', bypassing the file handler and making assumptions about disk block contents. A shame. I _almost_ like it now. And now for something completely different. A small ARexx program called arcall.rexx, that will recursively go through a directory and rename all files, generate a script file while doing so, and ARC the entire kabooble into a file called ARCFILE.ARC. The script file created, (a standard Amigados script called Exec.me) is included in the ARC, and upon execution, will make any necessary subdirectories, and rename all files to their original name and position in the directory structure. It is short, so I will include it here, with apologies to the net.gods if I have misinterpreted the guidelines. ---------- slice here ---------------- /* arcall.rexx by Larry Phillips. Use this code in whatever way you like. */ arg root if right(root,1) ~= ':' then root = root || '/' if root = '/' then root = '' filecount = 1 dummy = open(execfile,root || 'Exec.me','write') call renamefiles(root) say call close(execfile) 'arc a arcfile *' exit 0 renamefiles: procedure expose filecount root parse arg x contents = showdir(x); do i = 1 to words(contents) temp = x || word(contents,i) select when word(statef(temp),1) = 'FILE' then do rename temp root || 'File' || filecount call writeln(execfile,'rename File' || filecount x || word(contents,i)) call writech(stdout,'.') filecount = filecount + 1 end when word(statef(temp),1) = 'DIR' then do call writeln(execfile,'') call writeln(execfile,'makedir' temp) call renamefiles(temp || '/') end otherwise do if translate(temp) = 'EXEC.ME' then break else say 'Error: File' temp 'is neither DIR nor FILE.' end end end call writeln(execfile,'') return 0 ---------- slice here - end of program ---------------- Enjoy -larry -- Janus? Well, look at it this way. If you squint a little, the J could be Amiga checkmark, and the rest of the word describes MsDos. +----------------------------------------------------------------+ | // Larry Phillips | | \X/ {ihnp4!alberta!ubc-vision,uunet}!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 | +----------------------------------------------------------------+
dillon@CORY.BERKELEY.EDU (Matt Dillon) (05/15/88)
>USENET and UNIX people are familiar with the uuencode/uudecode. > >BBS users, Amiga Users' Groups, etc. are familiar with ARC and ZOO. Well I wouldn't put it quite that way... after all, you can't send raw ARC or ZOO files over the USENET anyway... most people uuencode the ARC/ZOO file and send that. So no argument there. You don't see uuencode on BBS's because its sole purpose in life is to turn binaries into ascii-mailer-readable files, and that's just a waste of space on a BBS. >But let's remember that MOST people have just ONE computer (and let's hope >that it's an Amiga! :-), and said users WILL have ARC and ZOO readily >available. Or can get them off just about any BBS, ARPA archive, or sources/binaries group whenever they want! -Matt
kent@xanth.cs.odu.edu (Kent Paul Dolan) (05/15/88)
I want to petition for zoo's for everything. Having the file names and the directory structure be maintained is just too valuable a feature to give up for the pitifully small chance that I can make a repair that even I trust to a source file that lost a couple of characters along the way. I download with kermit, which does a CRC check on each packet, and if the file got to my host OK, it gets to me OK. If it didn't, the host folks reacquire it and I wait a few days. It took 15 hours over 2 days to rebuild the ARP 1.1 stuff because the file structure and name space are destroyed as it was released, and I rebuilt it on a Unix system, where there was lots of space, rather than my 512K two floppy home Amiga system. When I got it all right, I dwnloaded it (perfectly, of course, despite some of the noisiest phone lines imaginable - good old kermit!) and built it onto another disk with a single command (and twenty minutes of grinding noise competitions between the drives ;-). If the files had all been distributed as a big zoo, I could have skipped the intermediate step. Marco, who can't get hold of zoo, arc, compress, sq and all the other stuff I use every day? They are freely distributed around the world for Amigas, and we have all but sq on the VAX here as well. I build zoos to send out on the vax, rather than hauling stuff home, zooing it here, and uploading it again. Easy as pie. Kent, the man from xanth.
nic@dworld.UUCP (Nic Bernstein) (05/15/88)
I guess I agree with the general concensus that all postings should have SHAR as their outer layer, binaries must be uuencoded, and I can even live with ARC or ZOO on sources. The one thing that drives me crazy, however, is filenames > 13 chars. I understand that many of you AmigaGods are using BSD machines, but unless someone wants to send me a free port of 4.3BSD for the AT&T 3b1, I'm stuck with the Sys V filename maxlen. It can be a real pain in the ars when the only difference between several files in a set are in the end of a too long filename, ie: dnet.amiga.zoo.uu.aa dnet.amiga.zoo.uu.ab dnet.amiga.zoo.uu.ac dnet.amiga.zoo.uu.ac on my Sys V machine after doing an Unshar * in the dnet directory, I get: dnet.amiga.zoo This sort of thing happens far too often. I find it handy to be able to unshar and uudecode and then ARC stuff on my news machine, at work, before transferring it at 1200 baud to my Amiga at home. Sometimes this can result in a time savings of a half hour or so when downloading a few days worth of stuff. While I'm at it, thanks for all the great software Matt! -- "You can't spend your history!" Nic Bernstein Melinda Briggerty Discovery World Museum "... but you can sell it!" 818 W. Wisconsin av. Me Milwaukee, WI 53233 ____________________________________________________________________________ {uunet|uwmcsd1|gryphon}!marque{!introl}!dworld!nic ____________________________________________________________________________
gaspar@almsa-1.arpa (Al Gaspar) (05/16/88)
Scott Evernden <scott@applix.uucp> writes: > Is there a version of ZOO for unix? I really hate it when I dload > a 400K .zoo file to my amiga (via 1200 baud modem) only to discover 1) > that it contains stuff I don't want, or 2) that the > "(FL4m{{i{i"R$``!>0<" on line 5293 in the .uu file should have been > a "(FL48-!@2B"R$``!>0<". > > At lease I can unwrap .arc files on my sun... > > -scott Zoo is available for UNIX. You can obtain the latest version by anonymous ftp to uunet.uu.net or you can send a message to netlib@uunet.uu.net. If you send a message, use 'send info' as your subject line and you'll get the details on how to get sources. Zoo (source) is in 7 parts in volume 11 of the archives. I hope this helps. Cheers-- Al
lphillips@lpami.van-bc.UUCP (Larry Phillips) (05/16/88)
In <9037@oberon.USC.EDU>, papa@pollux.usc.edu (Marco Papa) writes: >I second Chuck's point: sources should be SOURCES, binaries should be >BINARIES. Both should be SHARed. Binaries should be UUENCODED and not >ARCed or ZOOed, at least in general since EVERYBODY has uuencode/uudecode >(on both UNIX and Amiga) while the same is not true fo the other two programs. Whatcha gonna do with Amiga binaries on your Unix machine Marco? -larry -- Janus? Well, look at it this way. If you squint a little, the J could be Amiga checkmark, and the rest of the word describes MsDos. +----------------------------------------------------------------+ | // Larry Phillips | | \X/ {ihnp4!alberta!ubc-vision,uunet}!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 | +----------------------------------------------------------------+
jw@sics.se (Johan Widen) (05/16/88)
>I like to do some unpacking on UNIX before shipping stuff down. But if >it's arced or zooed I'm out of luck. No source to zoo, and ironically the >UNIX version of arc is allergic to braindamaged intel architectures! The UNIX sources for zoo appeared in comp.sources.unix or comp.sources.misc (not sure which one) in August 1987. Works too. You should be able to get a copy from a site near you. -- Johan Widen SICS, PO Box 1263, S-164 28 KISTA, SWEDEN Tel: +46 8 752 15 32 Ttx: 812 61 54 SICS S Fax: +46 8 751 72 30 Internet: jw@sics.se or {mcvax,munnari,ukc,unido}!enea!sics.se!jw
gore@eecs.nwu.edu (Jacob Gore) (05/17/88)
/ comp.sys.amiga / dillon@CORY.BERKELEY.EDU (Matt Dillon) / May 12, 1988 / > ... When the distribution requires a > directory structure to be maintained, or has lots of files with > long filenames, ZOO should be used... Why? Can't a shar contain "create directory" commands? And what's wrong with long filenames? Jacob Gore Gore@EECS.NWU.Edu Northwestern Univ., EECS Dept. {oddjob,gargoyle,ihnp4}!nucsrl!gore
ins_adjb@jhunix.HCF.JHU.EDU (Daniel Jay Barrett) (05/17/88)
Since lots of people have mentioned the lack of a UNIX version of ZOO, I thought I'd tell you that there IS one. I got it from the following machine: 128.174.5.54 uxe.cso.uiuc.edu I believe the directory name is something like amiga/zoo. Anonymous ftp works fine. This machine also has a large selection of PD Amiga software, arranged by Fish Disk. -- Dan Barrett ins_adjb@jhunix.UUCP barrett@cs.jhu.edu
plouff@nac.dec.com (Wes Plouff) (05/18/88)
[Sorry, can only reply by mail to Usenet postings] Matt Dillon (dillon@cory.berkeley.edu) complained > This is why DNET is being distributed on sources as a uuencoded > ZOO archive... There is no other way to maintain the directory > structure and I wasn't about to hand-generate the ARCs or split > everything into a thousand singular-directory files and provide > a script to restore it. Hmm... I get postings on a VAX running VMS. So now I must dig out a VMS version of ZOO from somewhere in order to extract docs, look the files over, etc, without down- and up-loading to my Amiga. It would also be nice to attempt a VMS port of DNET. So let's look at the Unix end of the sources. Oh, they're in TAR format? VMS TAR? Right, harder digging if I'm to make any use of this stuff at all. As David Herron (david@ms.uky.edu) says, in a different context, >Usenet is growing beyond its Unix starting points. We have IBM mainframes >which are full news partners/participants, nntp based news readers for >tops-20, vms, and symbolics lisp machines, and a number of other developments. UUencoding versus plaintext is not a big issue to me, but please, PLEASE don't introduce other encodings just because it is convenient, unless the coding tools are widely available on non-Unix systems. Rich Salz does an excellent job on multi-directory postings to comp.sources.unix using rather nice shell scripts (which our 'shar' can interpret). With creative use of Amiga tools like 'arcre' it just can't be that hard to put together a reasonable package using only standard commands. Aside to .sources. moderators: this is a small failing in your otherwise excellent handling of the moderated newsgroups. -- Wes Plouff plouff%nac.dec@decwrl.dec.com Digital Equipment Corp, Littleton, Mass. or ...!decwrl!nac!plouff
thad@cup.portal.com (05/18/88)
Mostly to Nic Berstein: If you'd like to be a pioneer (quote,unquote), look at the UNIX-PC newsgroup on Usenet ... there have been solutions proposed to permit longer filenames than the SysV 14 character limitation. We're investigating this locally ("we" == the informal SIG of the AT&T Users' Group).
page@swan.ulowell.edu (Bob Page) (05/18/88)
I don't care how the files come across, just get 'em to me.
Personally, I'm for a comp.programs.amiga, where you get the whole
distribution. These days of doc files in 8-bit ASCII, icons and other
non-7-bit ASCII; it doesn't make a lot of sense to distiguish.
lphillips@lpami.van-bc.UUCP (Larry Phillips) wrote:
>Whatcha gonna do with Amiga binaries on your Unix machine Marco?
I'll tell you what I do:
1. Make them available for Amiga NFS access
2. Make them avaliable for anonymous FTP over the Internet
3. Disassemble them (yep! for my own amusement)
..Bob
--
Bob Page, U of Lowell CS Dept. page@swan.ulowell.edu ulowell!page
darin@laic.UUCP (Darin Johnson) (05/19/88)
In article <1764@van-bc.UUCP>, lphillips@lpami.van-bc.UUCP (Larry Phillips) writes: > >In <9037@oberon.USC.EDU>, papa@pollux.usc.edu (Marco Papa) writes: >>I second Chuck's point: sources should be SOURCES, binaries should be >>BINARIES. Both should be SHARed. Binaries should be UUENCODED and not >>ARCed or ZOOed, at least in general since EVERYBODY has uuencode/uudecode >>(on both UNIX and Amiga) while the same is not true fo the other two programs. I used zoo on both my Amiga and Unix system to 'extract' the DNET stuff (after poking around everywhere for a zoo for unix). Turns out that on BOTH the Amiga and the Unix machine, ZOO failed to keep the directory structure!! Oh, well, zoo -list told me what to put where, and it was cheaper than running down to the store to see if there was a later vesion of zoo on a fish disk and forking over 3 bucks. -- Darin Johnson (...lll-lcc.arpa!leadsv!laic!darin) (...ucbvax!sun!sunncal!leadsv!laic!darin) "All aboard the DOOMED express!"
kim@amdahl.uts.amdahl.com (Kim DeVaughn) (05/19/88)
In article <7142@swan.ulowell.edu>, page@swan.ulowell.edu (Bob Page) writes: > > I don't care how the files come across, just get 'em to me. > Personally, I'm for a comp.programs.amiga, where you get the whole > distribution. Yeah ... I think this is a good idea too! 'Twould make the moderator's job a little easier, and eliminate the duplication of the "doc" file(s) that is being done now (in many cases). That, to me, seems to be a real waste of net bandwidth, and I think it should be stopped. /kim -- UUCP: kim@amdahl.amdahl.com or: {sun,decwrl,hplabs,pyramid,ihnp4,uunet,oliveb,cbosgd,ames}!amdahl!kim DDD: 408-746-8462 USPS: Amdahl Corp. M/S 249, 1250 E. Arques Av, Sunnyvale, CA 94086 CIS: 76535,25
dillon@CORY.BERKELEY.EDU (Matt Dillon) (05/19/88)
>and the Unix machine, ZOO failed to keep the directory structure!! Oh, well, >zoo -list told me what to put where, and it was cheaper than running down to >the store to see if there was a later vesion of zoo on a fish disk and forking >over 3 bucks. Oh no! I believe the proper extraction command line is: zoo x// blah.zoo where // (I think) means 'extract into the original directory structure and create directories as you go'. -Matt
jbwaters@bsu-cs.UUCP (J. Brian Waters) (05/20/88)
In article <1758@van-bc.UUCP>, lphillips@lpami.van-bc.UUCP (Larry Phillips) writes: > > There remains only one small problem. ZOO does not work on any device > that uses the new file system, meaning that I have to ZOO things in VD0: > or RAM: It would seem that extracting files is fine, but that it must go a > little too 'close to the hardware', bypassing the file handler and making > assumptions about disk block contents. A shame. I _almost_ like it now. > All the file io in the Amiga version of zoo is done through either the dos.library, stdio routines from the C compiler and one use of a packet (the setdate packet that was added in 1.2). It does nothing that bypasses the handler and makes no assumptions about the disk block. As soon as I get a way to test out zoo with the fast file system I will verify and correct any problems with it. By the way I have only recieved two bug reports since zoo has been distributed for the Amiga. I am sure more people than that have found problems. I can only fix things that I know about and I do not have time to read all the comp.sys.amiga messages. If you find something about the Amiga version of zoo and would like to make sure a feature you want is considered or a bug fixed please mail it to me. -- Brian Waters <backbone>!---\ ihnp4!{iuvax|pur-ee}!bsu-cs!jbwaters uunet!---/
ncreed@ndsuvax.UUCP (Walter Reed) (05/20/88)
In article <247@laic.UUCP> darin@laic.UUCP (Darin Johnson) writes: >I used zoo on both my Amiga and Unix system to 'extract' the DNET stuff (after >poking around everywhere for a zoo for unix). Turns out that on BOTH the Amiga >and the Unix machine, ZOO failed to keep the directory structure!! Oh, well, >Darin Johnson (...lll-lcc.arpa!leadsv!laic!darin) Are you sure you used zoo correctly? If you don't specify that you want directory structure to be used, it will put all the files in one directory. What you should be using is Zoo x// zooarchive.zoo * The x// is eXtract with full pathnames. Hope this helps! -- ------ Walter Reed ------ + uunet!ndsuvax!ncreed or ncreed@ndsuvax.BITNET "There's no point in being + or ncreed%NDSUVAX.BITNET@CUNYVM.CUNY.EDU grown up if you can't be + Phone: (701) 235-0774 childish sometimes!" Dr. Who + USnAIL: 1430 12 Ave N. Fargo, ND 58102
phil@titan.rice.edu (William LeFebvre) (05/21/88)
In article <1764@van-bc.UUCP> lphillips@lpami.van-bc.UUCP (Larry Phillips) writes: > >In <9037@oberon.USC.EDU>, papa@pollux.usc.edu (Marco Papa) writes: >>Binaries should be UUENCODED and not >>ARCed or ZOOed, at least in general since EVERYBODY has uuencode/uudecode >>(on both UNIX and Amiga)... > >Whatcha gonna do with Amiga binaries on your Unix machine Marco? Download them. With kermit in binary mode, of course. I do it all the time. It's faster....less bytes to move. Makes a big difference at 1200 baud. Also, uudecode is faster on a Sun 3 than on my Amy. William LeFebvre Department of Computer Science Rice University <phil@Rice.edu>
lphillips@lpami.van-bc.UUCP (Larry Phillips) (05/21/88)
In <3143@bsu-cs.UUCP>, jbwaters@bsu-cs.UUCP (J. Brian Waters) writes: >In article <1758@van-bc.UUCP>, lphillips@lpami.van-bc.UUCP (Larry Phillips) writes: >> There remains only one small problem. ZOO does not work on any device >> that uses the new file system ... > > All the file io in the Amiga version of zoo is done through either the >dos.library, stdio routines from the C compiler and one use of a packet >(the setdate packet that was added in 1.2). It does nothing that bypasses >the handler and makes no assumptions about the disk block. Fascinating. I'm glad you posted this. I couldn't see any reason for you to bypass the handler, and it's a relief to hear you didn't. It does, however, bring up the question of what's broken. Could it be one of the stdio calls in the compiler? As far as I've been able to see (I didn't spend a lot of time on it), the new file system differs only in the data blocks themselves, having no pointers or checksum info, and 512 bytes of pure data. Hope you figure it out. While I have you on the line, I want to thank you for removing the restrictions concerning the posting of Zoo on commercial services. -larry -- Janus? Well, look at it this way. If you squint a little, the J could be Amiga checkmark, and the rest of the word describes MsDos. +----------------------------------------------------------------+ | // Larry Phillips | | \X/ {ihnp4!alberta!ubc-vision,uunet}!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 | +----------------------------------------------------------------+
lphillips@lpami.van-bc.UUCP (Larry Phillips) (05/27/88)
In <710@thalia.rice.edu>, phil@titan.rice.edu (William LeFebvre) writes: >In article <1764@van-bc.UUCP> lphillips@lpami.van-bc.UUCP (Larry Phillips) writes: >>Whatcha gonna do with Amiga binaries on your Unix machine Marco? >Download them. With kermit in binary mode, of course. I do it all the >time. It's faster....less bytes to move. Makes a big difference at 1200 >baud. Also, uudecode is faster on a Sun 3 than on my Amy. Fair enough. I don't bother with that, as I have plenty of time at home on my Amiga, and too much to do at work on my Sun (like reading SunSpots... nice job you're doing on that William). In addition, I get my comp.xxx.amiga at home, at 2400 baud, so I just tend to think that most people do I guess. > William LeFebvre -larry -- If all the MSDos machines were laid end to end, they still wouldn't be as fun as a single Amiga. +----------------------------------------------------------------+ | // Larry Phillips | | \X/ {ihnp4!alberta!ubc-vision,uunet}!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 | +----------------------------------------------------------------+