UNIX CLI'si için araçlar yazarken, programın yardım ve / veya kullanımı yazdırmasını nasıl sağlarım?

Genellikle kullanıyorum fprintf(stderr, "help text here");, ancak bununla ilgili birkaç sorun var.

• İlk olarak, kullanmam gerekip gerekmediğinden emin değilim stderr. Bu iyi mi, yoksa kullanmalı stdoutmıyım?
• Tahmin edebileceğiniz gibi, yardım metni, aracın sahip olduğu seçeneklere bağlı olarak oldukça uzundur. Şimdi, genellikle "strings like that\n"ikinci parametreye birkaç tane koyarım. Ancak bu, kaynak kodumu elli veya daha fazla yardım metni satırı ile doldurur. Hiç kolay yönetilemez. Bunun yerine ne yapmalıyım?
• Bir araç C veya C benzeri bir dilde yazılmadığında, burada mümkün olan yerlerde (en belirgin şekilde Perl ile) dokümanları kullanma eğilimindeyim . Bunu C'de kullanamam, ama kullanabileceğim bir şey var mı?
• headerfile.hİçine koymayı düşünüyordum a #define HELP "help text here", Vahşi doğada hiç görmedim, gerçekten kullanmam gerekip gerekmediğini bilmiyorum.

İdeal olarak, metni harici bir dosyaya koyabilir ve dahil edebilirim. #includeBununla birlikte kullanmak yanlış görünüyor. O zaman ne yapmalıyım?

Fikir, bir yardım metnine sahip olmak, kolayca yönetilebilir. Kaynak kodun içinde olması gerçekten uygun değildir.

Hedef platformunuzun içindekilerden ilham alın

BSD'nin kaynak koduna bir göz atın. Örneğin:

• usage(void)NetBSD'nin /usr/bin/unamearacı [ kaynak ] için:

  usage(void)
  {
      fprintf(stderr, "usage: uname [-amnprsv]\n");
      exit(EXIT_FAILURE);
  }
  

• usage(void)NetBSD için /usr/bin/telnet[ kaynak ]

• usage(void)OpenBSD için /bin/ls[ kaynak ]

Alternatiflere bir göz atın

Daha iyi ya da daha kötü olup olmadığına kendiniz karar verin. Google CodeSearch'ü aşağıdakiler gibi başkalarını bulmak için kullanabilirsiniz:

• SkyLoad kullanımı [ kaynak ]

Gördüğünüz gibi, bunlar ve yukarıda listelenen BSD sistemleri entegre araçları arasındaki farklı stil. Bu, birini ya da diğerini takip etmeniz gerektiği anlamına gelmez . Ancak genellikle etrafa bakmak ve tutarlı çözümü bulmak iyidir.

50 yardım hattına standart olmayan bir çözüm ...

50 satırlık metinden kaçınmak istemiyorsanız, yardımı bir metin dosyasından okuyabilirsiniz (düz metin biçiminde veya manoluşturduysanız doğrudan kaynağını ayrıştırabilirsiniz ). Bunu oldukça zarif bir yol olarak görüyorum (metin belgesine bile bakabileceğiniz gibi), ancak çekirdek sistem programları için onları doğal olarak güvensiz hale getirecek ve bir başarısızlık noktası getirecek. Diğer insanlar bir mesaj usageveya helpmesaj için ağır olduğunu iddia edecekler , ancak bunlara hızlı sıkı döngüler deniyor gibi değil ...

Şüphe duyduğunuzda, devleri takip edin.

Kullanıyorum stdout, çünkü bir yardım bir hata değildir.

Bu, C'de uzun bir yardımsa, burada dokümanlar taklit etmeye çalışıyorum:

printf("This is the help for MyWonderfulApp\n"
       "Options are:\n"
       "    --help: display what you are reading now\n"
       "    --quiet: output nothing\n");

Ama çoğu zaman özel etiketler mankullanarak bir sayfa yazıyorum nroff -man. Uygulama içi yardım sadece bu mansayfaya atıfta bulunmayı içerir .

Ben sen olurdum ben sadece kaynaklarını açtı ediyorum grep, tail, cat, your_other_favorite_unix_shell_commandorada nasıl yapıldığını görmek için. Eminim, yolları oldukça iyi düşünülmüş ve birçok kişi tarafından korunabilir.

Hakkında stderrveya stdout. Gerçekten basit, eğer bir hata varsa - yazın stderr, sadece bilgi ise - stdout. Örneğin, aracınızı yanlış seçeneklerle çalıştırırsam Use --help for usage, bunun ait olduğu bir hata görüntülemek isteyebilirsiniz stderr. Aracınızı geçerli bir seçenekle çalıştırırsam --help, lütfen kullanın stdout.

Eğer kodunuzun yakınında uzun yardım dizeleri istemiyorsanız tercih etmeyin. Bir başlık dosyasındaki #define gayet iyi, ancak bu gerçekten kişisel bir tercih. Bir komut satırı aracının kodunu okumak zorunda kalsaydım, yardım dizesinin kullanıcı tarafından sağlanan seçenekleri işleyen bir dosyanın içinde olmasını tercih ederim.

Gnu getopts kütüphanesini kullanıyorum. Yardımlı bir örnek için bu örnek projeye , özellikle de parser.y öğesinin altındaki ana yönteme bakın .

Kıvırcık parantezlere sarıldığından, kullandığım vim editörü çizgileri birlikte katlayabilir ve ihtiyacım olmadığında bile fark etmiyorum.

C kullanırsam veya Boost kitaplıklarına bağımlı olmamayı tercih edersem, GNU'ya bağlı kalırım getopt. Aksi takdirde yardımı otomatik olarak bastıran Program Yükseltme Seçeneklerini tercih ederim .

Ayrıca, seçenek işleme söz konusu olduğunda doğru seçeneği en iyi uygulamalardan biri olarak tahmin etmeyi düşünüyorum. Git'ten öğrendim ve şimdi aynı şeyi projelerimde de kullandım. Kullanıcı bilinmeyen bir komut satırı seçeneğine girerse en iyi eşleşmeleri yazdırmak için temel olarak Damerau – Levenshtein mesafesini kullanır.

Bu konuda örnek olarak kullanabileceğiniz küçük bir makale yazdım .

Umarım yardımcı olur :)

Açıkçası, özellikle paragraflarınızı değiştirmeniz ve yeniden doldurmanız gerekiyorsa, cout << veya printf () kodunda bir delik sayfası yazmak hantaldır. Bu nedenle, örneğin metninizi daha kolay biçimlendirebileceğiniz emacs kullanarak, bu metni ayrı bir dosyada düzenlemek iyi bir fikirdir .

Sonra bu metin dosyasını yasal bir C başlık dosyasına dönüştürmek için aşağıdaki sed komut dosyasını kullanabilirsiniz:

s/\"/\\\"/g
s/$/\\n"/
s/^/"/
1i\
const char *helpStr = 
$a\
;

Ardından, #include- başlık dosyanızı kaynak kodunuza ekledikten sonra, metninizi kullanarak

cout << helpStr;