A bug encountered using SED on CentOS 5.5

Using SED to encounter a bug on CentOS 5.5

$ echo AAA > config$ ln-s config cfg$ sed-i ' s/aaa/aaa/' cfgsed:ck_follow_symlink:couldn ' t lstat c/config:no such File or directory

This bug occurs when Sed-i do_sth Symbolic_links_without_slash

Download the source code for it https://google-search-appliance-mirror.googlecode.com/files/sed-4.1.5-5.fc6.src.rpm

Unzip to see Redhat on the sed-4.1.5 on the 3 patch

Sed-4.1.5-bz185374.patch

Sed-4.1.5-relsymlink.patch

Sed-4.1.5-utf8performance.patch

Redhat Why to patch the SED, which stems from another problem, when Sed-i do_sth file, the actual process is this

Sed do_sth file > tmpmv tmp file

So the problem is, if file is a soft connection to file File2, sed-i do_sth file results in:

Sed "shortened" file to file2 soft connection file2 content does not change file to a file2 copy its contents changed (if Do_sth will modify)

This is not a big problem in itself (a "little pit" of SED)

But someone tried to solve the problem, so there was sed-4.1.5-bz185374.patch.

There's a new function in this patch Ck_follow_symlink

Its core place is the use of Readlink

For example, file A-b file B-C

Ck_follow_symlink is able to find a successful trace to the final document A-C

But Ck_follow_symlink is not working properly in a situation.

File A. /b and File B, c

In other words, a--. /C and Ck_follow_symlink to understand it for a-c

Which means that a new problem is introduced.

In order to solve this new problem, so there is a patch Sed-4.1.5-relsymlink.patch

This patch is intended to solve a. A scenario such as/b and C

The solution is this: (Patch fragment)

BUF is the buffer err = Readlink (buf, BUF2, bufsize) that records the current file name;  BUF2 [Err] = ' + ';    if (buf2[0]! = '/') {dir = dirname (BUF); Dir part of orig path int len = strlen (dir);      Orig path len Buf[len] = '/'; strncpy (buf+len+1, Buf2, bufsize-len-1);

So here's the question, how does dirname work?

Char ch[] = "/tmp/123"; char * p = dirname (CH);

The behavior of dirname (CH) is to change the ch[4] from '/' to 0 and the address of CH as the return value

But what about the behavior of dirname (CH) when char ch[] = "tmp"?

The answer is not to make any changes to CH dirname (CH) Returns a pointer to a constant string "."

Here the use of dirname is wrong, he mistakenly think that DirName will go to modify the entry and return to the address of the parameter

So the wrong use of dirname introduced the bug at the beginning of the article

This bug exists in some versions of the Centos/rhel/fedora, there is no final repair is not verified

To the main line with SED, it does not have this problem, for sed-i effect with soft connection "cut short" soft connection This problem

sed after the 4.1.5 a new parameter,--follow-symlinks, is added to ensure that the sed-i does not "cut" the soft connection

The behavior of Sed-i is consistent with previous versions without this parameter

A bug encountered using SED on CentOS 5.5