背景：

????通過fscanf抓取log文件里的文本數(shù)據(jù)，卻在while循環(huán)里出現(xiàn)了詭異的跳過現(xiàn)象。

????先來看一下常見的fscanf用法，我們來匹配一下Line<num>

????每一行的line_num都正常。

????那么不常見的fscanf長什么樣呢？這里就要請出同事的if else匹配方式了：

新的log文件中，每一行都加入了arg關(guān)鍵字，在if else里通過具體的Line<N>進行匹配

你以為是arg1....arg4，實際上，VCS只會給出arg1，甚至還會出現(xiàn)while循環(huán)不完而超時的情況。

我們加入一行打印看看卡在哪里

事實上沒卡住，而是在不斷的循環(huán)

這個讓同事一晚上沒睡好覺的bug是怎么來的呢？

關(guān)鍵問題在于，$fscanf 是逐字匹配的，這是一個很反直覺的事實，因為常見的腳本語言都是逐行匹配的。這個問題就會導致我們在做 $fscanf(fl,"Line1 %s",line_num) 這種匹配時，Line2也會進入該匹配行，盡管最后“2”會匹配失敗。而fscanf在進入匹配后，無論匹配成功與否，都會使得指針向后增加。所以當出現(xiàn)了if else的匹配時，盡管 if 內(nèi)的匹配失敗進入else了，指針卻已經(jīng)走到了Line之后。

一個最簡單的解決方案：掃描的關(guān)鍵字首個字符不一致。

或者安全一點的方案，用腳本把需要的關(guān)鍵信息讀取出來存在另一個log里，再由fscanf來讀取這些相對簡單的信息