Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!uxc.cso.uiuc.edu!tank!keith@curry.uchicago.edu From: keith@curry.uchicago.edu (Keith Waclena) Newsgroups: comp.sources.d Subject: Re: Zoo and directories Summary: ``Zoo *good*!'' -- Tarzan, Tonto and Frankenstein Message-ID: <5439@tank.uchicago.edu> Date: 18 Sep 89 16:48:33 GMT References: Reply-To: keith@curry.uchicago.edu (Keith Waclena) Organization: TIRA / UofC Lines: 67 In-reply-to: jv@mh.nl (Johan Vromans) In article , jv@mh (Johan Vromans) writes: > >I was wondering why Zoo ignores directories passed on the command >line. I find it irritating and error-prone that Zoo ignores them >*SILENTLY*. > >Has anyone modified Zoo to recurse directories like tar(1)? > Well, Zoo is more like cpio(1) than tar: read standard I/O for pathnames to archive. This means that to archive entire directory hierarchies you have to use Zoo's I option along with another program in a pipe to generate the pathnames (typically find(1) on Unix systems; Rahul provides his own find-clone, stuff, for MS/DOS systems). But I'm sure you know this. As for why: I would guess that Rahul is trying not to reinvent the wheel: this way, Zoo doesn't need to duplicate the code in find or stuff. If he did, he'd still need to provide the I switch for people who want to filter the list of files first in some complex way*. And, if he did, he'd have to deal with the question of how much of find's functionality to duplicate: conditional tests on file times and sizes? pruning? recognition of NFS-mounted file systems? * (E.g., I have an application using Zoo that pipes from find to a binpacking program I wrote/stole, so that I can squeeze optimal-sized Zoo archives onto multiple floppies). > >Is there a special reason why Zoo doesn't extract files in the >hierarchy they came from, but only in the current directory (unless I >use x//)? > My guess is that since Zoo is a very portable program that runs under several operating systems, Rahul made the default extraction behavior to be the simplest and most likely to be sensible under any opsys. It's fairly unusual for MS/DOS programs to create entire directory hierarchies, for example. Nonetheless, the option is there if you want it. Perhaps it would have been good to make the x (expert) option create directory hierarchies by default while having the -extract (novice) option not do so, but overall I'd say Rahul came up with a good, portable design. And anyway, it should be pretty straightforward to write a shell script front end for Zoo that will archive and extract directories by default; it should also be easy (dammit) under MS/DOS, even for those of us without the MKS Toolkit (but it probably isn't). > >Archiving directories and restoring into directories seems a suitable >default action to me. > It is pretty reasonable. I also think Rahul's approach was reasonable, and in fact preferable. Keith -- Keith WACLENA keith@curry.uchicago.edu GLS / TIRA / U of Chicago keith%curry@uchimvs1.bitnet 1100 E.57th.St Chi IL 60637 USA ...!uunet!curry.uchicago.edu!keith "Maybe one day the computers of the world will one by one be replaced by birds until there are no computers left -- only birds! Wouldn't that be a beautiful world?" Raymond Smullyan