zip в stdout: длина зависит от оператора перенаправления

Хм. Аналогично. Даже более:

zip 3.zip zeroes

Содержимое - понятно, там дата-время и всё такое.

В csh оба файла одинакового размера.

Но, чёрт возьми, КАК, Холмс?!

иди читай про разницу режима записи и режима добавления.

Точно. А в bash, dash и zsh - разные.

Чего? Если файл не существует, >> работает так же, как >.

Use zip -q ... (quiet mode), Luke!

Нерелевантно.

rc делает так (возможно, и csh), заместо O_APPEND:

open("2.zip", O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = 4
_llseek(4, 0, [0], SEEK_END)            = 0

zip в обоих случаях делает то же самое. Три вызова write и два lseek.

А вот как бы поведение шелла с помощью strace отловить?

http://stackoverflow.com/questions/24223661/o-append-flag-and-lseek

       O_APPEND
              The file is opened in append mode.  Before each write(2), the file offset is positioned at the end of the  file,  as
              if  with lseek(2).  O_APPEND may lead to corrupted files on NFS filesystems if more than one process appends data to
              a file at once.  This is because NFS does not support appending to a file, so the client kernel has to simulate  it,
              which can't be done without a race condition.

Похоже, оно.

Похоже, таки баг, и исправление вроде обещали в Zip 3.1:

Thanks for the report. This looks to me like a bug. I took a quick look, and it seems that in the «>>» case, Zip knows that the archive output is not seekable, and, accordingly, sets bit 3 (data descriptors) in the general purpose bit flags, but then, after putting out the compressed data, it apparently tries to (seek back and) rewrite the local header, instead of putting out the (no-seek-needed) data descriptor. That probably explains complaints like these from «unzip -t»:

warning [ls_2.zip]: 64 extra bytes at beginning or within zipfile (attempting to process anyway) file #1: bad zipfile offset (local header sig): 64 (attempting to re-compensate)

We'll add this to the bug list.

http://www.info-zip.org/phpBB3/viewtopic.php?f=6&t=422

А вот как бы поведение шелла с помощью strace отловить?

Если бы виноват был шелл, то любая операция >> давала бы тот же эффект, а так только zip косячит

Мне гораздо больше интересно, как ты дошёл до таких тестов zip.

То есть наверное тебе не просто так в голову пришла мысль заставить работать zip через >> ?

http://lurkmore.to/Rarjpeg

Но ведь такое обычно делают так:

zip -r rar.zip rar
cat jpeg.jpg rar.zip > rarjpeg.jpg

strace -f sh -c '...' , например

Да я вообще извращенец ещё тот (можно было догадаться).