Question

我正在尝试在一系列日志文件中搜索模式“Error”，然后将结果写入文本文件。

我正在使用命令：

foreach($file in $files){

   $match = get-content $file | Select-String $p | Out-File $matchfile
}

模式$ p已从命令行中获取。我在Windows Server 2008 R2上运行该脚本，如果“Error”是日志文件中的单个单词，则返回结果。我有“ErrorCode”的实例，我希望脚本能够识别。

我按照我的意愿在Windows 7上运行代码。但是，当我在Windows Server 2008 R2上运行脚本时，我没有得到任何结果。两个PowerShell版本都是2.0。

Answer 1

您确定它确实在Windows 7上运行吗？你编写它们的方式，foreach循环的每次迭代都会用$ files中最后一个文件的结果覆盖matchfile。您可以在Out-File之后添加-Append开关，但您甚至不需要foreach循环。另外，$ match的目的是什么？ $match =看起来对我来说是多余的。试试这个：

Get-Content $files | Select-String $p | Out-File $matchfile

我怀疑你在2K8服务器上没有得到任何结果的原因是$ files中的最后一个文件没有$ p匹配。在Windows 7计算机上，您获得的结果是因为最后一个文件与$ p匹配，但您没有从任何其他文件中获得结果。

Answer 2

我是第二个@Adi，你在每次迭代中覆盖文件。您可以通过将追加开关添加到Out-File来解决此问题。这也应该有效并且使用起来更简单：

$files | Select-String $p | Out-File $matchfiles

Answer 3

我希望$ match永远为null。根据帮助，Out-File从不向管道发送任何内容。但如果这与你的问题有关，我会感到惊讶。

本着“任何帮助将不胜感激”的精神......

我在Win7和WS08R2上尝试了一个简单的实验，无法重复你的结果（它按预期工作）。我还尝试使用不同的编码创建正在搜索的文件：Unicode，UTF8和ASCII。一切顺利。我甚至告诉Select-String使用错误的编码：

get-content mytestfile.ascii | select-string error -Encoding Unicode

它仍然有效。我使用十六进制查看器来验证mytestfile.ascii，mytestfile.unicode和mytestfile.utf8实际上是以不同方式编码的。我也尝试过不同的行结尾（Linux风格与Windows风格）并且有效。

我的猜测是你对某些探测器必须发现的文件，系统等有一些独特之处。考虑到这一点......

我建议您使用十六进制查看器查看其中一个日志文件（从两个系统中尝试），以查看Win7系统和WS08R2系统之间是否存在不同之处。在UTF8文件的开头，您将看到EF BB BF，然后是日志的每个字符的一个字节。在Unicode文件的开头，您将看到FF FE，然后是每个字符的两个字节。（如果文本是英文，那么每个其他字符将为0）。对于ASCII文件，开头没有特殊值，每个字母有一个字节。 Linux行结尾是单个0A（换行），Windows行结尾是0D 0A（回车，换行）。除了如上所述的开头的特殊字符和行结尾之外，您将要查找的文本与您在记事本中查看时完全相同的字符集。（顺便说一句，如果行结尾是Windows风格，在记事本中查看它只会看起来“正确”）。如果您看到任何额外的字符，那么这可能是问题的根源

如果没有显示任何意外情况，那么我建议从Powershell命令行进行一系列实验。以下过程列出了许多步骤，但它试图涵盖许多意外情况。你不会执行每一步。（但是在开始时进行了一些修改 - 考虑用于测试的日志文件中出现“错误”的位置 - 您可以复制并粘贴整个脚本，然后一次解释整个结果集）< / p>

# 0. Get some text to experiment with
#    If "error" appears on line 200 and line 493 (where first line in file is Line 1), then:
$testTxt= cat mylogfile | select-object -skip 195 -first 300
# or better still:
$testTxt= cat mylogfile | select-object -skip 195 -first 10
$testTxt2= cat mylogfile | select-object -skip 488 -first 10
$testTxt += $testTxt

# 1. Figure out where in testTxt "error" appears
$testTxt[3..5] # if my math is right "error" will appear as middle line

# 2. If #1 doesn't work on both systems, then on failing system(s):
$testTxt[4] | select-string error

# 2.5 If #2 fails then you need to look at every character
#  of $testTxt
[char[]]$testTxt 
# or even look at every byte value in hex:
[byte[]][char[]]$textTxt | % { $_.tostring("X")}

# 3. If #2 worked, then:
$testTxt | select-string error

# 4. If #3 failed, then:
$testTxt[3..5] | select-string error

# 5. If #4 failed, then:
$testTxt[3..4] | select-string error
$testTxt[4..5] | select-string error

# 6. If either of #5 failed, then carefully examine those lines of text:
"line 3"
[char[]]$testTxt[3] 
"line 4"
[char[]]$testTxt[4] 
"line 5"
[char[]]$testTxt[5] 

# 7. If #3 worked then:
$testTxt2 = cat myLogFile
$testTxt2 | select-string error

# 8. If #7 worked, then you have a solution
# Replace:
get-content $file | Select-String $p | Out-File $matchfile
# With (on Powershell v3 this may perform worse than the above, assuming above worked)
$logText = get-content $file
$logText | Select-String $p | Out-File $matchfile

# 9. If #8 failed, then the situation is somewhat awkward.
#    On one hand you have twenty lines working, but on the other the file as a whole
#    doesn't work. You could go back to step #0 and start with a larger amount of text,
#    say 40 lines, and see if it works. If it does you could try 80, 160, etc. until it
#    fails. But this case seems pretty unlikely.

# 10. In general when a step fails you want to try something "smaller". And when steps
#     succeed you want to try something "bigger", where "bigger" means more like the 
#     solution you want.

PowerShell：在日志文件中搜索字符串的一部分

3 个答案: