Bash: разница в днях между двумя датами

В баше есть встроенная арифметика, которая во многих случаях может заменить простой целочисленный калькулятор. Понадобилось высчитать разницу между двумя датами, решается вот так (хотя способ не единственный):

echo $(( ( $(date +%s -d 4/13/2020 ) - $(date +%s -d 3/23/2020 ) )/86400 ))

Функция вычислений $(( выражение ))
Вывод команды $( команда )
Арифметическое операторы и скобки (-/)
Перевести дату, заданную параметром -d в формат UNIX-date (число секунд с начала эры) +%s
Начальная дата в формате mm/dd/yyyy 4/13/2020
Конечная дата в формате mm/dd/yyyy 3/23/2020
Разницу между датами делим на число секунд в сутках 86400

Есть и другие способы такой арифметики, но именно этот первым пришел в голову. Данная команда выдает результат "21", то есть, между 13 апреля 2020 года и 23 марта 2020 года 21 день

По арифметике с временами у меня есть более ранний пост.

MySQL в Zimbra: пароль доступа и некоторые параметры

Решил поглубже поковыряться в БД зимбры. И понял, что не знаю пароля. Решение:

su - zimbra
zmlocalconfig -s | grep mysql | grep password

На выходе получаем что-то вроде:

mysql_logger_root_password = AWHZ60JYaBw8_hVkA9NDVGh0irmp7xVz
mysql_root_password = lkAd7vkYI.Q_VeWt8uyL9kj0
zimbra_logger_mysql_password = 2iiyAVj3GeH0akkCe6M1o_HvY
zimbra_mysql_password = uMv4EsNqPZdK5htERx97VY5m

и видим пароли как для пользователя root, так и для пользователя zimbra. ЧТД.

В этой БД есть разные параметры, в т.ч. и различные даты/времена. Как выяснилось, хранятся они в стандартном юниксовом формате "число секунд с начала эпохи". Не ломая голову, просто преобразуем это длинное целое в человекочитаемый вид:

date -d @дата_в_формате_unix

Теперь о хранении данных о пользователях. Все они хранятся в БД zimbra в таблице mailbox. Емайл почему-то хранится в поле comment. а номер почтового ящика - в поле id. Номер п/я - это составное число вида

UGG

где GG - номер группы (БД mboxgroupGG), от 1 до 100. При формировании id пользователя, находящегося в группе с номером <10 к номеру группы дописывается ведущий ноль, например для сотой группы gg="00"
U - номер пользователя в группе, начиная с нуля, причем если U=0, то id=GG (ведущие нули в базе, понятное дело, не хранятся), при U=1 id=1GG, например, для сотой группы id=100.

Именно id используется в пути к каталогам хранения данных и индексов почтового ящика. Например, для 3-го пользователя из 94-ой группы путь будет:

/opt/zimbra/store/0/394/

Однако, если пользователь еще не обращался к своему почтовому ящику, то каталоги с его id могут отсутствовать. Например, недавно коллега сделал учетку для нового кладовщика, но не настроил ее комп. Пользователь с id=ugg уже есть в группе gg, а вот пути /opt/zimbra/store/0/ugg/ еще нет.

И снова о просмотре логов squid и выводе полей в awk.

Очередной способ получить человеко-читаемое время в логах прокси-сервера.

awk '{print strftime("%Y-%m-%d %H:%M:%S",$1) " " substr($0, index($0,$2))}' FILENAME

Основная идея: по умолчанию поля в этом логе отделяются пробелами. Awk преобразует первое поле (дата и время в юникс-формате) в читаемый вид и выводит его. Далее печатается пробел, после которого печатается всё от начала второго поля до конца строки.

Как выяснилось, это самый быстрый способ заставить awk вывести "всё остальное", не перебирая поля последовательно в цикле.

Решение найдено здесь.

SQUID access.log: преобразование времени

Сквид в своем логе пишет время в формате UNIX, что ни разу не есть удобно для чтения.
Где-то я уже разбирался с преобразованием времени, но для анализа конкретно этого лога нашлось такое решение:

grep rush access.log|perl -nwe's/^(\d+)/localtime($1)/e; print'

В данном случае ищем в логе обращения к сайту, содержащему в имени последовательность "rush" и выводим в найденных строках время по-человечески.

Но для одноразовой конверсии лучше воспользоваться стандартной командой date:

$ date --date='@1362981179.186'
Пн. марта 11 16:52:59 VLAT 2013

После "@" вписываем время из лога в формате UNIX. И телемаркет!