Globs aren't expanded on Windows

[jminer]

If I run this command:

PS C:\Files> renamer *.txt

Then this file opens in my text editor:

*.txt

Windows passes command line arguments as-is to programs, and it seems that pipe-rename doesn't expand the glob like I would expect. I found that I can use this command:

PS C:\Files> renamer (Get-Item *.txt)

and then the opened file looks like I'd expect:

C:\Files\file1.txt
C:\Files\file2.txt

And I can rename files. But using (Get-Item *.txt) is annoying, and I probably won't remember it the next time I use pipe-rename.

I'm using Windows 10, PowerShell, and pipe-rename 1.3.0 (updated today from crates.io).

[marcusbuffett]

Interesting, I wasn't aware that windows didn't expand glob patterns. Should be fairly trivial to add this in, will tackle this when I get the time, or I'd welcome a PR for it if anyone wants to :)

[assarbad]

This is natural, since it's not a "Windows" or "Unix" feature at all, but a shell feature. So when on your favorite shell it expands it or not. For example the Bash that comes with Git for Windows will expand wildcard/glob characters by default.

I don't know enough about Rust and targeting Windows as of yet, but it appears that the default toolchain targets the MSVC libs. So link options (as opposed to linker options) may be a tool of choice here for simplicity (see entries for setargv.obj and wsetargv.obj respectively). These are essentially object files you add to the linker command line (and which take precedence over contained identically-named symbols from libs) that allow to modify the default behavior of the C/C++ runtime lib from MSVC. The "setargv" link options will pass an already expanded list of file names (based on Windows' rules for wildcard expansion) to the main function.

Btw, given PowerShell Core (>= 6) is meant to be cross-platform these days, perhaps there's a way to get it to expand globs, @jminer?

[assarbad]

Hah, there even seems to be a way to do it directly via clap with little effort, see here.

[jminer]

@assarbad I looked it up and found that PowerShell Core has added globbing but only on Unix systems. It's based on a compile time define, here:

https://github.com/lzybkr/PowerShell/blob/7f3364f5dd5c3095d1b177c682960f3bb3ca4ca0/src/System.Management.Automation/engine/NativeCommandParameterBinder.cs#L265

I suppose its behavior makes sense. While the globbing is handled by the shell, I think it is a Windows vs Unix difference. People expect that shells on Unix do expansion, and Windows programs don't expect the shell to do expansion (because the built-in shells don't). I consider Bash on Windows to be a Unix program. It doesn't support Windows without using a compatibility layer (Cygwin) and can't even handle native Windows paths with a drive letter or backslashes without quoting them.

I wouldn't want to rely on MS C runtime library behavior. Rust developers have talked about possibly removing the dependency on the MS C runtime in the future (which I would be in favor of).

The wild crate is a great find. It looks perfect. Compared to what I was thinking before, it's simpler and better reproduces Windows' behavior.

[assarbad]

I wouldn't want to rely on MS C runtime library behavior.

It's just one option and one that few people realize exists. But makes sense to go for a consistent approach across the board.

Rust developers have talked about possibly removing the dependency on the MS C runtime in the future (which I would be in favor of).

Oh, I'd love that. Must have missed that discussion. If they did that on the glibc end as well it'd be bliss.

The main point I was trying to make is that since it's shell behavior it depends on the shell you intend to mimic and it doesn't stop * and ? as #16 goes to show. So you better decide up front what behavior you want to support and how you want it supported (e.g. use the rules clap brings, use a particular shell's rules, use the OS-specific rules and therefore something like PathMatchSpec on Windows ...).