GNU bug report logs - #30919
[grep: input file './x’ is also the output] too late!.. have a null file.

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 30919 in the body.
You can then email your comments to 30919 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: davidpbrown <openforum <at> davidpbrown.co.uk>
To: bug-grep <at> gnu.org
Subject: [grep: input file './x’ is also the output] too late!.. have a null file.
Date: Fri, 23 Mar 2018 19:35:26 +0000

Hi,

Surprised that the error is noted but only after the file gets clobbered.

Example:
=====================
echo "blah" > ./x
grep -v 'foo' ./x > ./x
# grep: input file './x’ is also the output
# results with x being empty.
=====================

Would have expected that catch to be caught ahead of writing a null in
place of the original file.


bash -v
suggests
RELEASE: 2.1
this on Linux Mint.

Regards
davidpbrown

Message #12 received at 30919-done <at> debbugs.gnu.org (full text, mbox):

From: Eric Blake <eblake <at> redhat.com>
To: openforum <at> davidpbrown.co.uk, 30919-done <at> debbugs.gnu.org
Subject: Re: bug#30919: [grep: input file './x’ is also the output] too late!.. have a null file.
Date: Fri, 23 Mar 2018 15:21:50 -0500

tag 30919 notabug
thanks

On 03/23/2018 02:35 PM, davidpbrown wrote:
> Hi,
> 
> Surprised that the error is noted but only after the file gets clobbered.
> 
> Example:
> =====================
> echo "blah" > ./x
> grep -v 'foo' ./x > ./x

Unfortunately, there is nothing grep can do about this.  The file was 
already clobbered by your shell long before the shell even called exec() 
to start grep.

I'm marking this as not a bug in grep's database, because there is 
nothing grep can do about it.  I'm sorry for your data loss, but this is 
a naive beginner's mistake that multiple people have made for multiple 
years.

The error message used in grep is reminiscent of the one used by 'sort 
--o'; at least there, sort really does have a chance to warn you before 
clobbering anything.  But since 'grep -o' already means something 
different than 'sort -o', I'm not sure if it is worth introducing a new 
command line option, just so that:

grep -v foo --new-option-for-output=./x ./x

could properly warn (because in that style, it is grep, rather than the 
shell, that would be opening stdout, and thus could avoid the 
truncation).  But even if we add a new option, it would take years 
before it reaches common distros, and would still be a GNU extension not 
present on other platforms, so you couldn't necessarily rely on it.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.