Support for glob matching

[BuonOmo]

Hi Lucio,

Thanks for the great tool, be sure I've already told all my coworkers about it, since it is an idea I wanted to work on for a long time (same issues with dotjs, and the monkey userscripts are just way less user friendly IMHO).

Anyway, I have a feature request, which I'll illustrate with GitHub paths. Say for instance I'd like to have a script for all my project settings github.com/a/b/settings. I must copy for that every project, or create a github.com.js that will look at the url. However, we could solve that one quite fast with glob matching:

github.com/BuonOmo/*/settings.js
github.com/B*/*/settings.js

The glob would act like a bash glob, with only the star pattern since ? may be confusing with urls.

I'd be glad to implement it at some point, just opening the issue for discussion beforehand 🙂

Best regards, Ulysse

[luciopaiva]

Hey @BuonOmo, thanks for the suggestion.

Yeah, the way I would do this is by creating a github.com.js and parsing the URL there to see if I am in the settings page of some project, like you suggested yourself.

At first sight, doing a wildcard match looks undesirable to me for a couple of reasons. First, we'd have no easy way of telling if the user wants glob matching or not. Say I have a script called /github.com/settings.js. Do I mean to strictly match https://github.com/settings.js or do I want to match everything inside github.com that ends with settings? What if it has settings in the middle of the path, should we match it too? Did the user mean to match github.com/set*ttings.js by any chance? I think you got the idea. We could adopt some symbol to represent the wildcard char (since the OS won't allow *), but we'd need to pick something that would be allowed by the OS while not being allowed in a real URL. Seems a bit too much complex logic to add to Witchcraft considering the second reason that comes to my mind is that doing the github.com.js URL parsing approach is pretty easy to do 🙂

Makes sense?

[BuonOmo]

At first sight, doing a wildcard match looks undesirable to me for a couple of reasons. First, we'd have no easy way of telling if the user wants glob matching or not. Say I have a script called /github.com/settings.js. Do I mean to strictly match https://github.com/settings.js or do I want to match everything inside github.com that ends with settings?

Glob matching does not mean uncomplete matching! /github.com/settings would still mean the same! However, /github.com/settings* could mean /github.com/settingsfoo (and not /github.com/settings/foo IMHO, yet this could be discussed).

In fact glob matching would be the same as in usual bash terminals

since the OS won't allow *

I'll have to admit, I've never worked on something else than Ubuntu, Mac OS or Debian, yet touch 'foo*' works well on those OS!

---

Anyway, I feel like this would be a great benefit because URL parsing is already redundant with the basic project idea of following folders to match urls (there are two layers of routing), however I get that this is adding too much complexity, I'll probably just have my dedicated branch sooner or later then 🙂

[luciopaiva]

Yep, Windows won't not accept * as a valid file name character. I'd also avoid using it on other operating systems anyway, not only due to portability issues but also because it could cause confusion to other users (I honestly didn't know it was possible to use asterisks - but I've just tried on my Mac and it really worked 😂).

Cool, let me know how it goes with your fork!

I'll close the ticket for now, but feel free to reopen it later if you feel like adding something.

Thanks!