Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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:


    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?

share|improve this question
Please don't crosspost: stackoverflow.com/questions/22441647/… – 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

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.

share|improve this answer
it still writes to the same directory back, where the source was taken from – royskatt Mar 18 '14 at 21:31

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
share|improve this answer
didn't work, see below – royskatt Mar 19 '14 at 8:17

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...

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.