When processing file lists with globbing characters, warn user about shed HOT 8 CLOSED

I'd go with Cheuk's solution here - we report an error if git ls-files'd files already, and I don't think adding ", maybe due to unexpanded glob pattern?" is a bad thing in the rather unlikely event that it happens.

Checking after we've failed to open and read the file has two other advantages: it's faster due to our multiprocessing, and it avoids time-of-check/time-of-use errors (which are not much of a concern here, but that way lie subtle mistakes when code changes over time).

from shed.

I think printing a "file not found" warning to stderr for each missing file would make sense, and happily that's also easy to implement! Happy to accept a PR; otherwise I'll get to this within the next few weeks.

from shed.

(misclick! Darn mobile interfaces...)

from shed.

@Zac-HD can this be resolved by adding an extra error message here?

from shed.

Depends on if you want to raise file-missing errors when auto-detecting files in git repos. I can see the case for either way there.

Alternative would be checking all files here

from shed.

@tommorris may I know which Make and Bash are you using? I cannot reproduce at mine using:

GNU Make 3.81 and GNU bash, version 3.2.57(1)-release (arm64-apple-darwin22)

shed will run correctly from the make command even with the globs

I can still put in a PR with the extra error message when the file name has '*'s in it, but it would be nice to be able to test it with the problem that it is trying to solve

from shed.

I'd probably just use a quoted string to get a non-existent path with an asterisk in it - realistic tests are nice for motivation, but not strictly necessary.

from shed.

Oh nvm me, I skimmed too quickly and didn't see how the returned value was handled. For some reason I thought the error message was ignored when running with git ls-files

from shed.