Unicode Chars in Windows Path

[Chris Angelico]

On Fri, Apr 4, 2014 at 12:57 AM,  <random832 at fastmail.us> wrote:
> An argument [in a position where a list of filenames is expected] with *
> or ? in it _always_ gets globbed, so "C:\dir with spaces\*.txt" can be
> used. This is part of the reason the program is responsible for globbing
> rather than the shell - because only the program knows if it expects a
> list of filenames in that position vs a text string for some other
> purpose.

Which, I might mention, is part of why the old DOS way (still
applicable under Windows, but I first met it with MS-DOS) of searching
for files was more convenient than it can be with Unix tools. Compare:

-- Get info on all .pyc files in a directory --
C:\>dir some_directory\*.pyc
$ ls -l some_directory/*.pyc

So far, so good.

-- Get info on all .pyc files in a directory and all its subdirectories --
C:\>dir some_directory\*.pyc /s
$ ls -l `find some_directory -name \*.pyc`

Except that the ls version there can't handle names with spaces in
them, so you need to faff around with null termination and stuff. With
bash, you can use 'shopt -s globstar; ls -l **/*.py', but that's not a
default-active option (at least, it's not active on any of the systems
I use, but they're all Debians and Ubuntus; it might be active by
default on others), and I suspect a lot of people don't even know it
exists; I know of it, but don't always think of it, and often end up
doing the above flawed version.

On the flip side, having the shell handle it does mean you
automatically get this on *any* command. You can go and delete all
those .pyc files by just changing "ls -l" into "rm" or "dir" into
"del", but that's only because del happens to support /s; other DOS
programs may well not.

ChrisA