tneff@bfmny0.UU.NET (Tom Neff) (09/17/89)
In article <JV.89Sep16213744@mhres.mh.nl> jv@mh.nl (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*. Use the I modifier to archive directory trees. "I" means ZOO takes the list of filenames from the standard input. This is not really different from tar or cpio as they are usually used. find * -print | zoo aI sample.zoo And of course this is much more flexible if you want to selectively archive etc. -- 'We have luck only with women -- \\\ Tom Neff not spacecraft!' *-((O tneff@bfmny0.UU.NET -- R. Kremnev, builder of FOBOS \\\ uunet!bfmny0!tneff (UUCP)
jv@mh.nl (Johan Vromans) (09/17/89)
First of all I want to express that I like Zoo very much, and use it
for almost all my archiving. But I do have a few remarks.
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)?
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//)?
Archiving directories and restoring into directories seems a suitable
default action to me.
Johan
--
Johan Vromans jv@mh.nl via internet backbones
Multihouse Automatisering bv uucp: ..!{mcvax,hp4nl}!mh.nl!jv
Doesburgweg 7, 2803 PL Gouda, The Netherlands phone/fax: +31 1820 62944/62500
------------------------ "Arms are made for hugging" -------------------------jv@mh.nl (Johan Vromans) (09/18/89)
In article <14683@bfmny0.UU.NET> tneff@bfmny0.UU.NET (Tom Neff) writes: > Use the I modifier to archive directory trees. "I" means ZOO takes > the list of filenames from the standard input. This is not really > different from tar or cpio as they are usually used. > > find * -print | zoo aI sample.zoo It is much harder to learn novice users lots of switches than a simple and elegant zoo -add sample * The same goes for extraction: zoo x// sample is less intiutive than zoo -extract sample Remember: I'm talking about novice users, not gurus like you (and me :-). Johan -- Johan Vromans jv@mh.nl via internet backbones Multihouse Automatisering bv uucp: ..!{mcvax,hp4nl}!mh.nl!jv Doesburgweg 7, 2803 PL Gouda, The Netherlands phone/fax: +31 1820 62944/62500 ------------------------ "Arms are made for hugging" -------------------------
keith@curry.uchicago.edu (Keith Waclena) (09/18/89)
In article <JV.89Sep16213744@mhres.mh.nl>, 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
root@cca.ucsf.edu (Systems Staff) (09/19/89)
In article <JV.89Sep16213744@mhres.mh.nl>, jv@mh.nl (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*. Several postings have really missed the point here. The purpose of an archiver is to preserve data and its structure. If an archiver is told (even incorrectly) to save something and neither does it nor produces an error message the program has a major bug. The only question is whether it is a design bug (intentional) or implementation bug (unintentional). The fact that some other construction would have worked is irrelevant. Since the Zoo 2.01 man page says that the command line parameters following the command and modifiers are _files_ it is presumably an error to specify a _directory_ here. In that case an error message should be produced. Similarly, an error message should be produced if the parameter does not refer to any file system object. Thos Sumner Internet: thos@cca.ucsf.edu (The I.G.) UUCP: ...ucbvax!ucsfcgl!cca.ucsf!thos BITNET: thos@ucsfcca U.S. Mail: Thos Sumner, Computer Center, Rm U-76, UCSF San Francisco, CA 94143-0704 USA I hear nothing in life is certain but death and taxes -- and they're working on death. #include <disclaimer.std>
frotz@drivax.UUCP (Frotz) (09/20/89)
root@cca.ucsf.edu (Systems Staff) writes: >In article <JV.89Sep16213744@mhres.mh.nl>, jv@mh.nl (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*. > >Several postings have really missed the point here. >The only question is whether it is a design bug (intentional) or >implementation bug (unintentional). WARNING: Personal opinion and conjecture about to follow... If you look at the history of zoo and what it was trying to replace (the A-word...;-), it made sense to use the novice command set because it was very, very similar to what was being replaced... (NOTE: I have not heard this from Rahul, but have concluded this based on my own learning curve (oh, so long ago...;-)) If one looks at it, the 1.71 manual (I assume the 2.0x manual as well), state the the novice option "-add" is defined as the expert option "aP:" which adds files without directories and then packs the archive when finished. This behaviour is exactly like other [net-in]famous archiving programs... It is therefore my opinion that Rahul attempted to create a novice interface that worked and looked like the then-ruling archiving program(s). In this I feel he has succeeded. Please notice the key words "worked and looked like". No, I don't think that this is a ..., no, I won't say it...;-} --Frotz @Digital Research, Incorporated amdahl!drivax!frotz 70 Garden Court, B15 (408) 649-3896 Monterey, California 93940 Ask for John Fa'atuai