Date: Sun, 07 Jun 2020 20:52:28 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 172862] sed(1) improperly deals with escape chars Message-ID: <bug-172862-227-X3aZ7ZHSBj@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-172862-227@https.bugs.freebsd.org/bugzilla/> References: <bug-172862-227@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D172862 Kyle Evans <kevans@freebsd.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bugs@FreeBSD.org, | |kevans@freebsd.org Assignee|bugs@FreeBSD.org |kevans@freebsd.org --- Comment #5 from Kyle Evans <kevans@freebsd.org> --- \t (and \r and \n) was properly implemented in r355590 and MFC'd to stable/= 12 in r355902. (In reply to Yuri Pankov from comment #3) I tend to agree that it's a standards violation based on my re-reading of t= he spec, but I would propose that it's an OK violation in the name of reasonab= le expectations and not making users' lives harder. \t =3D> t in a bracketed expression serves little value and doesn't accomplish anything you can't do otherwise, but being able to [ \t] to capture the subset of [:space:] that might represent leading indentation you want to normalize. --=20 You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-172862-227-X3aZ7ZHSBj>