Update: On closer inspection of the man page it appears that it is not yet supported by unzip to read archives from standard input. The man page refers the user to funzip instead. I guess this makes my question moot, but I will leave it regardless.

I am trying to compose zip and unzip to create a command that acts as the identity function, meaning that it accepts input in stdin and produces the same output on stdout. I am, however, not able to get it working. I read both manual pages (especially zip had a detailed one) and believed that this would work

echo "hello" | zip | unzip -p | echo


  • echo should produce the initial standard input
  • zip without commands, according to the man page, takes input on stdin and produces output on stdout
  • unzip with -p should produce output on stdout. NOTE: I believe something might be missing here, to indicate that input is arriving from stdin. I tried adding - but it did not work. The man page does not seem to cover this.
  • echo to visualize what appeared on stdout

Please note: I am only trying to feed a single file through this command, so I do not need to worry about directories/multiple files.

  • Side note about "echo to visualize what appeared on stdout" – Even if zip and unzip worked as you want, | echo would be wrong. Mar 14, 2023 at 10:25
  • why do you want to use zip? Zip is an archiver (which can also compress), and it seems you want a compressor instead: Mar 14, 2023 at 11:02
  • 1
  • The choice is not so important, I am working on something else and want two simple commands that when composed form an identity function. I am fuzzing this composed function to perform some evaluation, which is my point of interest. The function in question is not super important. @KamilMaciorowski
    – Rewbert
    Mar 14, 2023 at 11:30
  • "I[...] want two simple commands that when composed form an identity function" - how about cat | cat or tac | tac? Can't get much simpler than the first Mar 14, 2023 at 14:26

1 Answer 1


unzip requires the archive to be seekable (random access), because zip accumulates information on the archived files, and writes the whole contents list and statistics at the end. So a pipe will never be acceptable as a zip archive.

zip does not even know the lengths of each file inside the archive as it writes them, because they are individually compressed on the fly.

tar, by way of contrast, can be written and read through pipes. The overhead for this is (a) the file must be read serially to locate specific files (because the metadata is spread through the archive), and (b) the whole archive needs to be compressed and decompressed as one unit, so retrieving one file requires the whole archive to be decompressed.

Edit: slight rider on the tar notes: if the archive is not compressed, then tar can seek over file data on disk (it knows the size of each file, and the block padding rules). If a tape drive has a "skip blocks" capability, it can use that. In a pipeline, it has to read and discard any files it wants to skip.

  • 1
    To stress this twice: "is not yet supported": yes, and it never will; as Paul says in his first paragraph, it's inherent to the zip format that you need the whole archive to get anything from it. Mar 14, 2023 at 11:01

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .