GNU bug report logs - #25587
In -i mode, shouldn't sed continue processing the command line if it can't access some files?

Previous Next

Full log

View this message in rfc822 format

From: Assaf Gordon <assafgordon <at> gmail.com>
To: Norihiro Tanaka <noritnk <at> kcn.ne.jp>, Zack Weinberg <zackw <at> panix.com>
Cc: 25587 <at> debbugs.gnu.org
Subject: bug#25587: In -i mode, shouldn't sed continue processing the command line if it can't access some files?
Date: Tue, 9 Oct 2018 08:14:16 -0600

tags 25587 notabug
close 25587
stop

Hello,

(catching up on old reports)

On 31/01/17 04:51 PM, Norihiro Tanaka wrote:
> 
> On Tue, 31 Jan 2017 10:12:34 -0500
> Zack Weinberg <zackw <at> panix.com> wrote:
> 
>> Consider
>>
>> $ mkdir test
>> $ cd test
>> $ printf 'foo\nbar\n' > a
>> $ mkdir b
>> $ printf 'foo\nbar\n' > c
>> $ sed -i '$d' *
>> sed: couldn't edit b: not a regular file
>> $ ls -l
>> -rw-r--r-- 1 zack zack    4 Jan 31 10:06 a
>> drwxr-xr-x 2 zack zack 4096 Jan 31 10:06 b
>> -rw-r--r-- 1 zack zack    8 Jan 31 10:06 c
>>
>> I find this behavior surprising.  In -i mode, I think sed should go on
>> to process 'c' even though it failed to process 'b'.
>>
> 
> perl works as you say, but I seem that it is designed.
[...]
> grep skips errors, and gawk stops at error.
> i.e. the behavior is different between commands.

Thank you Norihiro for testing and reporting more programs.

I will add that the {Open,Free,Net}BSD sed implementation
behaves like GNU sed (i.e. stops immediately after failure
without changing 'c'),
while busybox's sed implementation does process all files
(including creating an empty file 'b' !! which is not less surprising).

With that, and the fact that this behavior has been in place for many
years and shouldn't be changed, I'm inclined to close this bug report.

Discussion can continue by replying to this thread.

regards,
 - assaf

Previous Next

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