“Her Yerde” Çalışan Düzenli İfadeler

 (johndcook.com)
3 puan yazan GN⁺ 14 시간 전 | 1 yorum | WhatsApp'ta paylaş
  • Düzenli ifadelerde desteklenen özellikler ve sözdizimi implementasyona göre değişir; bir araçta çalışan bir desen başka bir ortamda başarısız olabilir veya değiştirme gerektirebilir
  • Perl gibi özellik açısından zengin ortamlara ne kadar alışkınsanız, uyumluluk sorunlarıyla o kadar sık karşılaşırsınız; yazılım kurma yetkinizin olmadığı bilgisayarlar da düşünülünce ortak alt küme kullanmak daha güvenlidir
  • “Her yerde” ifadesini en katı biçimde tanımlarsanız, kapsam yalnızca literal’ler, […] karakter sınıfları ve . * ^ $ gibi temel özel karakterler kalacak kadar daralır
  • GNU sed, awk, grep kullanıp sed ve grep ile birlikte -E seçeneğini eklerseniz, kullanılabilir ortak özellikler genişler; ancak bu kombinasyonda awk genellikle en küçük ortak payda olur
  • Emacs’te +? ( ) { } | için ters eğik çizgi gerekir ve \s, \S anlamları da farklıdır; aynı düzenli ifadeyi birden çok araçta kullanmak için istisna sözdizimini de kontrol etmek gerekir

Düzenli ifade uyumluluğu neden zordur

  • Düzenli ifadelerin en büyük rahatsızlığı implementasyona göre farklılıklardan kaynaklanır
    • Bir araçta desteklenen bir özellik başka bir araçta hiç olmayabilir
    • Aynı özellikte bile sözdizimi biraz farklı olabilir
  • Perl, özellik bakımından zengin bir düzenli ifade ortamıdır; bu yüzden Perl’de doğal görünen bir özellik başka ortamlarda eksik olabilir
  • Başka araçların Perl benzeri alternatiflerini kullanmak da mümkündür, ancak bunlar standart değildir; bu da iş arkadaşlarına ya da müşterilere doğrudan çalışacak kod göndermeyi zorlaştırır
  • Yazılım kuramadığınız bilgisayarlarda da çalışmanız gerekebileceğini düşünürseniz, birden fazla ortamda çalışan düzenli ifade özellikleri alt kümesini bulma yaklaşımı gerekir
  • “Her yerde” tanımını ne kadar katı yaparsanız, kullanabileceğiniz özellikler o kadar azalır
    • literal’ler
    • […] karakter sınıfları
    • . * ^ $ özel karakterleri

sed, awk, grep ve Emacs’te ortak kapsama alanı

  • Hedef araçları sed, awk, grep, Emacs ile sınırlarsanız, “her yerde” ölçütünü biraz gevşetebilirsiniz
  • GNU sürümlerindeki sed, awk, grep kullanılır ve sed ile grep için -E seçeneği uygulanırsa ortak özellik listesi genişler
    • Bu üç aracın düzenli ifade özellikleri benzerdir
    • awk özellikleri diğer araçlarda da genellikle desteklenir
    • İstisna olarak kelime sınırı için awk, \b, \B yerine \<, \> kullanır
  • Emacs, awk özelliklerinin çoğunu karşılar ama sözdizimi farkları vardır
    • + ? ( ) { } | karakterlerinin awk ile aynı işlevi görmesi için başlarına ters eğik çizgi gelmelidir
    • awk içindeki \s, \S karşılıkları Emacs’te \s-, \S- şeklindedir
  • Emacs’te \s, \S, boşluk/boşluk dışı anlamına gelmez; karakter sınıfı başlatır
    • - sınıfı boşluğu ifade eder
    • \s. noktalama karakteridir
    • \S. noktalama dışı karakterdir
  • Bu ölçüte göre kullanılabilecek özellikler şunlardır
    • .
    • ^, $
    • […], [^…]
    • *
    • \w, \W, \s, \S
    • \1 ile \9 arasındaki geri başvurular
    • \b, \B
    • ?, +
    • | alternation
    • {n,m} tekrar sayısı
    • (...) yakalama
  • Ancak gawk, değiştirme dizelerinde geri başvuruları desteklese de düzenli ifadenin kendisinde geri başvuruları desteklemez
  • look-around ileri düzey bir özellik sayılabilir; \d ise sayılar için temel bir özellik gibi görünebilir, ancak birçok düzenli ifade varyantında desteklenmez

İlgili okumalar

1 yorum

 
GN⁺ 14 시간 전
Hacker News yorumları

  • Emacs’te neyin kaçış karakteriyle yazılması gerektiğini neredeyse tahmin etmeye çalışıyormuşsunuz gibi olduğu için özellikle zorlanıyorum
    rx adlı bir alternatif de var[0], ama pratikte kullanması pek keyifli değil
    Regex sözdiziminin ötesinde, gerçek kullanım aşamasında da kodlama ve kaçış sorunları sık sık ortaya çıkıyor
    Kabukta regex giriyorsanız düzgün kaçış uygulamanız gerekiyor; Python’da ise raw string olup olmadığını kontrol etmeniz gerekiyor
    Yine de çoğu araçta regex kullanma biçiminin bir ölçüde benzer bir aralığa oturmuş olması modern bir mucizeye yakın
    [0]: https://www.gnu.org/software/emacs/manual/html_node/elisp/Rx...

    • İçinde regex bulunan kabuk betikleri üreten Python yazınca iş daha da eğlenceli hâle geliyor
      Farklı kaçış kurallarının iç içe geçtiği durumlar sürekli yaşanıyor
    • Zoraki bir avantaj bulmak gerekirse, arama hedefi Elisp kodu olduğunda ( ve ) karakterlerinin olduğu gibi eşleşmesi biraz kullanışlı
    • Regex, çeşitli DSL’lerin karması değil, yapılandırılmış bir dil olmalıydı

  • Yazar neredeyse oraya varacak gibi oluyor ama sonuçta POSIX temel düzenli ifadelerinin her yerde çalıştığını söylemek istiyor gibi
    Ancak Single Unix Specification 8. baskısına herkes yetişmiş değil ve o baskıda BRE’nin biraz değiştiği notu düşülüyor

    • Bu değerlendirme yazara pek adil görünmüyor
      Böyle bir not olmasaydı zaten o yazıyı yazmaya gerek kalmazdı

  • Eskiden hem açgözlü semantik hem de leftmost maximal semantik altında aynı şekilde eşleşen regex’leri bulmaya dair bir makale yazmıştım
    https://par.nsf.gov/servlets/purl/10534654

  • Hangi aracın hangi regex dilini kabul ettiğini ve rastgele bir alt dizeyi, öneki, soneki, tüm dizeyi, bir satırı ya da satır içindeki bir alt dizeyi mi eşleştirdiğini netleştirme konusunda hep titiz davrandım
    Burada [daha yaygın kullanılanlar][1] var; ayrıca PCRE ve Python da mevcut
    grep gibi yerlerde görülen eski biçimlerin bir kısmının [POSIX’te belirtildiğini][2] öğrenmem biraz zaman aldı
    [1]: https://cppreference.com/cpp/regex#Regular_expression_gramma...
    [2]: https://pubs.opengroup.org/onlinepubs/009696899/basedefs/xbd...

  • Russ Cox’un regex sayfasını paylaşmak isterim
    Okumaya değer iyi bir kaynak olduğunu düşünüyorum
    https://swtch.com/~rsc/regexp/

  • Bu nedenle RFC 9485, yani I-Regexp: An Interoperable Regular Expression Format önemli
    https://datatracker.ietf.org/doc/html/rfc9485

  • Go standart kütüphanesindeki regexp paketi, RE2 motorunu kullandığı için backreference desteklemez
    Yerine koymada kullanılabilir ama eşleştirmede kullanılamaz

    • regexp, re2 kullanmıyor; aynı kavramların ayrı bir uygulaması

  • Kural motorları, şablon motorları ve IFTTT türü motorlarda benzer hayal kırıklıkları yaşadıktan sonra JSONLogic için Rust kütüphanesi yaptım ve başka diller için bağlamalarını da kullanıyorum
    https://github.com/GoPlasmatic/datalogic-rs

  • JSON Schema belgelerinde de önerilen bir regex alt kümesi var
    https://json-schema.org/understanding-json-schema/reference/...