Mengapa `cp` dirancang untuk secara diam-diam menimpa file yang ada? [Tutup]

Saya diuji cpdengan perintah berikut:

$ ls
first.html   second.html  third.html

$ cat first.html
first

$ cat second.html
second

$ cat third.html
third

Lalu saya salin first.htmlke second.html:

$ cp first.html second.html

$ cat second.html
first

File second.htmlditimpa secara diam-diam tanpa kesalahan. Namun, jika saya melakukannya di GUI desktop dengan menyeret dan menjatuhkan file dengan nama yang sama, itu akan berakhiran first1.htmlsecara otomatis. Ini menghindari menimpa file yang ada secara tidak sengaja.

Mengapa tidak cpmengikuti pola ini alih-alih menimpa file secara diam-diam?

Perilaku overwrite default cpditentukan dalam POSIX.

3. Jika source_file adalah tipe file biasa, langkah-langkah berikut harus diambil:

   3.a. Perilaku tidak ditentukan jika dest_file ada dan ditulis oleh langkah sebelumnya. Jika tidak, jika dest_file ada, langkah-langkah berikut harus diambil:

   3.ai Jika opsi -i berlaku, utilitas cp akan menulis prompt untuk kesalahan standar dan membaca baris dari input standar. Jika responsnya tidak setuju, cp tidak akan melakukan apa-apa lagi dengan source_file dan melanjutkan ke file yang tersisa.

   3.a.ii. Deskriptor file untuk dest_file harus diperoleh dengan melakukan tindakan yang setara dengan fungsi open () yang didefinisikan dalam volume Antarmuka Sistem POSIX.1-2017 yang disebut menggunakan dest_file sebagai argumen path, dan bitwise inklusif ATAU O_WRONLY dan O_TRUNC sebagai argumen oflag.

   3.a.iii. Jika upaya untuk mendapatkan deskriptor file gagal dan opsi -f berlaku, cp akan berusaha untuk menghapus file dengan melakukan tindakan yang setara dengan fungsi unlink () yang didefinisikan dalam volume System Interfaces dari POSIX.1-2017 yang disebut menggunakan dest_file sebagai argumen jalur. Jika upaya ini berhasil, cp akan melanjutkan dengan langkah 3b.

Ketika spesifikasi POSIX ditulis, sudah ada sejumlah besar skrip yang ada, dengan asumsi bawaan untuk perilaku overwrite default. Banyak dari skrip tersebut dirancang untuk dijalankan tanpa kehadiran pengguna langsung, misalnya sebagai tugas cron atau tugas latar belakang lainnya. Mengubah perilaku akan menghancurkan mereka. Meninjau dan memodifikasi mereka semua untuk menambahkan opsi untuk memaksa menimpa di mana pun dibutuhkan mungkin dianggap sebagai tugas besar dengan manfaat minimal.

Juga, baris perintah Unix selalu dirancang untuk memungkinkan pengguna yang berpengalaman untuk bekerja secara efisien, bahkan dengan mengorbankan kurva belajar yang sulit bagi seorang pemula. Ketika pengguna memasukkan perintah, komputer berharap bahwa pengguna benar-benar bersungguh-sungguh, tanpa menebak-nebak; itu adalah tanggung jawab pengguna untuk berhati-hati dengan perintah yang berpotensi merusak.

Ketika Unix asli dikembangkan, sistem kemudian memiliki memori dan penyimpanan massal yang sangat sedikit dibandingkan dengan komputer modern yang menimpa peringatan dan prompt yang mungkin dianggap sebagai kemewahan yang sia-sia dan tidak perlu.

Ketika standar POSIX sedang ditulis, preseden dibuat dengan mantap, dan para penulis dari standar tersebut menyadari dengan baik sifat-sifat tidak merusak kompatibilitas ke belakang .

Selain itu, seperti yang telah dijelaskan orang lain, setiap pengguna dapat menambah / mengaktifkan fitur-fitur itu untuk diri mereka sendiri, dengan menggunakan alias shell atau bahkan dengan membangun cpperintah penggantian dan memodifikasi mereka $PATHuntuk menemukan penggantian sebelum perintah sistem standar, dan mendapatkan jaring pengaman seperti itu jika diinginkan.

Tetapi jika Anda melakukannya, Anda akan menemukan bahwa Anda menciptakan bahaya untuk diri Anda sendiri. Jika cpperintah berperilaku satu cara ketika digunakan secara interaktif dan cara lain ketika dipanggil dari skrip, Anda mungkin tidak ingat bahwa ada perbedaan. Di sistem lain, Anda mungkin ceroboh karena terbiasa dengan peringatan dan permintaan di sistem Anda sendiri.

Jika perilaku dalam skrip masih akan cocok dengan standar POSIX, Anda cenderung terbiasa dengan permintaan dalam penggunaan interaktif, kemudian menulis skrip yang melakukan beberapa penyalinan massal - dan kemudian menemukan Anda sekali lagi secara tidak sengaja menimpa sesuatu.

Jika Anda menerapkan skrip juga, apa yang akan dilakukan perintah ketika dijalankan dalam konteks yang tidak memiliki pengguna, misalnya proses latar belakang atau tugas cron? Apakah skrip akan hang, batalkan, atau ditimpa?

Menggantung atau menggugurkan berarti bahwa tugas yang seharusnya dilakukan secara otomatis tidak akan dilakukan. Tidak menimpa kadang-kadang juga dapat menyebabkan masalah dengan sendirinya: misalnya, dapat menyebabkan data lama diproses dua kali oleh sistem lain alih-alih diganti dengan data terbaru.

Sebagian besar kekuatan baris perintah berasal dari kenyataan bahwa setelah Anda tahu cara melakukan sesuatu di baris perintah, Anda secara implisit juga akan tahu bagaimana mewujudkannya secara otomatis dengan skrip . Tapi itu hanya benar jika perintah yang Anda gunakan secara interaktif juga bekerja persis sama ketika dipanggil dalam konteks skrip. Setiap perbedaan signifikan dalam perilaku antara penggunaan interaktif dan penggunaan skrip akan menciptakan semacam disonansi kognitif yang mengganggu pengguna daya.

cpberasal dari awal Unix. Itu ada di sana jauh sebelum standar Posix ditulis. Memang: Posix baru saja meresmikan perilaku yang ada cpdalam hal ini.

Kita berbicara tentang Epoch (1970-01-01), ketika pria adalah pria sejati, wanita adalah wanita nyata dan makhluk kecil berbulu ... (saya ngelantur). Pada masa itu, menambahkan kode tambahan membuat program lebih besar. Itu adalah masalah saat itu, karena komputer pertama yang menjalankan Unix adalah PDP-7 (dapat ditingkatkan menjadi 144KB RAM!). Jadi semuanya kecil, efisien, tanpa fitur keselamatan.

Jadi, pada masa itu, Anda harus tahu apa yang Anda lakukan, karena komputer tidak memiliki kekuatan untuk mencegah Anda melakukan apa pun yang Anda sesali kemudian.

(Ada kartun bagus oleh Zevar; cari "zevar cerveaux assiste par ordinateur" untuk menemukan evolusi komputer. Atau coba http://perinet.blogspirit.com/archive/2012/02/12/zevar-et- cointe.html selama itu ada)

Bagi mereka yang benar-benar tertarik (saya melihat beberapa spekulasi dalam komentar): Yang asli cppada Unix pertama sekitar dua halaman kode assembler (C datang kemudian). Bagian yang relevan adalah:

sys open; name1: 0; 0   " Open the input file
spa
  jmp error         " File open error
lac o17         " Why load 15 (017) into AC?
sys creat; name2: 0     " Create the output file
spa
  jmp error         " File create error

(Jadi, sulit sys creat)

Dan, sementara kita berada di dalamnya: Versi 2 Unix digunakan (sniplet kode)

mode = buf[2] & 037;
if((fnew = creat(argv[2],mode)) < 0){
    stat(argv[2], buf);

yang juga sulit creattanpa tes atau perlindungan. Perhatikan bahwa kode-C untuk V2 Unix cpkurang dari 55 baris!

Karena perintah-perintah ini juga dimaksudkan untuk digunakan dalam skrip, mungkin berjalan tanpa pengawasan manusia, dan juga karena ada banyak kasus di mana Anda memang ingin menimpa target (filosofi dari shell Linux adalah bahwa manusia tahu apa dia melakukan)

Masih ada beberapa perlindungan:

• GNU cpmemiliki -n| --no-clobberpilihan
• jika Anda menyalin beberapa file ke satu saja cpakan mengeluh bahwa yang terakhir bukan direktori.

Apakah itu "melakukan satu hal pada satu waktu"?

Komentar ini terdengar seperti pertanyaan tentang prinsip desain umum. Seringkali, pertanyaan tentang ini sangat subyektif, dan kami tidak dapat menulis jawaban yang tepat. Berhati-hatilah karena kami dapat menutup pertanyaan dalam kasus ini.

Terkadang kami memiliki penjelasan untuk pilihan desain asli, karena pengembang telah menulis tentangnya. Tapi saya tidak punya jawaban yang bagus untuk pertanyaan ini.

Kenapa cpdidesain seperti ini?

Masalahnya adalah Unix berusia lebih dari 40 tahun.

Jika Anda membuat sistem baru sekarang, Anda mungkin membuat pilihan desain yang berbeda. Tetapi mengubah Unix akan merusak skrip yang ada, seperti yang disebutkan dalam jawaban lain.

Mengapa itu cp dirancang untuk file diam-diam menimpa yang ada?

Jawaban singkatnya adalah "Saya tidak tahu" :-).

Pahami itu cphanya satu masalah. Saya pikir tidak ada program komando asli yang dilindungi dari menimpa atau menghapus file. Shell memiliki masalah serupa saat mengarahkan output:

$ cat first.html > second.html

Perintah ini juga secara diam-diam menimpa second.html.

Saya tertarik untuk memikirkan bagaimana semua program ini dapat dirancang ulang. Mungkin membutuhkan beberapa kompleksitas tambahan.

Saya pikir ini adalah bagian dari penjelasan: Unix awal menekankan implementasi sederhana . Untuk penjelasan lebih rinci tentang ini, lihat "lebih buruk lebih baik", terkait di akhir jawaban ini.

Anda bisa mengubahnya > second.htmlsehingga berhenti dengan kesalahan, jika second.htmlsudah ada. Namun seperti yang kami sebutkan, terkadang pengguna memang ingin mengganti file yang ada. Misalnya, dia mungkin membangun perintah yang rumit, mencoba beberapa kali hingga melakukan apa yang diinginkannya.

Pengguna bisa berjalan rm second.htmldulu jika perlu. Ini mungkin kompromi yang bagus! Ini memiliki beberapa kemungkinan kelemahannya sendiri.

1. Pengguna harus mengetikkan nama file dua kali.
2. Orang-orang juga mengalami banyak kesulitan dalam menggunakan rm. Jadi saya ingin membuat rmlebih aman juga. Tapi bagaimana caranya? Jika kita rmmenunjukkan setiap nama file dan meminta pengguna untuk mengonfirmasi, dia sekarang harus menulis tiga baris perintah, bukan satu. Juga, jika dia harus melakukan ini terlalu sering, dia akan terbiasa dan mengetik "y" untuk mengonfirmasi tanpa berpikir. Jadi itu bisa sangat menjengkelkan, dan itu masih bisa berbahaya.

Pada sistem modern, saya sarankan untuk menginstal trashperintah , dan menggunakannya bukan rmjika memungkinkan. Pengenalan penyimpanan Sampah adalah ide bagus misalnya untuk PC grafis pengguna tunggal .

Saya pikir juga penting untuk memahami keterbatasan perangkat keras Unix yang asli - RAM terbatas dan ruang disk, output yang ditampilkan pada printer lambat serta sistem dan perangkat lunak pengembangan.

Perhatikan bahwa Unix asli tidak memiliki penyelesaian tab , untuk dengan cepat mengisi nama file untuk suatu rmperintah. (Juga, shell Bourne asli tidak memiliki riwayat perintah, misalnya seperti ketika Anda menggunakan tombol panah Atas bash).

Dengan output printer, Anda akan menggunakan editor berbasis baris ed,. Ini lebih sulit dipelajari daripada editor teks visual. Anda harus mencetak beberapa baris saat ini, memutuskan bagaimana Anda ingin mengubahnya, dan mengetik perintah edit.

Menggunakannya > second.htmlsedikit seperti menggunakan perintah dalam editor baris. Efeknya tergantung pada kondisi saat ini. (Jika second.htmlsudah ada, isinya akan dibuang). Jika pengguna tidak yakin tentang keadaan saat ini, ia diharapkan untuk menjalankan lsatau yang ls second.htmlpertama.

"Implementasi sederhana" sebagai prinsip desain

Ada interpretasi populer dari desain Unix, yang dimulai:

Desainnya harus sederhana, baik dalam implementasi dan antarmuka. Lebih penting agar implementasinya lebih sederhana daripada antarmuka. Kesederhanaan adalah pertimbangan terpenting dalam suatu desain.

...

Gabriel berpendapat bahwa "Lebih buruk lebih baik" menghasilkan perangkat lunak yang lebih sukses daripada pendekatan MIT: Selama program awal pada dasarnya baik, akan membutuhkan waktu dan upaya yang lebih sedikit untuk diterapkan pada awalnya dan akan lebih mudah untuk beradaptasi dengan situasi baru. Porting perangkat lunak ke mesin baru, misalnya, menjadi jauh lebih mudah dengan cara ini. Dengan demikian penggunaannya akan menyebar dengan cepat, jauh sebelum program [yang lebih baik] memiliki kesempatan untuk dikembangkan dan digunakan (keuntungan penggerak pertama).

https://en.wikipedia.org/wiki/Worse_is_better

Desain "cp" kembali ke desain asli Unix. Sebenarnya ada filosofi yang koheren di balik desain Unix, yang sedikit kurang setengah bercanda disebut sebagai Worse-is-Better ^* .

Ide dasarnya adalah bahwa menjaga kode tetap sederhana sebenarnya adalah pertimbangan desain yang lebih penting yang memiliki antarmuka yang sempurna atau "melakukan Hal yang Benar".

• Kesederhanaan - desainnya harus sederhana, baik dalam implementasi maupun antarmuka. Lebih penting agar implementasinya lebih sederhana daripada antarmuka . Kesederhanaan adalah pertimbangan terpenting dalam suatu desain.

• Kebenaran - desain harus benar dalam semua aspek yang dapat diamati. Sedikit lebih baik menjadi sederhana daripada benar.

• Konsistensi - desain tidak boleh terlalu tidak konsisten. Konsistensi dapat dikorbankan untuk kesederhanaan dalam beberapa kasus, tetapi lebih baik untuk menjatuhkan bagian-bagian dari desain yang berurusan dengan keadaan yang kurang umum daripada memperkenalkan kompleksitas implementasional atau inkonsistensi.

• Kelengkapan - desain harus mencakup situasi penting sebanyak praktis. Semua kasus yang diharapkan secara wajar harus dicakup. Kelengkapan dapat dikorbankan demi kualitas lainnya. Bahkan, kelengkapan harus dikorbankan kapan pun kesederhanaan implementasi terancam. Konsistensi dapat dikorbankan untuk mencapai kelengkapan jika kesederhanaan dipertahankan; terutama yang tidak berharga adalah konsistensi antarmuka.

^{( penekanan milikku )}

Mengingat bahwa ini adalah tahun 1970, kasus penggunaan "Saya ingin menyalin file ini hanya jika belum ada" akan menjadi kasus penggunaan yang cukup langka bagi seseorang yang melakukan salinan. Jika itu yang Anda inginkan, Anda akan cukup mampu memeriksa sebelum salinan, dan itu bahkan dapat dituliskan.

Mengenai mengapa sebuah OS dengan pendekatan desain kebetulan menjadi salah satu yang menang atas semua OS lain yang sedang dibangun pada saat itu, penulis esai memiliki teori untuk itu juga.

Manfaat lebih lanjut dari filosofi buruk-adalah-lebih baik adalah bahwa programmer dikondisikan untuk mengorbankan keselamatan, kenyamanan, dan kerumitan untuk mendapatkan kinerja yang baik dan penggunaan sumber daya yang sederhana. Program yang ditulis menggunakan pendekatan New Jersey akan bekerja dengan baik di mesin kecil dan besar, dan kodenya akan portabel karena ditulis di atas virus.

Penting untuk diingat bahwa virus awal harus pada dasarnya baik. Jika demikian, penyebaran virus terjamin selama portabel. Setelah virus menyebar, akan ada tekanan untuk memperbaikinya, mungkin dengan meningkatkan fungsinya mendekati 90%, tetapi pengguna telah dikondisikan untuk menerima yang lebih buruk daripada yang benar. Oleh karena itu, perangkat lunak yang lebih buruk adalah yang pertama lebih baik akan diterima, kedua akan mengkondisikan penggunanya untuk berharap lebih sedikit, dan ketiga akan ditingkatkan ke titik yang hampir merupakan hal yang benar.

^{* - atau apa yang penulis, tetapi tidak ada orang lain, yang disebut "The New Jersey approach"} .

Alasan utama adalah bahwa GUI adalah definisi interaktif, sedangkan biner seperti /bin/cphanyalah sebuah program yang dapat dipanggil dari semua jenis tempat, misalnya dari GUI Anda ;-). Saya berani bertaruh bahwa bahkan hari ini sebagian besar panggilan untuk /bin/cptidak akan berasal dari terminal nyata dengan pengguna mengetik perintah shell melainkan dari server HTTP atau sistem surat atau NAS. Perlindungan bawaan terhadap kesalahan pengguna masuk akal sepenuhnya dalam lingkungan interaktif; kurang begitu dalam biner sederhana. Sebagai contoh, GUI Anda kemungkinan besar akan memanggil /bin/cpdi latar belakang untuk melakukan operasi aktual dan harus berurusan dengan pertanyaan keamanan tentang standar meskipun itu hanya meminta pengguna!

Perhatikan bahwa itu sejak hari pertama yang dekat dengan sepele untuk menulis pembungkus yang aman /bin/cpjika diinginkan. Filosofi * nix adalah untuk menyediakan blok bangunan sederhana bagi pengguna: di antaranya /bin/cpadalah satu.