Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!purdue!bu-cs!buengc!bph
From: bph@buengc.BU.EDU (Blair P. Houghton)
Newsgroups: comp.unix.questions
Subject: Re: tar help
Message-ID: <3370@buengc.BU.EDU>
Date: 3 Jul 89 19:07:28 GMT
References: <1731@cmx.npac.syr.edu> <762@lilink.UUCP>
Reply-To: bph@buengc.bu.edu (Blair P. Houghton)
Followup-To: comp.unix.questions
Organization: Boston Univ. Col. of Eng.
Lines: 32

>gefuchs@goedel.uucp (Gill E. Fuchs) writes:
>>I type (at the ~ directory)
>>	tar cvf GUGU.tar .
>>but after sometime tar tars GUGU.tar recorsively upon itself,

In article <762@lilink.UUCP> mikej@lilink.UUCP (Michael R. Johnston) writes:
>	tar cvf /tmp/GUGO.tar .

However, there is at least one system I work on that does not maintain
enough temporary space so that I can tar all my stuff into it (and
recently it ran out of space in my home partition, so I'm stuck real
good... for the nonce :-)  The simple solution is (in csh):

 	rm -f GUGU.tar
 	tar cvf GUGU.tar ./{.??*,*}

The shell performs filename expansion before tar(1) is run by the shell,
and therefore before GUGU.tar is created.

You might be tempted to go into a subdirectory of your own and use
 "~/{.??*,*}" instead of "./{.??*,*}", but then you are not excluding
 the parent directory of GUGU.tar from the list of files tar'red, and
 you end up with the partially[1] recursive problem.

    [1] "partially", because only that part of GUGU.tar which is complete
    when tar(1) gets to that name will actually be read.

Actually, if your tar(1) supports the "exclusion" (-X) option, use it.
At least one that I use doesn't.

				--Blair
				  "Yeah, that's the ticket."