Как поставить кавычки в задании ANS с помощью grep, awk, sed - PullRequest
Новая
       47

Как поставить кавычки в задании ANS с помощью grep, awk, sed

0 голосов
/ 19 января 2019

Моя задача выполняет поиск конфигурации в столбце CMD, чтобы собрать информацию о том, что является каталогом конфигурации приложения, а также PID. 

---
- hosts: all
  pre_tasks:
    - name: Check if process is running
      become: yes
      shell: 'ps -e --format="pid cmd" | grep process.cfg | sed -e "s/[[:space:]]\+/ /g"| grep -v color'
      register: proces_out

Вывод выглядит следующим образом после этой команды: 

32423 /var/local/bin/application -c /var/local/etc/process.cfg

Но я думаю, что у ansible есть проблемы с 2 greps в 1 команде.Я нуждаюсь в них обоих, потому что, если я не использую обратный "grep -v color", эта раздражающая вещь появляется "grep --color = auto", я не могу вырезать PID, который мне нужен в другой задаче, которая убивает процесс, потому что реальный процесс находится во второй строке.

Моя вторая идея заключалась в том, чтобы использовать AWK, который, как мне кажется, был бы лучшим инструментом для этого случая, но если бы я использовал двойные кавычки в параметре --format и в команде SED, а одинарный кавычка в awkпараметры они не хотят сотрудничать.Даже если я держу их в равновесии, они мешают им самим.

Идея AWK: 

shell: 'ps -e --format="pid cmd" | grep process.cfg | sed -e "s/[[:space:]]\+/ /g"| awk 'FNR == 2''

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

## PID
{{ proces_out.stdout.split(' ')[0] }} 
## application
{{ proces_out.stdout.split(' ')[1] }}
## config
{{ proces_out.stdout.split(' ')[3] }}

Ответы [ 2 ]

0 голосов
/ 19 января 2019

Спасибо Мэтью за это решение, но я нашел отличную возможность, чтобы избежать ненужных результатов. Так что синтаксис почти такой же, но я добавил к --format дополнительный параметр ppid Идентификатор родительского процесса, в большинстве случаев я считаю, что родительский процесс всегда имеет номер 1 в выводе, что помогает сортировать его так, как я хочу.

Это выглядит так: 

  shell: >
    ps -e --format="ppid pid cmd" |
    grep process.cfg |
    sed -e "s/[[:space:]]\+/ /g"
  register: output_process

И вывод выглядит так: 

 1 54345 /var/local/bin/application -c /var/local/etc/process.cfg
6435 6577 grep --color=auto process.cfg

Теперь это легко, мы можем использовать ANSIBLE модули для сортировки: 

- name: Kill process
  become: yes
  shell: "kill {{ output_process.stdout_lines[0].split(' ')[2] }}"

Что это делает? он выбирает строку 0, которая является первой строкой, разделяет вывод между пробелами и выбирает третью фразу. В выводе есть :space: до ppid, поэтому PID является третьим

Еще раз спасибо за ваше решение Мэтью, это может быть полезно в другом случае.

0 голосов
/ 19 января 2019

Но я думаю, что у ansible проблемы с 2 greps в 1 команде

То есть точно не соответствует действительности

Если я не использую обратный "grep -v color", эта раздражающая вещь появляется как "grep --color = auto", я не могу вырезать PID, который мне нужен в другой задаче, которая убивает процесс, потому что реальный процесс находится во второй строке.

Вы сталкиваетесь с классическим случаем, когда процесс grep соответствует его собственному регулярному выражению, как это происходит во многих «простых» случаях. То, что вы хотите, это регулярное выражение, которое соответствует вашей строке, но не соответствует самому себе. В приведенном выше примере это будет: 

  shell: 'ps -e --format="pid cmd" | grep process[.]cfg | sed -e "s/[[:space:]]\+/ /g"'

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

Что касается этого бита --color, вы, вероятно, можете обойти эту глупость, используя полный путь к grep, что приведет к тому, что bash действительно выполнит двоичный файл, по сравнению с некоторым псевдонимом, использующим --color=auto; На самом деле я бы не ожидал, что цвета будут отображаться в заданном порядке, потому что это не правильно $TERM, но системы странные

...