Ну скорее всего криво работает не программа, а ваш sed-скрипт. "Криво" - значит не так, как вы того хотите. Это вполне нормальное явление, и например у меня так бывает постоянно. Мало того, значительно чаще, чем скажем если я использую например C++. И тем не менее намного быстрее написать быстренько sed(bash/perl/...) скрипт, который с третьего раза, но выполнит задачу, чем мучится с составлением всяких ООПшных конструкций.

Для начала, авторы рекомендуют сначала изучить список известных "ошибок", которые из разряда "это не баг, а фича". Ну а я попытаюсь пояснить, почему-же это так сделано. Список представляет собой перевод файла BUGS из исходных текстов Gnu-sed version 4.2.

Куда слать баг-репорты?

Многие версии sed завершают работу скрипта, если выполняется команда N для последней строки. Однако, GNU sed в данном случае распечатает значение буфера, если это не запрещено (например опцией -n). И так-же прервёт выполнение скрипта.

См. также info sed, и Пример типичного использования команд D и N.

sed использует базовые POSIX регулярные выражения. Кроме стандартных, GNU sed использует несколько своих спец-символов:

`\|', `\+', `\?', `\`', `\'', `\<', `\>', `\b', `\B', `\w', `\W'

Таким образом, RE /x\+/ совпадает в GNU-sed с одним или боле символов «x», а в некоторых других sed это RE совпадает только с «x+».

см. также info sed

Короче:

sed d -i

удаляет содержимое файла. Даже если этот файл защищён от модификации. Это не ошибка. Это непонимание, как работают UNIX ФС.

Права на файл говорят о содержимом файла, а права на директорию - о списке файлов в этой директории. sed -i никогда не открывает файл для записи/модификации. Вместо этого она создаёт временную копию изменённого файла, который после редактирования переименовывает как старый, потому кажется, что этот файл был изменён. На самом деле, это новый файл, который был создан на основе старого.

Да. Я знаю... И разработчики sed тоже в курсе... Вот только проблема тут вовсе и не в sed, и даже не в GNU Linux... Данная проблема проявляется исключительно при использовании национальных локалей, которые не совпадают с POSIX, или что тоже самое с C. Или, говоря по иному, при использовании любых алфавитных символов не из диапазона /[A-Za-z]/. С первой проблемой справится довольно просто: можно записать не /А-Я/, а

/[АБВГДЕЖЗИЙКЛМНОПРСТУФХЦЧШЩЬЫЪЭЮЯЁ]/

Это конечно довольно криво, но что делать? За то это выражение отлично работает, и всегда совпадает с русскими большими буквами. При этом конечно подразумевается, что sed-скрипт, и обрабатываемый текст в одной и той-же кодировке (при использовании UTF-8 текст и скрипт может быть на любом языке мира, причём одновременно на разных языках). Проблема тут в том, что русские буквы вовсе не обязательно идут по алфавиту, потому сравнивая их мы получаем неопределённый результат (на разных компьютерах результат может быть разным).

Вторая проблема намного серьёзнее.

Проблема тут в том, что хотя метасимвол точка «.» безусловно совпадает с любым символом, он тем не менее вовсе не обязан совпадать с НЕСИМВОЛОМ! Алфавит UNICODE "дырявый", он содержит дыры, некоторые допустимые числа, которые не сопоставлены ни с каким символом. Поведение точки на таких несимволах не определено стандартом, и на практике точка НЕ совпадает с несимволом.

Вот простой пример: нам надо отсечь всё, что лежит после «|»

$ echo -e "тест|вредоносный код" | sed 's/|.*//'
тест

Как видите, всё прекрасно работает... Однако:

$ echo -e "тест|\xD1вредоносный код" | sed 's/|.*//'
тест?вредоносный код

Ну вот... Вредоносный код успешно проник сквозь фильтр :-(

Проблема sed - в лёгкости, мощности, и чрезвычайной простоте: можно написать изящный, и простой пример уязвимости... Конечно код на языке perl, и тем более C будет намного более громоздким. Беда в том, что если вы пишете на C или PERL'е, то у вас уже включён юникод, и ваша программа так-же подвержена этой уязвимости. Попробуйте например вот эту программу на C:

#include <locale.h>
#include <stdio.h>
#include <string.h>
#include <unistd.h>
#include <sys/types.h>
#include <regex.h>

#define ERRBUF_SIZE 1024
#define NMATCH 10

void error(int err_code, regex_t *rs)
{
        char errbuf[ERRBUF_SIZE];
        if(!err_code)   return;
        regerror(err_code, rs, errbuf, ERRBUF_SIZE);
        fprintf(stderr, "regex error: %s\n", errbuf);
        regfree(rs);
        _exit(err_code);
}

int main(void)
{
        const char str[] = "тестов\xD1\xD1ая строчка. ABCDEFG";
        const char regex[] = ".*";
        regex_t rs;
        regmatch_t pmatch[NMATCH];
        char *lc = setlocale(LC_ALL, "ru_RU.UTF-8");
        if(!lc)	return 77;
        printf("test string: `%s' (%s)\n", str, lc);
        int err = regcomp(&rs, regex, REG_EXTENDED);
        error(err, &rs);
        const char *ps = str;
        while(*ps)
        {
                err = regexec(&rs, ps, NMATCH, pmatch, 0);
                error(err, &rs);
                int j;
                const char *ps2 = NULL;
                for(j = 0; j < NMATCH; j++)
                {
                        if(pmatch[j].rm_so < 0)
                                continue;
                        printf("Совпадение %d: %d...%d\t`", j, pmatch[j].rm_so, pmatch[j].rm_eo);
                        int i;
                        for(i = pmatch[j].rm_so; i < pmatch[j].rm_eo; i++)
                                printf("%c", ps[i]);
                        printf("'\n");
                        if(!ps2)
                                ps2 = ps + i;
                }
                ps = ps2;
                if(!ps)	break;
                printf("остаток: `%s'\n", ps);
        }
        regfree(&rs);
        return 0;
}

Ага... Зависнет эта программа в бесконечном цикле... А всё потому, что выражение /.*/ не совпадает со всей строкой - строка некорректная. Ну и поведение программы тоже не предсказуемое. К сожалению, такое будет работать на любом языке, лишь-бы он поддерживал юникод.

Программа зациклилась, потому-что она нашла совпадение, и это совпадение - пустая строка. Это произошло на второй итерации, на первой мы нашли всё что до не символа, а во второй - от несимвола и до несимвола. В итоге и в строке что-то есть, и что-то находится, но продвижения вперёд нет.