Mengembalikan output ke terminal setelah mengeluarkan "exec &> filename"


15

Saya mencoba menjalankan yang berikut ini:

exec &>filename

Setelah ini saya tidak bisa melihat apa pun termasuk apa yang saya ketikkan, oke.

Aku dengan panik mencoba, exec 1>&1dan exec 2>&2, tetapi tidak ada yang terjadi.

Sekarang, tanpa mematikan shell, bagaimana saya mendapatkan kembali output yang diarahkan ke stdout dan kesalahan diarahkan ke stderr masing-masing? Apakah file deskriptor satu-satunya cara untuk merujuk standar [dalam | keluar] dimasukkan dan stderr?


1
Hmm ... mengapa Anda mengarahkan stderr / stdout dari shell interaktif Anda? Ini execmembangun biasanya digunakan dalam skrip yang berjalan di subkulit, untuk mengarahkan output mereka misalnya untuk file. Saya tidak melihat ada gunanya dalam sesi interaktif.
Martin von Wittich

3
@ Martinvon, saya setuju dengan pernyataan pada exec. Saya setuju. Saya hanya anak-anak yang bermain-main :)
user917279

Jawaban:


23

Setelah Anda menjalankan exec &>filename, output standar dan kesalahan standar dari shell pergi ke filename. Input standar adalah deskriptor file 0 menurut definisi, dan output standar adalah fd 1 dan standard error adalah fd 2.

Deskriptor file tidak diarahkan atau non-redirect: selalu menuju ke suatu tempat (dengan asumsi bahwa proses deskriptor ini terbuka). Untuk mengarahkan kembali deskriptor file berarti mengubah arahnya. Ketika Anda berlari exec &>filename, stdout dan stderr sebelumnya terhubung ke terminal, dan menjadi terhubung filename.

Selalu ada cara untuk merujuk ke terminal saat ini: /dev/tty. Ketika suatu proses membuka file ini, itu selalu berarti terminal pengontrol proses , mana pun itu. Jadi jika Anda ingin mendapatkan kembali stdout dan stderr asli shell, Anda dapat melakukannya karena file yang terhubung masih ada.

exec &>/dev/tty

1
seperti @Joseph R. menjawab $ (tty) menunjukkan saya / dev / pty0, tetapi perintah Anda juga berfungsi, mana yang lebih portabel di seluruh rasa Unix? terima kasih atas jawaban yang lebih jelas.
user917279

2
@ user917279 Mereka sama-sama portabel dalam arti bekerja pada rasa unix yang berbeda. /dev/ttybekerja dalam kasus di mana $(tty)tidak: /dev/ttybekerja selama proses memiliki terminal pengendali (yang terbaik yang dapat Anda harapkan, karena harus ada sesuatu yang masih menghubungkan proses dengan terminal), sedangkan $(tty)mengharuskan terminal masih dibuka pada input standar.
Gilles 'SO- stop being evil'

11

Kamu ingin

exec &>$(tty)

Apa yang Anda lakukan dalam pertanyaan Anda adalah mereplikasi di stdout dan stderr stdout asli dan stderr yang sudah diarahkan ke file.

Sebagai jawaban Gilles menjelaskan, ttyakan mengembalikan perangkat terminal dari terminal saat ini. Di sinilah ketiga deskriptor file standar berasal / masuk ke default di shell login. Jadi pernyataan di atas memanfaatkantty untuk mengarahkan stdout dan stderr kembali ke perangkat terminal seperti sebelumnya.

Jika Anda khawatir tentang portabilitas (sesuai komentar Anda pada jawaban Gilles), kedua metode ( utilitas tty dan /dev/ttyfile ) ada dalam standar POSIX.

Salinan kata demi kata dari komentar Gilles:

There's an advantage to /dev/tty: it works even after exec <somefile, 
whereas $(tty) would complain “not a tty”

berhasil! Terima kasih. echo $ (tty) memberi / dev / pty0 (dalam cygwin), bagaimana hubungannya dengan stdin, stdout dan apa yang terjadi dengan pernyataan di atas? tolong beri tahu saya jika saya perlu menanyakan ini sebagai pertanyaan terpisah.
user917279

@ user917279 Jawaban telah diperbarui.
Joseph R.

Joseph terima kasih. Saya memposting pertanyaan ini sebelum melihat jawaban Giles. Terima kasih banyak. Tolong izinkan saya menandai jawaban Giles yang diterima, karena itu membuat pikiran bodoh seperti punyaku untuk memahami dengan baik.
user917279

2
Ada keuntungan untuk /dev/tty: itu berfungsi bahkan setelahnya exec <somefile, sedangkan $(tty)akan mengeluh "tidak banyak".
Gilles 'SO- stop being evil'

@Gilles Terima kasih atas komentar yang mencerahkan secara khas :)
Joseph R.
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.