mwhidden

Would it instead work to parse the file line by line, and ignore any line which does not contain non-whitespace? Something like (untested) Do $line = FileReadLine($file) If(@error == 0) Then If(StringRegExp($line, "\S", 1) Then ; Grab the line unless it is only whitespaces. $singleSpace = $singleSpace&$line EndIf EndIf Until (@error <> 0)

After reading your response, I thought at first that it was though each function has a local @error, and SetError() reaches up into the calling scope and twiddles the calling function's local @error. But that's not right because the change of @error is visible within the called function as well as the caller. So I'm guessing instead of setting @error to 0 when a function is entered (as in the docs), what actually happens is that @error is also set to 0 when each function exits, unless SetError was called in the scope of that function itself. Is that right?

The documentation for SetError() says "When entering a function @error is set to 0.", but it seems there are other circumstances when @error is also set to 0. For example, somewhere in this code, after MakeError() is called, @error gets set back to 0, even though no functions are entered after SetError(1) is called. Func PassThroughError() MakeError() EndFunc Func MakeError() SetError(1) EndFunc PassThroughError() ; Who set @error back to 0? MsgBox(1, "", "@error is "&@error)

Try something like this. Read line by line so we don't have to read the whole log, in case it is large. Do $sLine = FileReadLine($boot) If(@error > 0) Then SetError(1) ; Could not read file ElseIf(@error = 0 AND StringInStr($sLine, "Detected boot environment:")) Then If(StringInStr($sLine, "BIOS")) Then ; Here BIOS was detected ; Do whatever you need depending on the detected environment EndIf FileClose($boot) MsgBox(0, "Black Magic Tools", $sLine) ExitLoop ; No need to continue EndIf Until(@error < 0) ; End of file FileClose($boot) * Edited: Use MsgBox as requested, not ConsoleWrite. Fixed logic.

Sorry, I think my explanation was not clear. "A B" C" is a manufactured argument for illustration of parsing an escaped double quote embedded in an argument. A real-life example might be something more like SendEmail.au3 "My boss said "Finish this script" today. Can you believe it? -MWhidden" The single argument to the script would be a string with double quotes within it.

I'm not sure if this is the expected behavior, but the way $CmdLine handles escaped quotes is different than _WinAPI_CommandLineToArgv (which is recommended as an alternative for long argument lists) handles them. Eg., When invoked like this: AutoIt3.exe Test.au3 "A B\" C" A B C $CmdLine gives 2 arguments after the length: [ ..., 'A B', 'C" A B C"] _WinAPI_CommandLineToArgv gives 4 arguments after the script: [..., 'A B" C', 'A', 'B', 'C'] Is this as it should be? Thanks, Mike #include <WinAPIShPath.au3> #include <Array.au3> _ArrayDisplay(_WinAPI_CommandLineToArgv($CmdLineRaw)) _ArrayDisplay($CmdLine)

Remove the escaped quotation mark from just after AutoIt3.exe, or add another before C:. Your escaped quotes are imbalanced. Other than that, I don't see a problem. I tried your example after fixing the quotes, and it ran an AutoIt script just fine. What's the output when you run from the console?

@AZJIO, Thank you for the additional references! -mwhidden

I must respectfully disagree that the only interpretation is that the 2nd needs to be a number too. It is at least conceivable that it could have been the other way -- that when one states if("abc" = 1) that the 1 is converted to "1" as happens with the & operator, or even that it were just generally the case that strings and numbers are never (except in pathological cases) equal (ala C/C++ comparing a char* to an int with proper typecasts). Therefore, I think it is worth documenting that the authors of AutoIt chose that when comparing a number to a string that the string becomes a number, and not vice versa. Because = so naturally applies both to strings and numbers, (while, on the other hand, +, -, * are clearly numeric), it is ambigiuous in the documentation of which type takes precedence in a comparison. In fact, numbers are preferred, but the only way to learn this is to try it in code.

Regarding the treatment of Strings as Numbers by the comparison operators: User AZJIO >brought this up last year, but I still think this is an issue. While the documentatoin of Datatypes is clear that Strings are converted to Numbers where a Number is expected, it is not clear that the comparison operators convert a String to a Number if the operands are of mixed type. I think the documentation should make this clear, since it seems to be a recurring confusion. In other words, when comparing "abc" = 1, it is not documented that this expression "expects" numbers. I don't feel that it would be unreasonable for one to believe that this expression may convert 1 to "1" instead of converting "abc" to 0. Perhaps the documentation for the comparison operators might state something along the lines of: Comparison operators (case insensitive if used with strings except for ==. When operands are of mixed types, strings will treated as numbers, except for ==.) Thank you, mwhidden

Thank you everyone, especially Melba23 and water, for your help.

Thank you, but sorry it is not there. It says that Strings are coerced to numbers (using Number()) when strings are used, but there is no rule for when strings are treated as numbers. Common sense indicates that mathematical operators like +,-, etc., would treat operands as numbers, and the exampls in teh documentation imply this is so. However, there is nothing that speaks to the comparison operations, except in the case of ==. Empirical evidience suggests that comparison operators (except for == and <>) treat operands as numbers if at least one operand is a number. Otherwise, they treats the operands as strings.

I was confused because in an earlier post you stated that '=' does not convert values to numbers, but I guess you meant that it does not convert both to numbers, but sometimes converts only one to a number. But, now that I know that '=' (and also <, >, <=, >=) coerces strings to numbers in mixed-type situations ( vs. the other way around), I can be wary in the future. Is this the proper forum to request an update to the documentation?

If that's true, I'm having trouble finding where that is documented. I can't find (I might just be missing it) information on type coercion, or perhaps the documentation could make that more clear. It is true that "Foo" = 0 and that NOT "Foo" == 0. The latter is clear from the documentation, but the former is not clear (not to me) until it bites you.

I'm responding to user "water" who stated that in my example, the string were being implicitly converted to numbers. Are you saying that user water is incorrect in his explanation of why "Foo" = 0 is true but "Foo" == 0 is false? I'm still unclear as to whether and when '=' and '==' converts a string to a number. It seems that '=' does, at least sometimes.