I have a java program that I am running inside of a command prompt shell which generates a lot of output. Many of the lines start with the word "Prepared" or "prepared", and are not really necessary for me to see when running the program- they actually make it harder to see the data that I am interested in. Is there a way to hide any lines starting with these words while running the program?
Change your program to use log4j or something like it, and then control which levels of message are sent to the console.
you can pipe the output to:
FIND /V /I "string you want to omit"
This will remove all iterations of said string from your output.
myJavaApp | findstr /iv prepared
Related
The windows API provides GetCommandLine() which returns the cooked command line used to start a process.
For instance, if a console application is started with the command:
MyProg.exe > OutputHere
The command line seen by MyProg.exe will not include the portion
> OutputHere
I'd like to somehow get the command line exactly as it was. Is this possible ? and if yes, how ?
Suggestions in C and/or plain (no objects) Delphi greatly appreciated. Creative solutions welcome (hopefully, not requiring ring 0 code.)
Thank you very much for your help.
NOTE: I can tell if the input/output, etc has been redirected but, that is not what I'm looking for. I need the original/uncooked command line.
The redirection or piping of stdin, stdout and stderr is handled the command interpreter, typically cmd.exe. The interpreter parses the command and creates the necessary files and pipes, and then creates the one or more processes needed to implement your command.
The processes that are created have no knowledge of the original command, they only get that part of the command that is not related to piping and redirection.
So what you are trying to do is not possible, at least within your process. The only thing that knows the original command is the command interpreter.
Whether or not you can retrieve the full command line including the pipe commands depends on whether your start the program in a command window or for example using the "Run" command from the Start menu. If you use the "Run" command from the Start menu GetCommandLine actually retrieves the full command line including the redirection commands, but redirection does not work as it seems to be a feature of CMD.EXE.
As others have pointed out, what are you trying to achieve here / why do you need to capture the redirection commands?
This question already has answers here:
How can I echo a newline in a batch file?
(24 answers)
Closed 8 years ago.
When outputting status messages to the console from a Windows batch file, I want to output blank lines to break up the output. How do I do this?
Any of the below three options works for you:
echo[
echo(
echo.
For example:
#echo off
echo There will be a blank line below
echo[
echo Above line is blank
echo(
echo The above line is also blank.
echo.
echo The above line is also blank.
Note: Though my original answer attracted several upvotes, I decided that I could do much better. You can find my original (simplistic and misguided) answer in the edit history.
If Microsoft had the intent of providing a means of outputting a blank line from cmd.exe, Microsoft surely would have documented such a simple operation. It is this omission that motivated me to ask this question.
So, because a means for outputting a blank line from cmd.exe is not documented, arguably one should consider any suggestion for how to accomplish this to be a hack. That means that there is no known method for outputting a blank line from cmd.exe that is guaranteed to work (or work efficiently) in all situations.
With that in mind, here is a discussion of methods that have been recommended for outputting a blank line from cmd.exe. All recommendations are based on variations of the echo command.
echo.
While this will work in many if not most situations, it should be avoided because it is slower than its alternatives and actually can fail (see here, here, and here). Specifically, cmd.exe first searches for a file named echo and tries to start it. If a file named echo happens to exist in the current working directory, echo. will fail with:
'echo.' is not recognized as an internal or external command,
operable program or batch file.
echo:
echo\
At the end of this answer, the author argues that these commands can be slow, for instance if they are executed from a network drive location. A specific reason for the potential slowness is not given. But one can infer that it may have something to do with accessing the file system. (Perhaps because : and \ have special meaning in a Windows file system path?)
However, some may consider these to be safe options since : and \ cannot appear in a file name. For that or another reason, echo: is recommended by SS64.com here.
echo(
echo+
echo,
echo/
echo;
echo=
echo[
echo]
This lengthy discussion includes what I believe to be all of these. Several of these options are recommended in this SO answer as well. Within the cited discussion, this post ends with what appears to be a recommendation for echo( and echo:.
My question at the top of this page does not specify a version of Windows. My experimentation on Windows 10 indicates that all of these produce a blank line, regardless of whether files named echo, echo+, echo,, ..., echo] exist in the current working directory. (Note that my question predates the release of Windows 10. So I concede the possibility that older versions of Windows may behave differently.)
In this answer, #jeb asserts that echo( always works. To me, #jeb's answer implies that other options are less reliable but does not provide any detail as to why that might be. Note that #jeb contributed much valuable content to other references I have cited in this answer.
Conclusion: Do not use echo.. Of the many other options I encountered in the sources I have cited, the support for these two appears most authoritative:
echo(
echo:
But I have not found any strong evidence that the use of either of these will always be trouble-free.
Example Usage:
#echo off
echo Here is the first line.
echo(
echo There is a blank line above this line.
Expected output:
Here is the first line.
There is a blank line above this line.
There is often the tip to use 'echo.'
But that is slow, and it could fail with an error message, as cmd.exe will search first for a file named 'echo' (without extension) and only when the file doesn't exists it outputs an empty line.
You could use echo(. This is approximately 20 times faster, and it works always. The only drawback could be that it looks odd.
More about the different ECHO:/\ variants is at DOS tips: ECHO. FAILS to give text or blank line.
From my understanding of findstr, it looks for text within files. What, then, is making it search for a pattern in the filename itself?
dir | findstr "test[0-9][0-9][0-9]test"
Does the pipe alter its behavior? Someone explain the inner working of this. I know it works, but I don't understand how it works. Thanks.
The pipe redirects the standard output of dir to the standard input of findstr, this works as findstr will use either the arguments passed to it on the command line, or anything passed to it via stdin.
I don't know findstr itself, but it looks to be similar to grep.
What it does here is take the output of dir (the directory listing) and search for some string in that output. It then only outputs those lines that match (effectively searching in the directory listing).
This process (called piping) is pretty common in Unix-like operating systems. As you see it also exists on Windows (and DOS before that).
I inherited some large batch files, and I'd like to rewrite them to a more "developer friendly" language.
I'd like to find out the following things:
what other scripts it calls
what other processes it starts
what files does it write to
what environment variables it uses, which ones does it set
For the last point, I'm aware I can do this before I start:
set > original_environment.txt
And after I run it, I can do this:
set > new_environment.txt
and just do a diff between them ... but I'll probably miss some variables that may be unset when the script finishes ( or even all of them if the script's ran under setlocal ).
Is there any way of finding all those things without me adding tons of echo statements throughout the script code?
Is there such a tool that can monitor the process started by the batch file and tell me everything it did?
You can just look inside them and figure out what they do.
You can also remove any echo off statements and # preceding commands; that way every command is output before it's run and you can redirect the output to a file to study it later.
There is no debugging tool for batch files that I am aware of—but I contemplated writing one once.
There is no direct way to do it. But it's not impossible to create one.
Since Windows XP/Vista/7 came out the good'ole set of DOS batch commands has been greatly upgraded, although not many uses them or even RTFM (FOR /??)
So here I give you, a simple pure-batch TRACER that utilizes the FOR /F line-parsing switch:
#ECHO OFF
FOR /F "delims=" %%L IN (%1) DO (
CLS
ECHO __________________________________________________
ECHO ENV. VARIABLES *BEFORE*
SET
ECHO __________________________________________________
ECHO LINE
ECHO %%L
ECHO __________________________________________________
ECHO Hit any key to execute the line ...
PAUSE > NUL
ECHO __________________________________________________
ECHO EXECUTE
%%L
ECHO __________________________________________________
ECHO Hit any key to fetch the next line...
PAUSE > NUL
)
ECHO END OF FILE
You can take it as a start and modify it as you go.
Here's how you'd use it:
DEBUG.BAT TEST.BAT
And I'll also give you a test file to try it out:
#ECHO OFF
ECHO Hello World!
SET aaa=1
SET bbb=2
ECHO Doing step 2
SET aaa=
SET ccc=3
ECHO Doing step 3
SET bbb=
SET ccc=
ECHO Finished!
This DEBUG.BAT thing, however, due of its simplicity, has some limitations BUT which can be worked around if you slap enough BATCH-fu in there.
It cannot process multi-line blocks :: This can be worked around by having the FOR commands parse tokens and build the lines as they come in, and IF it encountered an open parenthesis, just dump the parenthesis block content to a temporary file and then call itself on the tempfile e.g. DEBUG tempfile.bat
It cannot process jumps :: You can of course, do an IF check for a GOTO label then do a FOR /F to parse out label itself, then maybe utilize the second argument %2of DEBUG.BAT to specify the label to jump to, in which case if this very argument is specified you'd just spin the FOR /F until the desired label came into view and then proceeds with normal debugging on the next line.
There is too much information from a single SET :: Just do what you did with the SET > before.txt and after thing but do it on each line and then run a cmd-line DIFF tools on the files (plenty are available on the net). Then you'll get a DIFF of each variable that has changed since last step. You might even be able to avoid the env. variables mess altogether by slapping in SETLOCAL and ENDLOCAL in there and then you'd get just the local SETs ... but YMMV.
Those are some. If you've found some show-stopping limitation or whatever enhancements would help you nail that last bug, feel free to just let me know (via the comments) and I'll try to help you if I can.
Hope this helps.
No, there is no way to debug old style batch files. You can, however, just get rid of all the ECHO OFF statements, and then all the commands and output will be echo'd to the console when you run them.
If you are willing to spend some money you should take a look at the Running Steps batch file IDE and its debugging capabilities.
I didn't test it, but it has some features that might help you in your task:
...
Visual Studio-like debugging environment.
Rich set of debugging commands (step into, step over, step out, and more)
Rich Project analyzer to find your errors and warnings in no time.
Integrated support for delayed-expanded environment
variables.
Multi-type breakpoint definitions to fit your multiple debugging needs.
Complex pipeline and redirection support with multi-color highlighting.
Environment variable visualization and modification support.
Expanded information window for true variable definition visualization.
Impressive 'For command' unrolling feature.
Interactive callstack and Parameters window.
...
They also offer a trial version.
Is there a way, to send commands to another command-line program?
'Cause i have a special command-line program, but I can't send commands to it using syntax like program.exe something_to_do
the program executes something like this: ("here syntax" is where i want to input text to and also enter to start)
TheWhateverCommandLineProgram
Version 1.1
Give an option: "here syntax"
the program in code looks something like this:
echo TheWhateverCommandLineProgram
echo Version 1.1
Set opt=
set /p opt=Give an option:
if %opt%==command1 goto com1
if %opt%==command2 goto com2
...
Well, i guess so cause it wasnt me who made it (btw: off course its not called TheWhateverCommandLineProgram)
If you just want to give keyboard input to a commandline program you can just use echo and pipe it:
echo some text | program.exe
If you need more lines, then write them to a file and use input redirection:
echo one line > file
echo second line >> file
program.exe < file
I'm not 100% sure I understand what you're looking for. Here's two options:
You have two windows, each running a batch program. Let's say they are called myscript1.bat and myscript2.bat. You want to send a set of commands from myscript1.bat to be executed by myscript2.bat
You have a single batch script named myscript.bat, which executes a single program named program.exe. You want program.exe to execute some commands, or do some something.
Are either of these what you're looking for? Here's some idea:
Make myscript1.bat create a third file, mycommands.bat. Once myscript2.bat sees the file mycommands.bat exists, it will execute it and delete it. (Wow. Lame.)
Use Windows Scripting Host command (it's built in to Windows since Win2K) or Powershell (usually on most computers nowadays, if they have been updated). Either of these can send keystrokes to another program. Using those keystrokes, you can control the other program.
In what form does the other program take input? From the command prompt?
If the latter then I recommend Autohotkey: http://www.autohotkey.com/
You can use Autohotkey as a bridge and it will send the command as keypresses to the window of the other batch file.
You can ask for help in their forum. They are quite helpful.