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.
Related
I have created a custom command entry in the registry to add an item to the Windows Explorer context menu when the user right-clicks on a folder. Here is exactly what the value looks like in the registry:
"C:\Program Files\Directory Switcher\DirectorySwitcher.exe" "%V" "2021.0"
%V returns the current directory. If the directory path has any folders with spaces in the name it causes the path to split into additional command line arguments. To get around this, Microsoft tells you put quotes around it "%V".
The specific issue is that when %V is at the drive root, the backslash in C:\ escapes the end quote and causes the rest of the command line parameters to be parsed incorrectly. For example, at C:\ I get a single argument C:" 2021.0 rather than the expected two of C:\ and 2021.0.
How do I properly encapsulate %V so that it works for normal folder paths and drive roots that end with a backslash? The alternative is to change my program to look for this edge case but I would rather understand how to correct my shell verbs.
(Information about %V can be found at this SuperUser question)
Official Microsoft documentation about shell command strings can be found here
If your program can deal with relative paths, I would enter
"%V\a\.."
resulting in
X:\\a\..
for a root drive, but C# can handle the double backslash.
The idea is: go into a (nonexisting) directory and back up again.
"%V\."
might even be better and shorter.
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 am writing an batch file in Windows to run post-installation scripts, and one of the things that needs to be done is to add a directory to the system path.
The script is working, and it does something like this:
setx Path "%PATH%;c:\path\to\add" -m
This is setting the path correctly, but this script could potentially be run multiple times if the user reinstalls the program.
I would like to search the string for c:\path\to\add so I don't keep adding the same path over and over to the system path. This is pretty trivial in Linux with sed, but I don't know what the command is in Windows. I've found findstr, but this seems to only work on files.
Is this possible in Windows without installing additional software?
EDIT:
I'm using Inno Setup to create the install executable.
At the risk of some downvotes till an expert provides a sound way of doing this,
the below removes the specific path from the environment variable if it exists, so that it can be added again:
set str=%path%
:: str is the same with path
set str=%str:;C:\Path\To\Add=%
:: ";c:\path\to\add" is now removed from str
setx Path "%str%;c:\path\to\add" -m
:: proceed with setting the path
This carries the risk of removing the string if it is in fact actually a part of a path, for instance c:\path\to\add\somefolder. Also if the path actually ends with a \, or it is the first entry and it in fact does not start with ;, etc..
Various forms can be called consecutively to circumvent some of these,
set str=%str:;C:\Path\To\Add\;=;%
set str=%str:;C:\Path\To\Add;=;%
set str=%str:;C:\Path\To\Add\=%
set str=%str:C:\Path\To\Add\;=%
set str=%str:;C:\Path\To\Add=%
But, AAMOF I'n not sure this is a sane way of doing this..
This is my code snippet to find the "cvsnt" path in the PATH variable.
if not "x%PATH:cvsnt=%" == "x%PATH%" goto proceed
set PATH=w:\build-repository\cvsnt\2.5.03-2382;%PATH%
echo Path added
:proceed
The part to look at is
not "x%PATH:cvsnt=%" == "x%PATH%"
First I replace all occurrences of "cvsnt" with an empty string. The result is compared to PATH without replacement of "cvsnt". If they are not equal because of "cvsnt" was replaced then it exists in PATH and the code can proceed.
The starting x before %PATH% is only a placeholder to protect against certain "improper" starting characters. see Batch file: Find if substring is in string (not in a file)
The setx utility has a drawback, it can not handle variables longer than 1024 characters.
I have been wrote a script to handle cases longer than the limit and without a need to install anything. Answered the question here: Set environment variables with NSIS in Window 7
Instead of adding the path each time - you could check if the executable you are looking for can be found within the path using a command like this:
for %f in (cmd.exe) do if [%~$PATH:f]==[] setx Path "%PATH%;c:\path\to\add" -m
Make sure to check for /? to read more about the magic of %~$PATH:f.
This is a bit of a hackish workaround, but follows the logic you expect:
Search the PATH
Conditionally add to the PATH
It never removes anything from the PATH, so there's no fear of screwing up Windows by removing something accidently. Also, it checks the PATH variable directly, so you don't have to worry about another file with the same name that lives somewhere on the PATH.
echo %PATH% > myTmpPath.tmp
find /C /I "c:\path\to\add" myTmpPath.tmp
if %ERRORLEVEL% neq 0 setx PATH "%PATH%;c:\path\to\add"
del myTmpPath.tmp
I hate using temporary files, but it's quick and dirty, and probably safer than removing something from the PATH.
The third line is the only tricky one. Basically, this line tests the outcome of the FIND command above. Rob van der Woude states:
FIND returns an errorlevel of 1 or higher if the search string wasn't found.
He also explains:
Some executables return negative numbers for errorlevels! However, this can be
fixed by using the following code to check for non-zero return codes:
IF %ERRORLEVEL% NEQ 0 ...
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.
What is that one not usually known command in unix and windows that you know?
It is heard that windows contains several hidden applications which sometimes
may be very useful.
linux:
history (history of command line)
mogrify (for all image needs/operations)
screen (for running programs after logging off via ssh)
In widows XP if you have ever tried to do somthing like this
cd \\pc\c$
You will have recieved the error
CMD does not support UNC paths as current directories.
Well you can use UNC paths as long as you map them to a temp drive letter like so.
pushd \\pc\c$
Then when you want to return simply...
popd
Windows:
fdisk /mbr
Saved my life (and system) after a Linux partition went berserk.
Linux:
strace
Came handy getting passwords with classmates running a telnet from a shell I was logged in ;-)
I'm not sure if this counts as unknown, but rsync is invaluable.
In older versions of Windows (XP, in particular), I found the shutdown command invaluable. For example:
shutdown /s /t 3600
will shut down the computer in an hour. Linux, of course, has a similar command (I'd say the majority of Linux users are intimately familiar with "shutdown -h now"), but the Windows equivalent is less well known.
The reason I mentioned older versions of Windows is that in newer ones (Vista I know for sure, don't know about Windows Server 200x) the functionality of shutdown has been hobbled a bit. For example, you can only set a maximum wait time of ten minutes, which makes it useless if you want your computer to shut down in an hour or two, when a download is done.
The hosts file can be used to filter online advertising.
In bash's ~/.bashrc file:
set -o vi
and in ~/.inputrc
set editing-mode vi
set keymap vi
Also, Using !$ to avoid retyping:
ls long/dir/name/i/dont/want/to/repeat/file.txt
rm !$
In Unix: apropos (rough idea of what you want) | less
On Windows XP+:
fsutil, the file system utility. I use this when I have to create test files of a specific size (fsutil file createnew <filename> <length>).
netstat, Displays protocol statistics and current TCP/IP network connections.
netsh, the network services shell; command line hook into all sorts of network info.
reg, the registry shell, for working with the registry from the command line.
on windows i used to like gpedit.msc but i think its only on certain versions of xp
and regedit of course
mmc.exe
you can do amazing things with the bare-bone version of the management console, given admin access to some machines in a network.
In PowerShell, you can:
cd \\server\c$\
In Windows, I use SET alot to get the basic information of the computer easily. There's also: IPCONFIG /FLUSHDNS, IPCONFIG /REGISTERDNS (to clear and reload dns entries), TRACERT (used to trace a path between your location and another on the network/internet), NETSTAT -s -p tcp (for network statistics), and PATHPING (like ping but better!)
I find that findstr is relatively unknown, at least I didn't know about it. It's a rough equivalent to grep, nice when you're not necessarily wanting or needing to install something like mingw or cygwin or even a natively built grep.
c:\Users\logan>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 occurrences 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
For full information on FINDSTR regular expressions refer to the online Command
Reference.
I just thought to put this in as I used it today about on 5 windows XP machines.
systeminfo
Gives you a list of your system details including os, hotfix/updates, hardware and network information. Sure you can get all this information in a lot of other places, either with commands or in the GUI but this is a great command to find out a lot about a machine very quickly.