Qual è la differenza tra “file cat | ./binary "e" ./binary <file "?

Ho un file binario (che non posso modificare) e posso fare:

./binary < file

Posso anche fare:

./binary << EOF
> "line 1 of file"
> "line 2 of file"
...
> "last line of file"
> EOF

Ma

cat file | ./binary

mi dà un errore. Non so perché non funziona con una pipa. In tutti e 3 i casi il contenuto del file è dato allo standard input del binario (in diversi modi):

1. bash legge il file e lo dà allo stdin del binario
2. bash legge le righe da stdin (fino a EOF) e le dà a stdin di binario
3. cat legge e mette le linee di file su stdout, bash le reindirizza su stdin di binario

Il binario non dovrebbe notare la differenza tra quei 3 per quanto ho capito. Qualcuno può spiegare perché il terzo caso non funziona?

A proposito: l'errore dato dal binario è:

20170116 / 125624.689 - U3000011 Impossibile leggere il file di script '', codice errore '14'.

Ma la mia domanda principale è: in che modo c'è una differenza per qualsiasi programma con quelle 3 opzioni.

Ecco alcuni ulteriori dettagli: l'ho provato di nuovo con strace e in effetti c'erano alcuni errori ESPIPE (ricerca illegale) da lseek seguito da EFAULT (indirizzo errato) da leggere subito prima del messaggio di errore.

Il binario che ho provato a controllare con uno script ruby ​​(senza usare file temporanei) fa parte dei callapi di Automic (UC4) .

Nel

./binary < file

binarystdin è il file aperto in modalità sola lettura. Nota che bashnon legge affatto il file, lo apre solo per la lettura sul descrittore di file 0 (stdin) del processo in cui viene eseguito binary.

Nel:

./binary << EOF
test
EOF

A seconda della shell, lo binarystdin sarà o un file temporaneo cancellato (AT&T ksh, zsh, bash ...) che contiene test\ncome inserito lì dalla shell o l'estremità di lettura di una pipe ( dash, yash; e la shell scrive test\nin parallelo all'altra estremità del tubo). Nel tuo caso, se lo stai usando bash, sarebbe un file temporaneo.

Nel:

cat file | ./binary

A seconda della shell, lo binarystdin sarà o la fine della lettura di una pipe, o un'estremità di una coppia di socket in cui la direzione di scrittura è stata chiusa (ksh93) e catsta scrivendo il contenuto filedell'altra estremità.

Quando stdin è un file normale (temporaneo o no), è ricercabile. binarypuò andare all'inizio o alla fine, riavvolgere, ecc. Può anche capovolgerlo, fare qualcosa ioctl()scome FIEMAP / FIBMAP (se usato al <>posto di <, potrebbe troncare / fare buchi in esso, ecc.).

le pipe e le coppie di socket invece sono un mezzo di comunicazione tra processi, non c'è molto da binaryfare oltre readai dati (anche se ci sono anche alcune operazioni come alcune specifiche di pipe ioctl()che potrebbero fare su di esse e non su file regolari) .

La maggior parte delle volte, è la capacità mancante seekche provoca le applicazioni a fallire / si lamentano quando si lavora con i tubi, ma potrebbe essere una qualsiasi delle altre chiamate di sistema che sono validi in file regolari, ma non su diversi tipi di file (come mmap(), ftruncate(), fallocate()) . Su Linux, c'è anche una grande differenza nel comportamento quando si apre /dev/stdinmentre fd 0 è su una pipe o su un file normale.

Esistono molti comandi là fuori che possono occuparsi solo di file ricercabili , ma in questo caso, generalmente non è per i file aperti sul loro stdin.

$ unzip -l file.zip
Archive:  file.zip
  Length      Date    Time    Name
---------  ---------- -----   ----
       11  2016-12-21 14:43   file
---------                     -------
       11                     1 file
$ unzip -l <(cat file.zip)
     # more or less the same as cat file.zip | unzip -l /dev/stdin
Archive:  /proc/self/fd/11
  End-of-central-directory signature not found.  Either this file is not
  a zipfile, or it constitutes one disk of a multi-part archive.  In the
  latter case the central directory and zipfile comment will be found on
  the last disk(s) of this archive.
unzip:  cannot find zipfile directory in one of /proc/self/fd/11 or
        /proc/self/fd/11.zip, and cannot find /proc/self/fd/11.ZIP, period.

unzipdeve leggere l'indice memorizzato alla fine del file, quindi cercare all'interno del file per leggere i membri dell'archivio. Ma qui, il file (regolare nel primo caso, pipe nel secondo) viene fornito come argomento path unzipe lo unzipapre da solo (in genere su fd diverso da 0) invece di ereditare un fd già aperto dal genitore. Non legge i file zip dal suo stdin. stdin è utilizzato principalmente per l'interazione dell'utente.

Se esegui quello binarytuo senza reindirizzamento al prompt di una shell interattiva in esecuzione in un emulatore di terminale, allora lo binarystdin verrà ereditato dalla shell madre, che a sua volta lo avrà ereditato dall'emulatore di terminale e sarà un dispositivo pty aperto in modalità lettura + scrittura (qualcosa del genere /dev/pts/n).

Neanche questi dispositivi sono cercabili. Quindi, se binaryfunziona correttamente quando si riceve l'input dal terminale, probabilmente il problema non riguarda la ricerca.

Se quel 14 è pensato per essere un errno (un codice di errore impostato da chiamate di sistema non riuscite), allora sulla maggior parte dei sistemi sarebbe EFAULT( indirizzo errato ). La read()chiamata di sistema fallirebbe con quell'errore se si chiedesse di leggere in un indirizzo di memoria non scrivibile. Ciò sarebbe indipendente dal fatto che il fd leggesse i dati da punti a una pipe o un file normale e indicasse generalmente un bug ¹ .

binaryprobabilmente determina il tipo di file aperto sul suo stdin (con fstat()) e si imbatte in un bug quando non è né un file normale né un dispositivo tty.

Difficile dirlo senza sapere di più sull'applicazione. Eseguirlo con strace(o truss/ tuscequivalente sul tuo sistema) potrebbe aiutarci a vedere qual è la chiamata di sistema se qualcuno non riesce qui.

¹ Lo scenario previsto da Matthew Ife in un commento alla tua domanda suona molto plausibile qui. Citandolo:

Ho il sospetto che stia cercando la fine del file per ottenere una dimensione del buffer per leggere i dati, gestire male il fatto che la ricerca non funziona e tentare di allocare una dimensione negativa (non gestire un malloc non valido). Passare il buffer per leggere quali errori dati al buffer non sono validi.

Ecco un semplice programma di esempio che illustra la risposta di Stéphane Chazelas usando lseek(2)sul suo input:

#include <stdio.h>
#include <sys/types.h>
#include <unistd.h>

int main(void)
{
    int c;
    off_t off;
    off = lseek(0, 10, SEEK_SET);
    if (off == -1)
    {
        perror("Error");
        return -1;
    }
    c = getchar();
    printf("%c\n", c);
}

test:

$ make seek
cc     seek.c   -o seek
$ cat foo
abcdefghijklmnopqrstuwxyz
$ ./seek < foo
k
$ ./seek <<EOF
> abcdefghijklmnopqrstuvwxyz
> EOF
k
$ cat foo | ./seek
Error: Illegal seek

Le pipe non sono ricercabili, ed è qui che un programma potrebbe lamentarsi delle pipe.

La pipe e il reindirizzamento sono animali diversi, per così dire. Quando usi il here-docreindirizzamento ( <<) o il reindirizzamento di stdin, < il testo non arriva dal nulla - in realtà va in un descrittore di file (o in un file temporaneo, se vuoi), ed è lì che punta lo stdin del binario.

In particolare, ecco un estratto dal bash'scodice sorgente, file redir.c (versione 4.3):

/* Create a temporary file holding the text of the here document pointed to
   by REDIRECTEE, and return a file descriptor open for reading to the temp
   file.  Return -1 on any error, and make sure errno is set appropriately. */
static int
here_document_to_fd (redirectee, ri)

Quindi, dal momento che il reindirizzamento può essere sostanzialmente trattato come file, i binari possono spostarli o seek()attraverso il file facilmente, passando a qualsiasi byte del file.

Le pipe, poiché sono buffer di 64 KiB (almeno su Linux) con scritture di 4096 byte o meno garantite come atomiche, non sono ricercabili, cioè non è possibile spostarle liberamente - leggere solo in sequenza. Una volta ho implementato il tailcomando in Python. 29 milioni di righe di testo possono essere ricercate in microsecondi se reindirizzate, ma se vengono cateseguite tramite pipe, beh, non c'è nulla che si possa fare, quindi tutto deve essere letto in sequenza.

Un'altra possibilità è che il binario potrebbe voler aprire un file in modo specifico e non desidera ricevere input da una pipe. Di solito viene eseguito tramite fstat()chiamata di sistema e verifica se l'input proviene da un S_ISFIFOtipo di file (che indica una pipe / named pipe).

Il tuo binario specifico, dal momento che non sappiamo cosa sia, probabilmente tenta di cercare, ma non può cercare pipe. Si consiglia di consultare la documentazione per scoprire cosa significa esattamente il codice di errore 14.

NOTA : Alcune shell, come dash (Debian Almquist Shell, impostazione predefinita /bin/shsu Ubuntu) implementano il here-docreindirizzamento con pipe internamente , quindi potrebbero non essere ricercabili. Il punto rimane lo stesso: i tubi sono sequenziali e non possono essere navigati facilmente e i tentativi di farlo comporteranno errori.

La differenza principale sta nella gestione degli errori.

Nel caso seguente viene segnalato l'errore

$ /bin/cat < z.txt
-bash: z.txt: No such file or directory
$ echo $?
1

Nel seguente caso l'errore non viene segnalato.

$ cat z.txt | /bin/cat
cat: z.txt: No such file or directory
$ echo $?
0

Con bash, puoi ancora usare PIPESTATUS:

$ cat z.txt | /bin/cat
cat: z.txt: No such file or directory
$ echo ${PIPESTATUS[0]}
1

Ma è disponibile solo immediatamente dopo l'esecuzione del comando:

$ cat z.txt | /bin/cat
cat: z.txt: No such file or directory
$ echo $?
0
$ echo ${PIPESTATUS[0]}
0
# oops !

C'è un'altra differenza, quando usiamo le funzioni shell invece dei binari. In bash, le funzioni che fanno parte di una pipeline vengono eseguite in sotto-shell (ad eccezione dell'ultimo componente della pipeline se l' lastpipeopzione è abilitata e bashnon interattiva), quindi la modifica delle variabili non ha effetti nella shell padre:

$ a=a
$ b=b
$ x(){ a=x;}
$ y(){ b=y;}

$ echo $a $b
a b

$ x | y
$ echo $a $b
a b

$ cat t.txt | y
$ echo $a $b
a b

$ x | cat
$ echo $a $b
a b

$ x < t.txt
$ y < t.txt
$ echo $a $b
x y