Что-то как-то очень сложно переменную ETCD_SERVERS создаете: первый sed безполезный, а еще и двойной echo (первый - в цикле в субшелле, потом внешний). Попробуйте вот это - у него приятный вкус:
Вот еще один деликатес - для ETCD_INITIAL_CLUSTER:
for n in $( seq 0 $(( MASTER_COUNT-1 )) )
do
n="$n.$BASE_CLUSTER_DOMAIN"
printf ",master-%s=https://master-%s:$ETCD_PEER_PORT" $n $n
done \
| sed 's/,//'
Думается мне - кровушки попили они с вас, пока не пришли к нужному виду.
Биом, обитающий внутри нас - штука приобретаемая нами после рождения: мы не рождаемся с ним, он попадает в нас позже. Как биом эволюционирует и где он выживает до того как в нас попасть?
Вспомнилось давно читанное в юности: Михаил Анчаров, Самшитовый лес.
Небольшая цитата оттуда:
- Барбарисов, это ты? - раздался на всю комнату жизнерадостный голос Сапожникова. - Это я, Сапожников, узнал?
- Боже мой, - сказал Барбарисов. - Узнал, узнал, мы только что о тебе говорили.
- Я почувствовал. Барбарисов, не сердись, но у тебя должен находиться некий Аркадий Максимович, тайный атлантолог.
- Кто? - спросил Барбарисов, потом вдруг смекнул, о ком речь, и ошалело уставился на Аркадия Максимовича. - Слушай, а ты не с того света?
- Нет. Я из пионерлагеря... Давай зови его. Или нет, не зови. Передай ему, что я у Дунаевых. Он знает. Слушай, кстати, я, кажется, действительно решил теорему Ферма! Не смейся, идиотски простым способом. Слушай, скажи всем заинтересованным, что если я действительно ее решил, то ее надо немедленно у меня украсть. Говорят, за решение дают Нобелевскую премию. Глупо, если она достанется дикому Сапожникову, а не кому-то организованному, в крайнем случае тебе...
С одной стороны как-то сложно и запутанно, и автор сам это отмечает. С другой стороны - подобные фичи в том или ином объеме представлены в других языках, например, Perl и его последователях.
Там используются сантисекундные задержки и ввод производится с помощью set /p и одного хитрого трюка (сам еще не до конца понял его) "%~F0" Input >> pipeFile.txt | "%~F0" Main < pipeFile.txt.
Интересно Ваша реализация следующего пути документообновления.
Вы (команда или один человек) готовите документ в asciidoc, затем собираете в формат docx и передаете заказчику (внешний или внутрении) на рассмотрение. Он редактирует документ, добавляет комментарии "на полях" (в которых часто выносятся новые мысли или предполагаемые предложения к правкам) и высылает обновленный docx файл.
И теперь вопросы. Есть ли возможность перевести изменения в репозиторий из формата docx снова в формат asciidoc? Есть возможность не потерять эти комментарии и принять их во внимание?
Если симлинка будет не на директорию, а на сам скрипт, то с ваш пример не сработает.
Согласен.
Про catecho все равно не очень понятно.
Вы все верно поняли. Это не то чтобы разное поведение, это одинаковый, единообразный вывод.
В примере выше я привел функцию logMsg, которая используют особенности catecho. С их помощью и с помощью других функций (как, например, warn из второго примера выше) можно единообразно логгировать. Здесь, 1-ый и 2-ой примеры взаимозаменяемы, но 1-ый, по мнению автора, элегантнее.
realpath нужно если скрипт вызывается через симлинку, а надо подгружать что-то лежащее непосредственно рядом со скриптом.
Не вижу проблем. Ну, если какие-то особые редкие случаи в экзотических дистрибутивах или в макоси, с которыми я не сталкивался.
Вот пример
$ cat /opt/scripts/test/z
#!/usr/bin/env bash
set -x
. "$( dirname "$0" )/z.sh"
blabla
$ cat /opt/scripts/test/z.sh
blabla() {
echo "Hello! I am $FUNCNAME"
}
$ sudo ln -s /opt/scripts/test /test
$ /test/z
++ dirname /test/z
+ . /test/z.sh
+ blabla
+ echo 'Hello! I am blabla'
Hello! I am blabla
про catecho
Ваш вопрос заставил меня немного задуматься. И я вспомнил, откуда ноги растут у этой функции. Это кусок кода для логирования всего с разными уровнями (DEBUG, INFO, NOTICE, WARNING, ERROR, CRITICAL). Не скажу, что в catecho сейчас есть большая нужда. Исторически так сложилось, что эта функция перетекает из одного скрипта в другой.
Вот небольшой фрагмент и несколько гипотетических примеров. Понятно, что echo "..." это просто заглушки для примеров, на самом деле - там какие-то внешние команды или функции. Первый пример, явно, избыточен - он легко перекрывается вторым, но первый виделся мне тогда и видится сейчас элегантнее, чем второй.
function logMsg()
{
local level="$1"
shift
catecho "$@" \
| sed "s|^|$(date '+%Y/%m/%d %H:%M:%S') ($$) ($level): |"
}
function warn()
{
logMsg "WARNING" "$@"
}
echo "какая-то-команда неожиданно что-то напечатала" | warn
# DATE TIME (PID) (WARNING): какая-то-команда неожиданно что-то напечатала
warn "$( echo "какая-то-команда снова что-то напечатала" )"
# DATE TIME (PID) (WARNING): какая-то-команда снова что-то напечатала
warn "какие-то проблемы - надо что-то напечатать"
# DATE TIME (PID) (WARNING): какие-то проблемы - надо что-то напечатать
Думаю, что для определения "домашнего" каталога скрипта цепочку dirname/realpath можно опустить и оставить только dirname.
Во многих своих скриптах я часто использу такое подобие шаблона. Некоторые определения могут отсутствовать. Кое-что добавляется в зависимости от задачи. Функции die/warn/catecho - для удобства вывода диагностических сообщений и аварийного прекращения.
#!/usr/bin/env bash
readonly ME="$( basename "$0" )"
readonly MYDIR="$( dirname "$0" )"
print_help() {
cat - <<HELP
USAGE
$ME [OPTIONS]
OPTIONS
bla-bla
HELP
}
main() {
init
parse_options "$@"
# do payload
}
init() {
# preparations and initialization
# set trap if needs
}
parse_options() {
while [ $# -gt 0 ]
do
# parse CLI options
done
}
# own functions' definitions doing the script payload
die() {
warn "$@"
exit 1
}
warn() {
catecho "$@" >&2
}
catecho() {
[ -t 0 ] && echo "$@" || cat -
}
main "$@"
Что-то как-то очень сложно переменную
ETCD_SERVERSсоздаете: первый sed безполезный, а еще и двойной echo (первый - в цикле в субшелле, потом внешний). Попробуйте вот это - у него приятный вкус:Вот еще один деликатес - для
ETCD_INITIAL_CLUSTER:Думается мне - кровушки попили они с вас, пока не пришли к нужному виду.
Биом, обитающий внутри нас - штука приобретаемая нами после рождения: мы не рождаемся с ним, он попадает в нас позже. Как биом эволюционирует и где он выживает до того как в нас попасть?
В скрипте опечатка в имени переменной:
SourcekDir(одно объявление и одно использование). В тексте статьи упоминается верно:SourceDir.На кдпв переполнение стека будет.
Правила 2 и 3 сомнительны
lg(19) = 1.3
lg(42) = 1.6
lg(45) = 1.7
Вспомнилось давно читанное в юности: Михаил Анчаров, Самшитовый лес.
Небольшая цитата оттуда:
Еще ссылка в копилку:
https://www.lifewire.com/windows-version-numbers-2625171
Код выше можно сократить до
$ echo "Welcome To The Geek Stuff" | sed 's/\b[A-Z]/(&)/g'Еще примеры
показать только первую и последнюю строки (комбинация
head -1/tail -1)sed -n '1p;$p'Объединить все строки (аналог
paste -sd ' ')sed ":a;N;s/\n/ /;ta"Объединить строки попарно
sed "N;s/\n/ /"Своп каждой пары строк
sed -n '$p;h;n;G;p'Сравнить две строки и вывести общий совпадающий фрагмент (начало строк)
sed -n 'N;s/\(.*\).*\n\1.*/\1/p'Странно, что очень редко сравнивают BPMN и блок-схемы. А первый если и не вырос из второго, но очень близок по сути.
С одной стороны как-то сложно и запутанно, и автор сам это отмечает. С другой стороны - подобные фичи в том или ином объеме представлены в других языках, например, Perl и его последователях.
В win10 в этом необходимости уже нет.
> Для ввода используется xcopy /W
Теперь все понятно. Я видел эту команду, но потом забыл о ней и все не мог понять как set /p принимает ввод клавиш без ожидания.
Посмотрите здесь: https://www.dostips.com/forum/viewtopic.php?f=3&t=6812
Там используются сантисекундные задержки и ввод производится с помощью
set /pи одного хитрого трюка (сам еще не до конца понял его)"%~F0" Input >> pipeFile.txt | "%~F0" Main < pipeFile.txt.Интересно Ваша реализация следующего пути документообновления.
Вы (команда или один человек) готовите документ в asciidoc, затем собираете в формат docx и передаете заказчику (внешний или внутрении) на рассмотрение. Он редактирует документ, добавляет комментарии "на полях" (в которых часто выносятся новые мысли или предполагаемые предложения к правкам) и высылает обновленный docx файл.
И теперь вопросы. Есть ли возможность перевести изменения в репозиторий из формата docx снова в формат asciidoc? Есть возможность не потерять эти комментарии и принять их во внимание?
Подобное обсуждалось здесь в коментариях к серии статей под общим названием "Asciidoc для подготовки сложной документации", например https://habr.com/ru/post/550086/comments/#comment_22886324.
На идеях, изложенных в статье, пишутся скрипты-полиглоты (другие названия: скрипты-гибриды, скрипты-химеры). А еще скрипты - генераторы таких скриптов
https://github.com/ildar-shaimordanov/cmd.scripts/blob/master/cmdize.bat
Davide
И произносится ближе к Давидэ.
Согласен.
Вы все верно поняли. Это не то чтобы разное поведение, это одинаковый, единообразный вывод.
В примере выше я привел функцию
logMsg, которая используют особенностиcatecho. С их помощью и с помощью других функций (как, например,warnиз второго примера выше) можно единообразно логгировать. Здесь, 1-ый и 2-ой примеры взаимозаменяемы, но 1-ый, по мнению автора, элегантнее.Промахнулся кнопкой "Ответить". Мой ответ Вам - ниже.
Не вижу проблем. Ну, если какие-то особые редкие случаи в экзотических дистрибутивах или в макоси, с которыми я не сталкивался.
Вот пример
Ваш вопрос заставил меня немного задуматься. И я вспомнил, откуда ноги растут у этой функции. Это кусок кода для логирования всего с разными уровнями (DEBUG, INFO, NOTICE, WARNING, ERROR, CRITICAL). Не скажу, что в
catechoсейчас есть большая нужда. Исторически так сложилось, что эта функция перетекает из одного скрипта в другой.Вот небольшой фрагмент и несколько гипотетических примеров. Понятно, что
echo "..."это просто заглушки для примеров, на самом деле - там какие-то внешние команды или функции. Первый пример, явно, избыточен - он легко перекрывается вторым, но первый виделся мне тогда и видится сейчас элегантнее, чем второй.Думаю, что для определения "домашнего" каталога скрипта цепочку dirname/realpath можно опустить и оставить только dirname.
Во многих своих скриптах я часто использу такое подобие шаблона. Некоторые определения могут отсутствовать. Кое-что добавляется в зависимости от задачи. Функции die/warn/catecho - для удобства вывода диагностических сообщений и аварийного прекращения.