Komut satırı seçenekleri stili - POSIX veya ne?

Bir yerde java / javac karşı Windows ve Unix tarzı bir karışımı kullanarak iddia rant gördüm

java -classpath ... -ea ... Something

IMHO, karışık değil, tıpkı findişler gibi, değil mi? AFAIK, POSIX'e göre sözdizimi şöyle olmalıdır

java --classpath ... --ea ... Something

ve -abcdefaynı anda 6 kısa seçenek belirtmek anlamına gelir. Hangi sürümün genel olarak daha az yazmaya ve daha az hataya yol açtığını merak ediyorum.

Java'da küçük bir yardımcı program yazıyorum ve hiçbir şekilde /a /böncelikle Unix ile ilgileniyorum çünkü Windows stilini kullanacağım . Hangi stili seçmeliyim?

POSIX bağımsız değişken kurallarını Yardımcı Program Kuralları bölümünde bulabilirsiniz. POSIX stili, tek bir tire ve ardından seçeneği belirten tek bir harf içeren seçeneklerden oluşur; bağımsız değişken değeri, seçenekten boşlukla ayrılır.

Kurallarda istisnalar vardır - findörneğin - bunlar tarihsel Unix emsallerinden kaynaklanmaktadır.

X Windows (X11), benzer findtek satırlı, uzun ad seçenekleri kullanır.

Çift kısa çizgi uzun ad seçeneklerine GNU öncülük etti ( +önek olarak kullanılan bir sapmadan sonra ).

Bilinen çok çeşitli komut satırı bağımsız değişken işleme sistemlerinin tartışılması için bu StackOverflow sorusuna bakın - çok şey var. ( Bu yazılmıştır beri soruyu karar verilmesi güçler yani-SO 367.309 SO için uygun değildi. Başka bir sorunun cevabını aktardıktan, Unix kabuk komutunun genel sözdizimi nedir? . )

Aşağıdaki gitgibi bir yapıya sahip olduğunuz tekniklerin listesini kapsayacak şekilde genişletebilirsiniz (ve bir dizi diğer sistemi):

• basecommand[ genel seçenekler ] subcommand[ alt komut seçenekleri ] [ad ...]

Her biri kendi seçenek sözlüğüne sahip birçok alt komut olabilir.

Tabii ki, Windows ' /' yerine ' -' seçenekleri belirtmek için eğik çizgi ' ' kullanır .

JCL (z / OS ve OS / 360 ve ara sistemler için) virgülle ayrılmış konumsal parametreleri kullanma eğilimindedir ve genellikle kullanıcı dostu veya iyi bir arayüz olmadığı kabul edilir.

DÜZENLEME: Bu stilin bir GNU-izm olduğu ve GNU tabanlı olmayan Unix'lerin tek kesikli bir sözdizimi (özellikle OS X ve BSD varyantları) kullanma eğiliminde olduğu belirtildi.

GNU-ism statüsüne rağmen, yeni yazılmış birçok Unix tarzı program bu stili kullanır:

• --long-option uzun seçenek adları için,
• -s kısa (tek karakter) seçenekler için,
• -abc bağımsız değişkenler olmadan birden fazla kısa seçenek için (seçenek başına bir karakter).
• Bağımsız değişkenli seçenekler:
  • --long argveya --long=arguzun seçenekler için,
  • -s arg, -sargveya (isteğe bağlı olarak) -s=argkısa seçenekler için. Yalnızca sonuncunun bir argümanı olduğu sürece, bu diğer kısa seçeneklerle birleştirilebilir .
• Aynı "anlamsal" seçenek, çoğunlukla kısa (yazmak daha hızlı) ve uzun (hatırlanması daha kolay) olan birkaç takma ada sahip olabilir.

Herhangi bir süre için bir Linux kabuğu kullanan herkes bu stile ¹ aşina olmalıdır , bu yüzden tarafında en az sürpriz ilkesine sahiptir. Uzun seçeneklerle belirsiz olmadan çoklu kısa seçeneklerin gruplandırılmasına izin vermek de güzel.

¹ Örneğin, (benim Linux makine) bu stili kullanan programlardan bazıları: ls, grep, man, sed, bash, vb ( DÜZENLEME: bunlar, BSD ve OS X makineleri bu stili kullanmayın olsa görünüşte GNU-izm vardır)

Sizin için bu ayrıştırma bakabilirim birkaç kütüphaneler vardır (çoğu olmanın iyi bilinen GNU uygulanması ait getopt ) sadece uzun ve kısa seçenekler onlar bir argüman da, ister mevcut ve ne zaman bir ne yapacağını belirtmek için sana ihtiyacım, seçeneği bulundu. (Ve elbette, konumsal argümanlar için ne yapmalı, yani başlangıç -seçenekleriyle başlamayan ve önceki seçeneklere argüman olmayanlar)

findyeni bir komut satırı sözdizimi kullanmak için kolayca değiştirilemeyen çok eski bir programdır (veya belki de daha olası: çok eski bir programın yeniden yazılmış bir sürümüdür). Çok fazla komut dosyası bozulur ve eski sözdiziminde kullanılan çok fazla kullanıcı şikayet eder. javacmuhtemelen gcctarihsel nedenlerden dolayı eski bir sözdizimini takip eden arkadaşlar ve arkadaşlardan etkilenmişti .

• Dash-dash ( --long-arg) ile argüman bir GNU kuralıdır (bkz. Getopt uygulaması).
• POSIX komutları hiçbir zaman çift tire bağımsız değişkenleri kullanmaz. Bu, varsayılan olarak GNU kullanan Linux hariç Unix'in (Mac OS X, BSD) çoğu çeşidi için geçerlidir.

Java projeniz için Java veya Apache CLI için GNU getopt'a göz atmak isteyebilirsiniz . Her iki sözleşmeyi de desteklerler.

Üçüncü seçenek, Java VM bağımsız değişkenlerini kullanmak ve çalışma zamanının sizin için ayrıştırmasına izin vermektir:

 $ java -Dcolor=blue

Ve sonra, kodda:

 System.getProperty("color");

Şahsen, -Ddeyimi kullanacağım ve Java büyüsünü sınıf yolu vb. Denetleme de dahil olmak üzere komut satırı ayrıştırmasını işleyen bir kabuk komut dosyasına sararım.

Değişir. Ben şahsen POSIX stilini tercih ediyorum, ancak sizin durumunuzda muhtemelen aracınızın kullanılacağı ortamla tutarlılığı hedeflerdim. Bu, JAR'lar için Java kuralını kullanmak anlamına gelir (tipik bir Unix komutuna benzeyecek bir sarmalayıcı komut dosyasına sahip olmayı planlamıyorsanız).