support $ interpolation in glob"..." macro?

[stevengj]

Since $ isn't used for glob patterns, it might be nice to implement Julia interpolation when a non-backslashed $ is encountered in glob"..." rather than treating it as a literal dollar sign.

(See also discourse.)

[ryofurue]

As discussed in #47 , you can use Glob.GlobMatch(...) to construct a Glob from a String.

This strategy is analogous to regex: Instead of allowing for string interpolation in r"...", it provides the Regex(...) constructor. See the official documentation of regex.

[stevengj]

Using Glob.GlobMatch("...") has the disadvantage of requiring you to escape backslashes. You could do it that way, but why not support $ interpolation in the glob macro itself?

Regexes are different, because $ is already a metacharacter for regexes.

[ryofurue]

Regexes are different, because $ is already a metacharacter for regexes.

I see your point and I agree with you! Thank you for your clarification.

While we are at it, I also wish the standard string concatenation worked on Globs. With Regex, you can do something like this:

a = r"hello"
b = r".*\.jpg"
m = match(a*b, "hello3.jpg") # matches

You sometimes prefer string interpolation and sometimes concatenation, depending on the complexity.

[stevengj]

I would make concatenation a separate issue, because its implementation seems entirely separate from (and much simpler than) that of interpolation.

[stevengj]

Note that @vtjnash commented on this issue on discourse and also #47 (comment)

He noted that if you are using this to interpolate path components then you have to be careful, because arbitrary paths might contain glob metacharacters that should be escaped to be treated as literals within a glob.

[vtjnash]

Right, as I mentioned there, this is somewhat intentionally unimplemented, as putting a path into the fnmatch is rather risky (it doesn't work well on Windows with the path separator is different or on Unix where metacharacters are legal in the path itself), so doing exactly raw text seemed the least surprising, and the most similar to fnmatch in a shell

We also could do something slightly special (relative to most shells), where fnmatch treats the contents of the $ as something that must be matched explicitly (and ignores embedded metacharacters) by putting a \ before every (special) character in the value to splice in

[ryofurue]

He noted that if you are using this to interpolate path components then you have to be careful, because arbitrary paths might contain glob metacharacters that should be escaped to be treated as literals within a glob.

As I said, I understand your point, but my argument is different . . . If we didn't have Glob in the first place, we would be doing this:

a = "hello"
for file in readdir()
   m = match(Regex("$(a).*\\.jpg")) # You have to be careful!
   isnothing(m) && continue # skip the file if it doesn't match the pattern
   # . . .
end

The same risk as you are talking about exists in the above code.

For that reason, I didn't understand why you needed to emphasize this risk. (It seemed to me that you were pointing to the risk as an argument not to implement these features.)

[vtjnash]

I am not opposed, but just noting that since globs are not filepaths (e.g. glob"a//b" does not match the path "a//b" and starting with "/" isn't legal), there seems like a lot of hidden complexity in what happens if someone does try to include something there other than a simple file path ending in / or followed by /. That doesn't happen at all if you use that same string as the readdir argument for the starting directory, or happens more obviously if you construct the Glob object explicitly. The API here was intended to be loosely based around regex"" vs Regex(raw""), which is how regexes are relevant to understanding what is expected behavior here (otherwise fnmatch isn't especially necessary, since unlike with PCRE2's implementation of a regex, it is essentially free to construct an FnMatcher at runtime)