If I have created a tarball including full path, how can I extract that
tarball to a different directory (using solaris tar) instead of having it
extract to the original full path?

I appreciate any advice...

Thanks,

AvidFan

"avidfan" <none@swbell.net> wrote in message
news:Xjf7d.312$q%7.47@newssvr11.news.prodigy.com...
> If I have created a tarball including full path, how can I extract that
> tarball to a different directory (using solaris tar) instead of having it
> extract to the original full path?
You can unpack with gtar, which by default removes the leading slash from
the file names in the archive:

mkdir /tmp/scratch
cd /tmp/scratch
gtar xvf myfiles.tar
/somedir/somefile0
gtar: Removing leading `/' from absolute path names in the archive
/somedir/somefile1
....

- Erlend Leganger

Erlend Leganger wrote:
> "avidfan" <none@swbell.net> wrote in message
> news:Xjf7d.312$q%7.47@newssvr11.news.prodigy.com...
> 
>>If I have created a tarball including full path, how can I extract that
>>tarball to a different directory (using solaris tar) instead of having it
>>extract to the original full path?
> 
> You can unpack with gtar, which by default removes the leading slash from
> the file names in the archive:

The OP asked to run solaris but not gnu tar.

A solution could be to run it in chroot environment (of course requires 
root)

In article <Xjf7d.312$q%7.47@newssvr11.news.prodigy.com>,
avidfan <none@swbell.net> wrote:
>If I have created a tarball including full path, how can I extract that
>tarball to a different directory (using solaris tar) instead of having it
>extract to the original full path?
>
>I appreciate any advice...
>
>Thanks,
>
>AvidFan
>
>


You can use pax to extract relative to the current directory. There should be 
an example in the man page

-Raf

2004-10-01, 16:10(+00), avidfan:
> If I have created a tarball including full path, how can I extract that
> tarball to a different directory (using solaris tar) instead of having it
> extract to the original full path?
[...]

You can't with tar. Use pax instead.

pax -rv -f file.tar -s ',^/,,'

-- 
Stephane

Stephane CHAZELAS <this.address@is.invalid> wrote in message news:<slrncm1unl.1pg.stephane.chazelas@spam.is.invalid>...
> 2004-10-01, 16:10(+00), avidfan:
> > If I have created a tarball including full path, how can I extract that
> > tarball to a different directory (using solaris tar) instead of having it
> > extract to the original full path?
> [...]
> 
> You can't with tar. Use pax instead.
> 
> pax -rv -f file.tar -s ',^/,,'

you try with -C option. GUN tar supports -C option

 # tar xvf /tmp/back -C /tmp
/a
tar: Removing leading `/' from member names

2004-10-4, 08:05(-07), tosundaram@gmail.com:
> Stephane CHAZELAS <this.address@is.invalid> wrote in message news:<slrncm1unl.1pg.stephane.chazelas@spam.is.invalid>...
>> 2004-10-01, 16:10(+00), avidfan:
>> > If I have created a tarball including full path, how can I extract that
>> > tarball to a different directory (using solaris tar) instead of having it
>> > extract to the original full path?
[...]
> you try with -C option. GUN tar supports -C option
>
>  # tar xvf /tmp/back -C /tmp
> /a
> tar: Removing leading `/' from member names

-C is GNU specific, and it doesn't affect the removal of "/".
GNU tar removes the leading "/" by default (use the -P option to
prevent it).

-- 
Stephane

In article <slrncm2rps.1jg.stephane.chazelas@spam.is.invalid>,
Stephane CHAZELAS  <this.address@is.invalid> wrote:

>-C is GNU specific, and it doesn't affect the removal of "/".
>GNU tar removes the leading "/" by default (use the -P option to
>prevent it).

-C is not GNU specific, all TAR implementations should support it.

However only star and gnutar support it in extract mode.....

-- 
EMail:joerg@schily.isdn.cs.tu-berlin.de (home) J�rg Schilling D-13353 Berlin
      js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
      schilling@fokus.fraunhofer.de	(work) chars I am J"org Schilling
URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

2004-10-4, 21:57(+00), Joerg Schilling:
[...]
> -C is not GNU specific, all TAR implementations should support it.
[...]

I agree it's not GNU specific.

Why should applications have it? Is it in any standard?

SUSV3 has no tar command. SUSV2 has a LEGACY marked one, but
no "-C", AFAICS. Unix V7 tar didn't have one.

It seems to have appeared in BSD (was in 2.10BSD).

Solaris 8 tar has no -C option either.

-- 
Stephane

In article <slrncm4mps.1jg.stephane.chazelas@spam.is.invalid>,
Stephane CHAZELAS  <this.address@is.invalid> wrote:
>2004-10-4, 21:57(+00), Joerg Schilling:
>[...]
>> -C is not GNU specific, all TAR implementations should support it.
>[...]
>
>I agree it's not GNU specific.
>
>Why should applications have it? Is it in any standard?

Because it makes sense....

>SUSV3 has no tar command. SUSV2 has a LEGACY marked one, but
>no "-C", AFAICS. Unix V7 tar didn't have one.
>
>It seems to have appeared in BSD (was in 2.10BSD).

It did appear around 1980.
Note that the fact that SUSV3 does not include a tar utility
is a result of the fact that AT&T has been able to introduce the
unskillful CPIO format and cpio utility to POSIX.1-1988.
Now with POSIX.1-2001, the CPIO archive format has finally been
declared as what it always has been: a format without future.

As a result of putting cpio into POSIX.1-1988, a tar vs. cpio war came
up in the standard committees. 

As usual, the result was a new utility that nobody likes (pax) has been
created and made it into the POSIX standard. The pax utility by default
creates tar archives and a new archive format (called "pax") has been
created. The pax archive format is just an infinitely 
extensible extension to the good old TAR archive format. 

Star <ftp://ftp.berlios.de/pub/star/alpha/> is the first implementation
that supports this new pax (extended tar) format (since August 2001).

As users still prefer the tar command line syntax and don't like the
pax syntax, it makes sense to implement what star does:

	A utility that supports both the pax and the tar command line
	interface in a single binary.

Star gives you POSIX.1-2001 compliance with the "pax" cmdline interface
and a lot of extension with the "star" cmdline interface. Star even allows
you to do "true incremental dumps" in a OS and FS independent way without
drawbacks compared to ufsdump/ufsrestore.

>Solaris 8 tar has no -C option either.

Wrong! ---> RTFM

-- 
EMail:joerg@schily.isdn.cs.tu-berlin.de (home) J�rg Schilling D-13353 Berlin
      js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
      schilling@fokus.fraunhofer.de	(work) chars I am J"org Schilling
URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

2004-10-5, 13:09(+00), Joerg Schilling:
[...]
>>> -C is not GNU specific, all TAR implementations should support it.
>>[...]
>>
>>I agree it's not GNU specific.
>>
>>Why should applications have it? Is it in any standard?
>
> Because it makes sense....

Why? why should tar have a -C option and not grep or ls?

Why wouldn't one do:

(cd directory && tar c)

?

[...]
>>Solaris 8 tar has no -C option either.
>
> Wrong! ---> RTFM

Right! it's in the man page but not in the usage message. It's
only available for "c" and "r", though.


-- 
Stephane

In article <slrncm59k2.1jg.stephane.chazelas@spam.is.invalid>,
Stephane CHAZELAS  <this.address@is.invalid> wrote:
>2004-10-5, 13:09(+00), Joerg Schilling:
>[...]
>>>> -C is not GNU specific, all TAR implementations should support it.
>>>[...]
>>>
>>>I agree it's not GNU specific.
>>>
>>>Why should applications have it? Is it in any standard?
>>
>> Because it makes sense....
>
>Why? why should tar have a -C option and not grep or ls?
>
>Why wouldn't one do:
>
>(cd directory && tar c)

Because -C may appear multiple times and "cd somewhere" does not
help in this case.

Not that star also allows you to distribute files by patterns:

star -xp -C headers pat=*.h -C sources pat=*.c -C /tmp/ pat=* f=archive

will extract all *.h files to the directory "headers", all *.c files
to the directory sources and all other files to /tmp.

How do you like to do this in one star run without using -C?

-- 
EMail:joerg@schily.isdn.cs.tu-berlin.de (home) J�rg Schilling D-13353 Berlin
      js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
      schilling@fokus.fraunhofer.de	(work) chars I am J"org Schilling
URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

js@cs.tu-berlin.de (Joerg Schilling) writes:

> Not that star also allows you to distribute files by patterns:
>
> star -xp -C headers pat=*.h -C sources pat=*.c -C /tmp/ pat=* f=archive
>
> will extract all *.h files to the directory "headers", all *.c files
> to the directory sources and all other files to /tmp.
>
> How do you like to do this in one star run without using -C?
>

My first question is why would you want to do this? Extract all files and
use mv afterwards. Freely. The probablity of error in a too complex single
line command is rather high. 

Besides, shouldn't the above be


star -xp -C headers pat='*.h' -C sources pat='*.c' -C /tmp/ pat='*' f=archive

?

Bye, Dragan

-- 
Dragan Cvetkovic, 

To be or not to be is true. G. Boole      No it isn't.  L. E. J. Brouwer

!!! Sender/From address is bogus. Use reply-to one !!!

In article <lmzn31dvb9.fsf@privacy.net>,
Dragan Cvetkovic  <dragan_usenet@gmx.net> wrote:
>js@cs.tu-berlin.de (Joerg Schilling) writes:
>
>> Not that star also allows you to distribute files by patterns:
>>
>> star -xp -C headers pat=*.h -C sources pat=*.c -C /tmp/ pat=* f=archive
>>
>> will extract all *.h files to the directory "headers", all *.c files
>> to the directory sources and all other files to /tmp.
>>
>> How do you like to do this in one star run without using -C?

>My first question is why would you want to do this? Extract all files and
>use mv afterwards. Freely. The probablity of error in a too complex single
>line command is rather high. 

Well, star is based on a single archiving engine that needs to support
anything that is required by the various historic archive utilities.

The POSIX standard has complex requirements for pattern matching and
the star feature is very easy to implement once you can do what pax requires.

Regarding the mv idea: You may be right if the target directory is empty
and the number of files to move is low.

-- 
EMail:joerg@schily.isdn.cs.tu-berlin.de (home) J�rg Schilling D-13353 Berlin
      js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
      schilling@fokus.fraunhofer.de	(work) chars I am J"org Schilling
URL:  http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily

In article <cjulf3$3ki$1@news.cs.tu-berlin.de>, Joerg Schilling wrote:
> Regarding the mv idea: You may be right if the target directory is empty
> and the number of files to move is low.

... or if you are staying within the same FS.
                                                                Daniel
-- 
\ Daniel Rychcik     INTEGRAL Science Data Centre, Versoix/Geneve, CH
 \--------------------------------------------------------------------
  \  GCM/CS/MU/M d- s++:+ a- C+++$ US+++$ P+>++ L+++$ E--- W++ N++ K-
   \ w- O- M PS+ PE Y+ PGP t+ 5 X- R tv b+ D++ G+ e+++ h--- r+++ y+++ 

Joerg Schilling <js@cs.tu-berlin.de> wrote:
> In article <slrncm4mps.1jg.stephane.chazelas@spam.is.invalid>,
> Stephane CHAZELAS  <this.address@is.invalid> wrote:
>>2004-10-4, 21:57(+00), Joerg Schilling:
>>[...]
>>> -C is not GNU specific, all TAR implementations should support it.
>>[...]
>>
>>I agree it's not GNU specific.
>>
>>Why should applications have it? Is it in any standard?
> 
> Because it makes sense....

Ah, so "should" means "in my world..." rather than "in order to conform
to standards..."

Gotcha.

2004-10-5, 15:38(+00), Joerg Schilling:
[...]
>>Why? why should tar have a -C option and not grep or ls?
>>
>>Why wouldn't one do:
>>
>>(cd directory && tar c)
>
> Because -C may appear multiple times and "cd somewhere" does not
> help in this case.
[...]

Sure. That makes sense now. And I understand now why some tar
implementations only have it for "c" or "r".

The whole point is to reshape the content of the archive so that
it contains a different directory structure as the original. It
can be then seen as a subset of pax -s substitute
fonctionnality.

Thanks,
Stephane