Today I wanted to get a list of files in a particular directory. The easiest way to accomplish this is to open a prompt and run a
dir > filelist.txt
I assumed that first the 'dir' command runs and then its output is created. It is THEN redirected to the file.
What is interesting however is that the directory listing inside of 'filelist.txt' includes 'fielist.txt' with zero bytes which was not expected.
Once the command completes 'filelist.txt' actually shows as having 450 bytes (when I run a dir without the redirection, same prompt).
1) Why does 'filelist'txt' show up at all?
2) What is the command prompt doing behind the scenes?
I assumed that first the 'dir' command runs and then its output is created.
Where would the output live in the meantime?
The output is by default displayed on the console, almost immediately after being output by the program.
Now if you redirect the output to a file instead, it is written to that file as it would be written to the console: at the moment the program writes the output.
Even when a command has no output, the file is still created. The console first tries to create the requested output file; if that fails, the requested command won't even be executed.
Related
I have a command line program that produces output that I would like to log to a file.
I know that I can redirect the output of a command (foo.exe for example) to a file using the > operator, but for this current project I need more than just simple output functionality. I would also mention that I can't change any of the code in foo.exe.
I am looking for a command line utility/command that can do the following:
Log the output of a foo.exe to a file
Place a timestamp on each individual output of foo.exe
When the current log file reaches a certain specified size (say 1mb), close the current file and start putting log data in a new file.
In a perfect world the utility would encapsulate the command I wish to execute and log its output, looking something like the following:
log.exe -MaxLogSize=1mb -FileName="FooOutput.log" -Execute="foo.exe"
Any help or suggestions are appreciated!
I was just curious as to why with Windows O/S a simple Ruby file that prints one line to the command prompt can execute correctly from one path, but not the other.
Currently, I have said file in C:\Ruby193\test\lib saved inside the lib folder. When I go to the command prompt and set the path to C:\Ruby193\test\lib, I'd expect to see the code string be printed to the command prompt. However, nothing but an empty line is produced, and if I go up the path and set it to C:\Ruby193\test and execute the ruby file from there, it works just fine.
Does anyone have a sound explanation as to why it works that way? Would this also be the same case for a MAC O/S as well?
I run a batch file as an external tool (by adding it in Tools->External tools) in VS2010 (I've checked the "Use Output Window" option). This batch file performs compilation as in VS command prompt. The project that I'm working on has makefiles for various folders, so I use the mk command to build.
In the batch file, I set up the VS environment and then run the following commands:
cd $directoryWhichContainsFileToBuild
mk
cd main //This directory contains the executable that is to be built
mk
I see the output of the first mk in the Output window but after that it just hangs. I also tried to use an echo after the first mk but even that doesn't get printed in the output window (the ones before it can be seen).
Somewhere I read that there is an issue with VS 2010 output window where it hangs after showing some output, although I couldn't really be sure that that is what's the issue here.
Do I need to enable some other VS setting? Has anybody else encountered this issue?
Thanks.
Update: I unchecked the "Use Output Window" and "Close on exit" option, and I see an extra statement: "Press any key to continue". On doing that however, their is no further processing of the batch file.
Update2: Got it to work by prefixing mk with "call".
Thanks all who tried.
It is always good in batch files to specify executables with full path and file extension instead of just the file name. This avoids often lots of problems.
Here was just mk used instead of mk.bat. Therefore on every compile the command line processor cmd.exe searches for mk.* and then checks if any of the found files have an extension listed in environment variable PATHEXT. The order of file extensions separated by a semicolon in PATHEXT defines the order of execution in case of a directory contains multiple mk.* files.
If a command being specified in a batch file not being an internal command of cmd.exe without path, command line processor searches first for a file with given name in current working directory. This is often one more cause of error. What is the current working directory on execution of the batch file?
Next if no file to execute can be found in current working directory, the command line processor searches in all folders being listed in environment variable PATH separated by semicolons.
So specifying in batch files edited only rarely an external application or another batch file with full path, file name and file extension, in double quotes if necessary because of 1 or more spaces in path or file name, helps command line processor to more quickly execute that application or batch file and avoids problems because of executable not found (unknown command).
Sure, when typing commands in a command prompt window, nobody wants to enter the executables with full path, name and extension. But for batch files it is always good to be not lazy and type files to be executed with full path and extension.
TripeHound has given already the explanation why the observed behavior occurred here.
If a batch file is executed from another batch file without using command call, the command line processor continues batch execution in the other batch file and does never come back. In a C/C++ program this is like using goto with the difference that parameters can be passed to the batch file containing the further commands to be executed next.
But running from within a batch file another batch file with call results in continuation of execution below the line calling the other batch file once the other batch file reaches end, except command exit is used in the called batch file without parameter /B.
So the solution here is using:
cd /D "Directory\Which\Contains\File\To\Build"
call "Path\Containing\Batch\File\To\Build\mk.bat"
rem With mk.bat not changing current working directory change working
rem directory to the directory containing the executable to be built.
cd main
call "Path\Containing\Batch\File\To\Build\mk.bat"
BTW: exit exits command processor, exit /B exits just current batch file. I'll give you three guesses why the parameter is B and not a different letter. Yes, B is the first letter of batch.
Writing as a separate answer instead of an update in the question itself as many readers see the header and skim to the answer: got it to work by prefixing mk with "call". (#TripleHound has also posted the conceptual reason for it in the comment above.)
This seems like I'm missing something obvious but I can't get redirects (>) to work in a .bat / .cmd file.
From the command line, this works as expected and sends the output and error streams to the log file:
doxygen doxygen.config 2>&1 > doxygen.log
Putting the exact same line inside a batch file and running it doesn't work however. It looks like it tries to write the entire command to the log file rather than execute it and then loops??
How do I get output redirects to work inside a bat / cmd file? In case it makes a difference, I am using Win7 and have tried from cmd and powershell.
Perhaps the batch script is calling itself. I would suggest you explicitly specify the extension for the executable your script is calling:
doxygen.exe doxygen.config 2>&1 > doxygen.log
How do I pipe standard error to a file in a DOS batch file? Piping using >> only pipes the standard output and the standard error still goes to the console.
Details of my issue:
I am running WinRAR via command line, in an automated daily backup. And the following example pipes WinRar's output, but not the error output which is what I want most, to winraroutput.txt:
RAR.exe a -esh -r "E:\backup.rar" "D:\*.*" >> winraroutput.txt
The issue is sometimes files are in use and when they are I want to know they were missed in the archive and record this in a .txt file next to each .rar file in case we ever have to go back. The missing files are easily replaced by reinstalling programs so it's no big deal to replace them, as long as we know they are missing. So it's just information that would be great to know, not necessary, in the time of need.
How do I output just the standard error output to the .txt file and, if possible but not necessary, leave the the regular output to the console?
Bonus points:
Bonus points if you can tell me how to delete the file if it's blank (no errors)! Asked here: How do I Detect (and Delete) a File if it is Empty using a Windows Batch File?.
Try this:
command.exe 2>file.txt
Or if you prefer not to see any errors, send it to nul:
command.exe 2>nul
This should leave std::cout on the console.