emacs-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[debbugs-tracker] bug#30919: closed ([grep: input file './x’ is also the


From: GNU bug Tracking System
Subject: [debbugs-tracker] bug#30919: closed ([grep: input file './x’ is also the output] too late!.. have a null file.)
Date: Fri, 23 Mar 2018 20:22:03 +0000

Your message dated Fri, 23 Mar 2018 15:21:50 -0500
with message-id <address@hidden>
and subject line Re: bug#30919: [grep: input file './x’ is also the output] too 
late!.. have a null file.
has caused the debbugs.gnu.org bug report #30919,
regarding [grep: input file './x’ is also the output] too late!.. have a null 
file.
to be marked as done.

(If you believe you have received this mail in error, please contact
address@hidden)


-- 
30919: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=30919
GNU Bug Tracking System
Contact address@hidden with problems
--- Begin Message --- Subject: [grep: input file './x’ is also the output] too late!.. have a null file. Date: Fri, 23 Mar 2018 19:35:26 +0000 User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
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



--- End Message ---
--- Begin Message --- 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 User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
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


--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]