Комментарии 40
Суммируя: в coreutils некорректно работает
fold
, зато корректно работает в busybox.+23
По моему, любой IT специалист по умолчанию должен ожидать проблем при работе с кирилицей, везде.
+13
По моему, utf-8 должен уже поддерживаться везде.
+5
По моему, где бы utf-8 не появлялся, работать с ним постоянно приходится через косыли.
0
По моему, где бы не появлялся текст не в ASCII, работать с ним постоянно приходится через костыли.Я поправил. Юникод — это сложно, и правильная его обработка естественно выглядит «костылями» на фоне идиллии ASCII: «один байт — один символ».
0
т.е. обойти = заменить инструмент?
+6
Fedora 20, coreutils-8.21-21.fc20.x86_64 — проблема отсутствует.
echo «абвгдеёжзи» | fold -w 4
абвг
деёж
зи
echo «абвгдеёжзи» | fold -w 4
абвг
деёж
зи
0
Не только в Fedora-20, сейчас попробывал Fedora 18, OEL5, OEL6.
Проблема есть только в OEL5 coreutils-5.97-34.el5_8.1.
В остальных все ок.
Проблема есть только в OEL5 coreutils-5.97-34.el5_8.1.
В остальных все ок.
0
А локаль у вас какая?
0
Думаю, ребята из Red Hat знают об этой проблеме и накладывают патчи. В Fedora всё попадает «по наследству».
+1
echo "абвгдеёжзи"| sed -e "s/.\{4\}/&\n/g"
абвг
деёж
зи
что не так?
+7
Все так… кроме использования более тяжелого инструмента для задачи, которая вроде как решается более простым.
-5
Во-первых, не решается, ну вернее, прямо не решается.
Сколько у вас ушло времени на поиск решения?
Если бы сразу седом побили сколько времени б сэкономили?
Во-вторых, возможно более тяжелого, а возможно и лёгкого, никто ж не мерял.
Какая принципиальная разница?
Ну будет 8Г файл будет на 3 секунды дольше обрабатывать, и что?
Вряд ли разница будет на порядок. И не думаю, что эта задача будет крутится постоянно, и грузить процессор постоянно,
что бы имел смысл вопрос оптимизации этого процесса.
PS: я за перфекционизм, но в пределах здравого смысла.
Сколько у вас ушло времени на поиск решения?
Если бы сразу седом побили сколько времени б сэкономили?
Во-вторых, возможно более тяжелого, а возможно и лёгкого, никто ж не мерял.
Какая принципиальная разница?
Ну будет 8Г файл будет на 3 секунды дольше обрабатывать, и что?
Вряд ли разница будет на порядок. И не думаю, что эта задача будет крутится постоянно, и грузить процессор постоянно,
что бы имел смысл вопрос оптимизации этого процесса.
PS: я за перфекционизм, но в пределах здравого смысла.
+4
$ echo "абвгдеёжзи" |sed -r 's/(.{4})/\1\n/g'
абвг
деёж
зи
+4
В Debian Wheezy (coreutils 8.13-3.5) баг есть, в Jessie 8.21-1.2 тоже.
Багрепорт от чешских товарищей: bugs.debian.org/cgi-bin/bugreport.cgi?bug=721324
Багрепорт от чешских товарищей: bugs.debian.org/cgi-bin/bugreport.cgi?bug=721324
0
В bsd'шном fold под маком всё действительно нормально работает.
+1
cut, кстати говоря, тоже содержит эту «ошибку»
$ echo абвгдеёжзи |cut -c3-4
б
0
Кстати, что более интересно:
$ echo абв | fold -w 1
�
�
�
0
Загадка.
Как удалить все файлы и папки из текущей директории, запустив один раз одну утилиту и при этом не получив сообщение об ошибке?
Как удалить все файлы и папки из текущей директории, запустив один раз одну утилиту и при этом не получив сообщение об ошибке?
0
find -delete 2>/dev/null
0
Ответ верный (не благодаря `2>/dev/null`, я имел в виду как раз без таких приемов). Ту же задачу можно решить с помощью
А подвох в том, что утилита
locate
.А подвох в том, что утилита
rm
не удовлетворяет условию. И удалять приходится не утилитой удаления, а утилитой поиска (либо игнорировать ошибки, конечно).-3
Как поведет себя эта команда на директории с миллионом файлов? rm сдувается
0
а чем «rm -rf *» не нравится? ошибок не даёт никаикх
0
Эта команда игнорирует файлы, чье имя начинается с точки.
0
Ну так
rm -rf * .[^.]* ..?*
+3
Вот это я понимаю ловкость рук!
+3
$ touch ./-a
$ ls
-a
$ rm -rf * .[^.]* ..?*
zsh: sure you want to delete all the files in /home/dginzburg/tmp/rmtest [yn]? y
rm: invalid option -- 'a'
Try 'rm ./-a' to remove the file ‘-a’.
Try 'rm --help' for more information.
+3
>_
-2
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Обходим ошибки утилит из пакета GNU Core Utilities