svn commit: r312404 - head/usr.bin/sed

[Bruce Evans]

On Fri, 20 Jan 2017, Antoine Brodin wrote:

> On Thu, Jan 19, 2017 at 9:01 AM, Xin LI <delphij at freebsd.org> wrote:
>> Author: delphij
>> Date: Thu Jan 19 08:01:35 2017
>> New Revision: 312404
>> URL: https://svnweb.freebsd.org/changeset/base/312404
>>
>> Log:
>>   Use S_ISREG instead of manual & (also it's better to compare the
>>   result from & and the pattern instead of just assuming it's one bit
>>   value).
>>
>>   Pointed out by Tianjie Mao <tjmao tjmao com>.
>>
>>   MFC after:    2 weeks
>>   Differential Revision:        https://reviews.freebsd.org/D4827
>
> Hi,
>
> sed -i no longer works on symlinks which breaks lots of ports.
> Please revert and request an exp-run.

sed() doesn't seem to actually understand symlinks (it has no flag like
-h to prevent following them when opening files), so its use of lstat()
to classify them is wrong.  This was harmless for symlinks but not for
other irregular file types pointed to by symlinks.  The buggy S_IFREG
test accidentally classified symlinks, sockets and whiteouts as regular,
but failed classify the file type of the target of symlinks that will
actually be used.  The fixed test limits sed to "regular" files
(including highly irregular ones in /proc).

It is a bug for sed to have any restrictions on file types.   This
breaks device indepedence.  Even /dev/std* was supposed to not work,
but worked accidentally since these files happen to be implemented as
symlinks.  Their targets /dev/fd/[0-2] didn't work accidentally, but
it was possible to trick sed into working on them by pointing to them
using symlinks.  Similarly for all file types.

POSIX only requires sed to work on text files.  I couldn't find anywhere
where it clearly defines what a text file is or any restriction to
regular files.  It requires sed to work on stdin which is often a pipe,
so it must not restrict on the file type found by fstat().  So a text
file should defined as "a file of any type containing text".  Utilities
shouldn't be restricted to text either, but that is a larger bug.  It
is now difficult to even define text.  Non-ASCII encodings of text look
like binary to me.

Bruce