5 Limitazioni e non-limitazioni di GNU sed

Per chi vuol scrivere script di sed portabili, è bene sapere che alcune implementazioni sono note per limitare la dimensione delle righe (per il pattern space e per l’hold space) a non più di 4000 byte. Lo standard POSIX specifica che le implementazioni conformi di sed devono supportare dimensioni di riga di almeno 8192 byte. GNU sed non ha limiti precostituiti per la dimensione delle righe; con l’unico limite della memoria (virtuale) allocata da malloc(), si possono inserire o formare righe lunghe a piacere.

Comunque, per trattare sotto-espressioni e ripetizioni indefinite è usata la ricorsione. Questo vuol dire che gli spazi di stack possono limitare la dimensione del buffer che può essere elaborato per alcune espressioni.

Ci sono alcune limitazioni di dimensione nella lunghezza delle espressioni regolari da utilizzare, ma si spera che in pratica non siano quasi mai rilevanti. La lunghezza massima di un’espressione compilata è 65539 (sic) byte. Ogni valore di una specifica di ripetizione dev’essere inferiore a 65536. La massima profondità di nidificazione di tutte le sotto-espressioni tra parentesi, sia quelle che trovano qualcosa, che quelle che non lo fanno,¹⁰, nonché alle dichiarazioni e ad altri tipi di sotto-espressione è 200.

Inoltre, GNU sed riconosce la sintassi POSIX [.ch.] e [=ch=] dove ch è un “insieme di elementi”, ma questi non sono supportati, e viene data una segnalazione di errore se li si incontra.

Qui sotto si possono vedere alcune distinzioni fra le autentiche espressioni regolari in stile Perl e quelle riconosciute da -R.

1. Dichiarazioni rivolte in avanti non possono terminare con quantificatori di ripetizione. Perl li consente, ma non significano quel che si potrebbe pensare. Per esempio, ‘(?!a){3}’ non richiede che i successivi 3 caratteri non siano ‘a’. Richiede invece tre volte che il carattere successivo non sia ‘a’ — uno spreco di tempo e nient’altro.
2. I ritrovamenti di sotto-espressioni regolari che capitano all’interno di dichiarazioni negative rivolte in avanti sono contati, ma i loro elementi sono considerati irrilevanti nella seconda metà di un comando s. Perl imposta le proprie variabili numeriche da ognuna di queste espressioni regolari che sono state trovate prima che la dichiarazione smetta di trovare qualcosa (in questo modo essendo soddisfatta), ma solo se la dichiarazione negativa rivolta in avanti contiene solo una ramificazione.
3. Le seguenti sequenze di protezione Perl non sono supportate: ‘\l’, ‘\u’, ‘\L’, ‘\U’, ‘\E’, ‘\Q’. In effetti esse fanno parte del codice Perl che gestisce le stringhe, e non appartengono a quello che individua le corrispondenze.
4. La dichiarazione Perl ‘\G’ non è supportata perché irrilevante per la ricerca di corrispondenze per una singola espressione regolare.
5. Evidentemente, GNU sed non supporta costrutti ‘(?{code})’ e ‘(?p{code})’. Comunque, c’è qualche supporto in via sperimentale per espressioni regolari ricorsive, usando il metodo non-Perl ‘(?R)’.
6. Quando queste note sono state scritte, c’erano alcune stranezze nella versione Perl 5.005_02 riguardo alle impostazione delle stringhe trovate qualora parte di un’espressione regolare sia ripetuta. Per esempio cercando corrispondenze in ‘aba’ usando l’espressione regolare ‘/^(a(b)?)+$/’ imposta ‘$2’¹¹ al valore ‘b’, cercando in ‘aabbaa’ l’espressione ‘/^(aa(bb)?)+$/’ lascia ‘$2’ non impostato. Comunque, se l’espressione da cercare è cambiata a ‘/^(aa(b(b))?)+$/’ allora ‘$2’ (e ‘$3’) sono impostati. In Perl 5.004 ‘$2’ è impostato in entrambi i casi e questo è anche il caso per GNU sed.
7. Un’altra discrepanza ancora irrisolta è che in Perl 5.005_02 l’espressione regolare ‘/^(a)?(?(1)a|b)+$/’ trova una corrispondenza nella stringa ‘a’, mentre in GNU sed questo non succede. Comunque, sia in Perl che in GNU sed la ricerca di ‘/^(a)?a/’ nella stringa ‘a’ lascia $1 non impostato.