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

[Norihiro Tanaka]

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'.
> 
> $ sed --version | sed 1q
> sed (GNU sed) 4.3
> 
> zw

perl works as you say, but I seem that it is designed.

$ rm -rf *
$ echo 1 >a
$ mkdir b
$ echo 1 >c
$ sed -i 's/1/2/' *
sed: couldn't edit b: not a regular file
$ cat a c
2
1

$ rm -rf *
$ echo 1 >a
$ mkdir b
$ echo 1 >c
$ perl -pi -e 's/1/2/' *
Can't do inplace edit: b is not a regular file, <> line 1.
$ cat a c
2
2

grep skips errors, and gawk stops at error.
i.e. the behavior is different between commands.

$ echo 1 > a
$ echo 1 > c
$ grep 1 *
a:1
grep: b: Is a directory
c:1
$ awk '{print $1}' *
1
awk: (FILENAME=a FNR=1) fatal: cannot open file `b' for reading (Success)