Neden `cp 'sessizce varolan dosyaların üzerine yazmak için tasarlandı? [kapalı]

cpAşağıdaki komutlarla test ettim :

$ ls
first.html   second.html  third.html

$ cat first.html
first

$ cat second.html
second

$ cat third.html
third

Sonra kopyalamak first.htmliçin second.html:

$ cp first.html second.html

$ cat second.html
first

Dosyanın second.htmlsessiz bir şekilde üzerine yazılır. Ancak, aynı adı taşıyan bir dosyayı sürükleyip bırakarak bir masaüstü GUI'de yaparsam, first1.htmlotomatik olarak sonlandırılır . Bu, mevcut bir dosyanın üzerine yanlışlıkla yazmaktan kaçınır.

cpDosyaların üzerine sessizce yazmak yerine neden bu deseni izlemiyor?

Varsayılan üzerine yazma davranışı cpPOSIX'de belirtilmiştir.

3. Source_file normal dosya tipindeyse, aşağıdaki adımlar atılmalıdır:

   3 A. Dest_file mevcutsa ve önceki bir adımda yazıldıysa, davranış belirtilmez. Aksi takdirde, dest_file varsa, aşağıdaki adımlar atılır:

   3.ai -i seçeneği etkinse, cp yardımcı programı standart hataya bir bilgi istemi yazmalı ve standart girdiden bir satır okumalıdır. Cevap olumlu değilse, cp source_file ile daha fazla bir şey yapmaz ve kalan dosyalara devam etmez.

   3.a.ii. Dest_file için bir dosya tanıtıcısı, yol argümanı olarak dest_file kullanılarak çağrılan POSIX.1-2017 Sistem Arabirimleri hacminde tanımlanan open () işlevine eşdeğer eylemler ve ve argüman olarak O_WRONLY ve O_TRUNC bit bitleri içeren OR oflag argümanı.

   3.a.iii. Bir dosya tanımlayıcısı edinme denemesi başarısız olursa ve -f seçeneği etkinse, cp, dest_file kullanılarak çağrılan POSIX.1-2017 Sistem Arabirimleri biriminde tanımlanan unlink () işlevine eşdeğer eylemler gerçekleştirerek dosyayı kaldırmayı dener. yol argümanı olarak. Bu girişim başarılı olursa, cp adım 3b ile devam edecektir.

POSIX belirtimi yazıldığı zaman, varsayılan yazma üzerine yazma davranışı için yerleşik bir varsayımla zaten çok sayıda komut dosyası vardı. Bu komut dosyalarının çoğu, cron işleri veya diğer arka plan görevleri gibi doğrudan kullanıcı varlığı olmadan çalışacak şekilde tasarlanmıştır. Davranışı değiştirmek onları bozabilirdi. Gerektiğinde nereye üzerine yazmaya zorlamak için bir seçenek eklemek için hepsini gözden geçirme ve değiştirme, muhtemelen minimum fayda sağlayan büyük bir görev olarak kabul edildi.

Ayrıca, Unix komut satırı her zaman deneyimli bir kullanıcının, yeni başlayanlar için zor bir öğrenme eğrisi pahasına olsa bile verimli çalışmasına izin verecek şekilde tasarlanmıştır. Kullanıcı bir komut girdiğinde, bilgisayar kullanıcının ikinci bir tahminde bulunmaksızın gerçekten kastettiğini beklemektir; Potansiyel olarak yıkıcı komutlara dikkat etmek kullanıcının sorumluluğundadır.

Orijinal Unix geliştirildiğinde, sistemler o zamanlar çok az bellek ve toplu depolamaya sahipti ve uyarıları üzerine yazanlar ve istemler muhtemelen boşa ve gereksiz lüksler olarak görülüyordu.

POSIX standardı yazılırken emsal kesin olarak kuruldu ve standardın yazarları geriye dönük uyumsuzluğu kırmamanın yollarını çok iyi biliyorlardı .

Ayrıca, başkalarının açıkladığı gibi, herhangi bir kullanıcı, bu özellikleri kendileri için, kabuk takma adları kullanarak veya hatta bir değiştirme cpkomutu oluşturarak ve $PATHyerine standart sistem komutundan önce değiştirmeyi bulmak için değiştirerek ekleyebilir / etkinleştirebilir ve güvenlik ağını bu şekilde alabilir. İstenen.

Ancak bunu yaparsanız, kendiniz için bir tehlike oluşturduğunuzu göreceksiniz. Eğer cpkomut bir etkileşimli kullanılan bir yol ve bir komut dosyasından adlı başka şekilde davranır, siz fark var olduğunu hatırlamak olmayabilir. Başka bir sistemde, kendi sisteminizdeki uyarılara ve uyarılara alışkın olduğunuz için dikkatsiz olabilirsiniz.

Komut dosyalarındaki davranış hala POSIX standardına uygunsa, etkileşimli kullanımdaki istemlere alışmanız ve ardından bazı toplu kopyalamalar yapan bir komut dosyası yazmanız olasıdır - ve sonra yanlışlıkla yanlışlıkla bir şeyin üzerine yazıldığını göreceksiniz.

Komut dosyalarında da sormaya zorlarsanız, çevresinde kullanıcı bulunmayan bir bağlamda çalıştırdığınızda, örneğin arka plan işlemleri veya cron işleri gibi komut ne yapar? Komut dosyası askıda kalacak, iptal edilecek veya üzerine mi yazacak?

Asılması veya iptal edilmesi, otomatik olarak yapılması gereken bir görevin yapılmayacağı anlamına gelir. Üzerine yazmamak bazen bir soruna yol açabilir: örneğin, eski verilerin güncel verilerle değiştirilmek yerine iki kez başka bir sistem tarafından işlenmesine neden olabilir.

Komut satırının gücünün büyük bir kısmı, komut satırında bir şeyi nasıl yapacağınızı bir kez bilirseniz, komut satırında otomatik olarak nasıl gerçekleştirileceğini de açık bir şekilde bilirsiniz . Ancak, yalnızca etkileşimli olarak kullandığınız komutlar aynı zamanda bir komut dosyası bağlamında çağrıldığında da aynı şekilde çalışırsa geçerlidir. Etkileşimli kullanım ve komut dosyasıyla kullanım arasındaki davranışta önemli farklılıklar, güçlü bir kullanıcıyı rahatsız eden bir tür bilişsel uyuşmazlık yaratacaktır.

cpUnix'in başlangıcından geliyor. Posix standardı yazılmadan önce oradaydı. Nitekim: Posix cpbu konuda var olan davranışını resmileştirmiştir .

Epoch'un etrafında konuşuyoruz (1970-01-01), erkekler gerçek erkekler iken, kadınlar gerçek kadınlardı ve küçük yaratıklar tüylüydü ... (Dalgılıyorum). O günlerde, fazladan kod eklemek bir programı daha büyük yaptı. O zamanlar bir sorun oldu, çünkü Unix'i çalıştıran ilk bilgisayar bir PDP-7 idi (144KB RAM'e yükseltilebilir!). Böylece, güvenlik özellikleri olmadan işler küçük, verimli oldu.

Öyleyse, o günlerde ne yaptığınızı bilmek zorundaydınız, çünkü bilgisayar daha sonra pişman olduğunuz hiçbir şeyi yapmanıza engel olacak güce sahip değildi.

(Zevar'ın güzel bir karikatürü var; bilgisayarın evrimini bulmak için "zevar cerveaux assiste par ordinateur" kelimesini aratın ya da http://perinet.blogspirit.com/archive/2012/02/12/zevar-et- cointe.html olduğu sürece

Gerçekten ilgilenenler için (Yorumlarda bazı spekülasyonlar gördüm): cpİlk Unix'in orjinalinde iki sayfa derleme kodu vardı (C daha sonra geldi). İlgili kısım:

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

(Yani, zor sys creat)

Ve biz onun yanındayken: Unix'in 2. sürümü kullanılmış (kod sniplet)

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

Bu da creattestler veya güvenceler olmadan zor bir durumdur . V2 Unix'in C kodunun cp55 satırdan az olduğuna dikkat edin !

Çünkü bu komutların senaryolarda kullanılması, muhtemelen herhangi bir insan gözetimi olmadan çalıştırılması ve ayrıca hedefin üzerine yazmak istediğiniz birçok durum olduğu için (Linux kabukları felsefesi, insanın ne bildiğini bilmesidir). o yapıyor)

Hala birkaç güvencemiz var:

• GNU’nun cpbir -n| --no-clobberseçenek
• Birden fazla dosyayı tek bir dosyaya kopyalarsanız cp, sonuncunun bir dizin olmadığından şikayet edersiniz .

"Bir kerede bir şey yap" mı?

Bu yorum genel tasarım ilkesiyle ilgili bir soruya benziyor. Genelde, bunlarla ilgili sorular çok özneldir ve uygun bir cevap yazamıyoruz. Bu durumda soruları kapatabileceğimiz konusunda uyarılırsınız.

Bazen, özgün tasarım seçimiyle ilgili bir açıklama yapabiliriz, çünkü geliştirici (ler) onlar hakkında yazmıştır. Fakat bu soruya çok hoş bir cevabım yok.

Neden cpbu şekilde tasarlandı?

Sorun Unix'in 40 yaşın üzerinde olması.

Şimdi yeni bir sistem yaratıyorsanız, farklı tasarım seçimleri yapabilirsiniz. Ancak Unix'in değiştirilmesi, diğer cevaplarda da belirtildiği gibi varolan komut dosyalarını bozacaktır.

Neden sessizce varolan dosyaların üzerine yazmak için cp tasarlandı?

Kısa cevap "bilmiyorum" :-).

Bunun cpsadece bir sorun olduğunu anlayın . Orijinal komut programlarının hiçbirinin dosyaların üzerine yazılmasına veya silinmesine karşı korunmadığını düşünüyorum. Çıkış yönlendirilirken kabuğun da benzer bir sorunu var:

$ cat first.html > second.html

Bu komut aynı zamanda sessizce üzerine yazar second.html.

Tüm bu programların nasıl yeniden tasarlanabileceğini düşünmekle ilgileniyorum. Biraz ekstra karmaşıklık gerektirebilir.

Bunun açıklamanın bir parçası olduğunu düşünüyorum: Erken Unix basit uygulamaları vurguladı . Bunun daha ayrıntılı bir açıklaması için, bu cevabın sonundaki "daha da kötüsü iyidir" konusuna bakın.

> second.htmlVarsa, bir hata ile durması için değiştirebilirsiniz second.html. Belirttiğimiz Ancak, bazen kullanıcı yok varolan bir dosyayı değiştirmek istiyor. Örneğin, istediğini yapana kadar birkaç kez deneyerek karmaşık bir emir oluşturuyor olabilir.

rm second.htmlGerekirse kullanıcı önce çalıştırabilir . Bu iyi bir uzlaşma olabilir! Kendisinin bazı dezavantajları vardır.

1. Kullanıcının dosya adını iki kez yazması gerekir.
2. İnsanlar da kullanmakta zorlanıyorlar rm. Bu yüzden ben de rmdaha güvenli hale getirmek istiyorum . Ama nasıl? rmHer dosya adını gösterip kullanıcıdan onaylamasını istersek , şimdi bir satır yerine üç satır komut yazması gerekir . Ayrıca, bunu çok sık yapmak zorunda kalırsa, bir alışkanlık edinecek ve düşünmeden onaylamak için "y" yazacaktır. Bu yüzden çok sinir bozucu olabilir ve hala tehlikeli olabilir.

Modern bir sistemde, komutu yüklemenizi vetrashrm mümkün olduğunca yerine kullanmanızı öneririm . Çöp deposunun tanıtılması, örneğin , tek kullanıcılı bir grafik PC için harika bir fikirdi .

Orijinal Unix donanım sınırlı sınırlı RAM ve disk alanı, yavaş yazıcılarda görüntülenen çıktı , sistem ve geliştirme yazılımının sınırlarının anlaşılmasının da önemli olduğunu düşünüyorum .

Orijinal Unix'in bir komutun dosya adını hızlıca doldurmak için sekme tamamlamadığına dikkat edin rm. (Ayrıca, orijinal Bourne kabuğunun komut geçmişi yoktur, örneğin Yukarı ok tuşunu kullandığınızda olduğu gibi bash).

Yazıcı çıktısı ile satır tabanlı editör ed,. Görsel bir metin editöründen daha öğrenmek zor. Mevcut bazı satırları yazdırmanız, nasıl değiştirmek istediğinize karar vermeniz ve bir düzenleme komutu yazmanız gerekir.

Kullanmak > second.html, bir satır düzenleyicide bir komut kullanmak gibidir. Etkisi mevcut duruma göre değişir. ( second.htmlZaten varsa, içeriği atılır). Kullanıcı mevcut durumdan emin değilse, önce lsveya kaçması beklenir ls second.html.

Tasarım prensibi olarak "basit uygulama"

Unix tasarımının popüler bir yorumu var.

Tasarım hem uygulamada hem de arayüzde basit olmalıdır. Uygulamanın arayüzden daha basit olması daha önemlidir. Sadelik bir tasarımdaki en önemli husustur.

...

Gabriel, "Daha kötüsü iyidir" nin MIT yaklaşımından daha başarılı bir yazılım ürettiğini savundu: Başlangıç ​​programı temelde iyi olduğu sürece, başlangıçta uygulanması çok daha az zaman ve çaba harcayacak ve yeni durumlara adapte olmak daha kolay olacaktır. Örneğin, yazılımı yeni makinelere aktarmak, bu şekilde çok daha kolay hale gelir. Bu nedenle kullanımı, [daha iyi] bir programın geliştirilmesi ve konuşlandırılması için bir şans vermeden çok önce yayılacak (ilk hamle avantajı).

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

"Cp" nin tasarımı Unix'in orijinal tasarımına dayanıyor. Aslında Unix tasarımının ardındaki tutarlı bir felsefe vardı, ki bu şaka yapısının yarısına şüphe uyandıran Kötüye-Daha İyi ^* olarak adlandırıldı .

Temel fikir, kodu basit tutmanın aslında mükemmel bir arayüze sahip olmanın veya "Doğru Olanı Yapmanın" önemli bir tasarım düşüncesi olduğudur.

• Basitlik - tasarım hem uygulamada hem de arayüzde basit olmalıdır. Uygulamanın arayüzden daha basit olması daha önemlidir . Sadelik bir tasarımdaki en önemli husustur.

• Doğruluk - tasarım gözlemlenebilir her açıdan doğru olmalıdır. Doğru olmaktan basit olmak biraz daha iyidir.

• Tutarlılık - tasarım aşırı tutarsız olmamalıdır. Tutarlılık, bazı durumlarda basitlik için feda edilebilir, ancak tasarımın karmaşıklığını veya tutarsızlığını ortaya koymaktan daha az yaygın koşullarla uğraşan kısımları düşürmek daha iyidir .

• Tamlık - Tasarım, pratik olduğu kadar önemli durumları da kapsamalıdır. Makul olarak beklenen tüm davalar ele alınmalıdır. Bütünlük başka herhangi bir kalite lehine kurban edilebilir. Aslında, uygulama basitliği tehlikeye atıldığında, bütünlük feda edilmelidir. Tutarlılık korunursa, tutarlılık sağlamak için tutarlılık feda edilebilir; özellikle değersiz, arabirimin tutarlılığıdır.

^{( vurgu madeni )}

Bunun 1970 olduğunu hatırladığımızda, "Bu dosyayı ancak henüz yoksa , kopyalamak istiyorum " kullanımı, bir kopya gerçekleştiren biri için oldukça nadir görülen bir durum olabilirdi. İstediğin buysa, kopyadan önce kontrol etme yeteneğine sahip olacaktın ve bu bile betik olabilir.

Bu tasarım yaklaşımına sahip bir işletim sisteminin neden o zamanlar diğer tüm işletim sistemlerinde kurgulanan bir işletme olduğu konusunda, makalenin yazarı için de bir teori vardı.

Daha da kötüsü daha iyi olan felsefenin bir başka avantajı, programcının iyi performans ve mütevazı kaynak kullanımı elde etmek için bazı güvenlik, rahatlık ve güçlükten ödün vermesi gerektiğidir. New Jersey yaklaşımı kullanılarak yazılmış programlar hem küçük makinelerde hem de büyük programlarda iyi sonuç verir ve bir virüsün üstüne yazılmış olduğundan kod taşınabilir olur.

İlk virüsün temelde iyi olması gerektiğini hatırlamak önemlidir. Eğer öyleyse, viral yayılma portatif olduğu sürece temin edilir. Virüs yayıldıktan sonra, muhtemelen işlevselliğini% 90'a kadar artırarak geliştirmeye yönelik baskı olacak, ancak kullanıcılar zaten doğru olandan daha kötüsünü kabul etmek için şartlandırıldı. Bu nedenle, daha kötüsü daha iyi olan yazılım ilk önce kabul görecek, ikincisi kullanıcılarının daha az beklemesine neden olacak ve üçüncüsü neredeyse doğru olan bir noktaya geliştirilecektir.

^{* - ya da ne yazar ama başka hiç kimse "New Jersey yaklaşımı" olarak adlandırılmadı} .

Bunun ana nedeni, bir GUI'nin tanım olarak etkileşimli olmasıdır; bununla birlikte bir ikili /bin/cp, her türden, örneğin GUI'nizden ;-) gibi çağrılabilen bir programdır. Bahse girerim bugün bile, çağrıların büyük çoğunluğu, /bin/cpbir kabuk komutu yazan bir kullanıcı ile gerçek bir terminalden değil, bir HTTP sunucusundan veya bir posta sisteminden veya NAS'tan gelecektir. Kullanıcı hatalarına karşı yerleşik koruma etkileşimli bir ortamda tam anlamıyla anlaşılır; daha az basit bir ikili dosyada. Örneğin, GUI'niz büyük olasılıkla /bin/cpasıl işlemleri gerçekleştirmek için arka planda arayacak ve kullanıcıya sorulsa bile güvenlikle ilgili standart dışı sorularla ilgilenmek zorunda kalacak!

/bin/cpİstenirse etrafına güvenli bir sarıcı yazmanın önemsizleştiği güne yakın olduğunu unutmayın . * Nix felsefesi, kullanıcılara basit yapı taşları sağlamaktır: bunlardan /bin/cpbiri.