Когда использовать каждый метод запуска подпроцесса в Ruby

1. `` Backtick

  • определенный в Kernel

1. a) %x{} Процент X < альтернативный синтаксис для Backtick

2. system()

3. fork()

4. open()

4.a. < t25 < ведет себя так же, как open()

4.b. open("|-")

  • fork to the pipe

4.c. < t28 < ведет себя так же, как open("|-")

5. Open3.popen3()

  • require 'open3'
  • stdlib Open3

6. PTY.spawn()

  • require 'pty'
  • stdlib PTY

7. Shell.transact()

  • require 'shell'
  • stdlib Shell

Когда нужно отказаться от надежного обратного тика для одного из более сложных методов?

Изменить 1. Большое спасибо Avdi Grimm за сообщения, описывающие пример использования каждого метода: # 1 (& gist); # 2 (& gist); # 3.

Они являются фантастическими ресурсами для ответа How, но не в явном виде отвечают, когда каждый из них должен использоваться или почему, и как таковые IMHO не являются полными ответами на этот вопрос.

Ответ 1

  • используйте backticks, если вы хотите легко захватить вывод программы в переменной. вы, вероятно, хотите использовать это только для коротких программ, потому что это будет заблокировано.

  • system удобно в двух разных случаях:

    а. У вас есть длинная работающая программа, и вы хотите, чтобы вывод печатался при запуске (например, system("tar zxvf some_big_tarball.tar.gz"))

    б. system может обойти расширение оболочки, например, exec (сравните вывод system "echo *" и system "echo", "*")

    пока не завершится подпроцесс.

  • fork имеет пару различных вариантов использования:

    а. Вы хотите запустить некоторый код ruby ​​в отдельном процессе (например, fork { .... }

    б. Вы хотите запустить дочерний процесс (или другую программу), не блокируя прогресс вашего script fork { exec "bash" }.

    fork является вашим другом, если вы хотите демонизировать вашу программу.

  • IO.popen полезен, когда вам нужно взаимодействовать со стандартным и стандартным программным обеспечением. Обратите внимание, что он не фиксирует стандартную ошибку, поэтому вам нужно перенаправить это с помощью 2>&1, если вам это интересно.

  • popen3 дает вам отдельный файловый дескриптор стандартной ошибки (если вам нужно сделать это отдельно от стандартного)

  • PTY.spawn необходим, если вы хотите, чтобы порожденная программа вела себя так, как будто вы работаете с терминалом. См. Разницу grep --color=auto pat file при порождении с помощью system vs PTY.spawn