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).
Related
While using the ESAPI executor to run a simple command such as:
C:\\Windows\\System32\\cmd.exe /c echo test >> D:\\wow\\test.txt
while the C:\Windows\System32\cmd.exe is the executable file.
and the /c echo test >> D:\wow\test.txt are parameters.
The problem is that the codec ruins the operator >> (which means avoiding it or referring to it as a String. so the output will be just be printing the "test >> D:\wow\test.txt".
The codec is doing exactly what it should be doing. Maybe an overly simple example would make that more clear as to why this is the correct behavior.
Let's suppose you have a web application where you have a user upload a document and then you run a spell-check on it for them and send them back the corrected results. For sake of simplicity, left's assume that you have set the current working directory to be specific to each user using your service and that you have a "spellcheck.bat" that takes a single filename as an argument and you planned to execute the string:
C:\Windows\System32\cmd.exe /c C:\spelling\spellcheck.bat userFilename > spelling-errors.txt
where userFilename is the name of the users uploaded file. Your intent is to run spellcheck.bat with the user's uploaded file and filename and the read and display the 'spelling-errors.txt' file back to the user. (IRL, that would probably be a temp file in a different directory, but I want to make this simple.)
So what happens if 'userFilename' contains a '>' character? Surely you want that quoted appropriately, do you not? Because otherwise an attacker might be able to overwrite some file that you don't want to be overwritten, including things like your web.xml or other configuration / properties files. Because running something like (say)
C:\Windows\System32\cmd.exe /c C:\spelling\spellcheck.bat myDoc.txt >sucker.txt > spelling-errors.txt
is going to create 'sucker.txt' and if that filename exists, it will be truncated and replaced by the output of "spellcheck.bat myDoc.txt". That is probably NOT what you want.
So preventing file I/O redirection operations via '<', '<<', '>', and '>>' is intended. If you really want to allow them (and I recommend against it), then you will have to parse your own command string based on what you want to allow.
Also, while I'm not sure it is true for Window's cmd prompt shell, it certainly is true for *nix shells that one can also do command execution in the redirection as part of the file redirection. For example, in bash, I can do something like this
cat < $(ls foo)
and if the file 'foo' exists, the 'ls foo' command will list the output foo, so this command becomes:
cat < foo
and we just end up taking stdin for the 'cat' command from the file 'foo'. But an attacker could do something much more nefarious with it. Of course, the OS codec also prevents '$(...)' style command substitutions, but I hopefully have made my point.
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?
I'm trying to do loop through the current directory that the script resides in, which has a bunch of files that end with _list.txt I would like to grep each file name and assign it to a variable and then execute some additional commands and then move on to the next file until there are no more _list.txt files to be processed.
I assume I want something like:
while file_name=`grep "*_list.txt" *`
do
Some more code
done
But this doesn't work as expected. Any suggestions of how to accomplish this newbie task?
Thanks in advance.
If I understand you problem correctly, you don't need a grep. You can just do:
for file in *_list.txt
do
# use $file, like echo $file
done
grep is one of the most useful commands of Unix. You must comprehend it well; see some useful examples here. As far as your current requirement, I think following code will be useful:
for file in *.*
do
echo "Happy Programming"
done
In place of *.* you can also use regular expressions. For more such useful examples, see First Time Linux, or read all grep options at your terminal using man grep.
I wrote a script that's retrieving the currently run command using $BASH_COMMAND. The script is basically doing some logic to figure out current command and file being opened for each tmux session. Everything works great, except when user runs a piped command (i.e. cat file | less), in which case $BASH_COMMAND only seems to store the first command before the pipe. As a result, instead of showing the command as less[file] (which is the actual program that has the file open), the script outputs it as cat[file].
One alternative I tried using is relying on history 1 instead of $BASH_COMMAND. There are a couple issues with this alternative as well. First, it does not auto-expand aliases, like $BASH_COMMAND does, which in some cases could cause the script to get confused (for example, if I tell it to ignore ls, but use ll instead (mapped to ls -l), the script will not ignore the command, processing it anyway), and including extra conditionals for each alias doesn't seem like a clean solution. The second problem is that I'm using HISTIGNORE to filter out some common commands, which I still want the script to be aware of, using history will just make the script ignore the last command unless it's tracked by history.
I also tried using ${#PIPESTATUS[#]} to see if the array length is 1 (no pipes) or higher (pipes used, in which case I would retrieve the history instead), but it seems to always only be aware of 1 command as well.
Is anyone aware of other alternatives that could work for me (such as another variable that would store $BASH_COMMAND for the other subcalls that are to be executed after the current subcall is complete, or some way to be aware if the pipe was used in the last command)?
i think that you will need to change a bit your implementation and use "history" command to get it to work. Also, use the command "alias" to check all of the configured alias.. the command "which" to check if the command is actually stored in any PATH dir. good luck
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