Come si esegue il debug di una regex? [chiuso]

Le espressioni regolari possono diventare piuttosto complesse. La mancanza di spazi bianchi li rende difficili da leggere. Non posso passare attraverso un'espressione regolare con un debugger. In che modo gli esperti eseguono il debug di espressioni regolari complesse?

Acquista RegexBuddy e utilizzi la sua funzionalità di debug integrata . Se lavori con regexes più di due volte all'anno, otterrai questi soldi indietro nel tempo risparmiati in pochissimo tempo. RegexBuddy ti aiuterà anche a creare espressioni regolari semplici e complesse e persino a generare il codice per te in una varietà di lingue.

Inoltre, secondo lo sviluppatore, questo strumento funziona quasi perfettamente su Linux se usato con WINE .

Con Perl 5.10, use re 'debug';. (Oppure debugcolor, ma non riesco a formattare correttamente l'output su Stack Overflow.)

$ perl -Mre = debug -e '"foobar" = ~ / (.) \ 1 /'
Compilare REx "(.) \ 1"
Programma finale:
   1: OPEN1 (3)
   3: REG_ANY (4)
   4: CLOSE1 (6)
   6: REF1 (8)
   8: END (0)
minlen 1
Corrispondenza di REx "(.) \ 1" contro "foobar"
   0 <> <foobar> | 1: aperta1 (3)
   0 <> <foobar> | 3: REG_ANY (4)
   1 <f> <oobar> | 4: Close1 (6)
   1 <f> <oobar> | 6: RIF1 (8)
                                  fallito ...
   1 <f> <oobar> | 1: aperta1 (3)
   1 <f> <oobar> | 3: REG_ANY (4)
   2 <fo> <obar> | 4: Close1 (6)
   2 <fo> <obar> | 6: RIF1 (8)
   3 <foo> <bar> | 8: END (0)
Incontro riuscito!
Liberazione di REx: "(.) \ 1"

Inoltre, puoi aggiungere spazi bianchi e commenti alle regex per renderli più leggibili. In Perl, questo viene fatto con il /xmodificatore. Con pcre, c'è la PCRE_EXTENDEDbandiera.

"foobar" =~ /
    (.)  # any character, followed by a
    \1   # repeat of previously matched character
/x;

pcre *pat = pcre_compile("(.)  # any character, followed by a\n"
                         "\\1  # repeat of previously matched character\n",
                         PCRE_EXTENDED,
                         ...);
pcre_exec(pat, NULL, "foobar", ...);

Ne aggiungerò un altro per non dimenticarlo: debuggex

È buono perché è molto visivo:

Quando rimango bloccato su un regex di solito mi rivolgo a questo: https://regexr.com/

È perfetto per testare rapidamente dove qualcosa non va.

Uso Kodos - The Python Regular Expression Debugger:

Kodos è un'utilità della GUI di Python per la creazione, il test e il debug di espressioni regolari per il linguaggio di programmazione Python. Kodos dovrebbe aiutare qualsiasi sviluppatore a sviluppare in modo efficiente e senza sforzo espressioni regolari in Python. Poiché l'implementazione di espressioni regolari da parte di Python si basa sullo standard PCRE , Kodos dovrebbe favorire gli sviluppatori in altri linguaggi di programmazione che aderiscono allo standard PCRE (Perl, PHP, ecc ...).

(...)

Funziona su Linux, Unix, Windows, Mac.

Penso che non lo facciano. Se regexp è troppo complicato e problematico al punto che è necessario un debugger, è necessario creare un parser specifico o utilizzare un altro metodo. Sarà molto più leggibile e mantenibile.

Esiste un eccellente strumento gratuito, il Regex Coach . L'ultima versione è disponibile solo per Windows; il suo autore Dr. Edmund Weitz ha smesso di mantenere la versione Linux perché troppe persone l'hanno scaricata, ma c'è una versione precedente per Linux nella pagina di download.

Ho appena visto una presentazione di Regexp :: Debugger del suo creatore: Damian Conway. Roba molto impressionante: esegui sul posto o usando uno strumento da riga di comando (rxrx), in modo interattivo o su un file di esecuzione "registrato" (memorizzato in JSON), fai un passo avanti e indietro in qualsiasi punto, fermati su punti di interruzione o eventi, output colorato (configurabile dall'utente ), mappe di calore su regexp e stringa per ottimizzazione, ecc ...

Disponibile su CPAN gratuitamente: http://search.cpan.org/~dconway/Regexp-Debugger/lib/Regexp/Debugger.pm

Uso questo strumento online per eseguire il debug del mio regex:

https://www.regextester.com/

Ma sì, non può battere RegexBuddy.

Debug dei miei regex con i miei occhi. Ecco perché uso il /xmodificatore, scrivo commenti per loro e li divido in parti. Leggi Mastering Regular Expressions di Jeffrey Friedl per imparare a sviluppare espressioni regolari veloci e leggibili. Vari strumenti di debug regex provocano solo la programmazione voodoo.

Per quanto mi riguarda di solito uso l'utilità pcretest che può scaricare il codice byte di qualsiasi regex, e di solito è molto più facile da leggere (almeno per me). Esempio:

PCRE version 8.30-PT1 2012-01-01

  re> /ab|c[de]/iB
------------------------------------------------------------------
  0   7 Bra
  3  /i ab
  7  38 Alt
 10  /i c
 12     [DEde]
 45  45 Ket
 48     End
------------------------------------------------------------------

Io uso:

http://regexlib.com/RETester.aspx

Puoi anche provare Regex Hero (usa Silverlight):

http://regexhero.net/tester/

Se mi sento bloccato, mi piace tornare indietro e generare la regex direttamente da un testo di esempio usando txt2re (anche se di solito finisco per modificare manualmente la regex risultante).

Se sei un utente Mac, mi sono appena imbattuto in questo:

http://atastypixel.com/blog/reginald-regex-explorer/

È gratuito e semplice da usare ed è stato di grande aiuto per me per affrontare RegExs in generale.

Dai un'occhiata agli strumenti (non gratuiti) su regular-expressions.info . RegexBuddy in particolare. Ecco il post di Jeff Atwood sull'argomento .

Scrivere reg ex usando una notazione come PCRE è come scrivere assemblatore: va bene se riesci a vedere solo gli automi a stati finiti corrispondenti nella tua testa, ma può essere difficile da mantenere molto rapidamente.

Le ragioni per non usare un debugger sono molto simili a quelle per non usare un debugger con un linguaggio di programmazione: puoi correggere gli errori locali, ma non ti aiuteranno a risolvere i problemi di progettazione che ti hanno portato a fare gli errori locali nel primo posto.

Il modo più riflessivo è utilizzare le rappresentazioni dei dati per generare regexps nel tuo linguaggio di programmazione e avere astrazioni appropriate per costruirle. L'introduzione di Olin Shiver alla notazione regexp del suo schema offre un'eccellente panoramica delle problematiche affrontate nella progettazione di queste rappresentazioni dei dati.

Uso spesso pcretest - quasi un "debugger" ma funziona su una connessione SSH di solo testo e analizza esattamente il dialetto regex di cui ho bisogno: il mio codice (C ++) si collega a libpcre, quindi non ci sono difficoltà con sottili differenze in ciò che è magico e cosa non lo è, ecc.

In generale, sono d'accordo con il ragazzo sopra a chi ha bisogno di un debugger regex è un odore di codice. Per me il più difficile usare regex non è di solito la regex stessa, ma i molteplici livelli di quotazione necessari per farli funzionare.

Io uso spesso regexp basato Rubino tester Rubular

e anche in Emacs usa M-x re-builder

Firefox ha anche un'estensione utile

Uso Rx Toolkit incluso in ActiveState Komodo .

Puoi provare questo http://www.pagecolumn.com/tool/regtest.htm

Per me, dopo aver osservato il regex (dato che sono abbastanza fluente e quasi sempre uso / x o equivalente), potrei eseguire il debug piuttosto che testare se non sono sicuro di colpire un abbinamento degenerato (cioè qualcosa che fa eccessivamente arretramento) per vedere se potevo risolvere tali problemi modificando, ad esempio, l'avidità di un operatore.

Per fare ciò, utilizzerei uno dei metodi sopra menzionati: pcretest, RegexBuddy (se il mio attuale posto di lavoro lo ha concesso in licenza) o simile, e talvolta lo cronometro in Linqpad se lavoro in regex C #.

(Il trucco perl è nuovo per me, quindi probabilmente lo aggiungerò anche al mio toolkit regex.)