Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 17
Первые два способа у меня не сработали, скорее всего из-за настроек терминала.Если у вас Ubuntu или что-то ещё, то PC-спикер отключён в ядре чёрным списком /etc/modprobe.d/blacklist.conf. Цитата, с которой я полностью согласен:
# ugly and loud noise, getting on everyone's nerves; this should be done by a
# nice pulseaudio bing (Ubuntu: #77010)
blacklist pcspkr
Bell обычно выводится как-то так:
Зачем там у вас доллар — никак не пойму.
echo -e '\a'Зачем там у вас доллар — никак не пойму.
select — это зверский башизм, не стоит его использовать. Если уж так хочется интерактива — то любой из вариантов dialog выглядит и работает на порядке адекватнее.
Bash заявлен в названии статьи, так что башизм вполне уместен.
А dialog — это вообще отдельный пакет.
А dialog — это вообще отдельный пакет.
Уместен-то уместен, но учитывая нацеленность статьи на в целом начальный уровень — я бы все-таки обосновывал его применение — а здесь явно смысла использовать именно bash никакого. А так — особенно для новичков — bash довольно медленный и местами сильно странно себя ведет — в отличие от sh (dash, ash), которые весьма близко соответствуют стандарту.
А что до dialog — он входит в basesystem всех известных мне современных ОС — правда, возможно, в весьма покоцанном виде. Чего, кстати, совсем не скажешь о bash — на многих не-GNU системах он по умолчанию не устанавливается.
А что до dialog — он входит в basesystem всех известных мне современных ОС — правда, возможно, в весьма покоцанном виде. Чего, кстати, совсем не скажешь о bash — на многих не-GNU системах он по умолчанию не устанавливается.
Dialog описывался в первой части. Кстати есть такая штука, как whiptail, которая в большинстве случаев стоит по дефолту.
Иногда использовать псевдографику не очень оправдано.
На счет портируемости — да, не подумал. Но с необходимостью использовать скрипты на без bash-ных системах не встречался. В любом случае, выбор инструмента за вами.
Иногда использовать псевдографику не очень оправдано.
На счет портируемости — да, не подумал. Но с необходимостью использовать скрипты на без bash-ных системах не встречался. В любом случае, выбор инструмента за вами.
Первую часть помню, за ее написание — спасибо :)
Но в целом, субъективно, основная проблема написания на sh/bash — решить, нужно ли на нем это писать или не нужно. В некоторых случаях (и почти все интерактивные случаи относятся в основном сюда) лучше написать на каком-то другом скриптовом языке, а в некоторых случаях — наоборот, shell scripting себя оправдывает — и тогда нужно выбирать между sh и bash. У bash есть несколько killer features (таких, как pipefail, хитрые глоббинги, гораздо более богатые substitutions, pushd/popd, массивы или интерактивный режим), но далеко не всегда лучше выбирать его (и уж если выбирать — то осознанно).
Но в целом, субъективно, основная проблема написания на sh/bash — решить, нужно ли на нем это писать или не нужно. В некоторых случаях (и почти все интерактивные случаи относятся в основном сюда) лучше написать на каком-то другом скриптовом языке, а в некоторых случаях — наоборот, shell scripting себя оправдывает — и тогда нужно выбирать между sh и bash. У bash есть несколько killer features (таких, как pipefail, хитрые глоббинги, гораздо более богатые substitutions, pushd/popd, массивы или интерактивный режим), но далеко не всегда лучше выбирать его (и уж если выбирать — то осознанно).
Люди разные. Кому-то проще писать скрипты на питоне/перле, а кому-то хочется писать на sh/bash. ИМХО в Linux bash как-то нативнее, что ли…
Но спасибо за информацию, буду думать :)
Но спасибо за информацию, буду думать :)
Вопрос не в людях, а, в первую очередь, в задачах. Я уже многие годы бьюсь и хочу хоть как-то для себя сформулировать четкие принципы — когда стоит решать задачу каким подходом и инструментом.
Про shell я по крайней мере понял, что четкое «нет» — это любые алгоритмически-нагруженные вещи.
Поэтому как только число переменных становится больше десятка, хочется заводить всякую объектно-ориентированность, массивы, сложные структуры данных и т.д. — это такая лакмусовая бумажка, хороший индикатор того, что shell нужно оставлять и переходить к скриптовым языкам.
Четкое «да» и показание к применению — когда то, что пишешь занимается ровно тем, для чего нужны shell scripts — запускать другие программы — и иногда какая-то минимальная логика, связывающая эти запуски. Из shell может быть вполне удобно запускать программы довольно сложными способами (в background, pool'ом worker'ов, с разными приоритетами, очередями, с привязкой к разным процессорам и т.п.). make (если можно считать его частью shell scripting) и xargs местами *здорово* облегчают жизнь.
Четкое «да» — когда нужно много прыгать с машины на машину через ssh и делать тем самым некую распределенную систему.
А вот по поводу всяких пограничных случаев — сильно не уверен, несмотря на то, что shell все познаю и познаю потихоньку… года с 98-го, наверное?.. или 97?..
Про shell я по крайней мере понял, что четкое «нет» — это любые алгоритмически-нагруженные вещи.
Поэтому как только число переменных становится больше десятка, хочется заводить всякую объектно-ориентированность, массивы, сложные структуры данных и т.д. — это такая лакмусовая бумажка, хороший индикатор того, что shell нужно оставлять и переходить к скриптовым языкам.
Четкое «да» и показание к применению — когда то, что пишешь занимается ровно тем, для чего нужны shell scripts — запускать другие программы — и иногда какая-то минимальная логика, связывающая эти запуски. Из shell может быть вполне удобно запускать программы довольно сложными способами (в background, pool'ом worker'ов, с разными приоритетами, очередями, с привязкой к разным процессорам и т.п.). make (если можно считать его частью shell scripting) и xargs местами *здорово* облегчают жизнь.
Четкое «да» — когда нужно много прыгать с машины на машину через ssh и делать тем самым некую распределенную систему.
А вот по поводу всяких пограничных случаев — сильно не уверен, несмотря на то, что shell все познаю и познаю потихоньку… года с 98-го, наверное?.. или 97?..
Спасибо, хорошо сформулировал.
Стоит разделить понятие скрипт и программа. Скрипт по определению не может быть большим и сложным. Он должен выполнять конкретную задачу, в большинстве случаев — облегчение рутинных операций.
Я как-то разделение с трудом представляю — по крайней мере для себя… Если у меня работа такая — автоматизировать рутинные операции? И через пару-тройку месяцев сборище скриптиков по 3-4 строчки, которых пишешь десятки в день, начинает превращаться в какие-то фреймворки, с своей системой библиотек, зависимостей — это уже программа или нет?
echo "…" >> /var/log/syslogНе делайте так НИКОГДА. В файл /var/log/syslog уже пишет один процесс (сам syslogd), а когда в один файл пишут несколько процессов в файле образуется мешанина из записанных в него данных (одни частично перекрывают другие). Ибо нет у нас гарантии, что и syslogd и bash открывали этот файл с флагом O_APPEND. Хотите что-то записать в syslog — пишите в /dev/log (через socat) или через утилиту logger.
setleds -D +caps < /dev/tty7Врядли для этого нужен root. Скорее просто нужны права на запись в /dev/tty*. В некоторых дистрибутивах для этого достаточно добавить пользователя в группу tty, в других можно к примеру при загрузке системы изменить владельца или права доступа к всё равно неиспользуемому /dev/tty63, тогда даже в cron-скриптах можно будет beep-ать и мигать лампочками через >/dev/tty63.
Скрипт необходимо запускать с правами рута!
Спасибо! Полезные статьи, именно как пинок в нужном направлении :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Взаимодействие bash-скриптов с пользователем. Часть 2