GREP: интерактивный против crontab - PullRequest
Новая
       9

GREP: интерактивный против crontab

3 голосов
/ 16 февраля 2012

У меня есть простой текстовый файл, который я отслеживаю для изменения, используя скрипт BASH.Текст, который я ищу, может начинаться с начала строки или смещаться на пробелы.Мой поиск довольно прост;

#!/bin/bash
value=`/bin/grep "^\s*mystring:" mytextfile`
echo "found: [$value]" >> myoutput.log

Это прекрасно работает при запуске из командной строки, но не работает, если вызывается из скрипта, настроенного в crontab.У меня есть обходной путь для моей проблемы, но я все еще не могу объяснить, почему одновременное использование символов вставки (^) и пробела (\ s *) при вызове grep из crontab?

Изменение PATH и среды не кажетсяиметь какое-либо влияние.Любые идеи?

... спасибо за комментарии!

  1. путь к grep был последовательным
  2. то же самоеСценарий вызывался из командной строки, как было настроено в crontab

Решением было использование синтаксиса; 

value=`/bin/grep -E '^[[:space:]]*mystring:' myfile`

Необходима комбинация из 3 вещей;

  1. одинарные кавычки при использовании регулярного выражения
  2. grep -E! Расширенное регулярное выражение
  3. [[: space:]] вместо \ s для пробела

Я до сих пор не уверен, почему [[: space:]] работал, когда \ s не в crontab, когда он работает в интерактивном режиме.

Ответы [ 3 ]

0 голосов
/ 10 августа 2013

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

0 голосов
/ 28 января 2014

Извините, если немного опоздал на вечеринку ... Я только что обнаружил очень похожую проблему с egrep после нескольких лет безукоризненного использования этого же сценария.

Получилась переменная окружения LANGпроблема.Если я скажу, скажем, 'blablabla', он отлично работает как в консоли, так и в crontab.Тем не менее, если я ищу «blablablá», в последнем случае происходит сбой, но не в первом (я везде использую кодировку Latin1).

printenv в crontab дал мне LANG=en_US.UTF-8, в то время как в консоли у меня нет LANG установленной переменной env.Поэтому решение было добавить LANG="" в мой файл crontab.Проблема решена.

Понятия не имею, почему она внезапно изменилась.Может быть, обновление в crontab или grep?

Итак, я бы посмотрел на проблему с переменной env.Другие также предложили это с другими переменными.

0 голосов
/ 20 февраля 2012

Если вы можете запускать эти команды изнутри скрипта оболочки в командной строке, и он работает, но не в crontab, то я предполагаю, что переменная SHELL по умолчанию в crontab не имеет ту же оболочку, что и выиспользовать в командной строке.Будет ли это так?

Вы можете проверить значение по умолчанию в / etc / crontab или принудительно установить его в самом crontab (над графиками) таким же образом:

SHELL = /bin / bash

Мой установлен на / bin / bash, и я смог использовать ваш скрипт следующим образом:

  • Создан /tmp/test.sh с вашим кодомв нем
  • Создан / tmp / mytextfile со строкой «mystring:» в нем, за которым следуют дополнительные тестовые строки случайных символов.
  • Создал следующую запись в моем crontab: */1 * * * * (cd /tmp; /bin/bash test.sh)
  • Замкнул файл myoutput.log и ждал 1 минуту.

Линия found: [ mystring:] появлялась каждую минуту.Так что это сработало.

Я использую CentOS 6.2

...