I'm cleaning up some old Windows batch files at work, and keep seeing lines like this:
D:
cd\
cd some\other\path\
is there any reason (compatibility with command.com maybe?) to not just write this as
cd /d d:\some\other\path\
cd doesn't actually change the working drive; it only changes the working directory for that drive. That's why it's broken up that way.
An example might help:
C:\users\david>cd D:\some\path
C:\users\david>
Note the drive hasn't changed.
C:\users\david>D:
D:\some\path>
Now that D: is the "working disk", the working directory is changed to what you specified previously.
As you point out, cd /d will do both. [UPDATE: I must have missed the /d when reading your original post :( -- sorry]
I believe you're correct -- there's no "good" reason not to use the one-liner -- other than compatibility with COMMAND.COM (which I'm pretty sure doesn't support the /d switch). For this reason, I always create my script files with a .cmd extension if they depend on features not supported in COMMAND.COM.
A better alternative IMHO is to use pushd which behaves like cd /d -- and also gives you the ability to go back to wherever you were before (via popd). You can even pushd to a UNC path (\\server\share) and Windows will create a temporary drive letter for you. (Although I only found that feature this morning, and I'm running Win 7 Pro, so I'm not sure if it's available on older versions and/or Home editions.)
Related
I am trying to get a directory listing of only files with a given extension. At first blush this seems to be a simple thing to do, however check out this simple example:
C:\CODE\metcal>dir /b *.exe
metcal.exe
metcal.exe1
Notice that this returns metcal.**exe** and metcal.**exe1** as matches.
With python files a similar thing happens:
C:\CODE\metcal>dir /b *.py
metcal.py
metcal.pyc
Notice again Windows has determined that *.py takes anything that starts with *.py so it captures the .pyc files as well.
Is there a way to get only the extensions that match exactly? In the above python files example I would like the following to occur (obviously with the correct syntax substituted for *.py)
C:\CODE\metcal>dir /b *.py
metcal.py
As a note the matching under Windows not as simple as it seems.
*.exe matches foo.exe, foo.exe1, foo.exeabcde but not foo.exe.bak
There are other questions on SO that are similar that are related to long/short file names. The *.py and *.pyc example here should not introduce name mangling machinery.
**I have experimented on XP and Win7 machines and this behavior is not consistent at the cmd Prompt and file open dialogs. This inconsistant behavior makes me suspect this problem is related to settings of somekind. **
It's because windows wildcards on extensions check both long and short names as explained in this answer:
https://superuser.com/questions/238900/winxp-dir-command-3-and-4-char-extensions-are-the-same#238930
Solution there is to disable 8.3 names creation and then striping them on ntfs volumes which will also improve performance.
Microsoft Docs: Fsutil 8dot3name
Remarks:
Permanently removing 8dot3 file names and not modifying registry keys that point to the 8dot3 file names may lead to unexpected application failures, including the inability to uninstall an application. It is recommended you first back up your directory or volume before you attempt to remove 8dot3 file names.
So if you want to get only those extensions (.py and .pyc), you should try like this way :
#echo off
dir /b *.py*
pause
You can use the Unix ls command from the Windows Subsystem for Linux to do this, assuming you have WSL installed. It's freely available from Microsoft. From your Windows command prompt, type wsl followed by the ls command to list the files you want.
So, for your example, wsl ls metcal.py returns only metcal.py. To get the same results as you're seeing with dir, use wsl ls metcal.py*.
In a cmd prompt, if you want to go from
c:\foo\
to
d:\bar\
You must type
d:
to change drive first, before you can
cd d:\bar\
On Linux, you do not have to do this. Why does cmd unintuitively make you have to do this? Historical? Implementation limitation? By design?
I understand that
cd /d
mimics the Linux behavior, however why is Linux's behavior not default?
As far as I can tell when you
cd anotherDrive:\directory\
it just does nothing, so it's not like the "without /D" usage is reserved for some other semantics.
Having one current working directory per drive allows you to do things like
> cd d:\some\long\path\ # Set the working directory of that other drive
> copy myFile.txt d: # Copy the current file to that drive
> cd .. # Go elsewhere
> copy anotherFile.txt d: # Copy another
I bet this was handy back in the days when you worked with 2 floppy drives.
I don't see any technical reasons for this. Presumably just a design choice of how to work with the prompt.
As PA. mentions you can use the /d switch if you don't like this behaviour.
you don't need to
just read HELP CD
and then try
CD /d d:\bar
the CD default behavior is still there for backwards compatibility with old versions of DOS where the existence of dual diskette bays made it useful.
Newer commands, like pushd for example, make the default behavior to honor drive and path.
I have a huge series of folders, named 'A' through 'Z' such that each folder has subfolders in the same form.
For example, I could have a directory at this path: .\A\D\E
I want to populate each of these folders with an empty file (so I can commit it to a git repository if anyone's curious).
Windows doesn't have an equivalent of Linux's touch, but I have the GnuWin32 toolset installed so I can, in fact, use touch in my Windows environment.
I've started by creating a batch file with the following:
FOR /D /r do touch empty
But when I run it, the folders aren't populated. I don't get any errors either:
C:\sandbox>FOR /D /r do touch empty
C:\sandbox>
Does anybody see anything glaringly wrong about the line of batch script above? Is there anything else I can try short of using additional non-Windows commands?
You just need to get the syntax of the FOR command right:
for /r %f in (.) do touch %f\empty
In Windows, how do you copy an entire directory, INCLUDING the parent directory folder?
For instance, let's say we have the directory c:\Folder and want to copy it over to d: .
The only way right now would be:
xcopy /E c:\Folder d:\Folder
Is there a way to do this without specifying the same end directory (Folder)?
I'm told that an application called RoboCopy can do it, however, I believe it's part of a series of server 2003/2008 tools -- I can't speak to its capabilities or whether it will work on your version of Windows. That said, there are a set of tools (basically UNIX commands ported to DOS) located here that will do what you need -- specifically the "cp" command. My apologies for not being able to assist further.
I don't seem to have this problem on my home laptop with Windows XP, but then I don't do much work there.
On my work laptop, with Windows XP, I have a problem deleting directories when it has directories that contain .svn directories. When it does eventually work, I have the same issue emptying the Recycle bin. The pop-up window says "Cannot remove folder text-base: The directory is not empty" or prop-base or other folder under .svn
This continued to happen after I changed config of TortoiseSVN to stop the TSVN cache process from running and after a reboot of the system.
Multiple tries will eventually get it done. But it is a huge annoyance because there are other issues I'm trying to fix, so I'm hoping it is related.
'Connected Backup PC' also runs on the laptop and the real problem is that cygwin commands don't always work. So I keep thinking the dot files and dot directories have something to do with both problems and/or the backup or other process scanning the directories is doing it. But I've run out of ideas of what to try or how to identify the problem further.
You don't need to reboot; just open Task Manager and kill TSVNCache.exe.
This is safe, too. It's designed so you can kill it and it will automatically restart when needed.
(As a result of the auto-restart, note that browsing some SVN folders in Explorer, File-Open dialogs, etc. may cause TSVNCache.exe to restart. Keep an eye on Task Manager.)
Tortoise SVN is great but I have found that TSVNCache.exe can hold on to locks and get in the way at times. (Sometimes justified, sometimes not.) As a result, for some automated scripts I run I include commands to kill TSVNCache.exe as part of the scripts so it doesn't get in the way. That's only worth doing if it's an operation you perform often, though.
You can try a few things:
Since you are getting this error frequently, you can use handle.exe from sysinternals to check which process currently have open handles for the .svn\* directory. If handle utility tells you about any process, try stopping that process and then delete the directories.
Error while deleting from recycle bin: In simple terms, when a file is sent to recycle bin after deleting, it is not actually deleted, rather, a few manipulations are done in directory hierarchy (file system level) to avoid showing the file while browsing content of a folder. So If you happen to resolve the problem mentioned in comment#1, you will not get this error probably.
Cygwin command not working: Running a cygwin command on windows requires (in particular) cygwin1.dll, which is known to be shipped with other programs (eg: CopSsh, some version of svn clients etc...) as well. If there is any mismatch in the version of cygwin1.dll, cygwin commands won't work. Try searching for cygwin1.dll on your computer and try to resolve version conflicts (if any).
did you ever do mkpasswd and mkgroup for cygwin? If you're using cygwin from the command line you are pretty much guaranteed to have file system permissions issues. and you have to read a little to fix it.
http://cygwin.com/cygwin-ug-net/ntsec.html
Try this answer from me. Although it's given for TortioseGit instead of TortoiseSVN, the handling is the same:
disable the status cache (i.e. prevent the TSVNCache.exe from accessing the .svn folders continuously)
delete what you have to delete
enable the status cache to get updated overlays again
I have just experienced this problem (or similar)
I am using tortoise 1.6.7
To fix it I went to 'Tortoise Settings' from the tortoise context menu.
from there select "Icon Overlays" in the tree widget.
In the icon overlays page, I entered the path that was giving me angst into the "exclude paths:"and tortoise no longer holds that directory handle.
This is a directory that is often deleted by a process other than explorer.
Since what it appears that you are trying to do is export the repository from SVN, why not use the export functionality with TortoiseSVN. This removes all .svn directories from the generated 'working copy'.Cmdline: http://svnbook.red-bean.com/en/1.0/re10.html
If you want to delete all sub folders named .svn in windows
then create batch file with this content:
for /f "tokens=* delims=" %%i in ('dir /s /b /a:d *.svn') do (
rd /s /q "%%i"
)
save it in a file del_All_Dot_SVN_Folders.cmd . Run it. Your done.
Thanks to http://www.axelscript.com/2008/03/11/delete-all-svn-files-in-windows/
Remember the above code has .svn whereas the code in the link has only *svn so its better
to have the .svn to not accidentally have undesired effect.