Difference between these 2 different ways of extracting files from a zip archive

It looks like you're using macos whose tar (the one from libarchive like on modern BSDs or Microsoft Windows, or the bsdtar you can install on GNU/Linux distributions) can extract zip files, and take the list of members to extract newline-delimited or NUL-delimited from a file (with the -T¹ option aka --files-from (like in GNU tar) aka -I²).

So:

for f ($zipdir/*.zip(N)) tar -xf $f -T unzip.txt

Beware, that like for unzip, lines of unzip.txt are treated as patterns, and it doesn't look like there's a way to disable it other than escaping the wildcard operators. There's also a special handling of a line containing just -C³.

That will complain if some members cannot be matched.

It can also generate a tar archive on the fly from a list of zip archives, with the tar -cf - @file1.zip @file2.zip... syntax, so you could also do:

(){tar -cf - @$^@ | tar -xf - -T unzip.txt} $zipdir/*.zip

Where the first tar outputs a tar concatenation of all the zip archives and the second extracts the requested members.

Then an error will only be reported if members listed in unzip.txt are found in none of the archives.

If you also have GNU tar (which doesn't doesn't do pattern-matching unless explicitly requested with --wildcards) installed, for instance as gtar or /opt/gnu/bin/tar, you can replace the second tar with gtar --verbatim-files-from so the file passed to -T be treated as a list of literal file paths. That works as that's tar format (as opposed to zip) that is fed to it which GNU tar can handle.

Above, the list of archives is passed as arguments to an anonymous function, so we can use @$^@ to prepend @ to each of them. You could also prepend that @ as part of the glob expansion using the e glob qualifier ($zipdir/*.zip(e:REPLY[1,0]=@:)) or with the histsubstpattern option enabled with the :s/pattern/replacement/ modifier ($zipdir/*.zip(:s/#/@)).

Note that your:

while IFS= read -r line; do
  printf "%s\0" "$line" 
done

Can be written tr '\n' '\0'⁴.

You can also get the contents of unzip.txt as an array of its non-empty lines using the f (to split on linefeed) parameter expansion flag:

files=( ${(f)"$(<unzip.txt)"} )

And use zsh's own zargs instead of xargs to split that list to avoid the E2BIG execve() error in case of very large lists:

autoload -U zargs
zargs -r --eof= -- $files '' unzip $f

As to why you get a different number of extracted files with xargs and different numbers passed to -n, that may be caused by unzip prompting the user and reading the response from stdin, which in this case is the pipe your loop is feeding, which means unzip may read parts of or the whole of the file list as soon as it issues a prompt.

With GNU xargs, you'd use:

xargs -rd '\n' -a unzip.txt unzip '/Volumes/filedir/*.zip'

(note the quotes around the globs, as unzip being more like a MS-DOS application actually does globbing by itself and in the process is able to extract members from more than one archive at a time).

Then xargs' and unzip's stdin remain untouched meaning that if you run that from a terminal, you'll be able to answer the prompts.

BSD xargs have neither -d nor -a, but has -o which tells it to reopen stdin on /dev/tty (you'd only use it when run from a terminal), so you can do:

<unzip.txt tr '\n' '\0' | xargs -or0 unzip '/Volumes/filedir/*.zip'

As noted by Matija Nalis, if there are are lines of unzip.txt that start with -d or -x, they'll be interpreted by unzip as destination directory or file pattern to exclude for the rest of the entries passed to that unzip invocation and even if -- is used.

Prefixing all bytes except the line delimiters with \ in unzip.txt would work around that and also avoid problems with entries that contain wildcard characters:

<unzip.txt LC_ALL=C sed 's/./\\&/g' |
  tr '\n' '\0' |
  xargs -or0 unzip '/Volumes/filedir/*.zip'

^{¹ from John Gilmore's public domain tar (upon which GNU tar is based) since at least as far back as 1986.}

^{² From SunOS 4.0 from 1988. I wouldn't be surprised if John Gilmore was also involved in that.}

^{³ A "feature" apparently inherited or inspired by GNU tar (added there in 1991). It's actually worse in GNU tar, where there's also whitespace trimming by default and where all strings starting with - in the file are treated as tar options, though only the position sensitive options are allowed. In GNU tar, you'd add the --verbatim-files-from (added in 1.29 from 2016) to make sure the file is interpreted as just a list of file paths.}

^{⁴ well, strictly speaking, the while loop would discard the part after the last newline character if any, while tr wouldn't.}

Firstly, double-quote your variables. e.g. use "$f" rather than just unquoted $f.

After that, the next thing that comes to mind is that if the unzip1.txt input file is newline-separated, then there's no point converting it to NUL separated for xargs. You should use -d '\n' instead of -0, then you can just cat or redirect unzip1.txt into xargs and avoid the excruciatingly slow shell while-read loop. e.g. xargs -d '\n' -n 100 unzip "$f" < unzip1.txt

But why use -n 100 to limit it to 100 files at a time? Is there any good reason for xargs to run unzip once per 100 files rather than the default of as many as will fit into a command line?

BTW, you may want to use unzip's -n option to always skip extracting files that already exist (e.g. were already extracted in a previous run of unzip). Or, more dangerously, -o to always overwrite existing files. See man unzip.

Also, $1 / $f is obviously the zipfile to be unzipped - personally, I'd use $zipfile or $zf rather than just $f, but that's a trivial detail. More importantly, is it being passed to the function with a full pathname or just the basename? And what is the $zipdir variable meant to be used for? Did you mean to cd to that directory before unzipping, or pass it to unzip as "$zipdir/$f"? Or is it meant to be the directory to extract into (using unzip's -d exdir option)?

Finally, ChatGPT is an LLM. That means it's a stochastic bullshit generator. It's not "intelligent", it's not "smart", and it doesn't understand anything, it just spews out text that is likely to follow from the prompt and previously-seen input.

I wouldn't trust any code "written" (i.e. plagiarised from the original author(s) without attribution and without regard to copyright) by it or any other LLM for any reason. I'd trust it even less than I would trust code posted by some random stranger on the net - at least the human stranger has a chance of understanding what they're doing, while an LLM has no chance of understanding anything.

I still wouldn't trust code from either unless I took the time to read and understand what that code was doing and how it was doing it.

The use of unquoted variables is an obvious example of LLM failure - it has just copied the error made by thousands or millions of novice shell programmers. There are far more examples of variables not being quoted, so it's far more likely to perpetuate that bad programming practice.

TL;DR: add -- to unzip.

There must be a bug in xargs, and how it works with unzip. Is this something that should be reported to xargs, or am I imagining this as a bug?

Statistically, when one has a problem with a tool that is used many times a day by many millions of people for decades, I'd say it is quite unlikely that one has found a genuine bug of such level.

As for the problem, I'd say it is (as it most often is) an user error. Try changing -n 1000 in your experiments to -n 1 and suddenly it will work as well as it did before.

The reason is likely in the filenames. When one bad filename causes unzip to abort, it only loses one file. When there were 10 others files in unzip, when unzip aborts, it loses all 10 files. Thus the difference.

I think you'll find out even your original script loses files, but less often (i.e. ls | wc -l will differ from wc -l unzip.txt

So, changing xargs -0 -n 1000 unzip $f to xargs -0 -n 1000 unzip -- $f (or even better just xargs -0 unzip -- $f, to use maximum available and safe size) should help in this particular case.

-- in many (but not all) commands forces the said command to stop interpreting any following parameters as possible options, and only consider them as filenames. It happens to work in my zip 3.0-13 from Debian Bookworm:

Consider the following example:

% mkdir /tmp/test
% cd /tmp/test
% touch ./a ./b ./c ./-d
% zip all.zip *

zip warning: all.zip not found or empty
zip error: Nothing to do! (all.zip)

% zip all.zip -- *
  adding: -d (stored 0%)
  adding: a (stored 0%)
  adding: b (stored 0%)
  adding: c (stored 0%)

Same problem would occur with unzip, of course.

If -- didn't work, you'd have to pre-process the filenames in unzip.txt so they are in format compatible with unzip(1). Prepending ./ might work (like I did with touch(1) in example above) but there might be other workarounds needed depending on filename breakage (e.g. not all filesystems support full UTF-8 complement of characters in filename, but that is another deeper problem for another question)

I'd also note somewhat relatedly that if that zip archive contains all kind of strange stuff, adding -j to that unzip might be prudent too.

And always verify if number of files extracted is the same as number or files you were expecting to get.