('binary' encoding is not supported, stored as-is) A problem exist in FreeBSD's version of SED, that when you specify last line and do not get contents of hold area and then delete the first part of a pattern space against a file which contains two lines or more, it results in a Segmentation fault "coredump". This is the following two instructions explained above. sed '$!g; D' file And "file" containing two or more lines. When you specify last line and GET the contents of the hold area and then delete the first part of the pattern space, it results in a Segmentation fault as well. Which is the following two instructions, sed '$g; D' file [keoki@jeff:~/test] for i in 1 2; do echo "blah" >> example; done [keoki@jeff:~/test] sed '$!g; D' example Segmentation fault (core dumped) [keoki@jeff:~/test] sed '$g; D' example Segmentation fault (core dumped) [keoki@jeff:~/test] Then I get the following using gdb on sed.core [keoki@jeff:~/test] gdb sed sed.core #0 0x280da416 in memmove () from /usr/lib/libc.so.4 (gdb) Then at address 0x280da416, which is 0x280da416 <memmove+26>: repz movsl %ds:(% esi),%es:(%edi) I believe the problem resides in proccess.c Which is located in /usr/src/usr.bin/sed/ and at line 145 of proccess.c, which is memmove (ps, p + 1, psl); in the following case statement, case 'D': if (pd) goto new; if ((p = memchr(ps, '\n', psl - 1)) == NULL) { pd = 1; goto new; } else { psl -= (p + 1) - ps; memmove(ps, p + 1, psl); goto top; } I haven't tested on NetBSD or openBSD's version of sed. I only have tested on FreeBSD. Also note, sed ! = gsed. And this problem doesn't exist in gsed, which is what most linux distros afaik use as "sed". -- keoki
This archive was generated by hypermail 2b30 : Wed Feb 06 2002 - 09:16:23 PST