4

I've a strange problem that I have never seen before in my ~30 years of working with batch files. Given a dummy CMD file such as this:

@echo off
:somelabel
echo Testing something
dir /b
echo All is well.
:end

This mostly runs as expected, but sometimes I get output such as 'ing something' is not recognized as an internal or external command, operable program or batch file.

That's clearly an occurrence where it has chopped off a bit of a line and attempted to execute the rest of it. When this happens, it's always a 'random' fraction of a 'random' line; it's not always line X, or losing Y characters, or occurring where I have a particular character combination. Nor does it affect only echo statements, it could just as well try to execute abel or ir /b.

My system is a fully updated Win2008 R2, running in VirtualBox 5.0.2, running in a fully upgraded Linux Mint, running on a Lenovo ThinkPad. The scripts are all UTF-8 encoded.

... what's going on? How can I avoid this?

KlaymenDK
  • 714
  • 9
  • 31
  • 2
    Are the batch files modified on the fly? Did you disable the virus scanner on the host? – jeb Jan 18 '16 at 14:46
  • They are not modified on the fly, and there is no virus scanner on this virtual machine. – KlaymenDK Jan 18 '16 at 14:55
  • How do you run your batch file exactly? via other tools, in command prompt or by dounle-clicking? what is the text encoding of the batch file? – aschipfl Jan 18 '16 at 15:08
  • The first one is started from an (admin) command prompt window. This one calls others. They are (supposedly, according to Notepad++) all UTF-8 encoded. – KlaymenDK Jan 18 '16 at 15:21
  • 5
    The command line doesn't play nice with UTF-8. Use ANSI instead. – SomethingDark Jan 18 '16 at 15:30
  • If your strings in echo has '&' that you don't know ahead, it will report the not recognized as an internal or external command for the rest of the string after '&' – SomeDude Jan 18 '16 at 16:19
  • @SomethingDark, _really_? Gah, well, okay then, I'll re-encode all my script files to ANSI. _(...mumble mumble stupid Flanders mumble mumble...)_ – KlaymenDK Jan 18 '16 at 18:48
  • @svasa, thanks for the suggestion, but that's definitely not it. – KlaymenDK Jan 18 '16 at 18:49
  • Check for correct line endings... BAT/CMD files *must* have all lines ending with CRLF (Windows-flavor). I've run into this intermittent failure silliness several times when accidentally saving the file with LF line-endings (Unix-flavor). It was horrible to track down. Now, I always add tests to my code repos to check for CRLF endings on all .BAT/.CMD files. – rivy Jan 18 '16 at 21:10
  • @rivy, I don't believe this is true; batch files work with both DOS/Windows (CR+LF) and Unix line endings (LF), because the parser scans for LF to detect lines and it ignores the last character of each line if it is CR; MAC line endings (CR) however do not work, because there is no LF... – aschipfl Jan 18 '16 at 23:31
  • Nope, from long experience, anything except CRLF line endings for DOS/CMD batch files can lead to intermittent failures, though generally it takes longer BAT/CMD files to uncover the failure. LFs alone will not do. Notably, I haven't tested this with any CMD versions after Win7. At that point, I had made the decision to always use CRLFs and moved on... It is possible that Win8+ CMD shells may have fixed this, but I doubt it. – rivy Jan 19 '16 at 03:37
  • 1
    @rivy: Well, it is very simple to test this point. You may post a short example that show this behavior, so we can copy-paste it in a file with lines ending at LF only. This way, we can test if such file fails in our own computers. – Aacini Jan 19 '16 at 07:08
  • Given that it's difficult for me to reproduce, I'll just refer you to this answer by VonC (http://stackoverflow.com/a/232674/43774). Again, things may have changed with newer CMD shell versions, but I wouldn't bet on it. – rivy Jan 19 '16 at 14:09

4 Answers4

1

Well, in my experience there is no way that a normal Batch file may present this behavior. The only way this can happen is if the Batch file is modified while it is running, so the cmd.exe processor continue reading the "next line" of the Batch file, but at that position in the modified file there is a part of another line. The example below show this behavior:

@echo off
:somelabel
(for /F "skip=1 delims=" %%a in (%~NX0) do echo %%a) > temp.tmp
del "%~NX0" & ren temp.tmp "%~NX0"
echo   Testing something
echo All is well.
:end

In this example after the del ... & ren ... line is executed, the next line to execute will be read at the beginning of original position of echo Testing something line, but now at that point there is its ing something part because the first @echo off line was deleted. See this:

@echo offRL
echo   Testing something

In previous scheme the RL letters exemplify the CR+LF control characters, so the next position is at the "ing".

Aacini
  • 65,180
  • 12
  • 72
  • 108
1

Credit goes to @SomethingDark for the comment:

The command line doesn't play nice with UTF-8. Use ANSI instead.

This seems to have resolved the issue (as far as I can be sure with an intermittent problem).

KlaymenDK
  • 714
  • 9
  • 31
  • I had the same problem like you have and when about to see my encoding method, my encoding is already set on ANSI so don't think it is that. I think it is just some sort of bug. Or possibly that when editing the code the cmd can't catch up with the edits, something similar to Aacini answer. This might just be the true reason. If you like this answer, tell me and I will go create an answer on here for it. – Jonathan J. Pecany Jun 12 '20 at 21:33
1

I know this is a couple years late but I actually found the most accurate answer.

I actually did some testing on why it could register only partial code and got the answer. If you are editing the code and run batch while still open, it has a partial chance of only registering partial code. This is actually correct, nothing with encoding although that might be part of it except still does it to me with ANSI but with some testing, I realize that isn't it and that it is because batch cannot catch up with you when editing the code.

I did type a comment on the answer marked as best and said what I think but after further testing on the question I realized the pattern is when editing the code and running the batch file while still open, almost right away it seems to only read partial code.

When you said it seems to work when changing encoding to ANSI, did you just run it or did you edit it and run it at the same time. The main reason I did want to answer this is because my encoding method on a batch file I am working on is in ANSI and still causes the error of partially reading the code. Once I read Aacini answer, it gave me a thought of it and that he is partially correct to KlaymenDK situation.

Do prevent the error of partially reading the code modify and wait a bit than run and if that doesn't work than restart it. If you are planning on publicly posting it, you don't really have to worry about the problem because it would most likely only occur if you edit the code while running it. Nothing that could really be a problem with your code as I know.

  • Thank you for your comment, even late as it is. Alas, I do remember these sessions and I can tell you that "interlaced" editing and running was one of my first thoughts and promptly ruled out. So I remain convinced that this is wonky encoding support from Microsoft, rather than file system caching / timing. – KlaymenDK Jun 13 '20 at 22:08
0

Recently I run into the same problem, although the cause might be different. In my case there was an REM command with text which have special characters in other languange. After I erased the REM command, the problem was solved. For disclosure the problem did not happened in all computers the code was executed, and still dont know why will special characters cause the batch file to execute partial lines.

e_l_m_t_7
  • 61
  • 1
  • 4