extracting to a directory other than the current directory with pax archiver

Question

I have a strange behaviour with the pax archiver here, had too much troubles with tar and it's absolute path, that's why I gave pax a shot. The below oneliner is used under FreeBSD 9.2 to extract encrypted archives. Basically it works quite well, but when trying to extract the archive to another path than the working directory, I get the error message:

WARNING! These patterns were not matched:
/home/myuser/testing

Example:

    cd /home/myuser

    gpg --no-tty --quiet --no-secmem-warning --yes --batch --passphrase-file /home/myuser/keyfile --decrypt /home/myuser/testing/20110426.pax.xz.gpg | unxz | pax -r 
    # SUCCESS                                                                                                                                                 # SUCCESS

    gpg --no-tty --quiet --no-secmem-warning --yes --batch --passphrase-file /home/myuser/keyfile --decrypt /home/myuser/testing/20110426.pax.xz.gpg | unxz | pax -r /home/myuser
    # SUCCESS                                                                                                                                                 # SUCCESS

    gpg --no-tty --quiet --no-secmem-warning --yes --batch --passphrase-file /home/myuser/keyfile --decrypt /home/myuser/testing/20110426.pax.xz.gpg | unxz | pax -r /home/myuser/testing
    # FAILS                                                                                                                                                   # FAILS

    gpg --no-tty --quiet --no-secmem-warning --yes --batch --passphrase-file /home/myuser/keyfile --decrypt /home/myuser/testing/20110426.pax.xz.gpg | unxz | pax -r /home/myuser/testing/
    # FAILS                                                                                                                                                   # FAILS

There is definately write permission on /home/myuser/testing/ on top of that, I'm executing it as root.

Does that really "works as designed" and I have to cd /output/path before each extraction or am doing something wrong?

Please don't crosspost: http://stackoverflow.com/questions/22441647/bash-strange-behaviour-with-pax-archiver — jasonwryan, Mar 16 '14 at 19:57
Sorry, later on I realized that this place might be the better one... — royskatt, Mar 16 '14 at 20:18
@royskatt - this post already has 3 close votes b/c of that, you might want to delete the other Q and let ppl know here that you've done so, it will likely get closed by then here but then we can reopen it.. — slm, Mar 16 '14 at 21:38

score 6 · Answer 1 · answered Mar 16 '14 at 19:59

Yes, you have to cd first.

When you provide a file name argument, you're telling pax to only extract files matching that argument.

POSIX pax docs

In read mode (when -r is specified, but -w is not), pax shall extract the members of the archive file read from the standard input, with pathnames matching the specified patterns.

The error message you get

WARNING! These patterns were not matched: /home/myuser/testing

Is telling you that your archive doesn't contain any files under that directory.

it still writes to the same directory back, where the source was taken from — royskatt, Mar 18 '14 at 21:31

score 3 · Accepted Answer · edited Mar 18 '14 at 21:38

3

The argument to pax is a path inside the archive. The usual idiom if you want to unpack under a different directory is to change to the directory where you want to unpack.

… | { cd / && pax -r -pe; }

Another approach is to tell pax to rewrite the paths. This is especially useful when you want to strip some leading directories.

… | pax -s '!^/home/myuser!!' -r -pe

edited Mar 18 '14 at 21:38

Stéphane Chazelas

522,931
91
1,010
1,501

answered Mar 17 '14 at 01:14

Gilles 'SO- stop being evil'

807,993
194
1,674
2,175

didn't work, see below – royskatt Mar 19 '14 at 08:17

score 0 · Answer 3 · answered Mar 18 '14 at 21:37

Unfortunately none of your suggestions worked. What works is:

...| pax -rv -s '=^/old/source/dir/=/new/target/dir/='

Only one problem remains: I can't use shell variables in the regular expression. Workaround could be: creating the whole piped command dynamically in a for loop, but that's another story...

extracting to a directory other than the current directory with pax archiver

3 Answers3