grep color match but show all input

grep может «подсвечивать» совпадающие с «регуляркой» фрагменты, что, несомненно, удобно. Однако, иногда, хочется чтобы на экране был также «полный контекст» — то есть показывался весь входной текст, в котором бы, уже, цветом, отдельно, выделялось совпадение. Вариант решения: нужно включить альтернативный шаблон, который:

  1. Будет совпадать со всеми входными строками;
  2. (при этом) не будет показан.

Казалось бы — явное противоречие. Однако, решение простое-и-изящное:

egrep (original_pattern|$)

— в качестве альтернативного шаблона используем конец строки — он есть у каждой строки, и его не показать. «Люблю такое!» ©

pv — count both lines and bytes

Думаю, каждый, кто обрабатывает значительные по объёму потоки информации конвейерами в командной строке, рано или поздно, становится пользователем pv. Сегодня я понял, что режим индикации «либо строки, либо байты» меня не устраивает — хотелось и того, и другого. Вообще говоря, исключительность тут действительно вызывает вопросы, ничто, ведь, не мешает показывать оба варианта.

Virtualization leads to memory underuse

Интересная-забавная фигня происходит в случае с «нарезкой» сервера на виртуалки, например, на основе KVM. Предположим, что в сервере у вас 128 GB, вы запускаете одну VM, и, понятное дело, не даёте ей все 128 GB, а лишь, к примеру, 16 GB. В случае, если бы дали всё, память использовалась бы на полную катушку — закэшировалось бы всё, что только имело такой шанс. В случае с 16 GB — не видать вам кэша. И это реальный минус, который пока не очень ясно как обходить.

bcache stat in CLI

while cat /sys/block/bcache0/bcache/{dirty_data,stats_{five_minute,hour,day}/cache_hit_ratio} | xargs; do sleep 60; done

формат вывода будет такой:

0 5 7 7
0 4 6 7
0 4 6 7
0 4 6 7

— первое значение это dirty data, в данном случае, «грязи» не было вовсе. 😉 Остальные — cache_hit_ratio за 5 минут, час и день. Другой пример:

210M 47 27 21
124M 44 27 21
42.7M 41 27 21
5.1M 38 27 20
4.9M 34 27 20
4.6M 32 26 20
4.4M 26 26 20
4.2M 19 26 20
3.9M 15 25 20

White rabbit as mnemonic for pv

pv -Wrbt

It’s often useful to postpone pv‘s calculations until there’s data flow for real. As man page says:

-W Wait until the first byte has been transferred before showing any progress information or calculating any ETAs. Useful if the program you are piping to or from requires extra information before it starts, eg piping data into gpg(1) or mcrypt(1) which require a passphrase before data can be processed.

I have had difficulties with remembering that option until I’ve gotten it as “White rabbit”. Now it’s an ease.

How to reveal Wi-Fi passwords your Mac keeps

Чтобы узнать пароль от Wi-Fi точки, к которой подключался ваш Mac, нужно будет выполнить вот такую команду — в Terminal’е, да:

security find-generic-password -ga WiFi_you_need_password_for

DNS propagation is a myth

Ну правда — нет никакого DNS-propagation. Термин устоялся, применяется крупными игроками IT-рынка, вроде AWS Route53, Google Cloud DNS и, естественно, кучей мелких. Некоторые, причём, представляют это себе (да и окружающим, естественно) как то, что информация о ваших DNS-записях начинает расползаться по всем DNS-серверам мира. И пока это супер-глобальное расползание не закончилось (<УЖАС>”а оно может занимать до 2-х суток“</УЖАС>), у вас могут быть проблемы, связанные с тем, что кто-то-на-белом-свете, получит старую версию ваших DNS-записей, и не сможет открыть ваш сайт на новом хостинге.

Так вот, нет никакого DNS records propagation. Единственное о чём можно ещё как-то пытаться говорить в разрезе propagation это changes propagation — распространение изменений. И то, всё-таки, мне этот термин представляется неудачным, поскольку вводит в заблуждение.

В общем — в 2-х словах: ваша DNS-зона никуда не копируется, кроме одного-двух-ну-четырёх серверов (редко больше), которые за неё отвечают — именно поэтому они называются “авторитетными” серверами зоны. Когда кто-то-на-белом-свете желает узнать, какой IP-адрес у вашего сайта, он редко спрашивает напрямую авторитетные серверы вашей DNS-зоны — вместо этого, по авторитетным DNS-серверам, с таким поручением, носятся  DNS-серверы, которые называются DNS-resolver. Например, всем известные 8.8.8.8 и 8.8.4.4 — это DNS-resolver’ы. Чтобы сэкономить усилия (свои, да и “авторитетов”), DNS-resolver’ы кэшируют результаты, которые они получили у авторитетных серверов. У каждой DNS-записи есть значение “можно кэшировать на такое-то время” — даже если вам его не показывает панелька управления, она всё равно есть. Иногда там стоят воистину реликтовые значения, из той эпохи, когда ещё никаких панелек управления и в помине не было. Если до того, как вы перенесли сайт (сменили его IP), тот же 8.8.8.8 уже спрашивали о нём, то в кэше 8.8.8.8 будет старое значение. И если его спросят повторно, 8.8.8.8 имеет полное право использовать свой кэш, пока не истечёт срок кэширования записи.

Поэтому, например, если вы знаете, что скоро будете менять какие-то записи, и вы бы не хотели ждать DNS-propagation, имеет смысл снизить время кэширования этих записей.