I have done this .bat file to copy some maps and textures from my USB drive to the valve installation path, but it doesn't work, why?
#echo on
COPY \CS-Fix\Maps\*.* %PROGRAMFILES%\Valve\Half-Life\cstrike\maps
COPY \CS-Fix\Textures\*.* %PROGRAMFILES%\Valve\Half-Life\cstrike\
ERASE %PROGRAMFILES%\Valve\Half-Life\cstrike\maps\de_shipment.bsp
pause
What is wrong?
The %PROGRAMFILES% indicates that you're using Windows, not MS-DOS.
MS-DOS was Microsoft's variant of DOS, an operating system that preceded Windows.
Anyway, two main problems are apparent to my tired eyes:
Paths that possibly have spaces and are not quoted.
Probably no write access to the relevant folders.
To fix the first problem, quote paths.
The second problem is only a problem in Windows Vista and later.
You can probably fix that by running the batch file from an elevated command prompt.
I assume that the batch file is sitting on and being run from your thumb drive.
Do the paths need to be quoted?
#echo on
COPY "\CS-Fix\Maps\*.*" "%PROGRAMFILES%\Valve\Half-Life\cstrike\maps"
COPY "\CS-Fix\Textures\*.*" "%PROGRAMFILES%\Valve\Half-Life\cstrike\"
ERASE "%PROGRAMFILES%\Valve\Half-Life\cstrike\maps\de_shipment.bsp"
pause
You might need to quote things. %PROGRAMFILES% probably expands out to C:\Program Files. Try something like this:
#echo on
COPY "\CS-Fix\Maps\*.*" "%PROGRAMFILES%\Valve\Half-Life\cstrike\maps"
COPY "\CS-Fix\Textures\*.*" "%PROGRAMFILES%\Valve\Half-Life\cstrike\"
ERASE "%PROGRAMFILES%\Valve\Half-Life\cstrike\maps\de_shipment.bsp"
pause
Related
I am currently trying to write a batch program that installs a module named SetConsolePath.psm1 at the correct location. I am a beginner with Batch and I have absolutely no powershell experience.
Through the internet, I have learned how to display PSModulePath with powershell -command "echo $env:PSModulePath.
How can I, via .bat file, move SetConsolePath.psm1 from the desktop to the location displayed by powershell -command "echo $env:PSModulePath?
Thank you in advance, and I apologize for my lack of experience.
Before I answer, I must out that you do not want to copy PowerShell module files directly to the path pointed by PsModulePath. You really want to create a folder inside PSModulePath and copy the files there instead.
The prefix env in a Powershell variable indicates an environment variable. $env:PSModulePath is actually referring to the PSMODULEPATH environment variable. On the command line, and in batch files, environment variables can be displayed by placing the name between percent symbols. (In fact, you could have displayed this value by typing echo %PSMODULEPATH% instead.)
To reference the desktop folder, have a look at this answer, which shows you how to use another environment variable, USERPROFILE.
Therefore, to copy the file from the desktop directory to the path specified in PSModulePath, you would do this:
COPY "%USERPROFILE%\Desktop\SetConsolePath.psm1" "%PSMODULEPATH%"
And, as I warned earlier, you really should copy the file to a folder underneath PsModulePath. So what you really want is:
IF NOT EXIST "%PSMODULEPATH%\MyNewFolder" MKDIR "%PSMODULEPATH%\MyNewFolder"
COPY "%USERPROFILE%\Desktop\SetConsolePath.psm1" "%PSMODULEPATH%\MyNewFolder"
I have a Perl script that needs to delete a directory with all its contents.
Sometimes this directory contains a junction point into another directory. If I rmtree() naively, the rmtree() call will also delete all the files inside the target folder of the junction. I'm looking for a way to not do that, and instead just remove the junction.
Non Perl solutions would also be appreciated.
I just typed "junction point" into Google and found my way to
http://en.wikipedia.org/wiki/NTFS_junction_point
Command Prompt (cmd.exe)
The dir
command in Windows 2000 or later
recognizes junction points, displaying
instead of in
directory listings (use dir with the
/A or /AL command-line switch).
Any
commands that would normally affect
files inside a normal directory will
act the same here. Thus the command
del myjunction should not be used —
this will just delete all the files in
the targeted directory.
The commands
rmdir and move work fine with
junctions, with the caveat that move
won't let the junction move to another
volume (as opposed to Windows
Explorer, as mentioned above.)
The
rmdir command is safe in that it only
deletes the junction point, not the
targeted files. Whilst walking through
the directory with the command line
interface, files can be deleted, but
unlike explorer, directories can also
be deleted (using rmdir /s dirname for
example.)
Using the linkd command with
the /d switch is a safe way to delete
junction points.
From what I can see you can, for example, use dir and grep the output for <JUNCTION> or use the Windows rmdir. I think you can use either of these from Perl via system.
To find out where are the reparse points (or "junction points", if you will):
dir /a:l /b > myjunctions.txt
Will show all reparse points in the current directory. You can add /s, but beware that reparse points inside reparse points will be listed as well.
Suppose myjunctions.txt contains the line x:\subdir\foo. To remove it, you issue
fsutil reparsepoint "x:\subdir\foo"
And voilá! Your junction point is gone, and the original directory is untouched!
FastCopy utility does this: http://ipmsg.org/tools/fastcopy.html.en
I am using this program for copying or deleting folders that may contain junctions as subfolders so that the junction targets remain untouched. The junction points are properly copied while copying, even when the target drive is different.
Windows Explorer at least in Windows 7 Ultimate works also as wanted while deleting - junction targets remain intact.
But copying folders that contain junctions as subfolders in Explorer still does not work as intended - it actually does something that I cannot yet perhaps quite entirely describe: the junction folders seem to be copied as normal folders, but their content is empty.
I'm trying to run the following command in Windows Server 2003 but sed creates a pile of files that I can't delete from the command line inside the current directory.
for /R %f in (*.*) do "C:\Program Files\gnuwin32\bin\sed.exe" -i "s/bad/good/g" "%f"
Does anyone have any suggestions? Mysteriously enough, I'm able to delete the files using Windows Explorer.
As requested, here are some example filenames:
sed0E3WZJ
sed5miXwt
sed6fzFKh
And, more troubleshooting info...
It occurs from both the command prompt & batch files
If I just need to run sed on a single directory, then I use sed "s/bad/good/g" *.* and everything is OK. Alas, I also need it to tackle all the subdirectories.
I only have Sed installed.
Sed is creating the files
I have replicated your setup and I have the following observations.
I dont think there is a problem in the loop. The simple command "C:\Program Files\gnuwin32\bin\sed.exe" -i "s/bad/good/g" . - creates the same set of temporary files.
The files are indeed created by sed. sed creates these temporary files when the "in place" (-i) option is turned on. In the normal course, sed actually deletes the files (that is what happens in cygwin) using a call to the 'unlink' library. In case of gnuwin32, it looks like the 'unlink' fails. I have not been able to figure out why. I took a guess that maybe the unlink call is dependent on the gnuwin32 'coreutils' library and tried to download and install the coreutils library - no dice.
If you remove the 'read-only' restriction in the parent folder before executing the sed command, you can delete the temporary files from windows command prompt. So that should give you some temporary respite.
I think we now have enough information to raise a bug report. If you agree, I think it may be a good idea to bring it to the notice of the good folks responsible for gnuwin32 and ask them for help.
Meanwhile, the following version cleans up its temporary file:
https://github.com/mbuilov/sed-windows
As this is a known bug in sed with the -i option you can run attrib -R <filename> to remove the read only attribute from file after sed completes.
Alternatively do not use the -i option and redirect the output to a new file and then delete and rename the input and output.
Cygwin hoses the ACLs on files sometimes, you'll probably have to use cacls or chmod to fix it up before you can delete the file.
Here is where a bit of troubleshooting comes into play. Does this happen when you run that command from the command-line and a batch file? What if you run sed on an individual file on the command line - does it create these files for every file, or just certain files/filetypes? Does it only happen for that replacement, or all replacements in general, or just always when you run sed.exe on a file? Is it only sed creating these files, or all Gnuwin32 exe's (eg. awk, cat, etc)? Does the same thing happen on a sed.exe from a new install of Gnuwin32? What error message does it give when you try to delete the files? Can you delete the files from explorer while the command prompt is still open? What if you close the command prompt and reopen it, then try to delete the files?
you can just run sed without for loop
c:\test> sed -i.bak "s/bad/good/g" file*.*
This is a stab in the dark, but it wouldn't surprise me in the least if the gnuwin32 implementation of sed is duff (i.e., faulty in some way). Can you try to replicate the problem using the AT&T U/Win POSIX support for windows? It is easy to install and includes the Korn shell, sed, and find, so you can use find instead of the FOR /R. (I'm wondering if part of the problem is that the MS FOR and gnuwin32 sed don't play nicely together.)
I realize this is an old thread but It's still an issue. My fix is to add
"DEL sed*" to the end of a batch file after sed. Quick and dirty.
I am using this command to clean up the temporary files created by gnuwin32's sed:
FOR /f "tokens=*" %%a in ('dir /b ^| findstr /i "^sed[0-9a-zA-Z][0-9a-zA-Z][0-9a-zA-Z][0-9a-zA-Z][0-9a-zA-Z][0-9a-zA-Z]$"') DO del %%a
i know this is old. But just want to share with people what I did that cause this.
It was in fact the temp file for an already open file through gvim example .swap file that causing the sed tmp file didnt get remove completely.
So sed trying to read and append into the opened file which the user is currently viewing and having trouble doing it which causes the tmp file error.
Okay this is and isn't programming related I guess...
I've got a whole bunch of little useful console utilities scattered across a suite of projects that I wrote and I want to dump them all to a single directory to make using them simpler. The only issue is that I have them all compiled in both Debug and Release mode.
Given that I only want the release mode versions in my utilities directory, what switch would allow me to specify that I want all executables from my tree structure but only from within Release folders:
Example:
Projects\
Project1\
Bin\
Debug\
Project1.exe
Release\
Project1.exe
Project2\
etc etc...
To
Utilities\
Project1.exe
Project2.exe
Project3.exe
Project4.exe
...
etc etc...
I figured this would be a cinch with XCopy - but it doesn't seem to allow me to exclude the Debug directories - or rather - only include items in my Release directories.
Any ideas?
You can restrict it to only release executables with the following. However, I do not believe the other requirement of flattening is possible using xcopy alone. To do the restriction:
First create a file such as exclude.txt and put this inside:
\Debug\
Then use the following command:
xcopy /e /EXCLUDE:exclude.txt *.exe C:\target
You can, however, accomplish what you want using xxcopy (free for non-commercial use). Read technical bulletin #16 for an explanation of the flattening features.
If the claim in that technical bulletin is correct, then it confirms that flattening cannot be accomplished with xcopy alone.
The following command will do exactly what you want using xxcopy:
xxcopy /sgfo /X:*\Debug\* .\Projects\*.exe .\Utilities
I recommend reading the technical bulletin, however, as it gives more sophisticated options for the flattening. I chose one of the most basic above.
Sorry, I haven't tried it yet, but shouldn't you be using:
xcopy release*.exe d:\destination /s
I am currently on my Mac so, I cant really check to be for sure.
This might not help you with assembling them all in one place now, but going forward have you considered adding a post-build event to the projects in Visual Studio (I'm assuming you are using it based on the directory names)
xcopy /Y /I /E "$(TargetDir)\$(TargetFileName)" "c:\somedirectory\$(TargetFileName)"
Ok, this is probably not going to work for you since you seem to be on a windows machine.
Here goes anyway, for the logic.
# From the base directory
mkdir Utilities
find . -type f | grep -w Release > utils.txt
for f in $(<utils.txt); do cp $f Utilities/; done
You can combine the find and cp lines into one, I split them for readability.
To do this on a windows machine you'll need Cygwin or some such Unix Utilities handy.
Maybe there are tools in the Windows shell to do this...
This may help get you started:
C:\>for %i in (*) do dir "%~dpi\*.exe"
Used in the dir command as a modifier to i, ~dp uses the drive and path of everything found in (*). If I run the above in a folder that has several subfolders containing executables, I get a dir list of all of the executables in each folder.
You should be able to modify that to add '\bin\release\' following the ~dpi portion and change dir to xcopy. A little experimentation should make it pretty easy.
To use the for statement above in a batch file, change '%' to '%%' in both places.
Let's see if I can reach the EmacsW32 users on stackoverflow.
I've just installed the patched version of EmacsW32 from http://ourcomments.org/Emacs/EmacsW32.html
I find it very nice that .txt files are associated wth Emacs, so that when you click on one, emacsclient opens it in the running instance of Emacs.
Problem is, for some reason, the buffer is renamed with the old-style shortened file names, so, for example, the buffer with file "activities-2008.txt" is renamed to "ACTIV~1.TXT", which I don't like.
How do I get EmacsW32 not to rename the buffer, and use the whole file name as the buffer name instead ?
Ick, that sucks.
Why not just use the emacsclientw that comes with the standard Windows emacs distribution?
It does have a bit of an issue in that you get an annoying "No error" error box if Emacs isn't already running, but any real emacs user starts emacs first thing when they log on anyway. :-)
Solved.
The problem is not with emacs, but with the way Windows runs a program when a file type is associated in the registry.
In my registry, I had this value for the keys that associate txt files with Emacs:
C:\emacs-23.0.91.1\Emacs\bin\emacsclientw.exe -n "%1"
The problem is the %1, which is replaced by a short file name.
According to this message http://lists.gnu.org/archive/html/help-emacs-windows/2009-05/msg00022.html:
%L is long file names.
%1 is long file names IF
* Explorer can find the exe file (it does not look very hard)
AND
* The file header says it is Win 95 aware Win16 exe, or
* It is a 32 bit program
Else %1 will be a short name.
The solution is to use %L in place of %1 in the reg keys.