Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature request] add is_literal(pattern) #72

Open
gibfahn opened this issue Jan 27, 2019 · 7 comments
Open

[Feature request] add is_literal(pattern) #72

gibfahn opened this issue Jan 27, 2019 · 7 comments

Comments

@gibfahn
Copy link
Contributor

gibfahn commented Jan 27, 2019

It would be really helpful to have a function that tells you whether the input pattern contains any globs.

Basically a version of this that ignores escaped characters:

const GLOB_CHARS: [char; 3] = ['?', '*', '['];

pub fn is_literal(pattern: &str) -> bool {
    // Need to check the characters aren't escaped here.
    !pattern.chars().any(|c| GLOB_CHARS.contains(&c))
}
@gibfahn gibfahn changed the title [Feature request] add is_literal function [Feature request] add is_literal(pattern) Jan 27, 2019
@BurntSushi
Copy link
Member

Could you describe how you want to use this function?

@gibfahn
Copy link
Contributor Author

gibfahn commented Jan 27, 2019

Could you describe how you want to use this function?

Basically I want to do two different things depending on whether the path contains globs or not.

It's useful for example for copy operation (like cp, which does different things depending on whether you have two or more arguments).

@BurntSushi
Copy link
Member

Sorry, I'm not following. Could you spell it out for me?

@gibfahn
Copy link
Contributor Author

gibfahn commented Jan 28, 2019

Sure!

This is a simplification of the actual operation.

I want to copy some files. User provides source and dest paths.

If the user specifies a simple source path it's just a normal copy:

  • e.g. a/b/c -> d/e/f then I create d/e/f with the contents of a/b/c (file or dir).

If the user specifies a glob path then the previous copy approach is no longer possible, so I strip the source path until the first glob and then append that to the dest path.

  • so for a/b/**/c -> d/e/f I create d/e/f/**/c
    • a/b/x/y/c -> d/e/f/x/y/c
    • a/b/y/z/c -> d/e/f/y/z/c

Thus I have different logic paths depending on whether the user provides a literal path or a glob path. This is true even if the glob only resolves to a single path, so I can't just resolve it first.

@kraigher
Copy link

kraigher commented Nov 18, 2019

I am also interested in a similar feature. Basically I want users to be able to specify list of files using glob patterns. I do not want an error if a glob pattern yields an empty list of files. However I want to produce an error if the glob pattern is infact a plain file name and the file is missing.

Thus if would be nice if there was a function which determined if a string was in fact making use of any glob pattern feature or if it was just a plain file name.

@pfmoore
Copy link

pfmoore commented Feb 25, 2020

I would also like this. It would be helpful for implementing "argv globbing" of the form that I see in many other programs (on Windows, where globbing is done by the app, not by the shell). This works as follows:

  • If the argument is a literal, pass it along without modification.
  • If it is a pattern, expand it and insert the list of matches at this point.

The important point is that in a directory containing only a file b, the argument a should be passed unchanged, but the argument a* should become an empty list. So "leave a pattern that matches nothing unchanged" (which is, I believe, what Unix shells do) isn't the desired behaviour here.

@pawroman
Copy link

pawroman commented Dec 2, 2020

The use case I had (mentioned above by @mre) was to determine whether the pattern looks like a glob or plain path.

I ended up doing:

let is_glob = glob::Pattern::escape(value) != value;

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants