Vai al contenuto
Pattern toolkit

Glob pattern tester

Testa pattern glob contro una lista di path. Sintassi compatibile con i pattern di .gitignore, .npmignore e .dockerignore: * (any non-slash), ** (any incluso slash), ? (single char), [abc] (char set), [!abc] (negated set), {a,b,c} (alternation). Ogni riga della lista viene testata e mostrata color-coded match/no-match. Visualizza inoltre la regex equivalente compilata dal glob, copiabile e riusabile in script bash, Python o JavaScript. Per il regex full-power c'è il regex tester dedicato.

Come testare un pattern glob

  1. 1

    Inserisci il pattern

    Sintassi tipica: **/*.js (tutti i.js anche annidati), src/**/*.{ts,tsx} (tutti i TypeScript dentro src), **/node_modules/** (tutto sotto node_modules a qualsiasi livello), logs/[!.]* (file in logs eccetto dotfile).

  2. 2

    Incolla la lista di path

    Una path per riga. Tipicamente output di find. -type f oppure git ls-files. Path relativi o assoluti, slash o backslash; il tester normalizza separatori.

  3. 3

    Bottone 'Testa'

    Match e no-match colorati: verde = match (verra' incluso/escluso), grigio = no-match. Stats in alto: totale, match count, no-match count. Regex compilata visibile sotto, utile per copiare in script bash con =~ o JS con RegExp.

  4. 4

    Itera fino a coverage

    Edita pattern, ri-testa. Tipico flow: parti da pattern restrittivo, allarga finche' tutti i file desiderati matchano. Per .gitignore hardcoda i path che NON vuoi committare e verifica che i file desiderati siano fuori.

Perché un tester dedicato

Il problema con.gitignore. Sintassi simile ma non identica al glob shell: i pattern senza slash matchano a qualsiasi profondita' (*.log matcha logs/foo.log); pattern con slash sono path-relative; ** ha semantica specifica (match cross-directory). Errori comuni: foo/ include solo directory, !foo esclude pattern precedenti. Tester aiuta a capire perché un file viene committato (o non lo e'). Nota: questo tool implementa il subset minimatch / shell glob, NON le regole speciali piene di.gitignore (es. negation chains).

Il problema con minimatch. Bundle JS ~10KB, ma 90% degli use case usano solo i 5-6 metacaratteri base (*, **, ?, [], {}). Il glob compilato qui copre questi 5-6 con ~80 righe di codice, niente dipendenze. Per i casi edge che servono (extglob: !(foo|bar), ?(...), +(...)) serve il vero minimatch.

Compile to regex. Il tester converte il glob in regex e poi testa con RegExp.test(). La regex è visibile, copiabile, riusabile in script bash (=~ in [[) o codice (Python re.match, JS /.../.test()). Comodo per debug di pattern complessi: se il glob fa match strani, leggi la regex compilata e identifica l'errore.

Sintassi supportata

*
Match qualsiasi sequenza di caratteri NON slash. Es. *.js matcha foo.js ma non src/foo.js.
**
Match qualsiasi sequenza incluso slash. Es. src/**/*.js matcha src/foo.js, src/utils/helper.js, src/a/b/c/x.js.
?
Match singolo carattere non-slash. Es. file?.txt matcha file1.txt, fileA.txt ma non file12.txt.
[abc]
Match singolo carattere fra a, b, c. Range supportato: [a-z], [0-9], [A-Za-z0-9].
[!abc] o [^abc]
Match singolo carattere NON fra a, b, c. Negazione utile per [!.]* = no dotfile.
{a,b,c}
Match una delle alternative. Es. *.{js,ts,tsx} matcha file con quelle estensioni.
Letterali
Tutti gli altri caratteri (lettere, numeri, slash, dot) sono letterali. Per matchare letterale * o ?: questo tool NON supporta escape backslash (out of scope, usa regex tester).

Glossario

Termini tecnici usati in questa pagina, spiegati in due righe.

Glob #
Pattern matching language semplificato per file path, originato da Unix shell. Subset di regex con metacaratteri specifici per directory (*, **) e file (?, [], {}).
minimatch #
Libreria JavaScript open source per glob matching, dipendenza di npm, yarn, eslint, jest e di buona parte dell'ecosistema Node. Implementa la grammatica completa dei pattern glob inclusi gli extglob estesi (negazione, ripetizione).
extglob #
Estensione bash 4+ con pattern !(foo), ?(foo), +(foo), *(foo), @(foo). Non supportato da questo tester (use case raro).
.gitignore #
File con regole glob che dicono a git quali file NON tracciare. Sintassi simile shell glob ma con regole specifiche: ! per negation, / path-anchor, ** per cross-directory match.
Path normalization #
Conversione di separatori path: Windows \ -> /. I path con backslash vengono normalizzati prima del match. Trailing slash ignorato.
Brace expansion #
Sintassi {a,b,c} che espande in 3 alternative. Non è regex (regex usa (a|b|c)). Glob compilato espande in regex group con OR.

Domande frequenti

Il tester è compatibile al 100% con minimatch?
No, subset. Implementa * ** ? [] [!] {} + range. Non implementa: extglob bash (!(), ?(), +()), noglobstar options, nocase options, escape \. Per use case minimatch full, usa la libreria reale.
Posso testare pattern.gitignore?
Parzialmente. Le regole base (*.log, build/, **/temp) funzionano. La negation con ! non è supportata (e' una regola speciale di.gitignore non glob shell standard). Per testare gitignore reale: git check-ignore -v file/path.
Path con spazi funzionano?
Si', il tool tratta ogni linea come un path letterale. Spazi nei path sono caratteri normali. Niente bisogno di quoting/escape.
Match è case-sensitive?
Si', sempre. Per case-insensitive, normalizza prima la lista (es. tutto lowercase) e usa pattern lowercase. Non c'e' flag di compilazione qui.
Come testo che un pattern NON matcha?
Aggiungi alla lista i path che vuoi escludere e verifica che siano in 'No match'. Per testing inverso (matchare path che il pattern NON deve catturare): pattern complementare costruito a mano, pattern union ({a,b,c}), oppure passa a regex tester.
Il pattern viene compilato a regex: posso copiarla?
Si', la regex è mostrata sotto la lista risultati. Sintassi PCRE-compatibile (funziona in PHP preg_match, JS RegExp, Python re). Per bash con =~: rimuovi i delimitatori /.../ e usa direttamente la stringa.
Limite di righe nella lista?
Tecnicamente nessuno, ma per liste >10000 path il render diventa lento. Per dataset enormi: filtra prima la lista (es. solo file di interesse) o usa find... | grep -E '' da terminale.

Chi sviluppa questi strumenti?

Maurizio Fonte, consulente IT senior con oltre 20 anni di esperienza in PHP, Laravel, infrastrutture Linux, cybersecurity e integrazione AI/LLM in azienda. Backend di produzione, modernizzazione di codice legacy, audit di sicurezza, agenti AI e MCP server custom: il lavoro che sta dietro a questi strumenti.

Conosci Maurizio Fonte