1

I'm trying to use the findstr in the Testing_Results1 to find the string Conexão falhou.. But's not working because the ã. I tried to replace Conexão for ConexÆo but not worked. Also tried to skip the ã by this way but also not working.

:Testing_Results1
    findstr /I /C:"Conexão falhou." WinSCP.log >nul && (
              echo Sem conexÆo com a internet.
              echo Verifique o problema e tente novamente.
              pause
              goto End
    ) || (
              goto Testing_Results2        
    )

    :Testing_Results2

    findstr /I /C:"Conexão perdida" WinSCP.log >nul && (
              echo ConexÆo com o servidor perdida. Tente novamente.
              pause
              goto end
    ) || (
              goto Success
    )

    :Success
    echo Arquivo(s) Exportado(s) com sucesso.
    echo/ &echo/ &echo/
    pause
    goto End


    :Error
    echo Erro desconhecido ocorrido.
    pause
    goto End

    :End
    del /f /s /q %temp%\ftpsend.dat >nul 2>nul
    del /f /s /q WinSCP.log >nul 2>nul
    exit

Maybe this question can be considered duplicated of these:

But there i didn't found solution for my problem.

Any idea?


Edit 1:

Follow a piece of my WinSCP.log

. 2019-05-24 14:36:21.725 --------------------------------------------------------------------------
. 2019-05-24 14:36:21.725 Session name: xxxx@ftp.xxxx.com.br (Ad-Hoc site)
. 2019-05-24 14:36:21.725 Host name: ftp.xxxx.com.br (Port: 21)
. 2019-05-24 14:36:21.725 User name: xxxxx(Password: Yes, Key file: No, Passphrase: No)
. 2019-05-24 14:36:21.725 Transfer Protocol: FTP
. 2019-05-24 14:36:21.725 Ping type: Dummy, Ping interval: 30 sec; Timeout: 15 sec
. 2019-05-24 14:36:21.725 Disable Nagle: No
. 2019-05-24 14:36:21.725 Proxy: None
. 2019-05-24 14:36:21.725 Send buffer: 262144
. 2019-05-24 14:36:21.725 UTF: Auto
. 2019-05-24 14:36:21.725 FTPS: None [Client certificate: No]
. 2019-05-24 14:36:21.725 FTP: Passive: Yes [Force IP: Auto]; MLSD: Auto [List all: Auto]; HOST: Auto
. 2019-05-24 14:36:21.725 Local directory: default, Remote directory: home, Update: Yes, Cache: Yes
. 2019-05-24 14:36:21.725 Cache directory changes: Yes, Permanent: Yes
. 2019-05-24 14:36:21.725 Recycle bin: Delete to: No, Overwritten to: No, Bin path: 
. 2019-05-24 14:36:21.725 Timezone offset: 0h 0m
. 2019-05-24 14:36:21.725 --------------------------------------------------------------------------
. 2019-05-24 14:36:21.725 Conectando a ftp.xxxxx.com.br...
. 2019-05-24 14:36:21.725 Conexão falhou.

Edit 2:

Follow an image of my cmd using this code:

@echo on
findstr /I /C:"Conexão falhou" WinSCP.log 
echo %errorlevel%
pause

enter image description here

aschipfl
  • 33,626
  • 12
  • 54
  • 99
Black Mamba
  • 247
  • 1
  • 12
  • 2
    Both `find.exe` and `findstr.exe` will both work perfectly to find the string `Conexão`, or the strings `Conexão falhou.` and `Conexão perdida`, for that matter. As you're simply sending it to the `NUL` device the in use codepage doesn't matter either, so your issue is currently not reproducible. If you remove the `>nul` from both of your `findstr` lines, you should be able to see it output the matching lines when your script pauses. Also, I'd suggest you read the output from `del /?` at the command prompt, because you certainly need to review your use of its options, `/S` and `/Q`. – Compo May 24 '19 at 15:14
  • @Compo Just made this code to try find whats happenning: `findstr /I /C:"Conexão falhou" WinSCP.log &echo %errorlevel% &pause` I realized that even exists or no the string`Conexão falhou` it's returning `errorlevel 1` . If i try with another word without speacial character like `conectando`, its return `errorlevel 0` . Thank you for your advise about the `exit` code. changed to `/q` only now. – Black Mamba May 24 '19 at 17:31
  • `/Q` is not required at all, the help information from `Del /?` states that it's for use with wildcards, you're not using any wildcards, so get rid of it. It would help us if you post a snippet of your `WinSCP.log`, carrying the strings you're telling us are in the file, because as I've already told you, both `Find` and `FindStr` do not have issues with any of the characters in your string. – Compo May 24 '19 at 17:40
  • @Compo please check my `Edit1` – Black Mamba May 24 '19 at 17:41
  • Both `FindStr /IC:"Conexão falhou." "WinSCP.log"` and `Find /I "Conexão falhou."<"WinSCP.log"` both find the line without issue, as I have already stated. – Compo May 24 '19 at 17:46
  • "*the in use codepage doesn't matter*" is wrong. This is all about encodings. – melpomene May 24 '19 at 17:55
  • @Compo Please see my `Edit 2` – Black Mamba May 24 '19 at 17:55
  • @melpomene I saw that my `Conexão` is beeing converted to `ConexÒo`. How can i fix it? – Black Mamba May 24 '19 at 18:02
  • I don't know what you mean by that, but I would also question your attempt to write any non-trivial logic using batch files. Why use a batch file, one of the most unfriendly coding environments? – melpomene May 24 '19 at 18:03
  • @melpomene Do you recommend C++? or javascript? What is better? – Black Mamba May 24 '19 at 18:05
  • It depends on your constraints. Who is going to use your code? If I wanted a simple "search log file for pattern" script, just for myself, I'd probably use Perl. – melpomene May 24 '19 at 18:06
  • The standard font and codepage you are using in cmd.exe is having issues with `Echo`ing the character, `ã` but that has no effect at all on your `FindStr` command, it is looking for the correct character and finding it without issue. Your only issue seems to be that you're wanting any output of that character to look like `ã` instead of `Æ`. – Compo May 24 '19 at 18:10
  • @Compo What are you talking about? – melpomene May 24 '19 at 18:12
  • cmd.exe is showing `Æ`, instead of `ã`. `ã` is outside of the standard character set code points, it sits at code point 198 in codepage 850, and codepoint 132 in codepage 860. The character they need to use in their echo, should actually be `Æ` which in codepage 850, _(which I assume they're using)_, sits at code point 146. Like I said before, currently, only the output to `cmd.exe` is affected, not the functionality of the script. – Compo May 24 '19 at 18:52
  • Dude, the screenshot literally shows `findstr` not finding anything. You don't even know what encoding the log file is in. – melpomene May 24 '19 at 18:53
  • @melpomene, the log file has been posted, I've ran Find and FindStr against it and both of those output the line. The problem is not with `findstr.exe` it may be with the codepage and/or the script/log file encoding, but that isn't `FindStr`'s fault. – Compo May 24 '19 at 18:57
  • Let us [continue this discussion in chat](https://chat.stackoverflow.com/rooms/193902/discussion-between-melpomene-and-compo). – melpomene May 24 '19 at 19:02
  • Well guys, the fight is interesting :D but i need know how can i solve my problem. I can't change the codepage of the `.log` – Black Mamba May 24 '19 at 19:02
  • 2
    Just test "falhou"! – SachaDee May 24 '19 at 19:16
  • @I'mNotHere You haven't answered my question: Why a batch file? Also, what encoding is your log file in? – melpomene May 25 '19 at 05:09
  • @melpomene just changed the language of the WinSCP to english. So it worked fine without special character. I did the code in batch because it is the only programming language that i know a little bit. – Black Mamba May 25 '19 at 19:56
  • @Compo - See [my answer](https://stackoverflow.com/a/56345556/1012053). There is a code page issue, and the FINDSTR can fail when the non-ASCII search is provided on the command line. – dbenham May 28 '19 at 16:22

1 Answers1

3

The exact behavior you see depends a bit on what code page your text file is using. Assuming your file uses code page 1252 - Latin (Western European), then ã is 0xE3 (decimal 227).

The reason your FINDSTR fails is explained at What are the undocumented features and limitations of the Windows FINDSTR command? under the section Character limits for command line parameters - Extended ASCII transformation. There it explains how FINDSTR transforms (corrupts) many non-ASCII command line characters into an ASCII value.

If you read the referenced section, you will see that character 227 is transformed into 112, which corresponds to the letter p. So your FINDSTR command is looking for the wrong string.

The only way to use FINDSTR to search for your string is to put the search string in a text file and use the /g:file option. FINDSTR does not corrupt characters when using the /G option.

If the contents of "search.txt" is a single line Conexão falhou, then the following command will match the correct lines:

findstr /I /L /G:search.txt WinSCP.log

That being said, the way the string is displayed may be incorrect, depending on your active code page. My machine defaults to code page 437, so ã is displayed as π on my machine. Either way, the character code is 0xE3. If you pipe the results of the FINDSTR to a file, you should see the correct result.

If you really want to put the search string on the command line, then you can explicitly specify a regular expression search even though you use /C by adding the /R option. You can then use . to match any character at the offending position.

findstr /I /R /C:"Conex.o falhou" WinSCP.log

Another option is to use the FIND command instead:

find /I "Conexão falhou" <"WinSCP.log"

Though on my machine I need the following due to active code page 437

find /I "Conexπo falhou" <"WinSCP.log
dbenham
  • 127,446
  • 28
  • 251
  • 390