why doesn't 'tar' work?

why doesn't 'tar' work?

Post by Dushan Mitrovi » Fri, 20 Sep 2002 02:44:00



I've noticed in my RedHat 7.2 install that 'tar' doesn't seem to work.  For
any file  xxxx.tar.gz  when I issue the command

    tar --gunzip --extract xxxx.tar.gz

(or with 'z' replacing '-gunzip', 'x' replacing '-extract'), absolutely
nothing happens.  When I finally stop it with a Ctrl-Z, the prompt comes
back, and then I can kill the stopped tar process.  This behavior is in-
dependent of my being root or user, and occurs both from a cmd line shell
and from MC's cmd line.

Further, if I first unzip the *.gz file using gunzip, then use 'tar':

    tar --extract xxxx.tar

exactly the same thing happens.

OTOH, from MC I can simply press Enter on the *.gz file and see all its
content, and also copy any selection of files to whereever I want.  So ap-
parently 'tar' or its equivalent works for MC, but not for me the way I was
trying to use it.  Anyone have any suggestions as to what I'm doing wrong?

Thx.

- Dushan Mitrovich

 
 
 

why doesn't 'tar' work?

Post by Henrik Farr » Fri, 20 Sep 2002 03:25:55



>     tar --gunzip --extract xxxx.tar.gz
>     tar --extract xxxx.tar

If you just looked at the man page you would see it:

EXAMPLES
       tar -xvvf foo.tar
              extract foo.tar

       tar -xvvzf foo.tar.gz
              extract gzipped foo.tar.gz

       tar -cvvf foo.tar foo/
              tar contents of folder foo in foo.tar

See the f ? ;)

--
Mvh. / Kind regards
Henrik Farre
http://www.cs.auc.dk/~enrique
http://www.fsf.org/philosophy/no-word-attachments.html

 
 
 

why doesn't 'tar' work?

Post by mjt » Fri, 20 Sep 2002 03:49:00



Quote:> I've noticed in my RedHat 7.2 install that 'tar' doesn't seem to work.  For
> any file  xxxx.tar.gz  when I issue the command

>     tar --gunzip --extract xxxx.tar.gz

[bash] tar -xvzf filename.tar.gz

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 Michael J. Tobler: motorcyclist, surfer,  #    Black holes result
 skydiver, and author: "Inside Linux",     #   when God divides the  
 "C++ HowTo", "C++ Unleashed"              #     universe by zero

 
 
 

why doesn't 'tar' work?

Post by unknow » Fri, 20 Sep 2002 04:25:21



> I've noticed in my RedHat 7.2 install that 'tar' doesn't seem to work.
> For any file  xxxx.tar.gz  when I issue the command

>     tar --gunzip --extract xxxx.tar.gz

> (or with 'z' replacing '-gunzip', 'x' replacing '-extract'), absolutely
> nothing happens.  When I finally stop it with a Ctrl-Z, the prompt comes
> back, and then I can kill the stopped tar process.  This behavior is in-
> dependent of my being root or user, and occurs both from a cmd line
> shell and from MC's cmd line.

> Further, if I first unzip the *.gz file using gunzip, then use 'tar':

>     tar --extract xxxx.tar

> exactly the same thing happens.

> OTOH, from MC I can simply press Enter on the *.gz file and see all its
> content, and also copy any selection of files to whereever I want.  So
> ap- parently 'tar' or its equivalent works for MC, but not for me the
> way I was trying to use it.  Anyone have any suggestions as to what I'm
> doing wrong?

> Thx.

> - Dushan Mitrovich

For some reason, tar isn't clever enough to figure out that the thingie
mentioned after the options flag is the file name.

Try ending all tar command flags (the one letter things following the '-'
with an f and see what happens!
--
Cheers,

dmz17 --- If I had an Xbox it would run Linux ---

 
 
 

why doesn't 'tar' work?

Post by The.Central.Scrutinizer.wakaw.. » Fri, 20 Sep 2002 06:14:14



>For some reason, tar isn't clever enough to figure out that the thingie
>mentioned after the options flag is the file name.

everything in unix is a filename.  Tar without the 'f' param uses a tape drive
for storing/retrieving archives.
 
 
 

why doesn't 'tar' work?

Post by Paul Lutu » Fri, 20 Sep 2002 07:28:29





>>For some reason, tar isn't clever enough to figure out that the thingie
>>mentioned after the options flag is the file name.

> everything in unix is a filename.

Really.

/dev/hda1 is not a file name, it is a device name.

/dev is not a file name, it is a directory name.

/proc/* are devices and resources, none are files. They don't act like
files, because they aren't.

There was a poster in another group the other day complaining that he
couldn't delete that useless "file" /proc/kcore that (he thought) was
wasting so much space on his drive. Fortunately Linux didn't let him do
what he wanted. Why? Because /proc/kcore is not a file.

Quote:> Tar without the 'f' param uses a tape
> drive for storing/retrieving archives.

Only if you specify the drive, or stream the drive's data to tar. Tar
defaults to standard input, and that is why the OP had the result he did.

Tar doesn't know about tape drives per se, it only knows about the format of
data streams from and to tape drives.

--
Paul Lutus
www.arachnoid.com

 
 
 

why doesn't 'tar' work?

Post by The.Central.Scrutinizer.wakaw.. » Fri, 20 Sep 2002 08:11:32






>>>For some reason, tar isn't clever enough to figure out that the thingie
>>>mentioned after the options flag is the file name.

>> everything in unix is a filename.
>Really.
>/dev/hda1 is not a file name, it is a device name.

It is both.
 
 
 

why doesn't 'tar' work?

Post by Paul Lutu » Fri, 20 Sep 2002 08:18:57







>>>>For some reason, tar isn't clever enough to figure out that the thingie
>>>>mentioned after the options flag is the file name.

>>> everything in unix is a filename.

>>Really.

>>/dev/hda1 is not a file name, it is a device name.
> It is both.

This is entirely wrong. It is not a file name by any stretch of the
imagination. It is a device, not a directory, and not a file. The fact that
you can stream from it is a separate issue.

You might have been better off saying "Everything in a Unix filesystem is a
stream," but that also would lead to some substantial disagreement. It is,
however, much closer to the truth than "everything in Unix is a filename."
Only files have file names.

--
Paul Lutus
www.arachnoid.com

 
 
 

why doesn't 'tar' work?

Post by TheMartia » Fri, 20 Sep 2002 08:37:55


After a long battle with technology, "Dushan Mitrovich" an earthling

Quote:> I've noticed in my RedHat 7.2 install that 'tar' doesn't seem to work.
> For any file  xxxx.tar.gz  when I issue the command

>     tar --gunzip --extract xxxx.tar.gz

> (or with 'z' replacing '-gunzip', 'x' replacing '-extract'), absolutely
> nothing happens.  When I finally stop it with a Ctrl-Z, the prompt comes
> back, and then I can kill the stopped tar process.  This behavior is in-
> dependent of my being root or user, and occurs both from a cmd line
> shell and from MC's cmd line.

> Further, if I first unzip the *.gz file using gunzip, then use 'tar':

>     tar --extract xxxx.tar

> exactly the same thing happens.

> OTOH, from MC I can simply press Enter on the *.gz file and see all its
> content, and also copy any selection of files to whereever I want.  So
> ap- parently 'tar' or its equivalent works for MC, but not for me the
> way I was trying to use it.  Anyone have any suggestions as to what I'm
> doing wrong?

> Thx.

> - Dushan Mitrovich

tar xvfz filename.tar.gz

for more look at

www.ozetechnology.com/howtos/compress.shtml

--
www.ozetechnology.com
AIM:OrigMartian
PGP key: www.ozetechnology.com/downloads/watsondk.pgp
Fingerprint: CC14B85A31383A6E83CD996F9F15DF008264C766
100% Microsoft Free. Unleash the power of the Penguin

 
 
 

why doesn't 'tar' work?

Post by ?yvind R?tvol » Fri, 20 Sep 2002 15:39:52


[snip]

Quote:

> For some reason, tar isn't clever enough to figure out that the thingie
> mentioned after the options flag is the file name.

tar isn't clever enough to do what you didn't say but might have
intended.  In fact, it does excatly as you say.  I think this is a
good thing.  People who don't like that you should consider Windows,
it often does what it thinks you want rather than what you say.

[snip]

--
?yvind R?tvold, URL: http://www.darkside.no/olr/index.html

And I get trouble with my breathing
When she says boys don't know anything
But I know what I want it's easy - I want everything

 
 
 

why doesn't 'tar' work?

Post by Brett E. Dufaul » Fri, 20 Sep 2002 23:14:10



Quote:> For some reason, tar isn't clever enough to figure out that the thingie
> mentioned after the options flag is the file name.

Actually, tar *does* know the "thingie" (*grin*) is a filename.  But
without the -f option that you mentioned, tar *doesn't* know that the
"thingie" filename is the archive that it's supposed to process.  Tar
thinks the "thingie" is the name of a file it's supposed to retrieve from
inside some archive.

Where the heck is tar looking for an archive if you don't give it "-f"?  In
some Unixes, tar defaults to a tape device. (Remember that the name "tar"
is a shortened form of "Tape ARchive".)  In current Red Hat releases, tar
defaults to reading the archive data from stdin.

Ex: the command "tar x foo" tells tar to read an archive from stdin, and
retrive the file/directory named "foo" from the data stream on stdin.  
Someone who bzips their user backups might recover a user's home directory
using something like:

        bzcat user_backups.tar.bz2 | tar x home/tom

Or maybe the user accidentally deleted a critical tarball, and just needs
that one file restored:

        bzcat user_backups.tar.bz2 | tar x home/tom/beta_release.tar.gz

That'll retrieve Tom's beta release archive from inside the master
user_backups.tar.bz2 archive.  (It will *not* try and process
beta_release.tar.gz as an archive -- to tar, any dangling thingies are just
filenames to look for inside of some other archive.)

You can supply a whole list of files to tar, which it will treat as a list
of files/dirs to retrieve from the archive.  Example for someone who uses a
gzipped tarball for user backups, and has three desperate users needing
their home directories restored:

        tar xzf user_backups.tar.gz home/arthur home/betty home/charlie

All clear now?  :-)

Cheers,
--Brett

 
 
 

why doesn't 'tar' work?

Post by spi.. » Sat, 21 Sep 2002 01:17:43






>>>For some reason, tar isn't clever enough to figure out that the thingie
>>>mentioned after the options flag is the file name.

>> everything in unix is a filename.
> Really.
> /dev/hda1 is not a file name, it is a device name.

It's a special file.
It's still a file though... just a node pointing to the hardware.

Quote:> /dev is not a file name, it is a directory name.

dev is a file containing directory information and files.
Still a file though, just a different type)

Quote:> /proc/* are devices and resources, none are files. They don't act like
> files, because they aren't.

The do act like files. /proc is a virtual file system.
If you cat /proc/cpuinfo, it returns text contained in the virtual file
cpuinfo... As far as the user, the applications and everything but the
kernel are concerned, everything in proc is just a file.

Quote:> There was a poster in another group the other day complaining that he
> couldn't delete that useless "file" /proc/kcore that (he thought) was
> wasting so much space on his drive. Fortunately Linux didn't let him do
> what he wanted. Why? Because /proc/kcore is not a file.

Heheheh, it appears as a file though. That's what matters.
In unix, from the application point of view, everything *IS* a file.
Even stdin and stdout have file descriptors. Pipes have file descriptors.
Sockets... well, you get the point.
 
 
 

why doesn't 'tar' work?

Post by spi.. » Sat, 21 Sep 2002 01:19:20



> This is entirely wrong. It is not a file name by any stretch of the
> imagination. It is a device, not a directory, and not a file. The fact that
> you can stream from it is a separate issue.

You can stream from it, move it, rename it, delete it, symlink to it...
Looks like a file to me.
 
 
 

why doesn't 'tar' work?

Post by Paul Lutu » Sat, 21 Sep 2002 01:57:33




>> This is entirely wrong. It is not a file name by any stretch of the
>> imagination. It is a device, not a directory, and not a file. The fact
>> that you can stream from it is a separate issue.

> You can stream from it, move it, rename it, delete it, symlink to it...
> Looks like a file to me.

Those paths in Unix that do not lead to files, are not files, and do not act
like files. Try writing to, then reading back from, the various "files"
under the /proc" directory as root. Yes, I am kidding. I am kidding because
this will ruin your install, and that in turn is because you are wrong.

Your statements will get beginners into serious trouble, as I already
explained.

--
Paul Lutus
www.arachnoid.com

 
 
 

why doesn't 'tar' work?

Post by Paul Lutu » Sat, 21 Sep 2002 02:23:47







>>>>For some reason, tar isn't clever enough to figure out that the thingie
>>>>mentioned after the options flag is the file name.

>>> everything in unix is a filename.

>> Really.

>> /dev/hda1 is not a file name, it is a device name.

> It's a special file.
> It's still a file though... just a node pointing to the hardware.

Then open it and write to it. First, back up your entire system and get
ready for a re-install.

Quote:

>> /dev is not a file name, it is a directory name.

> dev is a file containing directory information and files.
> Still a file though, just a different type)

Then open it and write to it. First, back up your entire system and get
ready for a re-install.

Quote:

>> /proc/* are devices and resources, none are files. They don't act like
>> files, because they aren't.

> The do act like files. /proc is a virtual file system.

No, they do not act like files. They act like resources. Which normal
"files" return different contents each time they are read?

Quote:> If you cat /proc/cpuinfo, it returns text contained in the virtual file
> cpuinfo...

"Virtual file?" It is an algorithm that emits a CPU description. If I write
a shell script that emits "Hello world" and arrange for that to be emitted
on a "read" of a system resource node, does that make it a file? No, among
other things because the "file" cannot be written. Its length cannot be
accurately determined. It cannot be randomly accessed. And so forth.

Quote:> As far as the user, the applications and everything but the
> kernel are concerned, everything in proc is just a file.

1. That is not how "everything" is defined. Your choice of words, not mine.

2. Then open it and write to it. First, back up your entire system and get
ready for a re-install.

Quote:

>> There was a poster in another group the other day complaining that he
>> couldn't delete that useless "file" /proc/kcore that (he thought) was
>> wasting so much space on his drive. Fortunately Linux didn't let him do
>> what he wanted. Why? Because /proc/kcore is not a file.

> Heheheh, it appears as a file though.

That was his problem, one of mistaken perception. It is also your problem.

Quote:> That's what matters.

No, what matters is actually understanding what these things are.

Quote:> In unix, from the application point of view, everything *IS* a file.

False. If you actually believed this, you would be re-installing daily.

Quote:> Even stdin and stdout have file descriptors.

But they are not files, they are streams. You do understand the difference,
yes?

Quote:> Pipes have file descriptors.

Pipes are streams, not files.

Quote:> Sockets... well, you get the point.

I sure do. You have no idea what you are talking about. Most of your
examples are examples of streams, not files (with the glaring exception of
the devices under /proc). Streams are not files. Try random access on a
stream, as just one example. Try to read its length. Try to rename it.

It is now clear that you are confusing streams with files. Files have a
length, streams do not. Files can be randomly accessed, streams cannot. And
so forth.

--
Paul Lutus
www.arachnoid.com

 
 
 

1. BUG: 'tar +help' doesn't work with libc.so.4.4!!

I just got and installed the new libs in image-4.4.tar.z.
I updated the links so that they are referenced.  I later tried
to to a 'tar +help' command and tar didn't recognize it.
It had always worked before, so i tried linking the library
reference back to the old lib (libc.so.4.3.3).  'tar +help'
worked fine!  I changed the link back to the new libc.so.4.4, tried
'tar +help' again, and it didn't work...obviously a bug somewhere.
(In tar or libc.so.4.4 I haven't the foggiest...)
--
Jeff Uphoff -- "Uppie"     |  "The secret to good teaching is sincerity.  As


2. AIX and POSIX

3. Why doesn't sed 's/$/^M/' work as expected?

4. BigEyes

5. Why: perl -e <<'EOF' doesn't work (bash)

6. check if unix file is opened

7. Why doesn't 'write' work??

8. wireless card

9. Why doesn't echo "text" 'command' "more text" work?

10. Why doesn't 'cut' utility work intuitively?

11. Why 'man' doesn't work?

12. Why doesn't echo "text" 'command' "more text" work?

13. ping -g 'gateway-IP' 'host-IP' DOESN'T work!