7

I have a batch file (in windows XP, with command extension activated) with the following line:

for /f %%s in ('type version.txt') do set VERSION=%%s

On some computer, it works just fine (as illustrated by this SO question), but on other it kills cmd (the console window just closes)

Why ?

Note: the computers seem to have a similar configuration: XpSP2, the user has administrative right, no 'Command processor" defined in HKEY_CURRENT_USER\Software\Microsoft\Command Processor...

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • 1
    Thanks for the edit, Oli: I wanted to tag that question 'script', but the auto-completion on SO tag tricked me ;) – VonC Nov 04 '08 at 09:42

5 Answers5

5

I got a first empiric answer:

for /f %%s in (version.txt) do ...

works just fine, on every computer.

It seems for /f works with a filename, not with any dos command like 'type filename'.

However, it is not true for all my client's computer (on some, the 'type filename' works fine)

If you want 15 (easy ?) points ;-), you can leave an answer to the question:
why 'for /f' sometime does not work with anything else than a file name. And why it just closes the DOS session ?

Edit: 3 years later(!), barlop faced a similar situation, detailed in the question "for /f closes cmd prompt immediately?". His conclusion was:

COMSPEC did get listed when doing SET+ENTER.
So, I opened the environment variables window, and saw COMSPEC was not listed under user or system variables. I added it to System Variables, started a command prompt, and it seems to work fine.

This thread on ss64 forum, mentioned by Andriy M in his answer to barlop's question, contains the details.

The shelling out in the "for" loop to complete 'dir' (or whatever command you've asked to complete) requires ComSpec to be set in order to reload the cmd window.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment\ComSpec=
%SystemRoot%\system32\cmd.exe
Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Maybe offering 15 points does not cut the mustard? :-) Honestly, I failed to reproduce the behavior you mentioned. Can you post some more details? – Tomalak Nov 04 '08 at 13:14
  • Thank you, Tomalak, for having taken the time to check that issue out. The thing is, I have not much details beside the one laready mentionned: on one client's PC, on a DOS session, I type a "for /f %s in ('type afilename.txt') do echo %s" and... "poof" no more DOS windows... – VonC Nov 04 '08 at 14:16
  • I will pursue this, but I wanted to check with the SO community if that problem had already be seen before. Apparently not. I will post any conclusion I may find. – VonC Nov 04 '08 at 14:17
  • I do not have any precise answer from our own support team, so I "accept" my own answer for now (no reputation gain whatsoever) – VonC Jan 06 '09 at 12:36
  • @VonC Why did you accept your own answer when it doesn't answer it? – barlop Aug 30 '11 at 08:15
  • @VonC unless you can prove it is unsolvable, which would be a good answer, surely it should just not have an accepted answer. Your "answer" is just an elaboration of the question. If that's a good idea then the system may as well repeat the question and accept it as an answer after x amount of time has passed. If it hasn't got an answer on the page, it -should- be in the "no answers" list along with no doubt hundreds or thousands of others that should be there because they have not been answered. – barlop Aug 30 '11 at 10:41
  • @VonC Putting aside your odd practice of accepting a non answer that just repeats the question, and draws attention to a non answer. The question is infact answered, here , somebody asked and a solution was posted that worked for him http://stackoverflow.com/questions/7236499/for-f-closes-cmd-prompt-immediately – barlop Aug 30 '11 at 10:43
1

Regarding the command extensions, there is the possibility CMD.EXE is called with /E:OFF so that command extensions are disabled (even though enabled in the registry).

If using command extensions shell options in a script, it is HIGHLY suggested that you do the following trick at the beginning of your scripts.

-- Information pasted from http://www.ss64.com/nt/setlocal.html

SETLOCAL will set an ERRORLEVEL if given an argument. It will be zero if one of the two valid arguments is given and one otherwise.

You can use this in a batch file to determine if command extensions are available, using the following technique:

VERIFY errors 2>nul
SETLOCAL ENABLEEXTENSIONS
IF ERRORLEVEL 1 echo Unable to enable extensions

This works because "VERIFY errors" sets ERRORLEVEL to 1 and then the SETLOCAL will fail to reset the ERRORLEVEL value if extensions are not available (e.g. if the script is running under command.com)

If Command Extensions are permanently disabled then SETLOCAL ENABLEEXTENSIONS will not restore them.

Philibert Perusse
  • 4,026
  • 5
  • 24
  • 26
  • Thank you for this detailed answer... still no luck. That DOS windows still closes itself, even though the ENABLEEXTENSIONS is activated successfully... – VonC Nov 07 '08 at 16:23
0

Is it that the file doesn't have an extension and thus the cmd treats it like a directory that doesn't exist?

Keng
  • 52,011
  • 32
  • 81
  • 111
  • Actually, the file does exist and has an extension (filename was just a foobar name) : "for /f %s in ('type afilename.txt') do echo %s" triggers the immediate closing of the DOS windows – VonC Nov 04 '08 at 14:30
0

If command extensions are disabled, the (set) parameter to the for command must be a file.

If command extensions are enabled, the (set) parameter to the for command may be a file, a string, or a command.

Command extensions are disabled on the client's computer where the 'type filename' set fails.

For infomation on enabling or disabling command extensions, type "cmd /?"

Craig Lebakken
  • 1,853
  • 15
  • 10
  • He mentioned command extensions being activated (consistently, I guess). – Tomalak Nov 04 '08 at 14:33
  • Yes, but from Craig's remark, I will check again that. To be sure, Craig, could you precise the criteria validating the fact command extension is or is not enable ? – VonC Nov 04 '08 at 14:38
  • Darned... I just checked and re-check the registry, command extensions are indeed enabled, and no other special values stand out. The windows event does not display anything out of the ordinary. cmd /E:ON still closes itself on a for /f in ('command') command-line... frustrating ;) – VonC Nov 04 '08 at 15:22
  • If I am not mistaken you there is the possibility CMD.EXE is called with /E:OFF so that command extensions are disabled. I suggest you run these in the DOS shell: VERIFY errors 2>nul SETLOCAL ENABLEEXTENSIONS IF ERRORLEVEL 1 echo Unable to enable extensions – Philibert Perusse Nov 07 '08 at 01:38
0

Wait...could it be that you have the apostrophes around the file name? MS is saying that filenamesets get double-quotes and literal strings get apostrophes.

for /F ["usebackqParsingKeywords"] {%% | %}variable in ("filenameset") do command [CommandLineOptions]

for /F ["usebackqParsingKeywords"] {%% | %}variable in ('LiteralString') do command [CommandLineOptions]

for /F ["usebackqParsingKeywords"] {%% | %}variable in (`command`) do command [CommandLineOptions]

Unless of course you're doing this.

You can use the for /F parsing logic on an immediate string, by wrapping the filenameset between the parentheses in single quotation marks (that is, 'filenameset'). Filenameset is treated as a single line of input from a file, and then it is parsed.

Keng
  • 52,011
  • 32
  • 81
  • 111