bir liner vs komut dosyası

Tek gömlekler yerine senaryolar yazmaktan hoşlanmadığını (hatta bazen korktuğunu) ifade eden birçok soru, cevap ve yorum gördüm. Yani bilmek istiyorum:

• Ne zaman ve neden "bir astar" yerine tek başına bir senaryo yazmalıyım? Ya da tam tersi?

• Her ikisinin de kullanım durumları ve artıları ve eksileri nelerdir?

• Bazı diller (örneğin awk veya perl) bir liner için diğerlerinden daha uygun mu (örneğin python)? Öyleyse neden?

• Bu sadece kişisel bir tercih meselesi mi, yoksa belirli durumlarda birini veya diğerini yazmak için iyi (yani objektif) sebepler var mı? Bu sebepler neler?

Tanımlar

• one-liner: doğrudan bir kabuk komut satırına yapıştırılan veya yapıştırılan komut dizisi . Genellikle kapsayan boru hatları ve / veya gibi dillerin kullanımı sed, awk, perl, ve / veya araçları gibi grepya cutya sort.

  Bu, tanımlayıcı karakteristik olan komut satırındaki doğrudan yürütmedir - uzunluk ve biçimlendirme önemsizdir. Bir "tek astar" hepsi tek bir satırda olabilir veya birden fazla satıra sahip olabilir (örneğin, döngü için sh veya satır içi beslemeleri ve okunabilirliği artırmak için girintili gömülü awk veya sed kodu).

• script: bir dosyaya kaydedilen ve daha sonra yürütülen herhangi bir tercüman dilindeki herhangi bir komut dizisi . Bir komut dosyası tamamen tek bir dilde yazılabilir veya diğer dilleri kullanarak birden fazla "tek-liner" in etrafında bir kabuk-kodlu sarmalayıcı olabilir.

Kendi cevabım var (daha sonra göndereceğim), ancak bunun sadece kişisel fikrim değil, konuyla ilgili kanonik bir soru-cevap olmasını istiyorum.

Pratik deneyime dayalı başka bir cevap.

Hemen istememe yazabileceğim "atma" kodu olsaydı, bir liner kullanırdım. Örneğin, bunu kullanabilirim:

for h in host1 host2 host3; do printf "%s\t%s\n" "$h" "$(ssh "$h" uptime)"; done

Kodun kaydedilmeye değer olduğuna karar verirsem bir senaryo kullanırdım. Bu noktada, dosyanın üstüne bir açıklama ekler, büyük olasılıkla bir miktar hata kontrolü ekler, hatta sürümleme için bir kod deposuna bile eklerim. Örneğin, bir sunucu kümesinin çalışma zamanını kontrol etmenin tekrar tekrar kullanacağım faydalı bir işlev olduğuna karar verirsem, yukarıdaki tek astar bu şekilde genişletilebilir:

#!/bin/bash
# Check the uptime for each of the known set of hosts
########################################################################
#
hosts=(host1 host2 host3)

for h in "${hosts[@]}"
do
    printf "%s\t" "$h"
    uptime=$(ssh -o ConnectTimeout=5 -n "$h" uptime 2>/dev/null)
    printf "%s\n" "${uptime:-(unreachable)}"
done

Genelleme, söylenebilir

• Tek astar

  • Belirli bir kereye mahsus amaç için yazılmış basit kod (yalnızca "birkaç" ifadesi)
  • Gerektiğinde hızlı ve kolay bir şekilde yazılabilen kod
  • Tek kullanımlık kod

• Senaryo

  • Bir koddan (muhtemelen) bir veya iki defadan fazla kullanılacak kod
  • "Birkaç" ifadesinden fazlasını gerektiren karmaşık kod
  • Başkaları tarafından yapılması gereken kod
  • Başkaları tarafından anlaşılması gereken kod
  • Katılımsız çalıştırılacak kod (örneğin, dan cron)

Burada unix hakkındaki soruların çok sayıda görüyorum . Belirli bir görevi yerine getirmek için tek bir astar sor. Yukarıdaki örnekleri kullanarak, ikincisinin birinciden çok daha anlaşılabilir olduğunu düşünüyorum ve bu nedenle okuyucular bundan daha fazlasını öğrenebilir. Bir çözüm diğerinden kolayca elde edilebilir, bu nedenle okunabilirlik açısından (gelecek okuyucular için) muhtemelen en önemsiz çözümden başka bir şey için bir satırda sıkıştırılmış kod sağlamaktan kaçınmalıyız.

Ne zaman bir komut dosyası yaz :

• daha fazla kod gerekli
• okunabilirliğe değer veriyorsun
• Kodun ne yaptığını göstermek için yorum eklemek gerekli / faydalıdır
• parametreleri geçmeniz gerekir
• Komut dosyasının kendi ortamında çalışmasını istiyorsunuz
• Muhtemelen kodu daha karmaşık bir amaç için tekrar kullanacak

Aşağıdaki durumlarda bir liner yazın :

• sadece küçük bir miktarda kod gereklidir
• geçerli kabukta tanımlanan değişkenlere erişmek istediğinizde
• hızlı ve kirli bir çözüme ihtiyacınız var

Gerekli bir komut dizisi oldukça kısa olduğunda ve / veya daha büyük bir boru hattının veya bir komut takma isminin bir parçası olarak kullanılabilecek bir sonuç ürettiğinde, iyi bir tek astar olabilir.

Temel olarak, tek gömleklerin genellikle hem sorunu hem de kullanılan komutları bilen deneyimli bir sistem yöneticisinin çok fazla düşünmeden yerinde yazabileceği şeyler olduğunu düşünüyorum.

Bir astar aşırı derecede uzun olduğunda veya çok basit koşullardan veya döngülerden fazlasını içerdiğinde, okunabilirlik için bunları çok satırlı bir komut dosyası veya kabuk işlevi olarak yazmak daha iyidir. Ayrıca, tekrar tekrar kullanmak için yazdığınız veya başkaları tarafından kullanılacak (ve muhtemelen sıkıntı verici) bir şeyse, çözümü açıklığa kavuşturmak için zaman harcamak için istekli olmalısınız, yorum yapmalı, komut dosyası formu.

Python'da, girinti sözdiziminin bir parçasıdır, dolayısıyla bir liner yazarsanız kelimenin tam anlamıyla dilin özelliklerini tam olarak kullanamazsınız.

Perl ve awk tek gömlekleri genellikle düzenli ifadelerin ham gücünü kullanmakla ilgilidir. Ancak bazıları düzenli ifadeleri, tamamen sebepsiz değil, Salt Yazılabilir Dil olarak adlandırırlar. Çok satırlı bir komut dosyası yazmak, belirli bir düzenli ifadenin ne yapması gerektiğini açıklamak için yorum yazmanıza olanak sağlar; bu arada, altı ay boyunca başka şeyler yaptıktan sonra komut dosyasına tekrar bakarken çok yararlı olacaktır.

Bu, doğası gereği çok fikir temelli bir sorudur, çünkü ne kadar karmaşıklığın kabul edilebilir olduğunu ve okunabilirlik ile kompaktlık arasındaki değişimlerin ölçülmesini içerir; Bunların hepsi kişisel yargılamada çok önemlidir. Bir dilin seçimi bile kişisel meselelere bağlı olabilir: eğer belirli bir dil, belirli bir problem için teorik olarak en uygun yöntem olsa da, ama o konuya yabancıysanız ve sorunu başka bir dilde nasıl çözeceğinizi zaten biliyorsanız, İşin hızlı ve minimum çabayla yapılmasını sağlamak için tanıdık bir dil, ancak çözüm teknik olarak yetersiz olabilir.

En iyisi , genellikle yeterince iyi bir düşmandır ve bu, burada çok geçerlidir.

Ve eğer Perl'e aşina iseniz, TMTOWTDI'yı zaten duymuş olabilirsiniz: Bunu Yapmanın Birden Çok Yolu Var.

Lütfen bunun kişisel bir görüş olduğunu unutmayın; Bir tane tuzla birlikte alın.

1. Komut, 80 karakter içinde uyuyorsa, bir liner kullanın. Uzun komut satırları ile çalışmak zordur. Aynı zamanda nüks sorunu var, bakınız # 2

2. Komutları bir kereden fazla çalıştırmanız gerekirse, bir komut dosyası kullanın. Aksi takdirde, koşul 1'in karşılanması şartıyla, bir astar kullanın.

3. Bu çok öznel, ama evet, kabuk, Perl veya awk'yi tek gömlekler için go-to-tools'um olarak görüyorum.
4. Bakınız # 1, # 2, # 3.

İstediğim şeyi yapana kadar tekrar tekrar düzenlemek için tek bir astarı geçici bir geliştirme aracı olarak görüntüleyip kullanıyorum veya bir alt komutun inceliklerini nasıl çalıştığını anlıyorum.

Daha sonra araştırdığım konuyla ilgili bir metin dosyasında ya not edilir (ya da açıklanır) ya da muhtemelen daha fazla ayrıntılandırma, parametreleştirme vb. İçin kişisel kutu PATH'ime konan bir komut dosyasında temizlenir. Genellikle, başka bir değişiklik yapılmasa bile, bir satır daha okunabilir hale gelir veya komut dosyasını bir daha asla kullanmam.

Kabuk geçmişimi 5000'den fazla satır olacak şekilde ayarladım, terminal başına ayrı bir geçmişe ve uzaktan kumandada oturum açma başına vb. Bu geçmişlerde birkaç hafta önce geliştirdiğim tek satırlık bir komut bulamamaktan nefret ediyorum ve yine ihtiyacım olacağını düşünmedim, bu yüzden stratejim.

Bazen, bazı donanımları yapılandırmak gibi bir grup komutun bir şeyler yapması gerekebilir; Sonunda hepsini tarihin dışına kopyalarım, en az düzeyde temizlerim ve RUNMEyaptıklarımın notları gibi bir kabuk betiğine eklerim , aynı zamanda neredeyse bir başkası tarafından tekrar kullanılmaya hazır olmaları için. (Bu yüzden onları yalnızca böyle bir acıyı yapılandırmak için bir GUI sağlayan araçlar buluyorum.) Bunu verimlilikte inanılmaz bir kazanç buluyorum, çünkü çoğu zaman sadece bir kez yapmayı umduğunuz bir şeyin daha sonra 5 kez yapılması gerekiyor. .

Ekibimdeki kişilerin bir defadan fazla yapılması gereken işlemler (örneğin, "iş akışları" veya "boru hatları") ve belgelenmesi gereken (bir kereye mahsus işler) için tipik olarak senaryo yazmasını istiyorum. "yanlış veriyi düzeltmek için bazı veri setlerinde bazı şeyleri değiştir" gibi şeyler bizim durumumuzda). Bunun dışında “tek gömlekler” veya senaryolar çok da önemli değil.

İş akışlarını düzgün bir şekilde belgelememek (senaryolar veya eşdeğeri olarak) bir projeye yeni personel getirmeyi zorlaştırır ve insanları projeden çıkarmayı zorlaştırır. Ayrıca, her türlü denetimi zorlaştırır ve hataları izlemek mümkün olmayabilir.

Bu programlama için hangi dilin kullanıldığına bakılmaksızın.

Diğer işyerlerinin benzer / farklı gelenekleri veya beklentileri olabilir, hatta bunlar yazılabilir.

Evde ne istersen onu yaparsın.

Örneğin, bir U&L sorusuna cevap göndermeden önce veya bir komutun tek tek bileşenlerini veya komutlarını çalıştırmadan önce tek tek test etmem gerektiğinde, kabukta önemsiz bir şey yaptığımda komut dosyaları yazarım " gerçek".

Ayrıca her seferinde aynı şekilde yapmak istediğim tekrarlayan işler için senaryolar yazarım, basit olsalar bile,

• OpenBSD sistemimin ve tüm kurulu paketlerin güncellenmesi (bu, kısa bir komut dosyasında toplanan üç kısa komut ve ev temizliği için bir avuç dolusu gelir) veya
• sistemimi tesis dışı bir depoya yedekleme (aslında tek bir komutla, ancak yine de oldukça fazla temizlik ve komut dosyasıyla anlık görüntüler arasında farklılıklar yapmamı sağlıyor ve farklı sistemler üzerinde incelikle farklı çalışması gerekiyor. Bir cron işinden çalıştırıyorum), veya
• posta alma (yine, esasen tek bir komut, ancak bir cron işi olarak adlandırıldığında ve komut satırından kullandığımda farklı davranmasını istiyorum, bazı durumlarda posta almaya çalışmamalı ve bir dosyaya kısa günlük mesajı).

Kabuk işlevlerini (çok nadiren takma adlar) etkileşimli kabuklarda kolaylık sağlamak için kullanıyorum , örneğin varsayılan olarak belirli komutlara seçenekler eklemek için ( -Ffor ls) veya bazı komutların özel varyasyonlarını oluşturmak için ( pmanburada manyalnızca POSIX kılavuzlarına bakılan bir komuttur) .

Bu konuda azınlık bir görüşüm var gibi görünüyor.

"Senaryo" terimi kasıtlı olarak kafa karıştırıcı, ondan kurtulmak. Bu, yalnızca bashve kullanıyor olsanız bile, orada yazdığınız yazılımdırawk .

Bir ekip içerisinde, bir araç tarafından uygulanan kod inceleme sürecine sahip bir yazılım yazmayı tercih ediyorum (github / gitlab / gerrit). Bu sürüm kontrolü bir bonus olarak verir. Birden fazla sisteminiz varsa, sürekli dağıtım araçları ekleyin. Ve eğer hedef sistemler önemliyse bazı test süitleri. Bunlar hakkında dindar değilim ama faydaları ve maliyetleri tartıyorum.

Bir takım ekibiniz varsa, en basit vim /root/bin/x.sh olanı çoğunlukla değişimle ilgili iletişim, kod okunabilirliği ve sistemler arası dağıtım açısından bir felakettir. Genellikle ciddi bir arıza sözde "ağır" işlemden daha fazla zaman / paraya mal olur.

Ben bir gömlekler tercih aslında "ağır" sürecini hak etmiyor şey için. Kabuk geçmişinizi etkili bir şekilde nasıl kullanacağınızı biliyorsanız, birkaç tuşa basarak hızlı bir şekilde yeniden kullanılabilir; ilgisiz sistemler arasında kolayca yapıştırılabilir (örneğin, farklı müşteriler).

Tek gömlekleri ve gözden geçirilen yazılımı ("komut dosyaları") arasındaki önemli fark (tek komutlar): tek gömlekleri uyguladığınızda sorumluluk tamamen size aittir. Sen "ne takip benim hatam değil, ben anlamadan koştum, sadece bu tek satırlık bir yere buldum" kendinize diyemiyor - Eğer böylece, incelenmemiş ve denenmemiş bit-of-the yazılımı çalıştıran biliyordum olan sizin suçunuz. Sonuçları öngörebileceğiniz kadar küçük olduğundan emin olun - eğer yapmazsanız kahretsin!

Bazen bu basit yaklaşıma ihtiyaç duyarsınız ve çıtayı yaklaşık bir satır metin olarak ayarlamak pratikte işe yarar (yani, gözden geçirilmiş ve gözden geçirilmemiş kod arasındaki sınır). Tek gömleklerimden bazıları korkunç derecede uzun görünüyor, ancak benim için etkili çalışıyorlar. Onları kıstığım ve daha genç meslektaşlarım için kıpırdatmadığım sürece, her şey yolunda. Onları paylaşmam gereken an - standart yazılım geliştirme sürecinden geçiyorum.

Sorunun ilk bölümlerinin sonuçlarından biraz korktuğumu söylemeliyim. Unix betik dilleri tam teşekküllü programlama dilleridir ve programlama dilleri dillerdir , yani bunlar insan dilleri gibi neredeyse dövülebilir ve esnek olmaları anlamına gelir. Ve "sonsuz dövülebilirlik ve esneklik" işaretlerinden biri, bir şeyi ifade etmenin neredeyse hiç bir "doğru yolunun" olmamasıdır - çeşit çeşit yolları vardır ve bu iyi bir şeydir! Yani, evet, elbette kişisel tercih meselesi ve bunda yanlış olan bir şey yok. Bir şey yapmanın tek bir yolu olduğunu söyleyen herkes,

Bir zamanlar, benim kendi ~/binoldu tam benim yazdığım "yararlı" küçük komut. Fakat onların çoğunun, yazdığım gün kullanıldıklarını ve bir daha asla kullanmadıklarını fark ettim. Böylece, ne kadar fazla zaman geçerse, bindizin o kadar küçülür .

Senaryo yazarken yanlış bir şey olduğunu sanmıyorum . Siz veya bir başkasının tekrar kullanabileceğini hayal ediyorsanız, elbette, bir komut dosyası yazın. Onun uğruna desteklenebilir bir senaryoyu "uygun şekilde yapılandırmak" istiyorsanız, elbette, bunu yapın. (Hiç kimse onu kullanmasa bile, yazmak iyi bir uygulamadır.)

Sebepler artık daha fazla senaryo yazmıyorum (ve sanırım, "bir-astar" ı tercih ediyorum):

• bindizin dağınıklığının bir bedeli var. Gerçekten oraya ait olmadıkça bir şey daha koymuyorum.
• Kullandığım betik dilleri bunu dillerdir kullanmak ; Şimdiye kadar onlarla gerçekten yüzdeyim. İhtiyacım olduğu zaman bir astarı tekrar yazmak çalışmak gibi gelmiyor; Sadece (yeniden) yazma yükünü hafifletmek için bir senaryoyu saklama ve kaydetme ve kullanma zorunluluğu hissetmiyorum. (Başka şeylerin yanı sıra, bir noktada yeniden yazma yükü bir komut dosyasının ne olduğunu hatırlamanın bellek yükünden daha az olur).
• Bir şeyleri yeniden yazmanın bir başka nedeni de bir yük gibi hissetmemektir: Komut geçmişi. Her gün kullanmama rağmen senaryo olarak göstermediğim bir sürü gömlek var - ama onları yeniden yazmak zorunda değilim; Onları sadece tarihten hatırlıyorum. Bu şekilde onlar fakir adamın senaryolarını veya diğer isimlerini kullanıyorlar.

Bir zamanlar bir "tek-astar" talebinin aslında bir "ses ısırığı" talebi olduğuna inanıyorum:

Gazetecilik bağlamında, sağlam bir ısırık, konuşmacının söylemeye çalıştığı şeyin özünü yakalayan ve bilgiyi özetlemek için kullanılan kısa bir cümle veya cümle ile nitelendirilir ...

İnsanlar sordukları soruna bir çözüm olan en kısa kodu ister ve isterler.

Bazen, bir konuşmayı "ses ısırmasına" indirmenin bir yolu yoktur, ayrıca bir senaryoyu kısa bir "tek astar" olarak azaltmak mümkün olmayabilir. Bu gibi durumlarda tek olası cevap bir senaryodur.

Ve genel olarak, bir "ses ısırığı" hiçbir zaman tüm konuşmanın yerine geçmez. Bu nedenle, "bir astar" genellikle bir fikri iletmek veya bu fikir için pratik bir örnek vermek için iyidir. Sonra, fikir anlaşıldıktan sonra, bir betik içerisinde genişletilmeli (uygulanmalı).

Öyleyse, bir fikir veya kavramı iletmek için bir "tek astar" yazın.

Genel kodunuzu tek harfli değil tam komut dosyası olarak yazın.

"Senaryo korkusu ve küçümsemesi" hakkında soru soruyorsun. Bunun nedeni, sık sık cevabın söylediği Q + A durumundan kaynaklanıyor: Bu adıma ve buna ihtiyacı var, ama aynı zamanda tek bir satıra da koyabilirim (böylece kopyalayıp yapıştırabilir ve uzun basit bir komut olarak kullanabilirsiniz).

Bazen yalnızca Q'nun hızlı ve kirli bir kopya yapıştırma çözümü tarafından daha iyi sunulduğunu veya "hoş" bir komut dosyasının tam olarak Q'nun anlaması gereken şey olup olmadığını tahmin edebilirsiniz.

Buradaki artı ve eksilerin çoğu doğrudur, ancak hala noktayı kaçırmaktadırlar. Q'daki tanımların yardımcı olmadığını bile söyleyebilirim.

Kabuk geçmişi dosyaları "bir gömlek" dir, ancak yine de kaydedilirler. Bash işlevi operate-and-get-next (C-o)onları yarı otomatik olarak tekrar etmenizi sağlar.

Bahsettiğim kelime fonksiyonunu pek göremiyorum . Hem "script" hem de "one liners" yazmanın yolu budur. Ve birkaç tuşa basarak her iki format arasında geçiş yapabilirsiniz. Bir bileşik komut genellikle her ikisine de sığabilir.

history -r fileyalnızca varsayılan geçmiş dosyasından değil, herhangi bir dosyadan bir veya daha fazla komut satırı (ve yorum) okuma yoludur. Sadece minimal bir organizasyon gerektiriyor. Bir komut satırının (bazı) sürümlerini almak için büyük bir geçmiş dosya boyutuna ve geçmiş aramasına güvenmemelisiniz.

İşlevler benzer şekilde tanımlanmalıdır. Yeni başlayanlar için, thisfunc() {...}ana dizininizde "işlevler" dosyasını yerleştirin ve kaynak yapın. Evet bu biraz ek yük ama bu genel bir çözüm.

Her komut satırını ve her komut dosyası varyasyonunu ayrı bir dosyada saklarsanız, dosya sistemi bloklarının (teorik ama objektif) kaybıdır.

Tek astarın kendi başına hızlı ve kirli hiçbir şeyi yoktur. Daha çok kaşlarını çattıran kopyala-yapıştır kısmı ve bizim için sakladığımız komut geçmişine güveniyoruz.

@sitaram: Bir liner'iniz gerçekten onelinerish özelliklere sahip: shebang hattı, newline, dört faydalı arama - ikisi sed "programlar". Bence orijinal perl betiği daha güzel görünüyordu ve daha hızlı koştu ve 60 satıra yayılarak herhangi bir bayt boşa gitmedi. Perl ayrıca biraz sıkmanızı da sağlar.

Benim için, bu kesinlikle kaçınılması gereken bir astar türüdür. Komut satırında bunun (yapıştırılmış) olmasını ister misiniz? Hayır, ve sonra, yine de bir dosyada saklarsanız (komut dosyası veya işlev ne olursa olsun), güzel görünmesi için iki veya üç yeni satır bayt harcayacaksınız.

10 dk. daha sonra: Sadece "iki sed program" veya "iki sed ikame / çağrı" olup olmadığını kontrol etmek istedim. Fakat sitaramın cevabı gitti. Cevabım hala umarım mantıklı.