Kapan saya harus menggunakan pengalihan input?


21

Saya menggunakan dua perintah berikut untuk menghasilkan hasil yang sama: -

[root@localhost ~]# grep line comments
The line should start with a single quote to comment in VB scripting.
Double slashes in the beginning of the line for single line comment in C.
[root@localhost ~]#

[root@localhost ~]# grep line <comments
The line should start with a single quote to comment in VB scripting.
Double slashes in the beginning of the line for single line comment in C.
[root@localhost ~]#

Bisakah ada tolong jelaskan kepada saya pro / kontra jika salah satu dari 2 pendekatan ini saling mendekati.

Jawaban:


28

Dari man grephalaman (di Debian):

DESKRIPSI

   grep  searches the named input FILEs (or standard input if no files are
   named, or if a single hyphen-minus (-) is given as file name) for lines
   containing  a  match to the given PATTERN.  By default, grep prints the
   matching lines.

Dalam kasus pertama, grepbuka file; di yang kedua, shell membuka file dan menugaskannya ke input standar grep, dan greptidak meneruskan argumen nama file mengasumsikan perlu untuk menerima input standarnya.

Kelebihan 1:

  • grep dapat mengambil lebih dari satu file¹.
  • grepdapat menampilkan nama file di mana setiap kemunculan lineditemukan.

Kelebihan 2:

  • Jika file tidak dapat dibuka, shell mengembalikan kesalahan yang akan mencakup informasi yang lebih relevan (seperti nomor baris dalam skrip) dan dengan cara yang lebih konsisten (jika Anda membiarkan shell membuka file untuk perintah lain juga) daripada saat grepmembukanya. Dan jika file tidak dapat dibuka, grepbahkan tidak dipanggil (yang untuk beberapa perintah - mungkin tidak grep- dapat membuat perbedaan besar).
  • di grep line < in > out, jika intidak bisa dibuka, outtidak akan dibuat atau terpotong.
  • Tidak ada masalah dengan beberapa file dengan nama yang tidak biasa (seperti -atau nama file yang dimulai dengan -) ².
  • kosmetik: Anda dapat menempatkan di <filemana saja di baris perintah untuk menunjukkan aliran perintah lebih alami, seperti <in grep line >outjika Anda suka.
  • kosmetik: dengan GNU grep, Anda dapat memilih label apa yang akan digunakan di depan baris yang cocok alih-alih hanya nama file seperti di:

    <file grep --label='Found in file at line' -Hn line
    

Dalam hal kinerja, jika file tidak dapat dibuka, Anda menyimpan eksekusi grepketika menggunakan redirection, tetapi sebaliknya grepsaya tidak berharap banyak perbedaan.

Dengan redirection, Anda menyimpan harus melewati argumen tambahan grep, Anda membuat grepparsing sedikit lebih mudah. Di sisi lain, shell akan membutuhkan (setidaknya) panggilan sistem tambahan ke dup2()deskriptor file ke deskriptor file 0.

Dalam { grep -m1 line; next command; } < file, grep(di sini GNU grep) akan ingin seek()kembali ke tepat setelah baris yang cocok sehingga next commandmelihat sisa file (itu juga akan perlu menentukan apakah file tersebut dapat dicari atau tidak). Dengan kata lain, posisi dalam stdin adalah salah satu dari grepoutput. Dengan grep -m1 line file, itu bisa mengoptimalkan itu, itu satu hal yang lebih sedikit untuk grepdiperhatikan.


Catatan

¹ Dengan zsh, Anda dapat melakukan:

grep line < file1 < file2

tetapi melakukan hal yang setara cat file1 file2 | grep line(tanpa menjalankan catutilitas) dan jadi kurang efisien, dapat menyebabkan kebingungan jika file pertama tidak berakhir dengan karakter baris baru dan tidak akan memberi tahu Anda di mana file pola ditemukan.

² Dalam kasus ksh93dan bashmeskipun, ada file seperti /dev/tcp/host/port(dan /dev/fd/xpada beberapa sistem di bash) yang, ketika digunakan dalam target pengalihan shell memotong untuk tujuan khusus bukannya benar-benar membuka file pada sistem file (meskipun umumnya, file-file itu tidak ada pada sistem file). /dev/stdinmelayani tujuan yang sama seperti yang -dikenali oleh grep, tetapi setidaknya, di sini lebih tepat namespace (siapa pun dapat membuat file yang disebut -dalam direktori apa pun, sementara hanya administrator yang dapat membuat file yang dipanggil /dev/tcp/host/portdan administrator harus tahu lebih baik).


+1, untuk penjelasan yang bagus. Saya punya satu keraguan: dalam kasus ke-2 ketika shell membuka file apakah itu meneruskan konten file yang dibuka ke input standar (keyboard) ?? (Saya bingung dengan istilah 'input standar grep').
Ankit

1
@Ankit, stdin adalah tempat aplikasi membaca input mereka secara default, deskriptor file 0. Ketika di terminal, fd 0 dibuka dari pembacaan pada perangkat terminal (sesuatu seperti / dev / ttyxx atau / dev / pts / n). Begitulah akhirnya mereka mendapatkan apa yang Anda ketik di keyboard. Pengalihan shell dari stdin perintah hanya membuka fd 0 ke beberapa file lain sebelum menjalankan perintah.
Stéphane Chazelas

6

Jawaban oleh StephaneChazelas mencakup grep(1), dan sebagian besar perintah Unix bekerja seperti itu, tetapi tidak semua. Adalah standar untuk membaca baik dari input standar (dari keyboard, dari file yang dialihkan melalui < file, atau dari output yang disalurkan oleh perintah lain, contoh bodoh ls * | grep '^ab*c$'), atau dari file yang diberikan sebagai argumen, seperti grep comment file1 file2 file3. Beberapa perintah menggunakan konvensi di sana bahwa file bernama -input standar, sehingga Anda dapat mengatakan make-middle | cat head - tailuntuk mendapatkan aliran head, apa pun yang gen-middledihasilkan, diikuti oleh tail. Ini dengan desain, untuk memberikan fleksibilitas dalam penggunaan perintah.

Mana yang lebih baik? Selama ini berhasil, cmd filelebih pendek dari cmd < file; mungkin ada perbedaan kecil dalam waktu antara shell melakukan file frobbing ( <) dan perintah melakukannya dengan sendirinya, tetapi mungkin tidak terlalu mencolok kecuali Anda tidak melakukan hal lain sepanjang hari. Itu akan tergantung pada pertimbangan seperti pro yang disebutkan dalam jawaban Stephane.


cmd filetidak lebih pendek dari itu cmd<file.
Stéphane Chazelas

Ini adalah satu penekanan tombol yang lebih pendek, dengan anggapan Anda perlu menekan Shift untuk mengetik a <.
DopeGhoti
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.