Потребность получить различие между двумя разами в секундах

В настоящее время нет никакого прямого способа сбросить ключ, обязательный к его значению по умолчанию; инициализация привязки по умолчанию (в key_bindings_init()) сделан однажды, когда tmux сервер сначала запускается (в server_start()), и нет никакого механизма для сброса единственного ключа.

Для Вашего желаемого сценария, где Вы хотите, чтобы действие определения источника Вашего конфигурационного файла восстановило значение по умолчанию, связывающее, который был ранее переопределен пользовательской привязкой, которая была с тех пор удалена из Вашего конфигурационного файла, метод, который Вы разработали, разумно (хотя, к сожалению, подробный): unbind-key -a, затем восстановите всю привязку “по умолчанию”, затем установите свою пользовательскую привязку (некоторые из которых могли бы переопределить привязку “значения по умолчанию”).

Текущая привязка сервера может быть извлечена с list-keys команда*; это может помочь генерировать/поддержать Ваш предложенный .tmux.reset.conf файл, но Вам нужен способ извлечь привязку по умолчанию, не текущую привязку.

* существуют некоторые ситуации где вывод list-keys не в настоящее время непосредственно применимо: для привязки для точки с запятой нужна ее точка с запятой, которой оставляют с обратной косой чертой, чтобы препятствовать тому, чтобы он был интерпретирован как разделитель команды tmux, и любая привязка, которая имела аргументы, которые использовали двойные кавычки в одинарных кавычках (ни одна из привязки по умолчанию не похожа на это) выйдет как двойные кавычки в двойных кавычках.

Для получения привязки по умолчанию, Вам нужен временный сервер с минимальной конфигурацией (т.е. никакая пользовательская привязка) так, чтобы можно было получить list-keys вывод. Нет никакого предела количеству tmux серверов, которые можно выполнить, но каждый должен использовать различный путь сокета; -L и -S опции tmux могут использоваться для определения названия сокета (в $TMPDIR/tmux-$UID или полный путь сокета. Так, чтобы говорить (или запуститься) новый сервер на названном сокете temp, Вы использовали бы это:

tmux -L temp …

Для проверки это не использует Ваш .tmux.conf, Вы используете -f сказать этому читать /dev/null (специальный файл, который всегда пуст):

tmux -f /dev/null -L temp …

Примечание: это не предотвращает обработку /etc/tmux.conf, если такой файл существует; путь к этому “файлу конфигурации системы” трудно кодируется и нет никакой опции обойти его (за исключением исправления кода).

Обычно, Вам нужен a new-session управляйте для фактического запуска сервера, но мы не хотим, чтобы любые сессии, просто инициализированный сервер запросили. start-server команда делает просто что: запускает сервер, не создавая сессий.

tmux -f /dev/null -L temp start-server …

Теперь, мы просто должны добавить нашу команду “запроса” (list-keys в этом случае):

tmux -f /dev/null -L temp start-server \; list-keys

Примечание: точки с запятой нужно оставить или заключить в кавычки, чтобы препятствовать тому, чтобы оболочка рассматривала его как разделитель команды оболочки, так как мы хотим, чтобы она была разделителем команды tmux.

С тех пор нет никаких сессий для поддержания, сервер выйдет автоматически после того, как он закончит работать list-keys команда.

Так, можно использовать команду как это для генерации объема Вашего .tmux.reset.conf не имея необходимость волноваться о временном удалении Вашего .tmux.conf файл (чтобы позволить Вам видеть просто привязку по умолчанию) и не имея необходимость закрывать любые существующие серверы.


Если run-shell команда была синхронна, Вы могли встроить вызов как это в Вашем конфигурационном файле (получающий во временный файл, с которым Вы затем обработаете source-file) вместо того, чтобы иметь статический файл (Ваш .tmux.reset.conf). Это позволило бы Вам всегда использовать привязку по умолчанию от своей текущей версии tmux (привязка по умолчанию иногда изменяется). Увы, завершение run-shell команда является в настоящее время асинхронной относительно последующих команд (управляет, чтобы прибыли после a run-shell команда будет обычно работать перед процессом, порожденным run-shell имел шанс закончиться).

6
24.10.2013, 02:09
2 ответа

использование удара:

t2s()
{
  local T=$1;shift
  echo $((10#${T:0:2} * 3600 + 10#${T:3:2} * 60 + 10#${T:6:2})) 
}

start_time=06:07:25
end_time=07:02:08

diff_time=$(( $(t2s $end_time) - $(t2s $start_time) ))
7
27.01.2020, 20:23

Если Вы уверены это end_time всегда больше, чем start_time, можно использовать Perl как так:

export start_time=06:07:25
export end_time=07:02:08
perl -e '
    ($h1,$m1,$s1) = split /:/,$ENV{start_time};
    ($h2,$m2,$s2) = split /:/,$ENV{end_time};
    $delta_h = $h2 - $h1;
    $delta_m = $m2 - $m1;
    if( $delta_m < 0 ) { $delta_m = $delta_h-- * 60 + $m2 - $m1; }
    $delta_s = $s2 - $s1;
    if( $delta_s < 0 ) { $delta_s = $delta_m-- * 60 + $s2 - $s1; }
    print "diff_time=", $delta_h * 3600 + $delta_m * 60 + $delta_s, " seconds\n"
'

Обратите внимание, что можно сделать это просто в {k,}sh с расширением параметра и арифметикой оболочки. Я просто использую Perl для удобства.

Здесь это находится в сценарии оболочки POSIX:

start_time=06:07:25
end_time=07:02:08
h1=${start_time%%:*}
start_time=${start_time#*:}
m1=${start_time%%:*}
s1=${start_time#*:}
h2=${end_time%%:*}
end=${end#*:}
m2=${end_time%%:*}
s2=${end_time#*:}
delta_h=$(( h2 - h1 ))
delta_m=$(( m2 - m1 ))
if [ $delta_h -lt 0 ];then
    delta_m=$(( delta_h * 60 + m2 -m1 ))
    delta_h=$(( delta_h - 1 ))
fi
delta_s=$(( s2 - s1 ))
if [ $delta_s -lt 0 ];then
    delta_s=$(( delta_m * 60 + s2 - s1 ))
    delta_m=$(( delta_m - 1 ))
fi
delta_all=$(( delta_h * 3600 + delta_m * 60 + delta_s ))
printf "diff_time = %d seconds\n" $delta_all
6
27.01.2020, 20:23

Теги

Похожие вопросы