clark@cme.nist.gov (Steve Clark) (02/12/91)
>>>>> On 10 Feb 91 22:14:10 GMT, scs@adam.mit.edu (Steve Summit) said:
Steve> chmod 000 $HOME/subdir/hugedir
Steve> cd $HOME
Steve> tar c .
cd $HOME
echo ./subdir/hugedir | tar cX - .
Is this not portable?
--
-steve
------------------------------------------------------------------
Steve Clark
National Institute for Standards and Technology (formerly NBS)
clark@cme.nist.gov ..uunet!cme-durer!clark
(301)975-3595 / 3544jik@athena.mit.edu (Jonathan I. Kamens) (02/12/91)
In article <CLARK.91Feb11160645@discord.cme.nist.gov>, clark@cme.nist.gov (Steve Clark) writes: |> cd $HOME |> echo ./subdir/hugedir | tar cX - . |> |> Is this not portable? Neither Ultrix 3.1 or BSD 4.3 appear to support it. Neither, as far as I can tell, does A/UX, which supposedly is based on SysV. What version of Unix are you using? What version of tar? -- Jonathan Kamens USnail: MIT Project Athena 11 Ashford Terrace jik@Athena.MIT.EDU Allston, MA 02134 Office: 617-253-8085 Home: 617-782-0710
clark@cme.nist.gov (Steve Clark) (02/12/91)
In article <CLARK.91Feb11160645@discord.cme.nist.gov>, I wrote: Steve> cd $HOME Steve> echo ./subdir/hugedir | tar cX - . >>>>> On 11 Feb 91 21:40:54 GMT, jik@athena.mit.edu (Jonathan I. Kamens) said: Jonathan> What version of Unix are you using? What version of tar? Ooops. I made a mistaken generalization, it seems. Since Gnu tar does the obvious thing with the `-' filename after -X, I assumed SunOS tar and, by extension, others would as well (and a rather unconscious assumption it was, I might add). I was wrong. I hope this doesn't set off two more weeks of "my tar does[n't]" messages ... -- -steve ------------------------------------------------------------------ Steve Clark National Institute for Standards and Technology (formerly NBS) clark@cme.nist.gov ..uunet!cme-durer!clark (301)975-3595 / 3544
jik@athena.mit.edu (Jonathan I. Kamens) (02/12/91)
In article <CLARK.91Feb11181727@discord.cme.nist.gov>, clark@cme.nist.gov (Steve Clark) writes: |> Ooops. I made a mistaken generalization, it seems. Since Gnu tar |> does the obvious thing with the `-' filename after -X, I assumed SunOS |> tar and, by extension, others would as well (and a rather unconscious |> assumption it was, I might add). I was wrong. I hope this doesn't |> set off two more weeks of "my tar does[n't]" messages ... Um, I wasn't just talking about feeding names to the -X option via stdin. I was talking about the -X option in general. BSD 4.3, Ultrix 3.1 and A/UX all seem to be lacking this option. For those of you who are curious about what we're talking about here and don't have a -X option on their version of tar :-), what it does is reads a list of regular expressions from the specified file and ignore and files which match any of those regular expressions. -- Jonathan Kamens USnail: MIT Project Athena 11 Ashford Terrace jik@Athena.MIT.EDU Allston, MA 02134 Office: 617-253-8085 Home: 617-782-0710
scs@adam.mit.edu (Steve Summit) (02/12/91)
In article <1991Feb10.221410.2345@athena.mit.edu>, I wrote: > chmod 000 $HOME/subdir/hugedir > cd $HOME > tar c . >... >Admittedly, there are other ways of solving these problems... In article <CLARK.91Feb11160645@discord.cme.nist.gov> clark@cme.nist.gov (Steve Clark) writes: >cd $HOME >echo ./subdir/hugedir | tar cX - . > >Is this not portable? Well, I did imply that there were other ways. This will probably spark a big "cat -v considered harmful" flamefest, but I'll opine that adding this tar X option wasn't very worthwhile. The right way to exclude files matching some pattern is tar c `find . -print | grep -v pattern` Now, Unix is far less restrictive than most operating systems on things like command line length limitations, but this is one case where you can overload even the generous allotments that the shells (and exec) give you. Therefore, a wrinkle that *is* a worthwhile addition to tar is a way to read a list of filenames from a file, or from standard input. I once implemented this as tar c -R file_of_files ('R' for recursive; I don't remember if it was my idea or if I patterned it after somebody else's.) GNU tar has the same idea, but they named it -T, and it does work with `-' for stdin. It seems to me I've seen a third option, for reading filenames from stdin only, which didn't involve a special flag character; perhaps it was something like tar c - In any case, with an option like this we can do something like find . -print | grep -v pattern | tar c -T - and there's no need to build regexp handling into tar. (Sure, with a regexp library it's easy enough, but why bother?) I don't know how widespread -T is (or that third option I can't remember). I see that BSD tar has neither -T nor -X. Steve Summit scs@adam.mit.edu
allbery@NCoast.ORG (Brandon S. Allbery KB8JRR) (02/16/91)
As quoted from <CLARK.91Feb11181727@discord.cme.nist.gov> by clark@cme.nist.gov (Steve Clark): +--------------- | In article <CLARK.91Feb11160645@discord.cme.nist.gov>, I wrote: | Steve> cd $HOME | Steve> echo ./subdir/hugedir | tar cX - . | | >>>>> On 11 Feb 91 21:40:54 GMT, jik@athena.mit.edu (Jonathan I. Kamens) said: | Jonathan> What version of Unix are you using? What version of tar? | | Ooops. I made a mistaken generalization, it seems. Since Gnu tar | does the obvious thing with the `-' filename after -X, I assumed SunOS +--------------- Yeah, but what versions of tar have the X option? Remember that Gnu tar has a LOT of options that no other tar has. (Well, standard tar, I ignore commercial add-ons like LoneTar.) ++Brandon -- Me: Brandon S. Allbery VHF/UHF: KB8JRR on 220, 2m, 440 Internet: allbery@NCoast.ORG Packet: KB8JRR @ WA8BXN America OnLine: KB8JRR AMPR: KB8JRR.AmPR.ORG [44.70.4.88] uunet!usenet.ins.cwru.edu!ncoast!allbery Delphi: ALLBERY
bernie@metapro.DIALix.oz.au (Bernd Felsche) (02/16/91)
In <1991Feb12.043341.29652@athena.mit.edu> scs@adam.mit.edu (Steve Summit) writes: >This will probably spark a big "cat -v considered harmful" >flamefest, but I'll opine that adding this tar X option wasn't >very worthwhile. The right way to exclude files matching some >pattern is > tar c `find . -print | grep -v pattern` >Now, Unix is far less restrictive than most operating systems on >things like command line length limitations, but this is one case >where you can overload even the generous allotments that the >shells (and exec) give you. Therefore, a wrinkle that *is* a >worthwhile addition to tar is a way to read a list of filenames >from a file, or from standard input. I once implemented this as A permanent fix would be to have a dynamically-sized u_area, or whatever it's called now. The arg list could then be stored in it, no matter how large it gets (within address space limitations). This means that commands don't have to read stdin or files for filenames, or whatever. -- _--_|\ Bernd Felsche #include <std/disclaimer.h> / \ Metapro Systems, 328 Albany Highway, Victoria Park, Western Australia \_.--._/ Fax: +61 9 472 3337 Phone: +61 9 362 9355 TZ=WST-8 v E-Mail: bernie@metapro.DIALix.oz.au | bernie@DIALix.oz.au
guy@auspex.auspex.com (Guy Harris) (02/18/91)
>A permanent fix would be to have a dynamically-sized u_area, or >whatever it's called now. The arg list could then be stored in it, no >matter how large it gets (within address space limitations). It's generally still called the U area; however, it generally does *not* store the arg list (System V systems may store the first 80 or so characters of it as a string with blanks between them, for the benefit of "ps", but that's different). Perhaps it could be made to do so; however, at least one of the systems that supports huge argument lists, namely SunOS 4.x (1MB of args), manages to do so without storing arg lists in a dynamically-sized U area. Dunno about other systems that do (I believe S5R4 and some of the later Research UNIXes do), but I suspect they don't do so, either.
scs@adam.mit.edu (Steve Summit) (02/24/91)
In article <1991Feb16.083327.13256@metapro.DIALix.oz.au> bernie@metapro.DIALix.oz.au (Bernd Felsche) writes: >In <1991Feb12.043341.29652@athena.mit.edu> scs@adam.mit.edu (Steve Summit) writes: >>The right way to exclude files matching some pattern is > >> tar c `find . -print | grep -v pattern` > >>Now, Unix is far less restrictive than most operating systems on >>things like command line length limitations, but this is one case >>where you can overload even the generous allotments that the >>shells (and exec) give you. Therefore, a wrinkle that *is* a >>worthwhile addition to tar is a way to read a list of filenames >>from a file, or from standard input. > >A permanent fix would be to have a dynamically-sized u_area, or >whatever it's called now. The arg list could then be stored in it, no >matter how large it gets (within address space limitations). This >means that commands don't have to read stdin or files for filenames, >or whatever. I'd hate to sound like an apologist for fixed-size arrays, because I generally try to stamp them out whenever possible. However, a way for tar to read filenames from a file or stream is still important, because its uses are such that those address space limitations could actually burn you in practice. I have selectively written tapes with tens of kilobytes of filenames alone, which wouldn't have been possible on a pdp11 (or other 16-bit, 64K address space machine). Steve Summit scs@adam.mit.edu