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

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 25587 in the body.
You can then email your comments to 25587 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: Zack Weinberg <zackw <at> panix.com>
To: bug-sed <at> gnu.org
Subject: In -i mode, shouldn't sed continue processing the command line if it
 can't access some files?
Date: Tue, 31 Jan 2017 10:12:34 -0500

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

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

From: Norihiro Tanaka <noritnk <at> kcn.ne.jp>
To: Zack Weinberg <zackw <at> panix.com>
Cc: 25587 <at> debbugs.gnu.org
Subject: Re: bug#25587: In -i mode,
 shouldn't sed continue processing the command line if it can't access
 some files?
Date: Wed, 01 Feb 2017 08:51:59 +0900

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'.
> 
> $ 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)

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

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: Re: 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.