Expand globs in args

[spenserblack]

This is somewhat of a follow-up to #540.

Unfortunately, Windows command prompt and PowerShell do not expand globs by default. It is instead left up to the application to expand the globs. In PowerShell, this is doable with a call like scc.exe (Get-ChildItem *.go), because Get-ChildItem knows how to expand globs. But a simple call to scc.exe *.go will result in file or directory could not be read: *.go (unless you actually have a file called *.go of course).

This makes globs in the CLI easier to use on Windows. It may also be helpful in certain scripting situations.

If a glob pattern is invalid (the only possible error return value), it falls back to treating the pattern as the actual filepath.

This could negatively impact anyone who has pattern-like syntax in actual filenames (e.g. if someone wanted to match exactly a file called *.go), but I assume that's a very rare edge-case.

---

I could make this Windows-specific behavior at either runtime via runtime.GOOS or at compile-time via a main_windows.go file.

[boyter]

For this... I think we need to guard it a bit better to avoid regression.

     if !strings.ContainsAny(arg, "*?[") {
          filepaths = append(filepaths, arg)
          continue
      }
      matches, err := filepath.Glob(arg)

      if err != nil || len(matches) == 0 {

the above guards, || len(matches) and strings.ContainsAny should ensure we catch them. Have attached a script that should ensure this is good. Possibly worth adding into the test-all.sh

test-glob.sh

[spenserblack]

🤔 I think I'm realizing I didn't think this all the way through. Your code block (specifically the ContainsAny) reminded me that that [ is actually kind of common in filenames, thanks to Next.js and similar frameworks.

I think this will need to be enabled only if a flag like --expand-globs is set to prevent a significant regression. In Bash and similar Unix shells, a glob could expand in the shell to a filename that itself looks like a glob pattern when passed to scc.

BTW I think we can drop the nil check on the error if we check the length of the matches, since matches should be nil on an error. But keeping the err != nil communicates the intent a bit better, so it comes down to a matter of styling (simplicity vs readability).

[boyter]

Yeah... globbing support is one of those things I tried to kick out to the OS due to all the edge cases it presents.

[spenserblack]

I think that turning this on with --some-glob-flag would be a decent compromise. Additionally, this would also support globs in a @file.txt (if I'm reading main.go correctly).

If there's a flag, I don't think a "does this look like a glob" check would be necessary, since the user has explicitly opted into treating args as globs.

Of course, only if you consider glob support worth the additional complexity.

[boyter]

I think its fine in this case, its mostly for windows support? So long as thats mentioned in the -h I think its fine.

[spenserblack]

I think its fine in this case, its mostly for windows support?

That's my use case, though I imagine it could potentially be helpful in certain scripting scenarios, if scc gets called by another process and receives some filepath-like input.

Unfortunately, since command prompt doesn't expand globs, and it's a bit cumbersome to do in PowerShell, expanding globs in the executable is necessary to make usage between Windows built-in shells and Unix the same.