-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 According to Simon Josefsson on 5/27/2009 4:33 AM: > j...@mocca:~/src/libidn master$ echo 'version 2 '|sed -e 's/version > \(2\|2\.1\)\([ ,]\)/version 3\2/g' > version 3 > > But adding --posix makes it fail: > > j...@mocca:~/src/libidn master$ echo 'version 2 '|sed --posix -e 's/version > \(2\|2\.1\)\([ ,]\)/version 3\2/g' > version 2 > > I'm using GNU sed v4.2 from debian testing. I suspected the final g > parameter to s/// but removing that didn't help. > > Is this a sed bug? It kind of seems like it, but I'm not certain.
While we already determined that the expression is using the non-portable \|, and thus using --posix is allowed to change the behavior, I think we have also found an actual bug in sed 4.2. My preference would be that 'sed --posix' failed with a verbose error message when undefined input like \| is detected, rather than silently changing behavior. POSIX permits either action for unspecified input (treating it as a valid extension, or rejecting it); but from the perspective of a script writer trying to guarantee that they are only using POSIX-specified input, an error message identifying the unspecified use is much friendlier than a silent change in behavior. In other words, I would much rather see sed - --posix behave like it does for other forms of non-POSIX input: $ echo hi | sed/sed v || echo $? hi $ echo hi | sed/sed --posix v || echo $? sed/sed: -e expression #1, char 1: unknown command: `v' 1 $ echo hi | POSIXLY_CORRECT=1 sed/sed v || echo $? hi - -- Don't work too hard, make some time for fun as well! Eric Blake e...@byu.net -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkodKZsACgkQ84KuGfSFAYCOBQCfbcXnzhYXqpv/HHOp8oE2f5Wc 2h8An08mo/X5Jq3uulguNmNlsb1OYSPS =8rFa -----END PGP SIGNATURE-----
