Taşınabilir komut dosyaları yazmak ne zaman önemlidir?


18

Yazdığım çoğu kod PHP. Son zamanlarda kabuk komut dosyası öğrenmeye başladım. Karşılaştığım kaynakların ve öğreticilerin çoğu Bash'a özgüdür. Bazıları bashisms hakkında uyarır, bazıları ise uyarmaz. Burada çok fazla okudum ve Stack Overflow.

Ne zaman bir cevap bashisms kullanıyorsa , birileri kaçınılmaz olarak şunları söyleyecektir:

<Buraya bashizm ekle> kullanmamalısınız. Taşınabilir değil.

Bu, soru etiketlendiğinde bile olur bash. Bana göre, bir PHP programcısına PHP 4'te yeni bir kod kullanmamaları gerektiğini söylemek gibi, çünkü PHP 4 ile kullanılamaz. Windows üzerinde.

PHP yazarken, bir minimum gereksinimi seçin ve ileri uyumlu kod yazma . Geriye dönük hale getirme konusunda endişelenmiyorum .

Ben kullanırsanız #!/bin/bashshebang olarak, neden bashisms kullanmamalısınız? Sadece nasıl bir bazı insanlar olduğu izlenimini almaya başladım bash sadece onun uğruna bashisms (cinas amaçlanan).

İnsanlar genellikle bash'nin birçok sistemdeki varsayılan kabuk olduğu gerçeğinden dolayı bashve shellbirbirinin yerine kullanılır . Bu yüzden kod bashisms kullandığını uyarmak için bir yorum ekleyerek anlayabiliyorum, ama onları kullanmak yanlış olduğu anlamını anlamıyorum .

Açıkçası, kesinlikle kişisel kullanım için bir senaryo yazıyorsam, istediğim dilde yazabilirim. Ama yazdığım kodların bazılarının başkaları için yararlı olabileceğini düşünmek istiyorum.

Göndermeden önce sorumun cevabını aramayı denedim. Ben yaklaşık birçok bilgi buldum nasıl test etmek taşınabilirlik için değil, hakkında bir şey bulamadık zaman önemli olduğunu bunu yapmak için.

Peki, taşınabilir komut dosyaları yazmak ne zaman önemlidir?

Örneğin,

  • ne tür komut dosyaları olabildiğince taşınabilir olmalıdır?
  • Bash yüklü olmayan sistemler ne kadar yaygındır?
  • Sistemde Bash yüklüyse, find ve diğer yardımcı programların GNU sürümüne de sahip olacak mı?

4
Bu soruyu iptal ettim ve cevapladım, ancak daha çok düşündüğüm sadece siteye uygun son 2 soru. Diğerleri ise "esasen fikir temelli".
jordanm

1
Bu soruda da bir meta yönü var: Sorunun ilk cevaplanmasına yardımcı olmasa da, "bu taşınabilir değil" gibi yorumlar aylar veya yıllar sonra soru / cevap karşısında karşılaşan diğer okuyucular için çok yararlı olabilir.
Bananguin

2
@Bananguin Yorumlar "bu taşınabilir değil" diyerek beni rahatsız etmeyin. Bu sadece bir FYI. Bu tür yorumları kendim yaptım. Beni rahatsız eden "Kullanmamalısın ...". Bu, cevapta yanlış bir şey olduğunu ima eder. Bu, örneğin yanıtın kullanımdan kaldırılmış kodu önermesi durumunda geçerli olurdu. Bu yüzden Bash ile neyin yanlış olduğunu merak ettim.
toxalot

2
+1. Özellikle soru bashtek başına etiketlendiğinde, birisi "Taşınabilir değil, bashizmdir" der. Etiketli bir soruyu cevapladığımda C, taşınabilir olup olmadığı umurumda Javadeğil.
PP

4
bashTıpkı GNU'ya özgü bir uzantıyı bazı yardımcı programlar için kullanıldığına işaret edeceğim gibi (soru Linux olarak etiketlenmiş olsa bile), taşınabilir değil, belirli bir özellik olduğunu belirtmenin her zaman iyi olduğunu hissediyorum . Hiç kimsenin "bu bir bashizmdir ve asla kullanmamalısınız" dediğini görmedim.
Martin Tournoij

Yanıtlar:


15

Bu topluluğun bir üyesi olarak insanların bashları hedefleyen şeyler için bashisleri dikkate almadığını görmüyorum. Taşınabilirlik hakkında konuşurken, GNUizmler bashisms'ten çok daha kötüdür. bashMesleğiniz için kullandığınız sürece , komut dosyasının kullanarak yürütülmesini bekleyebilirsiniz bash. Ancak, açıkça kontrol etmedikçe sürümü garanti edemezsiniz. Bash sürüm 4, ilişkilendirilebilir diziler gibi bazı yararlı özellikler getirdi, ancak Bash v3, OS X ve RHEL 5'te hala yaygın olarak kullanılmaktadır.

ne tür komut dosyaları olabildiğince taşınabilir olmalıdır?

Bu, ihtiyaçlarınız ve geliştirici olarak neyi desteklemeyi seçtiğinizle ilgilidir. Tüm * NIX türlerini destekleyen bir uygulama için bir yükleme komut dosyası yazıyorsanız, taşınabilirlik çok önemli olacaktır.

Bash yüklü olmayan sistemler ne kadar yaygındır?

FreeBSD ve Solaris 10, varsayılan olarak bash yüklü olarak gelmeyen sistemlere örnektir. Gömülü sistemler hariç, çoğu Linux sistemi buna sahip olacaktır.

Sistemde Bash yüklüyse, find ve diğer yardımcı programların GNU sürümü de olacak mı?

Hayır, taşınabilirlikle ilgili asıl mesele bu. Taşınabilirlik önemliyse, yalnızca POSIX standardı tarafından tanımlanan kabuk komut özelliklerini kullanmalısınız. GNU yardımcı programları, FreeBSD gibi GNU olmayan sistemlere yüklenebilir, ancak bunların PATH'de ilk olma olasılığı düşüktür ve yüklenecek araçlara güvenemezsiniz.


1
Sanırım burada insanlardan daha çok bashismleri görmezden geldiğimi görüyorum . Sadece beni hayal kırıklığına uğratmanın ve bu soruyu sormamı istediğim kadar sık ​​fark ettiğimi biliyorum.
toxalot

1
Peki GNU yardımcı programları kurulur, ancak ilk olarak PATH'de değilse, bunları özel olarak çağırmanın bir yolu var mı? Aksi halde, neden hiç yüklenmediler?
toxalot

@toxalot: İkili dosyalar ve komut dosyaları mutlak yollar kullanılarak açıkça çağrılır.
Bananguin

1
@Bananguin Birisi Bash ve GNU yardımcı programlarını yüklediyse (ancak PATH'de değilse), komut dosyasını, mutlak yolları findve kullandığım diğer GNU'ya özgü yardımcı programları kullanmak üzere düzenlerse kullanabilirler mi? Açıkçası, bu bir yükleyici komut dosyası için kullanıcı dostu olmaz. Ama GitHub'a başkalarının istedikleri takdirde yakalaması için bir şeyler koymayı düşünüyorum. Her sistem için taşınabilir olmaması umurumda değil . Sadece birçok sistemde işe yaramaz olmasını istemiyorum .
toxalot

1
@toxalot: evet işe yarayabilir. FIND=/opt/gnu/dispicable/bin/findsenaryonuzun başlangıcına bir şey koyarsanız ve senaryonuzda kullanmak ${FIND}yerine findinsanlara yükleme yollarını koymaları ve senaryonuzun doğru araçları kullanmasını sağlamak için bir (!) yer verirsiniz.
Bananguin

5

Peki, taşınabilir komut dosyaları yazmak ne zaman önemlidir?

ne tür komut dosyaları olabildiğince taşınabilir olmalıdır?

Bunları çalışma ortamınız için kullanırken ve farklı makinelerde çalışıyorsanız (veya gelecekte de çalışabiliyorsanız) - VE, işe başlamadan önce araçlarınızı yeniden yazmak zorunda kalmazsınız.

örneğin: bir çöp betiği / rmdeğiştirme


Mark Stewart:

... sorun giderme araç setim için sadece vi ve Korn kabuğum olacağını varsayalım. Ve Unix'in çoğu lezzeti üzerinde çalışan komutları kullanmaya çalışıyorum.


3
Ben kaygan "Bash-isms" bazı gibi ama sorun giderme araç takımı için ben sadece vi ve Korn kabuk olacak varsayalım. Ve Unix'in çoğu lezzeti üzerinde çalışan komutları kullanmaya çalışıyorum. Bu şekilde, ps komutunun nasıl davrandığı, Bash veya Perl veya PHP'nin orada olduğu veya nerede oldukları konusunda endişelenmek zorunda kalmadan hasta bir sistemde triyaj yapmaya hazırım.
Mark Stewart
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.