LINUX.ORG.RU

bash if


0

1

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

но не могу понять что ему от меня надо

скриптик

#!/bin/sh while true; do sDate="$(date +%H):$(date +%M)"; if [$sDate = "15:50"]; then echo "запуск"; sleep 60; fi sleep 1; done

пишет [15:47: not found

где я пронубил не как понять не могу

пишет [15:47: not found

Какая буква здесь непонятна? Символ «[» это название программы. Оно должно быть отделено от параметров пробелами.

sin_a ★★★★★ ()

Для многострочного листинга используй тег [code]

theNamelessOne ★★★★★ ()
Ответ на: комментарий от vostrik

Нет, не имел; тут вам не си, хоть и работает (но не везде).

NeXTSTEP ★★ ()
Ответ на: комментарий от reptily

можно попробовать команду at

alf@xxx-dev:~$ date
Чтв Янв 23 17:11:05 MSK 2014
alf@xxx-dev:~$ ll test.file
ls: невозможно получить доступ к test.file: Нет такого файла или каталога
alf@xxx-dev:~$ at "17:12"
warning: commands will be executed using /bin/sh
at> touch /home/alf/test.file
at> <EOT>
job 6 at Thu Jan 23 17:12:00 2014
alf@xxx-dev:~$ ll test.file
ls: невозможно получить доступ к test.file: Нет такого файла или каталога
alf@xxx-dev:~$ at -l
6       Thu Jan 23 17:12:00 2014 a alf
alf@xxx-dev:~$ at -l
alf@xxx-dev:~$ ll test.file
-rw-r--r-- 1 alf user 0 Янв 23 17:12 test.file
vtVitus ★★★★★ ()

Нужны пробелы вокруг [ ].

anonymous ()

В дополнение к сказанному. date позволяет указать любое количество спецификаторов в строке формата, не нужно делать два вызова, достаточно date '+%H:%M'.

mky ★★★★★ ()
Ответ на: комментарий от vostrik

ты имел в виду ==

Нет, не имел. == это башизм, нужно писать =

А вообще, кроме отделения пробелами скобок, лучше привыкнуть в [] всегда писать аргументы в двойных кавычках, ибо иначе если в переменной попадётся пробел она раскроется в несколько аргументов. Т.е. если ты добавишь день недели, например

if [ $sDate = "15:50 Thu" ]

раскроется в

if [ 15:30 Thu = "15:30 Thu" ]
что не только не сматчится, но и неверный синтаксис.

slovazap ★★★★★ ()

Права на кронтаб у тебя быть должны, даже если тачка не твоя. Запускай crontab -e и удали свой ужасный скрипт.

Chumka ★★★ ()
Ответ на: комментарий от slovazap

лучше привыкнуть в [] всегда писать аргументы в двойных кавычках, ибо иначе если

Нужно не привыкать к оверинжинирингу, а убрать «если», те выявить переменные с произвольными данными, и только вокруг них поставить кавычки.

anonymous ()

пишет [15:47: not found

пробел после [

emulek ()
Ответ на: комментарий от reptily

к сожалению на крон нету прав у меня((( тачка не моя

а не нужно в рутовый кронтаб забивать, у тебя твой есть, собственный.

emulek ()
Ответ на: комментарий от anonymous

Нужно не привыкать к оверинжинирингу, а убрать «если», те выявить переменные с произвольными данными, и только вокруг них поставить кавычки

Подход, из-за которого появляется падучее и дырявое ПО. Как минимум, думать «где» могут быть произвольные данные - это куда большее усложнение разработки чем всегда ставить кавычки. Как максимум, после любого изменения нужно будет проводить аудит на предмет «нет ли шанса что где-то появился пробел» - жизненный пример я уже привёл. Иди подметай улицу и не давай больше таких советов.

slovazap ★★★★★ ()
Ответ на: комментарий от slovazap

лучше привыкнуть в [] всегда писать аргументы в двойных кавычках

Не стоит забывать и о [ "x$sDate" == "x15:50 Thu" ], ибо sDate может начинаться с минуса и трактоваться как опция.

E ★★★ ()
Ответ на: комментарий от slovazap

Подход, из-за которого появляется падучее и дырявое ПО.

Дырявое по появляется из-за говнокодеров.

Как минимум, думать ... - это куда большее усложнение разработки

Тяжело понять говнокодерам, но люди думают, когда пишут код.

Как максимум, после любого изменения нужно будет проводить аудит на предмет «нет ли шанса что где-то появился пробел»

Ты даже не понимаешь, что в коде на шелл в ещё множестве мест случайно поставленный символ не вызовет синтаксических ошибок, но сломает работу программы? Иди домывай посуду, и не пиши тупости.

anonymous ()
Ответ на: комментарий от anonymous

Дырявое по появляется из-за говнокодеров.

Вот-вот.

slovazap ★★★★★ ()
Ответ на: комментарий от wakuwaku

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

slovazap ★★★★★ ()
Ответ на: комментарий от E

Не стоит забывать и о [ "x$sDate" == "x15:50 Thu" ], ибо sDate может начинаться с минуса и трактоваться как опция.

читай man bash до полного просветления, и не говори больше ерунды.

[ "$sDate" == "15:50 Thu" ] отлично работает. С минусом.

emulek ()
Ответ на: комментарий от slovazap

[[ - тоже башизм.

что такого в этом страшного?

в C, где такое, впрочем, тоже пишут только имбецилы, хотя бы есть теретическое обоснование - застраховаться от присваивания в условии), только код становится сложнее читать.

на самом деле, читать таки проще. Сразу понимаешь, что это сравнение.

emulek ()
Ответ на: комментарий от slovazap

башизм

как будто что-то плохое. Кроме этого у ТС "$(date +%H):$(date +%M)" - зачем?

только имбецилы

но при этом применяется повсеместно, ага. Если это сложнее читать, стоит задуматься об умственных способностях читатающего. Такое сравнение более очевидно с 1 взгляда. Почему бы не притащить практики хорошего кода из сишечки?

wakuwaku ★★★★ ()
Ответ на: комментарий от emulek

что такого в этом страшного?

Привязка к bash который, на минуту, далеко не единственный шелл и есть далеко не везде.

на самом деле, читать таки проще. Сразу понимаешь, что это сравнение

Нет, не проще. Во-первых, в [] всегда сравнение. Во-вторых, сравнивают переменную с константой, никогда не наоборот.

slovazap ★★★★★ ()
Ответ на: комментарий от wakuwaku

как будто что-то плохое

Плохое. Ничем не отличается от windows-only кода.

но при этом применяется повсеместно

Нет.

Такое сравнение более очевидно с 1 взгляда

Нет.

slovazap ★★★★★ ()
Ответ на: комментарий от slovazap

Подход, из-за которого появляется падучее и дырявое ПО. Как минимум, думать ...

Это победа.

aedeph_ ★★ ()
Ответ на: комментарий от slovazap

Возможно, это спорный вопрос. Но в случаях, подобных данному, это вполне так. К тому же никто не ставил задачу писать переносимый код, достаточно указать #!/usr/bin/env bash в начале файла.

wakuwaku ★★★★ ()
Ответ на: комментарий от emulek

bash - не единственная оболочка в мире. Есть ещё sh и пока что это стандарт.

$ D="-eq"; [ "$D" == "1" ] && echo true || echo false
sh: 1: [: -eq: unexpected operator
false
E ★★★ ()
Ответ на: комментарий от wakuwaku

Ну да, а для вендософта достаточно поставить венду.

slovazap ★★★★★ ()
Ответ на: комментарий от emulek

а не нужно в рутовый кронтаб забивать, у тебя твой есть, собственный.

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

val-amart ★★★★★ ()
Ответ на: комментарий от emulek

отлично работает. С минусом.

в баше, ты забыл сказать

читай man bash до полного просветления, и не говори больше ерунды.

читай SUSv3 до полного просветления и не говори больше ерунды.

val-amart ★★★★★ ()
Ответ на: комментарий от val-amart

хорошо хоть env есть, могло и не быть.

Брысь на винфак.

aedeph_ ★★ ()
Ответ на: комментарий от reptily

к сожалению на крон нету прав у меня((( тачка не моя

тогда at.

dikiy ★★☆☆☆ ()
Ответ на: комментарий от slovazap

Привязка к bash который, на минуту, далеко не единственный шелл и есть далеко не везде.

и что? Да, если я начал с !#/bin/bash, то я пишу на баше. И не ограничиваю себя стандартом, который старше меня. М довольно глупо выглядит POSIX совместимая проверка ассоциативного массива.

Нет, не проще. Во-первых, в [] всегда сравнение.

например [ -d "$X" ].

Во-вторых, сравнивают переменную с константой, никогда не наоборот.

может ты Царь, да? А чё? Он тоже любит придумывать всякий бред, а потом его излагает.

emulek ()
Ответ на: комментарий от val-amart

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

это говорит только о том, что администратор == мудак. Естественно, его пользователи должны страдать, и писать костыли на POSIX-shell'е. На последнем потому, что админ мудак, и в любой момент может сделать вместо bash'а симлинк на csh.

emulek ()
Ответ на: комментарий от val-amart

в баше, ты забыл сказать

ты сабж осилил, детка?

читай man bash до полного просветления, и не говори больше ерунды.

читай SUSv3 до полного просветления и не говори больше ерунды.

детка, сейчас 2014й год, а не 2001й.

emulek ()
Ответ на: комментарий от emulek

нет, свой сервер на 256 CPU и 1Tb RAM. посикс, между прочим. и крон там только у админов и Control-M.

Короче, мир не заканчивается на твоем телефоне и домашнем PC, на GNU и Линуксе. хватит плодить быдлокод и других учить тому же. Особенно когда поддержка Posix от тебя ничего не требует, кроме знания стандарта, как в этом случае.

val-amart ★★★★★ ()
Ответ на: комментарий от val-amart

нет, свой сервер на 256 CPU и 1Tb RAM. посикс, между прочим. и крон там только у админов и Control-M.

т.е. у юзеров только POSIX shell есть, да?

Короче, мир не заканчивается на твоем телефоне и домашнем PC, на GNU и Линуксе. хватит плодить быдлокод и других учить тому же. Особенно когда поддержка Posix от тебя ничего не требует, кроме знания стандарта, как в этом случае.

детка, стандарты бывают разные. Gnu bash это тоже стандарт. И он поддерживается практически везде, где это имеет смысл. А где не имеет, там и posix shell'а нету.

emulek ()
Ответ на: комментарий от val-amart

я где-то пропустил

да. В самом начале. Ты пропустил азы, а именно, как правильно выполнять задания по расписанию. И POSIX имеет к этому отношения не больше, чем фэншуй. Не важно по фэншую или по POSIX'у написан скрипт, он всё равно — нестандартный костыль в данной ситуации.

Ну а т.к. ТС просил костыль на bash'е, то я ему про bash и рассказываю. А волнует-ли его феншуй(SUSv3) — я не в курсе.

emulek ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.