grep does not output null when -o -z is used

Bug #1621226 reported by Jarno Suni
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
grep (Ubuntu)
Fix Released
Undecided
Unassigned
Trusty
New
Undecided
Unassigned

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)

Revision history for this message
Jarno Suni (jarnos) wrote :
Jarno Suni (jarnos)
description: updated
Jarno Suni (jarnos)
Changed in grep (Ubuntu):
status: New → Fix Released
description: updated
Jarno Suni (jarnos)
description: updated
Revision history for this message
Robie Basak (racb) wrote :

<jarnos> I suggest Bug #1621226 should be SRUed.

<rbasak> jarnos: that's reasonable, but it's also a change in behaviour that users may be relying on, as grep tends to be used quite a bit in scripts.

<rbasak> So I'm not sure.

<rbasak> I added a task in the bug for you. Can discuss in there.

Jarno Suni (jarnos)
description: updated
Jarno Suni (jarnos)
summary: - grep does not output null when -o is used
+ grep does not output null when -o -z is used
description: updated
description: updated
description: updated
Jarno Suni (jarnos)
description: updated
Revision history for this message
Robie Basak (racb) wrote :

<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.

Revision history for this message
Jarno Suni (jarnos) wrote :

sounds fine.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.