| Date: | December 5, 2006 / year-entry #402 |
| Tags: | tipssupport |
| Orig Link: | https://blogs.msdn.microsoft.com/oldnewthing/20061205-00/?p=28833 |
| Comments: | 44 |
| Summary: | You already know how to do this, you just don't realize it. How do you find files with an "x" in their name? That's right, you use dir *x*. Now you just have to change that x to a space. And since spaces are command line delimiters, you need to quote the sequence so it... |
You already know how to do this, you just don't realize it.
How do you find files with an "x" in their name?
That's right, you use Now you just have to change that x to a space. And since spaces are command line delimiters, you need to quote the sequence so it gets treated as a single parameter rather than two "*" parameters: dir "* *"
Stick in a |
Comments (44)
Comments are closed. |
<pedantic>
All files? That only works on one logical volume. I expected something like
http://www.google.com/search?q=inurl:%20
as the better answer, but I can’t get that to work.
I also doubt that the answer given will list filenames with non-breaking spaces, Ethiopic wordspaces, etc. For that, Powershell may be your friend.
</pedantic>
Spaces, schmaces… this tool is pretty nice:
http://www.bulkrenameutility.co.uk/Main_Intro.php
If I understand you correctly: Apparently Vista does this if you shift+right click. For XP there’s a Powertoy at http://www.microsoft.com/windowsxp/downloads/powertoys/xppowertoys.mspx
David said
I’ve been doing that for years, using the 4NT shell replacement. You might be able to do it with cmd too, but I’m not sure how.
You go into the registry and find or create the key HKEY_CLASSES_ROOTFoldershell. Add a key and name it, like "Open shell here". Give this key a new subkey named "command" The contents of the key are to be a string containing the command you want to issue. Use "%1" for the path to the directory.
For 4NT, my command value is
D:4NT3014NT.EXE cdd "%1"
cdd means to change to the drive and directory specified. It’s something 4NT adds to the st of shell commands.
Even without this registry work, you can easily open a cmd session, then drag the directory from Explorer to the command line windiow. This will drop the full path to the directory into the command line.
And… how to find AND rename OR delete files created by Windows when it runs into same named files where the resulting filename looks like:
filename(1).jpg
That one is kicking my butt, even with BRU mentioned above.
Ahh, I hate that filename(1).jpg renaming task too, mostly because XP uses such a braindead scheme when renaming a group of files. Microsoft finally adds a feature I’ve been craving and it’s implemented so dumb as to be worthless.
The filename(1).jpg thing is easily solved in PowerShell. If you can cope with the deployment and don’t have to interoperate with legacy scripts (before Raymond points those out) it really does make life a lot easier.
Another tool which can be very handy is Oscar’s File Renamer. You can edit a directory like a text editor, search and replace, etc. It’s also fully free: http://www.mediachance.com/free/renamer.htm (the .exe can be copied anywhere and run standalone)
In Windows, you have to quote, since backslashes don’t escape (unless there’s some other escape char?). Unix can use * * instead.
But, how do you rename all filenames with spaces to use underscores instead?
In bash, the following works:
for file in * *;do echo mv ‘$file’ ${file// /_};done
But I can’t find an equally elegant way in cmd. Even the normally-rather-cool "ren" command, which makes many things far easier than they’d be in unix, seems to fail me.
This works to change any files with an initial space (counterintuitively for anyone who is used to unix’ pre-expansion of wildcards):
ren " *.*" _*.*
renames all files like " test.txt" to "_test.txt".
But the following doesn’t do what one might naïvely expect from that:
ren "* *.*" *_*.*
This renames "a test.txt" to "a test.txt_".
That’s what I thought back in Dos 3.3 when I tried to "del *temp.*". Unfortunately Dos 3.3 wasn’t that smart and just interpreted the command as "del *.*"! We all know the end of that story.
Ever since then I’ve been leery of prefixing any ‘del’ command with ‘*’!
Windows uses smarter wildcards. You can test it by using DIR with wildcards to see what files match:
C:Documents and SettingsThe MAZZTer>dir *scp.*
Volume in drive C is Windows XP
Volume Serial Number is DEAD-BEEF
Directory of C:Documents and SettingsThe MAZZTer
12/04/2006 07:26 PM 600 winscp.RND
1 File(s) 600 bytes
0 Dir(s) 7,130,140,672 bytes free
Renaming files using wildcards usually does not give the expected results. I prefer to use this tool:
http://www.codeproject.com/shell/shswapl.asp
Which gives me far greater control, of course you need to know regex to use it…
> But, how do you rename all filenames with spaces to use underscores instead?
for /f "tokens=1,2-99 delims=_" %a in (‘dir /s /b "*_*"’) do ren "%a_%b" "%a %b"
This only replaces the first underscore in each file, but you can run it several times…
So would it be overly picky to point out that RyanBernrose misinterpretted the problem and ends up changing underscores to spaces instead of vis versa? Or maybe I just shouldn’t have dawdled so much while coming up with very nearly the same thing.
for /f "tokens=1,2" %a in (‘dir /b "* *"’) do ren "%a %b" %a_%b
Good for all filenames containing one space in the current directory where the filename doesn’t start with that one space. Doing all files on a drive or down a directory branch would be a trivial change to the above. Dealing with leading spaces, multiple spaces, and/or multiple drives would be more work and probably be a batch file instead of a single line.
What would really be nice is if Windows Explorer would give an option for a command prompt in the selected directory when right clicking a directory name.
Option 2 would be for Windows Explorer to have the option to apply a filter like {dir "* *"} and only list those files.
Is there any way to do that already?
For what it’s worth
dir *" "*
also seems to work.
cmd /V:ON /C for %I in (*) do @(set N="%I"^&ren !N! !N: =_!)
dir *.
does list entries without any dots. Don’t trust this for one second.
dir *.
means "no extension", the part after the dot is empty. Know thy enemy!
@ryan bemrose:
using the output of "dir" in a for statement is NOT good, especially when combined with /s.
RyanBemrose:
cmd /v:on /c "for %a in ("* *") do @set a=%a&ren "%a" "!a: =_!""
How do you list all files that end in a dot then?
Adam: filenames can’t end with a dot.
I should point out that filenames that end in a dot are not legal in Windows.
Try the following:
echo test > test
echo test > test.
echo test > test..
echo test > test…
etc.
The "change spaces to underscores" problem is interesting. Hadn’t seen the %var:a=b% trick before. But what do you do if a particular directory contains both "a b.txt" and "a_b.txt"?
> dir *.
> does list entries without any dots. Don’t trust this for one second.
I believe that’s because files with no extension always have an implied (or hidden?) dot separator as part of their legacy "8dot3" filename.
What dir *. actually gives you is a list of all files that have no file extension.
Everyone craving for filters, renaming and fatures Explorer is missing check out Directory Opus:
http://www.gpsoft.com.au/
Wednesday, December 06, 2006 11:33 AM by Maurits
I should point out that different parts of Windows have different laws.
echo test > \?C:test.
Then you can delete it using del but you can’t delete it using Windows Explorer.
Norman:
how do you use "\?<something>" on Windows 9x/ME?-)
I interpret "Windows" on first sight here "as in Win32API". I’m quite sure that in the POSIX or the Interix subsystem (SFU) trailing dots are allowed too.
Thursday, December 07, 2006 8:14 AM by Stefan Kanthak
> I’m quite sure that in the POSIX or the
> Interix subsystem (SFU) trailing dots are
> allowed too.
You’re right. “touch d.” made a file that Windows Explorer couldn’t delete.
I wonder what happens if a samba client creates such a file in a share on a Windows 98 machine.
Stefan Kanthak wrote:
He did in fact also combine it with /b although that depends on none of his directories containing spaces, otherwise you get
ren "Documents and Settings" "Documents_and Settings"
ren "Documents and SettingsAll Users" "Documents_and SettingsAll Users"
etc.
Neil:
/S is a typo, I intended to write /B.
In fact the "dir" builtin is weird: when using /B/S together it lists the complete pathname(s), /S without /B but lists directory for directory.
> Windows 98 doesn’t have a POSIX layer
Vista doesn’t.
Thursday, December 07, 2006 8:45 PM by Norman Diamond
> “touch d.” made a file that Windows Explorer
> couldn’t delete.
To clarify, that was executed by Windows Services for Unix on a Windows XP Pro machine.
> I wonder what happens if a samba client
> creates such a file in a share on a Windows
> 98 machine.
To clarify, that would be when a Windows 98 machine serves a file share to the network, and the samba client would be on a Unix machine.
> [Windows 98 doesn’t have a POSIX layer.
> -Raymond]
Windows 98 doesn’t need a POSIX layer in order to serve a file share. I was wondering what would happen when the client creates such a file in the share. I would expect that Windows 98 would be completely unable to delete the resulting file.
Similar effects can be accomplished even with a Windows 98 German client creating a file in a share hosted by a Windows 98 Japanese machine. Maybe also by a Japanese client and a US-English host. Sometimes even Windows 98 Scandisk couldn’t rename a file to a deleteable filename.
(I can’t bring myself to type “Windows 98 servvvvvvvvvvvvvvvvvvvvv”, argh.)
> Thank you for conveniently ignoring my
> previous response. -Raymond
Do you mean the following, or do you mean something else?
Monday, December 11, 2006 3:03 AM by Norman Diamond
[Raymond Chen:]
>> Windows 98 would create the file without a
>> trailing dot since its file system is FAT,
>> not NTFS.
>
> Then the same thing should happen when
> Windows 2000 tries to create the same file on
> a FAT volume using:
> echo test > \?C:test.
> I have two computers with that configuration
> and now have to remember to test it.
The reason I think of testing it is that Posix semantics aren’t the
only way to get a trailing dot in a filename. For example if a
samba client uses Windows semantics then it’s not using Posix semantics
(even if one or both machines might provide Posix semantics to other
users).
For that matter I also ought to try it with an actual Windows 98
host and a samba client. I understand your statement that the
filename would be created without a dot, but I still have a nagging
doubt.
If your complaint means there was some other previous response of yours that I conveniently ignored, please point me to it.
file system that supports Posix semantics.” Windows 98 can’t even spell
“POSIX”. Its file system driver follows Win32 semantics, not NT
semantics. -Raymond]
Trying to use Unicode characters in a folder shared from Windows 98, either silently replaces those characters with similar-looking ANSI characters, or fails completely. Trying to use \?X:dot. trick on a drive mapped from Windows 98 fails.
> Windows 98 would create the file without a
> trailing dot since its file system is FAT,
> not NTFS.
Then the same thing should happen when Windows 2000 tries to create the same file on a FAT volume using:
echo test > \?C:test.
I have two computers with that configuration and now have to remember to test it.
Saturday, December 09, 2006 6:28 PM by back to VB
[Raymond Chen:]
>> Windows 98 doesn’t have a POSIX layer
>
> Vista doesn’t.
Vista does and doesn’t.
http://www.microsoft.com/windowsvista/getready/editions/enterprise.mspx
* Additionally, Windows Vista Enterprise
* includes Subsystem for UNIX-based
* Applications (SUA), which enables you to run
* UNIX applications unchanged on a Windows
* Vista Enterprise-based PC.
[…]
* The Windows Vista Enterprise edition is only
* available to Microsoft Volume License
* customers, it is not available for retail
* purchase.
http://www.microsoft.com/downloads/details.aspx?familyid=93FF2201-325E-487F-A398-EFDE5758C47F&displaylang=en
* Utilities and SDK for UNIX-Based
* Applications is an add-on to the Subsystem
* for UNIX-Based Applications (referred to as
* SUA, hence forth) component that shipped in
* Microsoft Windows Vista RC1 / Longhorn
* Server IDS_C release.
By the way the latter page crashes Internet Explorer 7. I tried twice to send myself a link to that page, and both times Internet Explorer closed 4 windows (this window and 3 other victims) and didn’t offer to send its crash dump to Microsoft. Using the mouse to copy and paste I could send myself a link, but still couldn’t fix the latest and greatest IE.
Dewi Morgan: in Windows, the escape character is "^", altough due to how the command line is parsed, it doesn’t work perfectly with characters like "%"
> What I meant was that Windows 98 doesn’t have
> a file system that supports Posix semantics.
OK, I believe that, but I think that is irrelevant.
Back to this:
> Windows 98 would create the file without a
> trailing dot since its file system is FAT,
> not NTFS.
I doubt that for two reasons.
(1) If FAT were incapable of storing a filename that ends with a dot, then on a computer where I tried it this morning, the FAT32 C partition wouldn’t contain a file named “a.” (without the quotes but with the dot, two single-byte Italian characters long). The echo command in Windows 2000 MSDN-English created the file. Windows Explorer in Windows 2000 MSDN-English cannot delete the file.
(As it happens Windows 98 Japanese is installed on C but it wasn’t running. The running Windows 2000 is installed on K. boot.ini and related stuff are on C.)
(2) If Windows 98 had been running then we already know that disk shares operate at a lower level than Windows 98’s Win32 semantics. This is exactly how a Windows 98 German client can create a file in a share which the Windows 98 Japanese host can’t delete (and even Scandisk can’t rename it to a deletable filename). I haven’t tested this yet with Windows 98 running on the host and a Windows XP client running an echo command to create the thing in the share, but I see that ender did.
> FAT doesn’t have POSIX support.
I think it’s clear by now that that’s completely irrelevant.
Monday, December 11, 2006 9:17 AM by ender
> Trying to use Unicode characters in a folder
> shared from Windows 98, either silently
> replaces those characters with similar-
> looking ANSI characters, or fails completely.
What OS was your client running? When I had two different language versions of Windows 98, the filename was chosen in ANSI by the client and the host simply obeyed. FAT32 (and FAT16 with long filenames) does store filenames in Unicode in addition to storing short names in ANSI. Characters which were unsupported on the host did not get changed to similar-looking characters in the host’s ANSI code page, they remained as they were set by the client in the client’s ANSI code page. Whether or not the host could access files stored on itself, this did not fail for the client, the client could still access the files.
Things got a lot more confused when the host was running Windows 98 Japanese and the client was running Windows 2000 MSDN-English. Windows 2000 MSDN-English properly displayed filenames written in Japanese on its own hard drives but garbaged up filenames written in Japanese on the share on the networked host. The contents of the files were retrieved correctly, only the names were garbaged up and only when viewed on the client. I might have time some weekend to reconstruct and test this networked environment.
> Trying to use \?X:dot. trick on a drive
> mapped from Windows 98 fails.
Thank you for this report. May I ask again what OS your client was running.
> Let me try again. Windows 98 supports only
> Win32 file names.
OK, we’re part way there. There is no longer an assertion about FAT not supporting some part of this. Some layer in Windows 98 supports only Win32 file names. The only remaining doubt now involves which layer that is.
> Your “a.” file was created by bypassing the
> Win32 layer and using the NT layer or POSIX
> layer.
Right, it was the NT layer in Windows 2000.
> There is no such layer on Win98 so the “side
> door” doesn’t exist.
There is no NT layer on Win98 so that particular side door doesn’t exist. However, Win98 does provide other side doors, that is how a Win98 client can create a file in a share on a Win98 host which the host can’t delete. The host enforces its code page at the Win32 level on programs running locally but it does not enforce its code page on network clients. The client’s code page rules.
ender tested the Win98 sharing layer and couldn’t create a filename ending in a dot, but the reason still isn’t clear.
Hmm, I can test this under Virtual PC, if I can get my keyboard to work long enough in guest PCs… You’re right, the filename gets created without the trailing dot. The host can delete the file in this case.
Let’s try it again with a Windows 98 US host and a Windows XP Japanese client… Hmm, this looks like something that changed between Windows 98 first edition and second edition. I’m using Windows Explorer to rename a file in mapped drive Y:. I’m sure this is the first time I’ve seen an error message that translates roughly as “Folder Y: doesn’t exist. Create?” and if I answer yes then the same error comes up again.
The file system driver on Windows 98 is the one that enforces Win32 semantics.
Whether the file name came in through the SMB redirector or via
an application running on the local machine, the result in
the file system follows Win32 rules.
On the other hand, Windows NT supports multiple file naming conventions, so the semantics are enforced at a higher level:
The underlying file system uses NT semantics and layers are used to enforce semantics as appropriate to the layer. The trailing dot is stripped off by the Win32 layer. On Windows NT, the Win32 layer is an explicit layer. On Windows 98, the Win32 layer is baked into the file system. I don’t know why I let you hijack threads like this. -Raymond]
The "Command prompt here" power toy gives this capability.
> Here’s the diagram I was hoping you could
> figure out from my hints.
Your diagram matches your hints but does not match my experience.
> On Windows 98, the Win32 layer is baked into
> the file system.
It still doesn’t match my experience.
> I don’t know why I let you hijack threads
> like this.
From these:
Wednesday, December 06, 2006 11:27 AM by Stefan Kanthak
> Adam: filenames can’t end with a dot.
Wednesday, December 06, 2006 11:33 AM by Maurits
> I should point out that filenames that end in
> a dot are not legal in Windows.
Evolution isn’t always intentionally designed.
Norman: my client was Windows XP sp2, host was Windows 98SE Slovenian running in a VMWare image.
Trying the echo foo > \?M:bar. trick on a FAT32 volume in Windows XP creates a file, but it’s without the trailing dot.
Try it on the root of a drive where you copied say NOTEPAD.EXE as CMD.EXE before (substitute EDIT.COM as COMMAND.COM for Wintendo). Ooops.
Try it on a "real" (say: virtual) shell folder. Ooops.
With the last I’m not completely sure whether the "original" PowerToys only placed an (incorrect) entry beneath HKCRFolder or the two correct entries beneath HKCRDrive and HKCRDirectory.
For the other two: REG_EXPAND_SZ "%ComSpec%" /K PushD "%L" works perfect (except on Wintendo).
This is kind of fun, too…
With no-one watching:
mkdir C:foo
echo.>\?C:foocon
Now you have a geek test – bring people to your machine and see if they can delete the "con" file, either from Windows Explorer or from the command line.
Tuesday, December 12, 2006 7:47 AM by Stefan Kanthak
Hey. Nintendo is a fine manufacturer of plastic playing cards. Nintendo was making plastic playing cards before computers were invented. Their plastic playing cards are a fine quality product and they last a good long time. Sure the company added a few side lines to their business but that’s no reason for abuse. Wii will not stand for it.
Tuesday, December 12, 2006 5:33 AM by ender
Thank you. Your results match what I got with virtually networked guests under Virtual PC, and match what Mr. Chen said.
Raymond Chen:
I agree.
PingBack from http://blogs.msdn.com/oldnewthing/archive/2007/12/17/6785519.aspx