<jarnos> rbasak, well, that bug has not got any visible attention from others, so I don't know who I am discussing it with.
<jarnos> rbasak, no-one should rely on behavior that makes output ambiguous. The bug is fixed in 16.04 anyway. <rbasak> jarnos: I don't think it matters where users "should" rely on behaviour or not. For a stable release, what matters is if they *are*, and if an SRU will break them. <jarnos> rbasak, their scripts are broken anyway. <rbasak> jarnos: it doesn't matter. If their scripts happen to work now, and we change behaviour in an SRU such that they break, then that needs to be considered. <rbasak> jarnos: unless you can demonstrate that it isn't possible to write a script that would change behaviour after your proposed update? <rbasak> jarnos: you'd be discussing the issue with me in the bug, but also leaving a record of the discussion so that if another member of the SRU team considers the bug, that person can see the previous discussion. <rbasak> jarnos: presumably you need the fix for some reason. But there are other ways to find a workaround that don't involve changing behaviour but might be useful to affected users. For example, a flag in the environment. These should be discussed, but I feel you first need to understand my point about not breaking users despite their scripts "being broken". <rbasak> You can't dismiss users like that. <rbasak> Just because they're wrong doesn't mean we can break them in a stable release. <jarnos> rbasak, how would a flag in environment help? <jarnos> rbasak, fixing the bug would make it possible for them to fix their scripts. <rbasak> jarnos: you could land an SRU that doesn't change behaviour, except when you want it to do so. <rbasak> jarnos: 16.04 makes it possible for them to fix their scripts. <rbasak> jarnos: and an environment flag would also do this for 14.04, but without breaking users surprisingly. <jarnos> rbasak, not, if you want to make a script that works in both. <rbasak> jarnos: if you want a script that works in both, SRU my environment flag proposal, then set the environment in your script. You'll then get consistent behaviour in both. I'm not saying it has to be this way, but it is an option that minimises regression risk to existing users. <jarnos> rbasak, What is your environment flag proposal? <rbasak> jarnos: SRU the fix to 14.04, but adjust it so that it maintains previous broken behaviour unless the environment variable FIX_LP_1621226 is set. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to grep in Ubuntu. https://bugs.launchpad.net/bugs/1621226 Title: grep does not output null when -o -z is used Status in grep package in Ubuntu: Fix Released Status in grep source package in Trusty: New Bug description: Impact Grepping null terminated records with -o option does not work. There may be a newline in a matched string, so the output may be ambiguous as the matched parts are separated by newline. This bug prevents users from using grep in some scripts that they want to work in all supported releases. Test Case $ printf 'a\0b\0b1' | grep --null-data b | hexdump -C 00000000 62 00 62 31 00 |b.b1.| 00000005 but $ printf 'a\0b\0b1' | grep -o --null-data b | hexdump -C 00000000 62 0a 62 0a |b.b.| 00000004 Expected result: 00000000 62 00 62 00 |b.b.| 00000004 Regression Potential Not remarkable. Scripts using -o -z are broken anyway with the broken grep. This is fixed in Xenial, but IMO should be fixed in Trusty, too. ProblemType: Bug DistroRelease: Ubuntu 14.04 Package: grep 2.16-1 ProcVersionSignature: Ubuntu 4.4.0-37.56~14.04.1-generic 4.4.19 Uname: Linux 4.4.0-37-generic x86_64 ApportVersion: 2.14.1-0ubuntu3.21 Architecture: amd64 CurrentDesktop: XFCE Date: Wed Sep 7 22:48:42 2016 EcryptfsInUse: Yes InstallationDate: Installed on 2014-09-21 (717 days ago) InstallationMedia: Ubuntu-Studio 14.04.1 LTS "Trusty Tahr" - Release amd64 (20140722.1) SourcePackage: grep UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/grep/+bug/1621226/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
