रेगेक्स अक्षर "$" का मतलब "end-of-string" नहीं है

मूल लेख ↗ Hacker News चर्चा ↗

Regular expression users are debating how the `$` anchor should behave: many expect it to mean “end of string,” but in languages like Python, Java, .NET, PHP, Ruby and Perl it can also match just before a final newline, while JavaScript, Go, Rust and RE2 treat it strictly as end-of-string when multiline mode is off. Commenters trace this to historical line-oriented tools and differing regex dialects (POSIX BRE/ERE, PCRE, RE2, custom engines), noting that these subtle differences can cause real bugs and security issues in input validation. The consensus is that there is no universal regex standard, so developers must read the engine-specific docs, write targeted tests, and use anchors like `\A`/`\Z` where available if they truly want start/end-of-string semantics.

मुख्य विवाद: $ का क्या अर्थ है

  • थ्रेड इस तथ्य पर केंद्रित है कि कई इंजनों में, non‑multiline mode में $ या तो end-of-string से मेल खाता है या trailing \n से ठीक पहले, न कि सख्ती से “end-of-string” से।
  • कुछ इंजन (JS, Go, Rust, RE2-style) multiline off होने पर $ को “end of string” के बराबर बनाते हैं।
  • अन्य (Python, Java, C#, PHP, Perl, PCRE, आदि) $ को “end of line” की तरह मानते हैं, और एक अकेले trailing newline के लिए विशेष मामला रखते हैं।
  • कई टिप्पणीकारों को Python/Perl-शैली का व्यवहार चौंकाने वाला और “whacky” लगता है, खासकर cat$ का cat\n\n से match न होना।

लाइन बनाम स्ट्रिंग semantics

  • एक बड़ा subthread इस पर बहस करता है कि $ अवधारणात्मक रूप से “end of line” है या “end of string”।
  • एक पक्ष ऐतिहासिक, line-based दृष्टिकोण (editors, ed/sed/grep से आया) का हवाला देकर कहता है कि $ का trailing newline को विशेष रूप से संभालना उचित है।
  • दूसरा पक्ष जवाब देता है कि अधिकांश APIs arbitrary strings लेते हैं, lines नहीं, इसलिए users का यह मानना उचित है कि $ का अर्थ “end of string” होना चाहिए।
  • POSIX में “line,” “incomplete line,” और newline को terminator बनाम separator मानने से $ पर क्या प्रभाव पड़ना चाहिए, इस पर भी बहस है।

Regex dialects और (मानकीकरण का अभाव)

  • कई लोग नोट करते हैं कि कोई एक regex standard नहीं है; कई परिवार हैं:
    • POSIX BRE/ERE, जिनकी anchor semantics अलग होती हैं।
    • Perl/PCRE और उनके descendants (PHP, कई languages, PCRE2)।
    • RE2-style, जिसका उपयोग Go और Rust की regex crate करती है, जो कुछ Perl quirks से जानबूझकर बचते हैं।
    • JavaScript की ECMA regex, जिसकी अपनी gaps और features हैं।
  • C++ <regex>, ECMA-262, POSIX, और एक हालिया RFC (I-Regexp) को formal specs के रूप में mention किया गया है, लेकिन वे behavior को एकीकृत करने के बजाय साथ-साथ मौजूद हैं।

Security और correctness के प्रभाव

  • trailing newline से पहले $ का match होना वास्तविक bugs का कारण बना है, जैसे Ruby input validation और ExifTool/GitLab vulnerabilities में, जहाँ attackers newline के बाद payload smuggle कर लेते हैं।
  • कई टिप्पणियों में सलाह दी गई है: जब आपका असली मतलब “whole string” हो, तो उपलब्ध होने पर \A...\Z या \z का उपयोग करें, ^...$ नहीं।

Tooling, usage patterns, और ergonomics

  • बहुत से लोग सलाह देते हैं कि हमेशा specific engine की docs देखें और regexes को स्पष्ट रूप से test करें।
  • कुछ लोग line-oriented tools (grep/sed/awk, Vim जैसे editors) को पसंद करते हैं और lines के संदर्भ में सोचते हैं; दूसरे मुख्यतः in-memory strings के साथ काम करते हैं और string semantics की अपेक्षा करते हैं।
  • regex flavor fragmentation, escaping rules, और character classes तथा anchors के असंगत समर्थन को लेकर व्यापक frustration भी दिखती है।