Comments 32
А так можете сделать?
mount / -o rw,remount
cat < /dev/clipboard > main.c
WAT
WAT
Прозреваю, что эмулятор пробрасывает буфер обмена в виртуалку, а ядро (оно там патченое) умеет с ним работать.
Буфером обмена является форма для ввода текста, справа от окна эмулятора. Вырезать, копировать и вставлять текст можно только мышкой,
поскольку нажатия клавиш перехватываются окном эмулятора.
поскольку нажатия клавиш перехватываются окном эмулятора.
Мне непонятна конструкция «cat < /dev/clipboard». Зачем?
«cp /dev/clipboard main.c» ни чуть не проще. Тогда какая разница? Можно было буфер обмена и параметром передать «cat /dev/clipboard > main.c». Все варианты имеют место быть.
Разве
cp /dev/clipboard не скопирует «файл устройства», а никак не его содержимое?Меня просто очень смутило перенаправление из файла в cat. Это данные лишний раз через ядро прогонятся.
Простите, но экономить ресурсы ядра при дублировании данных размером с helloworld, это моветон. Да и ядро, я думаю, достаточно умно, что бы знать, что stdin — read-only, а stdout — write-only. И представляют из себя ни что иное, как FIFO. Основываясь на этом, можно избежать лишнего копирования буфера, не боясь за порчу данных.
Моветон, знаете ли, бездумно составлять такие однострочники. Это не преждевременная оптимизация, это неправильное использование шелла.В том же духе cat file | grep.
С этого начинается говнокод и небрежное отношение к памяти.
С этого начинается говнокод и небрежное отношение к памяти.
Думаете это хуже, чем «grep regexp file»? Какая разница, кто прочитает файл: cut или grep? Данные поместятся в одинаковый буфер. Cat будет туда дописывать строки, grep считывать. Оверхеда будет. Я, например, не являюсь гуру регулярок, и часто не с первого раза составляю нужное выражение. Если я буду пользоваться «правильным» вариантом, то при каждом изменении регулярки, мне придется долго перемещать курсор (есть спецсимволы для этого, но не все их знают и не всеми терминалами поддерживается). В случае же с пайпом, я попадаю сразу в конец регуляного выражения и радуюсь.
Кстати. На многоядерных процессорах пайпы и перенаправление ввода/вывода позволяют ускорит выполнение скрипта. Вот прочитает grep пару строк с диска, обработает. Снова прочитает. И т.д.
А если cat ему будет помогать, то grep будет читать строки сразу из оперативной памяти, куда cat, пока grep занимался поиском вхождений, их любезно положил. (Опустим вопрос кэширования средствами ФС. Там могут быть какие угодно настройки, вплоть до полностью отключенного функционала).
Всё возможно, везде найдётся применение. К говнокоду и оптимизациям это не относится (хотя, как я уже сказал, пайпы иногда могут ускорить выполнение). Дело вкуса/привычки/удобства.
Кстати. На многоядерных процессорах пайпы и перенаправление ввода/вывода позволяют ускорит выполнение скрипта. Вот прочитает grep пару строк с диска, обработает. Снова прочитает. И т.д.
А если cat ему будет помогать, то grep будет читать строки сразу из оперативной памяти, куда cat, пока grep занимался поиском вхождений, их любезно положил. (Опустим вопрос кэширования средствами ФС. Там могут быть какие угодно настройки, вплоть до полностью отключенного функционала).
grep reg < file
grep reg file
cat file | grep reg
cat < file | grep reg
Всё возможно, везде найдётся применение. К говнокоду и оптимизациям это не относится (хотя, как я уже сказал, пайпы иногда могут ускорить выполнение). Дело вкуса/привычки/удобства.
Сравните скорость команд:
cat /dev/zero | pv > /dev/null
pv < /dev/zero > /dev/null
pv /dev/zero > /dev/null
Посмотрите на разницу.
cat /dev/zero | pv > /dev/null
pv < /dev/zero > /dev/null
pv /dev/zero > /dev/null
Посмотрите на разницу.
Зачем? Файлы находятся на диске и скорость считывания с диска или из кэша будет определяющей, с данными примерами вы её не померяетее. Кроме того, grep обрабатывает данные медленнее pv, так что данный тест никак не противостоит аргументам fshp. Также он никак не противостоит аргументу «изменять regex так проще».
Кстати, а что pv должен вывести? У меня он не выводит ничего.
Кстати, а что pv должен вывести? У меня он не выводит ничего.
При чем тут диск и кеш?
Речь о том что скорость выше в разы при меньшем количестве пайпов.
Понятно что для большинства лучший код — говнокод, но это не выход.
А pv выдает скорость передачи данных.
Речь о том что скорость выше в разы при меньшем количестве пайпов.
Понятно что для большинства лучший код — говнокод, но это не выход.
А pv выдает скорость передачи данных.
Какая к чёрту разница, с какой скоростью pv успевает считать нули? Вы не получите такой разницы на реальных файлах, даже если они находятся в памяти.
И ещё: вы сознательно игнорируете аргумент про загрузку файла в память cat’ом? Я заметил, что pv почему‐то считает, что stderr — не терминал (наверное, из‐за hilite), поэтому для того, чтобы он что‐то показал, нужен ключ -f. Так вот:
На мелких же файлах (я проверял на 45 КиБ), присутствующих в кэше, различие в скорости от запуска к запуску при обоих методах настолько велико¹, что говорить о какой‐либо разнице между методами смешно. Так что в большинстве случаев вы просто предлагаете заняться тем, что называется «предварительная оптимизация». То, что мы пишем, начнёт называться говнокодом не раньше, чем либо разница между временем работы вашей и нашей версии станет заметна человеческому глазу, либо чем нашу версию окажется сложнее читать.
¹ От 11,5 МиБ/с до 1,05 ГиБ/с —
И ещё: вы сознательно игнорируете аргумент про загрузку файла в память cat’ом? Я заметил, что pv почему‐то считает, что stderr — не терминал (наверное, из‐за hilite), поэтому для того, чтобы он что‐то показал, нужен ключ -f. Так вот:
cat file | grep abc | pv -af > /dev/null работает всегда быстрее, чем grep abc file | pv -af > /dev/null, если файл бинарный (т.е. grep надо только определить наличие шаблона, но не вывести строки) или отсутствует в кэше. Скорость отличается примерно на 20—30 %, если файл в кэше присутствует (проверялось на файлах размером 600 МиБ и 14 МиБ).На мелких же файлах (я проверял на 45 КиБ), присутствующих в кэше, различие в скорости от запуска к запуску при обоих методах настолько велико¹, что говорить о какой‐либо разнице между методами смешно. Так что в большинстве случаев вы просто предлагаете заняться тем, что называется «предварительная оптимизация». То, что мы пишем, начнёт называться говнокодом не раньше, чем либо разница между временем работы вашей и нашей версии станет заметна человеческому глазу, либо чем нашу версию окажется сложнее читать.
¹ От 11,5 МиБ/с до 1,05 ГиБ/с —
cat file | sed 's/abc/def/' | pv -af > /dev/null; от 26,1 МиБ/с до 1,02 ГиБ/с — sed 's/abc/def/' file | pv -af > /dev/null.Такой разброс скорости говорит что замер производится некорректно.
И что у вас за терминал без stderr?
И что у вас за терминал без stderr?
А как его ещё можно произвести? Я кроме time для замеров раньше ничего больше не использовал. На малых файлах time ожидаемо показывает нули, pv показывает чушь.
Терминал тут не причём. Подозреваю hilite — это программа для покраски stderr в красный цвет. Подозреваю, что hilite также причастна к неработающему mc и bash, стартующему в неинтерактивном режиме по‐умолчанию. Так как mc мне не нужен, bash’у можно сказать
Терминал тут не причём. Подозреваю hilite — это программа для покраски stderr в красный цвет. Подозреваю, что hilite также причастна к неработающему mc и bash, стартующему в неинтерактивном режиме по‐умолчанию. Так как mc мне не нужен, bash’у можно сказать
-i, а почти всё остальное работает (т.к. проверяет stdout, а не stderr, на принадлежность терминалу, который никто не трогал), исправлять я ничего не пытался. Во всяком случае, запуск pv не из оболочки работает штатно. Наверное, надо попробовать stderred.
Удаляем старый Makefile, копируем новый и заново make
Месье!
Там нет обычных редакторов (vim/nano). Есть, конечно, ed — можно заодно изучить его многогранность. Но быстрее файл заново скопировать, чем изучить его. Либо использовать sed/awk.
А
make CC=tcc и CC=tcc make не работают? У меня работают оба варианта без какого‐либо изменения Makefile.И, кстати, если вы попросите перенаправить в файл, используя один
>, то перед записью файл будет усечён, так что никакого удаления не требуется. Если только вы не хотите сказать, что в данном случае усечение не поддерживается.Вообще говоря там BusyBox, который предоставляет нечто похожее на vi.
Попытался было разобраться, почему нет цветов, но безнадёжно. Из файла /usr/include/ncurses.h можно увидеть, что используется версия ncurses 5.6. Из её исходных кодов можно найти функцию has_colors():
А далее всё зависит от того, как собирали библиотеку, и как реализован терминал. Необфусцированного код эмулятора ещё не существует, насколько я понял.
Скрытый текст
NCURSES_EXPORT(bool)
has_colors(void)
{
T((T_CALLED("has_colors()")));
returnCode((VALID_NUMERIC(max_colors) && VALID_NUMERIC(max_pairs)
&& (((set_foreground != NULL)
&& (set_background != NULL))
|| ((set_a_foreground != NULL)
&& (set_a_background != NULL))
|| set_color_pair)) ? TRUE : FALSE);
}
А далее всё зависит от того, как собирали библиотеку, и как реализован терминал. Необфусцированного код эмулятора ещё не существует, насколько я понял.
Sign up to leave a comment.
Компилируем змейку в браузере