Differenza tra "gatto" e "gatto <"


Risposte:


106

Nel primo caso, catapre il file e nel secondo caso, la shell apre il file, passandolo come catinput standard.

Tecnicamente, potrebbero avere effetti diversi. Ad esempio, sarebbe possibile avere un'implementazione della shell che fosse più (o meno) privilegiata rispetto al catprogramma. Per quello scenario, uno potrebbe non riuscire ad aprire il file, mentre l'altro potrebbe.

Questo non è il solito scenario, ma menzionato per sottolineare che la shell e catnon sono lo stesso programma.


83
Sì, e per esempio puoi farlo sudo cat myfile.txt. Ma sudo cat < myfile.txtnon funzionerà se non si dispone dei privilegi per leggere il file.
zuazo,

2
Si noti che ksh93ha catincorporato (non abilitato per impostazione predefinita a meno che non si abbia /opt/ast/binpresto nel tuo $PATHperò).
Stéphane Chazelas,

2
Alcuni programmi si comportano diversamente a seconda che ottengano un argomento nome file o stdin. Ad esempio, wcstamperà il nome file prima dei conteggi quando viene fornito un argomento.
Barmar,

21

Non ci sono grandi differenze visibili nel tuo caso di test. Il più ovvio sarebbe il messaggio di errore che ricevi se non ci sono file nominati myfile.txtnella directory corrente o se non ti è permesso leggerlo.

Nel primo caso, catsi lamenterà e nel secondo caso, la shell lo farà, mostrando chiaramente quale processo sta tentando di aprire il file, catnel primo e la shell nel secondo.

$ cat myfile.txt
cat: myfile.txt: No such file or directory
$ cat < myfile.txt
ksh93: myfile.txt: cannot open [No such file or directory]

In un caso più generale, una grande differenza sta nell'utilizzare i reindirizzamenti non può essere usato per stampare il contenuto di più di un file, che è dopo tutto lo scopo originale del comando cat(ie cat enate). Si noti che la shell tenterà comunque di aprire tutti i file passati come input reindirizzato, ma in realtà passa solo l'ultimo a catmeno che non si usi zshe il suo multios"zshism".

$ echo one > one
$ echo two > two
$ cat one two # cat opens one, shows one, opens two, shows two
one
two
$ cat < one < two # sh opens one then opens two, cat shows stdin (two)
two
$ rm one two
$ echo one > one
$ cat one two # cat opens and shows one, fails to open two
one
cat: two: No such file or directory
$ cat < one < two # the shell opens one then opens two, fails and 
                  # displays an error message, cat gets nothing on stdin
                  # so shows nothing
ksh93: two: cannot open [No such file or directory]

Su un sistema standard, la shell catnon ha alcuna differenza nei diritti di accesso ai file, quindi entrambi avranno esito negativo allo stesso modo. L'uso sudodi aumentare cati privilegi farà una grande differenza nel comportamento, come già suggerito da Thomas Dickey e dai commenti allegati.


5
Per curiosità, usi davvero la kshtua volontà, e se sì ... perché ?
gatto

1
@cat - questa domanda si basa ovviamente sull'ignoranza. costruiscilo tu stesso e vedi.
Mikeserv,

2
@mikeserv che doveva essere irriverente, non seriamente maleducato, ma abbastanza giusto, suppongo
gatto

2
@cat - non immaginavo diversamente. l'ignoranza non è una cosa di cui vergognarsi: è solo una mancanza di conoscenza. se non capisci perché qualcuno potrebbe scegliere di usare ksh93, allora posso solo supporre che sia perché non l'hai mai usato. quindi ti consiglio di farlo. vale la pena provare, per essere sicuri. e credimi quando ti dico che, rispetto a bash, ksh93è di gran lunga il guscio migliore. è il guscio, quasi.
Mikeserv,

5
Come sottolineato da @mikeserv altrove , cat < file1 > file2ha un effetto molto diverso rispetto cat file1 > file2al caso in cui file1sia illeggibile o inesistente. (Quest'ultima forma si interrompe file2; la prima no.)
Wildcard

7

cat myfile.txtlegge il file myfile.txtquindi lo stampa sull'output standard.

cat < myfile.txtqui catnon viene dato alcun file da aprire, quindi, come molti comandi Unix, legge i dati dall'input standard, che viene diretto dalla file.txtshell, e stampa sull'output standard.


6

La risposta di Thomas Dickey è geniale.

Voglio solo aggiungere alcuni fatti ovvi sul caso di leggere diversi file (vagamente correlati alla tua domanda, ma comunque):

  • cat <file1 <file2 <file3leggerà solo file3, almeno in bash. (In realtà, dipende dalla shell, ma la maggior parte delle shell duplica ogni file specificato su stdin, il che fa sì che l'ultimo abbia effetto.)
  • cat file1 file2 file3leggerà tutti i file specificati in sequenza (in realtà cat è la forma abbreviata della parola concatenata ).
  • cat file1 file2 file3 <file4 <file5 <file6 leggerà solo file1, file2, file3 (poiché cat ignora lo stdin quando vengono passati gli argomenti del nome file).
    • cat file1 file2 - file3 <file4 <file5 <file6 leggerà file1, file2, file6, file3 (poiché il trattino forza il gatto a non ignorare lo stdin).

E sugli errori. In caso di impossibilità di aprire alcuni dei file specificati come argomenti (senza <), cat salterà i file non riusciti (con l'output del messaggio rilevante su stderr), ma continuerà a leggere altri file. In caso di impossibilità di aprire almeno uno dei file specificati come reindirizzamenti (con <), la shell non avvierà nemmeno cat (ciò si verifica anche per i reindirizzamenti effettivamente non utilizzati da cat). In entrambi i casi verrà restituito un codice di uscita errato.


1
Nota che nel tuo primo esempio catsarà comunque aperto file1e file2, lo stesso con file4e file5nel tuo terzo esempio. Mostrerà solo file3, resp. file6contenuti se queste precedenti istruzioni aperte hanno esito positivo.
jlliagre,

@jlliagre, grazie, non lo sapevo. Strace ovviamente ha dimostrato la tua correttezza. Ho corretto il testo tra parentesi per i casi 1 e 3a.
sasha,

0

possiamo usare un altro comando per notare la differenza tra:

wc –w food2.txt .

Uscita possibile:

6 food2.txt .

il comando dice il nome del file poiché lo conosce (passato come argomento).

wc –w < food2.txt .

Uscita possibile:

6 .

l'input standard viene reindirizzato al file food2.txt senza che il comando lo sappia.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.