2013-01-18 71 views
1

您好我已經看到了一些在互聯網上的解決方案,他們都基本上創建一個文件,但我想將它們存儲在一個字符數組中。速度對我來說非常重要,我不想花時間在硬盤上工作。所以popen()對我來說不是一個真正的解決方案。執行bash命令並獲取輸出C

+2

'popen'不打開文件。它運行一個程序並將輸出直接連接到C輸入流。我知道流的類型被稱爲'FILE *',但它不是一個真正的文件。 – librik

+1

你對「popen」有什麼異議?這將是通常的做法。 –

+0

在這裏檢查:http://theunixshell.blogspot.com/2013/01/executing-shell-command-in-cc-and.html – Vijay

回答

-1

你介意有多個C程序嗎?如果你不這樣做,你可以使用命令行參數。在拳頭C程序中,你可以做以下

system("YourCommand | SecondProgram"); 

SecondProgram將是你會寫第二個C程序的「可執行」。在第二個C程序中,您可以接收命令YourCommand的輸出作爲SecondProgram中的命令行參數。爲了這個目的,也能開始第二個C程序的主()如下

main(int argc,char *argv[]) 

陣列argv將具有YourCommandargc的輸出將包含在陣列中argv元件的數量。

+1

使用'system'永遠不是一個好主意 –

+0

@AndreasGrapentin陳述原因 – PaulDaviesC

+0

我真的不認爲這是一個快速的方式來做。 除了我不明白第二個程序如何將輸出發送回第一個程序...... –

1

如果你會讀POPEN的手冊頁,你會發現如下:

的POPEN()函數創建一個管道,分叉, 並調用外殼打開一個過程。 [...] popen()的返回值在所有方面均爲 正常標準I/O流,但必須使用pclose()而不是fclose(3)關閉 。 從 讀取「popened」流讀取命令的標準輸出,並且 命令的標準輸入與 稱爲popen()的過程相同。

(重點煤礦)

正如你所看到的,到popen導致命令stdout呼叫正通過管道輸送到你的程序的I/O流,其中有無關磁盤I/O,而是由操作系統管理的進程間通信。 (作爲旁註:在合理的範圍內依靠操作系統的基本功能來解決常見問題通常是一個好主意,並且由於popenPOSIX.1-2001的一部分,所以您可以依賴它來在所有符合標準的operarting系統,甚至是Windows)

編輯:如果您想了解更多,請閱讀本:http://linux.die.net/man/3/popen

0

如果速度是對你很重要,你可以寫你自己的POPEN版本。

它可能是有意義的,因爲POPEN() - 創建一個管道 - 叉 - 執行外殼(很貴吧!) - 比創建一個管殼,叉,執行程序

你的定製版本可以減少程序進行: - 創建一個管道 - 叉 - 執行程序

你甚至可以擴展POPEN分別控制命令STDOUT,STDERR和STDIN。 我寫了這樣一個例程,看到https://github.com/rockdaboot/mget/blob/master/libmget/pipe.c 這是GPL的。

您可以使用FILE指針調用mget_popen3()或使用文件描述符調用mget_fd_popen3()。至少,它應該給你一個關於如何去做的想法。

2

這裏是工作的代碼片段:

char bash_cmd[256] = "ls -l": 
char buffer[1000]; 
FILE *pipe; 
int len; 

pipe = popen(bash_cmd, "r"); 

if (NULL == pipe) { 
    perror("pipe"); 
    exit(1); 
} 

fgets(buffer, sizeof(buffer), pipe); 

len = strlen(bash_cmd); 
bash_cmd[len-1] = '\0'; 

pclose(pipe); 
+1

這不是一個工作片段,你必須修改'fgets'後的'buffer'變量而不是'bash_cmd' – tttony

2

永遠不要忘記Knuth的話說,「過早的優化是所有罪惡的根源。」重要的是不要擔心表現,然後在做任何事情之前測量。除非常罕見的情況外,您的時間價值遠高於程序運行的成本。

喬恩本特利的「編寫高效的程序」(可惜已絕版,在他的"Programming Pearls"的一章是總結)是關於如何使程序運行更快(如果它是值得的)的詳細討論;並且只能作爲最後一項措施來排除最後可能的2%的性能(在將運行時間減少一半之後),它建議使用您所建議的更改。所引用的書包括一些非常有趣的戰爭故事「性能優化」,這些故事是完全浪費(優化代碼從未使用過,優化代碼運行時操作系統旋轉拇指,...)。

+0

Knuth Quote :) –

相關問題