Is there any windows command which can be used with cmd prompt to check for disk space use. The report should be detailed in terms of sizes in GB i.e. list out folders with size greater than 1
Also, I wouldn't prefer to use any third party tool. There are restrictions of using any third party software in the particular machine. So a cmd line command would be the best solution.
You should be able to write a custom PowerShell, VBScript, or JScript solution easily enough.
Or you could use my JREN.BAT utility - a hybrid JScript/batch script that is designed to rename files/folders via regular expressions, but it has a /LIST option that can be used to provide custom directory listings. JREN.BAT is pure script that runs natively on any Windows machine from XP onward.
Assuming you have JREN.BAT somewhere within your PATH, then the following command will list folders on the D:\ drive that are at least 1000000000 bytes (decimal GB) in size. Note that the reported size of each folder includes the size of all its children. So if a child is greater than 1GB, then its parent is guaranteed to also be greater than 1GB.
jren "^.*" "lpad((size()/1000000000).toFixed(3),' ')+' '+path()" /s /d /j /list /p "D:\" | findstr /rvc:"^ *0"
The JREN command lists each foder size in GB, followed by the full path. I pipe that to FINDSTR to filter out folders that are smaller than 1GB.
Given that JREN.BAT is a bat file, you must prefix the command with CALL if you want to use it in a batch script.
There are lots of options to specify the root path, exclusion lists, path masks, etc. Full documentation is embedded within the utility.
I believe there is a bug in the current version that causes the command to fail when it tries to access the size of a folder that it does not have access to. I may fix that when I get a chance.
I have a Unix shell script which will kill any process that is accessing a folder:
fuser -k ..\logs\*
Is there a Windows batch script equivalent to this? I am aware of TASKKILL but I'm not sure if it will do what I need. Does anyone know if this is possible with Windows shell?
Not with built-in tools (there is nothing that can enumerate handles), but you can use the Sysinternals Handle tool to get a list of the PIDs that have open handles on a file. You can then parse the output with FOR /F and use TASKKILL to end the processes.
Example:
for /f "skip=4 tokens=3" %i in ('handle ..\logs\') do taskkill /pid %i
skip=4 skips the copyright information in Handle's output and tokens=3 picks out the PID from each line of output. The rest are self-explanatory.
I found a fuser for Windows. Check this link to Sourceforge:
Many would ask, "why not use handle.exe from SysInternals?"
While being a truly excellent utility (as all of SysInternals stuff
is), it falls short -- at least for me -- for a couple of reasons:
It does filename pattern matching. I need it to do exact file matches with partial input. For example, when I'm in the C:\TMP directory, and I'm checking on a file named out.dat, I want it to see if the file C:\TMP\OUT.DAT is being used without having to type full path in. I think even if you type in the full path for handle.exe, it will still do pattern matching.
handle.exe seems to always exit 0. For scripting purposes, I need
it to exit 1 if the file is not being used, but 0 if it is. This is
very useful in scripts.
Why do Windows programs parse command-line switches out of their executable's path? (The latter being what is commonly known as argv[0].)
For example, xcopy:
C:\Temp\foo>c:/windows/system32/xcopy.exe /f /r /i /d /y * ..\bar\
Invalid number of parameters
C:\Temp\foo>c:\windows\system32\xcopy.exe /f /r /i /d /y * ..\bar\
C:\Temp\foo\blah -> C:\Temp\bar\blah
1 File(s) copied
What behavior should I follow in my own programs?
Are there many users that expect to type command-line switches without a space (e.g. program/? instead of program /?), and should I try to support this, or should I just report an error and exit immediately?
What other caveats do I need to be aware of? (In addition to Anon.'s comment below that "debug/program" runs debug.exe from PATH even if "debug\program.exe" exists.)
I think it's actually the DOS shell doing this:
My understanding is that DOS chose to use the forward slash (/) for command-line options (i.e., "DIR /s"), even before DOS supported sub-directories. Later, at the point that they introduced sub-directories, they realized they couldn't use forward slashes as the path separator (as was the standard on UNIX), so they had to use the backslash instead.
Also a factor is that DOS doesn't require a space between the command name and the first parameter. (I.e., "CD\" is the same as "CD \".)
Because of the above, my guess is that it isn't the program that is parsing the command line "incorrectly"-- instead it is the DOS shell that is using "C:" as the executable / command name, and the rest as the command line argument(s). (Of course, a quite test app could verify this, but I'm away from my compiler at the moment.)
I expect that any program doing this would be using GetCommandLine() instead of argv[] to access the command line arguments, and failing to account for the fungibility of / and \ in user-mode paths on Windows.
I have a couple of suggestions that might help. These are the result of a class that I made (and use) just to handle parameters and switches.
I check the argument array to see which delimiter is being used for the path and which is being used for the switches / parameters.
I personally differentiate between switches and parameters using a slash for one and a hyphen for the other.
If a switch is passed that doesn't match any of the expected parameters or switches, I check to see if multiple switches were passed with only one slash. This one has caused and will cause more issues for users if they mistype something. For instance, if I were looking for /d /e /l -or- /del SomeThing and the user inputs /del with the intent of passing the d e and l switches.
In the object, I stuff the switches in a std:: container and the parameter and parameter values in another std:: container which are then made available to the consumer application to process as it sees fit.
I've been working on spooling a bat file from a oracle query that would copy contents from one location to another,
Now that command that are getting generated are of lengths that are greater than 255 characters, e.g
C:> copy x y ( where len (x+y) > 255)
As this is throwing an error, is there a work around to manage this kind of situation to increase that command length?
P.S. Some paths+filenames are of length that are larger that 259 characters, to which I found that say there is less to argue
You could use subst to name the two subdirectories your working from with drive letters. Obviously the are not real, but logical drives then, but you could substantially shorten the paths.
LASTDRIVE=Z
SUBST S: c:\this is a very long path name\source
SUBST T: d:\this is a very long path name\Target
#do whatever you need to, like
copy s:\filename T:\filename
SUBST S: /D
SUBST T: /D
The /D parameter frees the association.
You may want to consider using DBMS_FILE_TRANSFER.COPY_FILE instead of creating a bat file. You can avoid using bat files (which are platform dependent) altogether.
SUBST (has already been proposed)
use 8.3 notation (e.g. C:\Progra~1\ - also has been proposed)
Use this syntax (if you run Command prompt in Windows):
copy \?\c:\verylongpath\verylongname \?\d:\anotherverylongpath\
Try using a .cmd file, not a .bat file unless you are using Win95/98/ME. This could solve the entire problem right there.
If that doesn't do it, you can break a command by preceeding a line break with the cmd-escape char ^ or by wrapping the command in parentheses.
I don't think so; I'd write that to a file maybe.
Probably no, sounds like you're hitting the MAX_PATH limitation. See File Names, Paths, and Namespaces on MSDN.
Possible workaround might be to use the short path equivalents, e.g. C:\Progra~1.
According to the the following article Command prompt (Cmd. exe) command-line string limitation,
On computers running Microsoft Windows XP or later, the maximum length of the string that you can use at the command prompt is 8191 characters. On computers running Microsoft Windows 2000 or Windows NT 4.0, the maximum length of the string that you can use at the command prompt is 2047 characters.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
This question's answers are a community effort. Edit existing answers to improve this post. It is not currently accepting new answers or interactions.
Any recommendations on grep tools for Windows? Ideally ones that could leverage 64-bit OS.
I'm aware of Cygwin, of course, and have also found PowerGREP, but I'm wondering if there are any hidden gems out there?
FINDSTR is fairly powerful, supports regular expressions and has the advantages of being on all Windows machines already.
c:\> FindStr /?
Searches for strings in files.
FINDSTR [/B] [/E] [/L] [/R] [/S] [/I] [/X] [/V] [/N] [/M] [/O] [/P] [/F:file]
[/C:string] [/G:file] [/D:dir list] [/A:color attributes] [/OFF[LINE]]
strings [[drive:][path]filename[ ...]]
/B Matches pattern if at the beginning of a line.
/E Matches pattern if at the end of a line.
/L Uses search strings literally.
/R Uses search strings as regular expressions.
/S Searches for matching files in the current directory and all
subdirectories.
/I Specifies that the search is not to be case-sensitive.
/X Prints lines that match exactly.
/V Prints only lines that do not contain a match.
/N Prints the line number before each line that matches.
/M Prints only the filename if a file contains a match.
/O Prints character offset before each matching line.
/P Skip files with non-printable characters.
/OFF[LINE] Do not skip files with offline attribute set.
/A:attr Specifies color attribute with two hex digits. See "color /?"
/F:file Reads file list from the specified file(/ stands for console).
/C:string Uses specified string as a literal search string.
/G:file Gets search strings from the specified file(/ stands for console).
/D:dir Search a semicolon delimited list of directories
strings Text to be searched for.
[drive:][path]filename
Specifies a file or files to search.
Use spaces to separate multiple search strings unless the argument is prefixed
with /C. For example, 'FINDSTR "hello there" x.y' searches for "hello" or
"there" in file x.y. 'FINDSTR /C:"hello there" x.y' searches for
"hello there" in file x.y.
Regular expression quick reference:
. Wildcard: any character
* Repeat: zero or more occurances of previous character or class
^ Line position: beginning of line
$ Line position: end of line
[class] Character class: any one character in set
[^class] Inverse class: any one character not in set
[x-y] Range: any characters within the specified range
\x Escape: literal use of metacharacter x
\<xyz Word position: beginning of word
xyz\> Word position: end of word
Example usage: findstr text_to_find * or to search recursively findstr /s text_to_find *
Based on recommendations in the comments, I've started using grepWin and it's fantastic and free.
(I'm still a fan of PowerGREP, but I don't use it anymore.)
I know you already mentioned it, but PowerGREP is awesome.
Some of my favorite features are:
Right-click on a folder to run PowerGREP on it
Use regular expressions or literal text
Specify wildcards for files to include & exclude
Search & replace
Preview mode is nice because you can make sure you're replacing what you intend to.
Now I realize that the other grep tools can do all of the above. It's just that PowerGREP packages all of the functionality into a very easy-to-use GUI.
From the same wonderful folks who brought you RegexBuddy and who I have no affiliation with beyond loving their stuff. (It should be noted that RegexBuddy includes a basic version of grep (for Windows) itself and it costs a lot less than PowerGREP.)
Additional solutions
Existing Windows commands
FINDSTR
Select-String in PowerShell
Linux command implementations on Windows
Cygwin
Cash
Grep tools with a graphical interface
AstroGrep
BareGrep
GrepWin
Additional Grep tools
dnGrep
GrepWin is free and open source (GPL)
I've been using grepWin which was written by one of the TortoiseSVN guys. It does the job on Windows...
Update July 2013:
Another grep tool I now use all the time on Windows is AstroGrep:
Its ability to show me more than just the line search (i.e. the --context=NUM of a command-line grep) is invaluable.
And it is fast. Very fast, even on an old computer with non-SSD drive (I know, they used to do this hard drive with spinning disks, called platters, crazy right?)
It is free.
It is portable (simple zip archive to unzip).
Original answer October 2008
Gnu Grep is alright
You can download it for example here: (site ftp)
All the usual options are here.
That, combined with gawk and xargs (includes 'find', from GnuWin32), and you can really script like you were on Unix!
See also the options I am using to grep recursively:
grep --include "*.xxx" -nRHI "my Text to grep" *
PowerShell's Select-String cmdlet was fine in v1.0, but it is significantly better for v2.0. Having PowerShell built in to recent versions of Windows means your skills here will always be useful, without first installing something.
New parameters added to Select-String: Select-String cmdlet now supports new parameters, such as:
-Context: This allows you to see lines before and after the match line
-AllMatches: which allows you to see all matches in a line (Previously, you could see only the first match in a line)
-NotMatch: Equivalent to grep -v o
-Encoding: to specify the character encoding
I find it expedient to create an function gcir for Get-ChildItem -Recurse ., with smarts to pass parameters correctly, and an alias ss for Select-String. So you an write:
gcir *.txt | ss foo
It may not exactly fall into the 'grep' category, but I couldn't get by on Windows without a utility called AgentRansack. It's a GUI-based "find in files" utility with regex support.
It's dead simple to right-click on a folder, hit "ransack.." and find files containing what you're looking for. It is extremely fast too.
Baregrep (Baretail is good too)
PowerShell has been mentioned a few times. Here is how you would actually use it in a grepish way:
Get-ChildItem -recurse -include *.txt | Select-String -CaseSensitive "SomeString"
It recursively searches all text files in the current directory tree for SomeString with case sensitivity.
Even better, run this:
function pgrep { param([string]$search, [string]$inc) Get-ChildItem -recurse -include $inc | Select-String -CaseSensitive $search }
Then do:
pgrep SomeStringToSearch *.txt
Then to really make it magical, add the function alias to your PowerShell Profile and you can almost dull the pain of not having proper command line tools.
Git on Windows = grep in cmd.exe
I just found out installing Git will give you some basic Linux commands: cat, grep, scp and all other good ones.
Install then add the Git bin folder to your PATH and then your cmd.exe has basic Linux functionality!
http://code.google.com/p/msysgit/downloads/list?can=3
I'd recommend AstroGrep.
It's free, open source, and has a simple interface. I use it to search code all the time.
ack works well on Windows (if you've got Perl). I find it better than grep for many uses.
dnGREP is an open source grep tool for Windows. It supports a number of cool features including:
Undo for replace
Ability to search by right clicking on folder in explorer
Advance search options such as phonetic search and xpath
Search inside PDF files, archives, and Word documents
IMHO, it has a nice and clean interface too :)
Cygwin includes grep. All the GNU tools and Unix stuff works great on Windows if you install Cygwin.
I always use WinGREP, but I've had issues with it not letting go of files.
Well, besides the Windows port of the GNU grep, there's also Borland's grep (very similar to the GNU one) available in the freeware Borland's Free C++ Compiler (it's a freeware with command-line tools).
I have successfully used GNU utilities for Win32 for quite some time and it has a good grep as well as tail and other handy GNU utilities for Win32. I avoid the packaged shell and simply use the executables right in Win32 command prompt.
The tail that is packaged is quite a good little application as well.
I'm the author of Aba Search and Replace. Just like PowerGREP, it supports regular expressions, saving patterns for further use, undo for replacements, preview with syntax highlight for HTML/CSS/JS/PHP, different encodings, including UTF-8 and UTF-16.
In comparison with PowerGREP, the GUI is less cluttered. Aba instantly starts searching as you are typing the pattern (incremental search), so you can experiment with regular expressions and immediately see the results.
You are welcomed to try my tool; I will be happy to answer any questions.
I wanted a free grep tool for Windows that allowed you to right click on a folder and do a regex search of every file - without any nag screen.
The following is a quick solution based on the findstr mentioned in a previous post.
Create a text file somewhere on your hard drive where you keep long lived tools. Rename to .bat or .cmd and paste the following into it:
#echo off
set /p term="Search term> "
del %temp%\grepresult.txt
findstr /i /S /R /n /C:"%term%" "%~1\*.*" > "%temp%\grepresult.txt"
start notepad "%temp%\grepresult.txt"
Then browse to the SendTo folder. On Windows 7 browse to %APPDATA%\Microsoft\Windows\SendTo and drag a shortcut of the batch file to that SendTo folder.
I renamed the shortcut to 1 GREP to keep it at the top of the SendTo list.
Things that I'd like to do next with this is pipe the output of findstr through something that would generate an html file so that you could click on each output line to open that file. Also, I don't think it works with shortcuts to folders. I'd have to inspect the parameter and see if it contains ".lnk".
My tool of choice is the appropriately named Windows Grep:
nice simple GUI
supports search and replace
can show the lines around the lines found
can search within columns in CSVs and fixed-width files
UnxUtils is the one I use, and it works perfectly for me...
I used Borland's grep for years, but I just found a pattern that it won't match. Eeeks. What else hasn't it found over the years? I wrote a simple text search replacement that does recursion like grep - it's FS.EXE on SourceForge.
grep fails...
C:\DEV> GREP GAAPRNTR \SOURCE\TPALIB\*.PRG
<no results>
Windows' findstr works...
C:\DEV> FINDSTR GAAPRNTR \SOURCE\TPALIB\*.PRG
\SOURCE\TPALIB\TPGAAUPD.PRG:ffSPOOL(cRPTFILE, MEM->GAAPRNTR, MEM->NETTYPE)
\SOURCE\TPALIB\TPPRINTR.PRG: AADD(mPRINTER, TPACONFG->GAAPRNTR)
\SOURCE\TPALIB\TPPRINTR.PRG: IF TRIM(TPACONFG->GAAPRNTR) <> TRIM(mPRINTER[2])
\SOURCE\TPALIB\TPPRINTR.PRG: REPLACE TPACONFG->GAAPRNTR WITH mPRINTER[2]
Another good choice is MSYS. It gives you a bunch of other GNU utilities to allow you to be more productive.
PowerShell's Select-String is similar. It does not have the same options and semantics, but it's still powerful.
I've been using AJC Grep daily for years. The only major limitation I've found is that file paths are limited to 255 characters and it stops when it encounters one, rather than just issuing a warning. It's annoying but doesn't happen very often.
I use it on 64-bit Windows 7 Ultimate, so its 64-bit credentials are fine.
GREP for Windows
I've been using it forever and luckily it's still available. It's super fast and very small.
If you want a simple-to-use Windows Grep tool, I created one called P-Grep that I have made available for free download from my website: www.adjutantit.com - home menu, downloads.
Windows Grep seemed to have problems with a large number of files, so I wrote my own - which seems more reliable. You can select a folder, right click and send it to P-Grep. The sendto folder gets updated during installation.
I have Cygwin installed on my machine and put the Cygwin bin directory in my environmental path, so the Cygwin grep works like normal in a command line which solves all my scripting needs for grep at the moment.
If none of the solutions is quite what you are looking for, perhaps you could write a wrapper to FindStr that does exactly what you require?
FindStr is pretty good anyway so it should just be knocking a GUI up (if you want it) and providing a few extra features (like combining it with Find to find the count of files which contain a specified string [mentioned above]).
This, of course, assumes you have the requirement, time and inclination to do this!