使用getopt_long()從命令列獲取引數

yui發表於2010-06-13
命令列

眾所周知，C程式的主函式有兩個引數，其中，第一個引數是整型，可以獲得包括程式名字的引數個數，第二個引數是字元陣列指標或字元指標的指標，可以按順序獲得命令列上各個字串引數。其原形是：

int main(int argc, char *argv[]);

或者

int main(int argc, char **argv);

 

如果有一個解析CDR的程式，名叫destroy，負責將一個二進位制格式的CDR檔案轉換為文字檔案，輸出的文字的樣式由另外一個描述檔案定義，那麼，命令列要求輸入的引數就有三個：CDR檔名、輸出檔名和描述檔名。其中，前兩個引數是必須輸入的，第三個的描述檔名可以不輸入，程式會自動採用預設的輸出樣式。很自然，主函式的三個引數就應該這樣排列：

./destroy cdr cdr.txt [cdr.desc]

 

這樣做在一般情況下不會有太大問題，問題來源於擴充套件性的需求。如果有一天，使用者要求解析程式能夠按關鍵字解析，只有含有關鍵字的CDR才能夠輸出。解決方法很簡單，只要在引數列表的最後，加上它就可以了。不過，這樣就使得原本可選的描述檔名變為必須輸入：

./destroy cdr cdr.txt cdr.desc [keyword]

 

因為不改的話，你就不知道，第三個引數究竟是描述檔名，還是關鍵字。現在還算好辦，如果以後陸續有增加引數的需求，關鍵字也變成必須輸入了，這個時候，如果要查詢全部CDR，你還得定義一個“特殊的關鍵字”，告訴程式，把資料統統給我撈出來……

 

有鑑於此，在Unix/Linux的正式的專案上，程式設計師通常會使用getopt()或者getopt_long()來獲得輸入的引數。兩者的一個區別在於getopt()只支援短格式引數，而getopt_long()既支援短格式引數，又支援長格式引數。

短格式：./destroy -f cdr -o cdr.txt -c cdr.desc -k 123456

長格式：./destroy --file cdr --output cdr.txt --config cdr.desc --keyword 123456

 

引入了getopt()和getopt_long()的專案，設計者可以按需要，方便地增加引數，或者隨意地放置引數的先後次序，只需要在程式中判斷，哪些引數是必須的就可以了。關於這兩個函式的用法，大家可以上網搜尋一下，不再累述。附件destroy_linux.c給出了在Linux下使用getopt_long()的例項。

 

另外一個區別是，getopt()幾乎通用於所有類Unix系統，而getopt_long()只有在GNU的Unix/Linux下才能用。如果把上述程式放到Tru64上編譯，就會出現以下錯誤：

cc -o destroy destroy_linux.c

cc: Error: destroy_linux.c, line 24: In the initializer for long_opts, an array's element type is incomplete, which precludes its initialization. (incompelinit)

                {"help", no_argument, NULL, 'h'},

----------------^

 

所以，如果一定要在Tru64等非GNU的OS上做到長格式的效果，除了自己另起爐灶之外，基本上只好藉助一些跨平臺的開源專案了。附件裡的getopt_long.c和getopt.h是從opensolaris的網站上抄下來的，是包含在sg3_utils軟體包中的程式。sg3_utils具體是什麼，我也不知道，據說是一個Linux的開發包，用來直接使用SCSI命令集訪問裝置。（sg3_utils is a package of utilities for accessing devices that use SCSI command sets.）反正拿來能用就是了！

 

拿過來後，把他們放到與destroy_linux.c同一目錄下，只需要把destroy_linux.c的標頭檔案改一個地方，#include <getopt.h>改為#include “getopt.h”，就能夠編譯執行了。而且，這樣改好後，不僅在Tru64上能執行，在Linux、SunOS上也能執行。

 

Linux下編譯

-bash-3.2$ gcc -o destroy destroy.c getopt_long.c

短格式，全部輸入

-bash-3.2$ ./destroy -f aaa -o aaa.txt -c ccc -k 222

Parameters got: file_name = aaa, output_name = aaa.txt, config_name = ccc, keyword = 222

前兩個長格式，後兩個短格式

-bash-3.2$ ./destroy --file aaa --output aaa.txt -c ccc -k 222

Parameters got: file_name = aaa, output_name = aaa.txt, config_name = ccc, keyword = 222

漏掉一個必須輸入的引數會報錯

-bash-3.2$ ./destroy -output aaa.txt

Error: file name must be specified

次序隨意，長短混用

-bash-3.2$ ./destroy -c ccc -o aaa.txt -k 222 --file aaa

Parameters got: file_name = aaa, output_name = aaa.txt, config_name = ccc, keyword = 222

 

題外話，#include <filename.h>與#include “filename.h”有什麼區別，是面試C程式設計師經常問到的一個問題。答案大家都知道了，#include <filename.h>，編譯器從標準庫路徑搜尋filename.h，而#include “filename.h”，編譯器從使用者的工作路徑搜尋filename.h。

 

此外，網上也有人說從glibc（http://sourceware.org/glibc/）上把getopt.h、getopt.c和getoptl.c拿過來也能夠用。我也試過，但是不清楚什麼原因不成功。

 

在這個小實驗的過程中，還發現了C語言在各個OS下的一些細小差異，比如destroy.c裡，79行到82行：

// if not setting default, Linux OK, but SunOS core dump

if ( !config_name ) config_name = "(null)";

if ( !keyword ) keyword = "(null)";

printf("Parameters got: file_name = %s, output_name = %s, config_name = %s, keyword = %s/n", file_name, output_name, config_name, keyword);

 

如果在81行和82行不設定空指標的預設值，Linux和Tru64都會自動幫你轉換而避免執行時錯誤，但是SunOS不會，它會死給你看。

./destroy -f aaa -o aaa.txt

Segmentation Fault (core dumped)

 

再比如第62行的abort()在標頭檔案stdlib.h中定義，如果不包含此檔案，SunOS與Tru64編譯都沒問題，Linux編譯時會警告：

warning: incompatible implicit declaration of built-in function abort

 

由此看來，雖然C也公認是可移植性比較好的語言，但是在跨平臺的專案中，也應該注意這些微小的差別。

相關文章