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

[Assaf Gordon]

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 <address@hidden> 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