---------- Forwarded message ----------
From: Adin Burroughs <email@example.com>
Date: May 9, 2005 1:12 AM
Subject: Filename Globbing issues on Win32?
OK, first off, I'm on Win32 (XP) using 5.3 of coreutils.
I have been knocking my head on this and I'm feeling *really* stupid.
I swear, I'm unix literate, but I can't seem to get the following to
work without cheating:
cp -uvp "c:\dir with space\long path\*" k:\path
cp -uvp "c:\dir with space\long path"\* k:\path
I call this "cheating": (though it works)
cp -uvp c:\dirwit~1\longpa~1\* l:\path
this also works:
cp -uvp "c:\dir with space\long path\filename" k:\path
The problem seems to crop up when using wildcards in a path enclosed
by quotes. The exact error that cp gives is that it can't stat the
path, so it's an invalid argument.(it does echo back the escaped path
-- c:\\dir with space\\long path\\*)
I haven't been able to find much of anything in the documentation that
specifically addresses the windows implementation...and I didn't see
anything in the bug archives.
Am I missing something *really* obvious, or have I tripped across an
old bug? (this behavior is consistent with coreutils 5.2.1 and the
older fileutils versions).
The guys over at the gnu coreutils list think its a bug in the GnuWin32 implementation of coreutils....is there anything specific to the windows shell to take care of filename globbing?
Thanks in advance!
Really obvious? no.
Did the coreutils folk really blame GnuWin32? 10 points from their house, for finger pointing.
The problem is not cp, coreutils, or GnuWin32. Indeed, the question is not "how", but "who".
I am guessing that you are calling cp from a Windows Command Prompt (aka cmd.exe). Try this:
Try it especially in some directory with lots of files. You should get back one line, with a single asterisk. On a Unix-like system, running 'echo *' in just about any common shell would print out the names of all entries in the current directory, like ls, but all mashed together without the ls row & column formatting.
You are running into problems with wildcard expansion. Which the Windows Command Prompt doesn't do. But then, neither does cp. Instead, it presumes that the shell (its caller) actually handed over valid file names. And cp can't find a file called '*', so it complains.
If you still want to used cmd.exe, then I have no idea. The old Mortice Kern System ($$) version recognized that its caller didn't do expansions, so it would do them in-process.
UnxUtils has Amol Deshpande's port of zsh to Windows (as sh.exe). This expands wildcards more as you expect.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.