4 ms·

That is just plain incorrect, local variables would not work in scripts if that were the case.

vortico 7y ago
I definitely remember both reading about and experiencing this years ago, but I can't seem to find a source and it's driving me crazy (will search more later). I imagine variables would persist in the shell's memory. I'm talking about an implementation detail of the batch shell script parser/runner. I recall that some people would put GOTO statements to jump across large comment blocks in the days where reading a few KB was noticeable.
- concerned_user 7y ago
  It can be correct if you are talking about subprocesses/subshells of another batch script/command then yes, separate shell process will be spawned in each iteration.
  - vortico 7y ago
    No, I recall reading that the batch processor closes/re-opens the file, scans for n carriage returns where n is the current line number, executes that line, and repeats. These are the sources I found. http://xset.tripod.com/tip3.htm http://xset.tripod.com/tip3.htm "COMMAND.COM reads and executes batch files one line at a time; that means that it reads one line, execute it and rereads the file from the beginning to the next line." Perhaps this is a really old version of COMMAND.COM? Perhaps it's poorly stated but actually meant that it "rereads the file from the beginning of the next line to the next line". https://docs.microsoft.com/en-us/windows/win32/fileio/local-caching https://docs.microsoft.com/en-us/windows/win32/fileio/local-... "Command processors read and execute a batch file one line at a time. For each line, the command processor opens the file, searches to the beginning of the line, reads as much as it needs, closes the file, then executes the line." This also seems to agree with my original claim. I tested this with a batch script generated by print("@echo off") for i in range(1000): for j in range(1000): print("rem hello world") print(f"echo {i}") and ran it using COMMAND.COM in a Windows 95's VM. It appears to run in linear time. Either COMMAND.COM was fixed, or both sources are incorrect.
    - ygra 7y ago
      Seeking to a file offset is a constant-time operation (assuming no fragmentation), so re-opening the file and skipping to where you left off isn't that bad. And you can certainly write self-modifying batch files, but only appending at the end is safe, not changing lines before you're currently executing.
      - vortico 7y ago
        >re-opening the file and skipping to where you left off That's what Windows does now. But I think in the past it wasn't that way (as suggested by the sources). In my tests it appears that the command processor caches the byte offsets of each line, so it's possible to GOTO any line in the past without rescanning the whole file.

I definitely remember both reading about and experiencing this years ago, but I can't seem to find a source and it's driving me crazy (will search more later). I imagine variables would persist in the shell's memory. I'm talking about an implementation detail of the batch shell script parser/runner. I recall that some people would put GOTO statements to jump across large comment blocks in the days where reading a few KB was noticeable.

concerned_user 7y ago
It can be correct if you are talking about subprocesses/subshells of another batch script/command then yes, separate shell process will be spawned in each iteration.
- vortico 7y ago
  No, I recall reading that the batch processor closes/re-opens the file, scans for n carriage returns where n is the current line number, executes that line, and repeats. These are the sources I found. http://xset.tripod.com/tip3.htm http://xset.tripod.com/tip3.htm "COMMAND.COM reads and executes batch files one line at a time; that means that it reads one line, execute it and rereads the file from the beginning to the next line." Perhaps this is a really old version of COMMAND.COM? Perhaps it's poorly stated but actually meant that it "rereads the file from the beginning of the next line to the next line". https://docs.microsoft.com/en-us/windows/win32/fileio/local-caching https://docs.microsoft.com/en-us/windows/win32/fileio/local-... "Command processors read and execute a batch file one line at a time. For each line, the command processor opens the file, searches to the beginning of the line, reads as much as it needs, closes the file, then executes the line." This also seems to agree with my original claim. I tested this with a batch script generated by print("@echo off") for i in range(1000): for j in range(1000): print("rem hello world") print(f"echo {i}") and ran it using COMMAND.COM in a Windows 95's VM. It appears to run in linear time. Either COMMAND.COM was fixed, or both sources are incorrect.
  - ygra 7y ago
    Seeking to a file offset is a constant-time operation (assuming no fragmentation), so re-opening the file and skipping to where you left off isn't that bad. And you can certainly write self-modifying batch files, but only appending at the end is safe, not changing lines before you're currently executing.
    - vortico 7y ago
      >re-opening the file and skipping to where you left off That's what Windows does now. But I think in the past it wasn't that way (as suggested by the sources). In my tests it appears that the command processor caches the byte offsets of each line, so it's possible to GOTO any line in the past without rescanning the whole file.