Guard: Ctrl-C вылетает из охранника

Тоже испытываю на 2.2.5.

Я тоже испытываю это (фактически такая же трассировка стека), но использую Ruby v2.3.0 , Guard v2.13.0 .

Если я запускаю Guard через bundle exec guard а затем нажимаю Ctrl-C в командной строке, я вижу проблему. Однако, если я запустил guard не через пакет, нажатие Ctrl-C не вызовет проблемы.

Полные версии Ruby и Readline:

$ ruby -v
ruby 2.3.0p0 (2015-12-25 revision 53290) [x86_64-darwin15.5.0]

$ ruby -rreadline -e 'puts Readline::VERSION'
6.3

После появления ошибок подсказки Pry я получаю повреждение терминала, подобное тому, что описано здесь:
https://github.com/pry/pry/issues/1275
https://github.com/pry/pry/issues/1183
https://github.com/guard/guard/issues/719

Если я вручную устанавливаю гем rb-readline , это устраняет проблему повреждения, которая возникает впоследствии, но Ctrl-C дает ту же трассировку стека. Когда этот гем установлен, охранник сообщает о моей версии Readline следующим образом:

[1] guard(main)> Readline::VERSION
=> "5.2"

Здесь возникает точно такая же проблема ... как предлагает

$ ruby -v
ruby 2.3.1p112 (2016-04-26 revision 54768) [x86_64-darwin14]
$ guard -v
Guard version 2.14.0

Моя версия Readline - 6.3 как внутри, так и снаружи.

Это похоже на комбинацию нескольких вещей.

Скорее всего, я создам ветку «quickfix», а позже решу, как ее интегрировать.

Хорошо, я создаю ветку с некоторыми хаками: https://github.com/guard/guard/tree/experimental_fixes

Вот как использовать в Gemfile :

gem 'guard', github: 'guard/guard', branch: 'experimental_fixes'

Затем бандл апдейт и bundle exec guard как обычно.

Кроме того, вы можете попробовать отключить уведомления, чтобы узнать, помогает ли это:

bundle exec guard -n f

Пожалуйста, сообщайте о проблемах, а также об исправлениях.

Некоторые проблемы это должно исправить:

1. Pry должен перестать вылетать при выходе из охраны с помощью ctrl-C
2. Вывод после последних строк не должен скрывать приглашение оболочки под
3. Уведомители TMux и TerminalTitle, похоже, вызывают проблемы с выводом.
4. Я не проверял, но возможно, что при ведении журнала LumberJack используется промывка времени, хотя этого не должно быть.
5. STDERR поток больше не закрыт
6. Pry больше не убивается и не присоединяется - вместо этого он просыпается (поэтому он не должен "зависать" с учетом других настроек)

Некоторые регрессии / проблемы:

1. Если охрана / задача испортят цветной вывод, это не будет исправлено (сброс консоли был отключен).
2. Для этого нет тестов (я пытаюсь сначала решить, смогу ли я исправить проблемы)
3. Не тестировался на других рубинах, кроме МРТ 2.3.1.

Другие обходные пути:

Если вы в отчаянии, вы можете попробовать использовать Guard без Pry и без уведомлений:

bundle exec guard -n f -i

Сообщите мне, поможет ли это или возникнут другие проблемы, чтобы я мог работать над официальным исправлением и выпуском.

Не стесняйтесь отправлять PR, которые выборочно используют любое из этих исправлений (хотя тесты были бы хороши).

Я внес несколько поправок.

Вы можете вытащить эти изменения (или bundle update если вы используете указанную выше строку Gemfile ) добавить это в свой Guardfile чтобы узнать, поможет ли это:

UI.options.merge!(flush_seconds: 0, level: :debug, device: 'guard.log')
notification :off

Он также будет записывать ошибки в guard.log . (Хотя это может вызвать сканирование всего каталога в OSX).

Спасибо @ e2 , к сожалению, мне не повезло:

• При запуске без дополнительных флагов поведение при сбое при нажатии Ctrl-C остается таким же, как и для ветки "экспериментальные_функции".
• Предоставление -n f не имеет значения.
• Использование параметра -i предотвращает сбой при нажатии Ctrl-C в тестах (хотя из этого трудно выйти!).

Я часто получаю одно из следующих исключений при выходе с Ctrl-D, возможно, из-за состояния гонки:

19:56:17 - INFO - Bundle already up-to-date
19:56:17 - INFO - Guard is now watching at '/mnt/data1/home/andrew/projects/042-joinly/joinly-app'
^Clog writing failed. can't modify frozen IOError
➜  joinly-app git:(master) ✗
/home/andrew/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/bundler/gems/guard-d299ad21cfa8/lib/guard/commander.rb:69:in `stop': undefined method `destroy' for #<Guard::Jobs::Sleep:0x0056104497dd80> (NoMethodError)
        from /home/andrew/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/bundler/gems/guard-d299ad21cfa8/lib/guard/commander.rb:53:in `start'
        from /home/andrew/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/bundler/gems/guard-d299ad21cfa8/lib/guard/cli/environments/valid.rb:16:in `start_guard'
        from /home/andrew/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/bundler/gems/guard-d299ad21cfa8/lib/guard/cli.rb:122:in `start'
[...]

А также

19:56:29 - INFO - Bundle already up-to-date
19:56:30 - INFO - Guard is now watching at '/mnt/data1/home/andrew/projects/042-joinly/joinly-app'
^CE, [2016-08-01T19:56:38.584021 #10597] ERROR -- : run() in thread failed: stream closed:\n /home/andrew/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/rb-inotify-0.9.7/lib/rb-inotify/notifier.rb:300:in `readpartial'
/home/andrew/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/rb-inotify-0.9.7/lib/rb-inotify/notifier.rb:300:in `readpartial'
/home/andrew/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/rb-inotify-0.9.7/lib/rb-inotify/notifier.rb:271:in `read_events'
/home/andrew/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/rb-inotify-0.9.7/lib/rb-inotify/notifier.rb:238:in `process'
/home/andrew/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/rb-inotify-0.9.7/lib/rb-inotify/notifier.rb:221:in `run'
/home/andrew/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/listen-3.1.5/lib/listen/adapter/linux.rb:39:in `_run'
[...]

Строки Guardfile с bundle exec guard -n f кажется, вносят задержку в ошибку. Нажатие Ctrl-C во время тестового запуска по-прежнему вызывает отключение Pry, при этом тест продолжает записывать в STDOUT вместе с активным приглашением. Но заканчивается все так же:

[1] guard(main)> Error: Input/output error - read
/home/andrew/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/pry-0.10.4/lib/pry/repl.rb:198:in `readline'
/home/andrew/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/pry-0.10.4/lib/pry/repl.rb:198:in `block in input_readline'
/home/andrew/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/pry-0.10.4/lib/pry/input_lock.rb:115:in `interruptible_region'

Спасибо @Odaeus за проверку.

Во-первых, я облажался с неконтролируемым интерактором. (Я просто нажал фиксацию, чтобы исправить это).

Во-вторых, вы столкнулись с этой ошибкой rb-inotify: https://github.com/nex3/rb-inotify/pull/59

Для которого я создал исправление (еще не объединенное и не выпущенное).

А пока вы используете это в своем Gemfile :

gem 'rb-inotify', github: 'e2/rb-inotify', branch: 'e2-fix_ioerror_when_closed'

Это решит проблему 2.

Для проблемы 3 - это, вероятно, работа, но убедитесь, что у вас есть в вашем Guardfile :

UI.options.merge!(flush_seconds: 0, level: :debug, device: 'guard.log')
notification :off

И вы можете использовать tail -f guard.log для вывода в другом окне.

Я беспокоюсь, что для исправления этой проблемы придется переработать всю обработку сеанса Pry. На это, наверное, уйдет целая суббота :(

Если у меня будут еще патчи, я сообщу всем здесь как можно скорее.

Хорошо, это должно сработать (насколько я могу судить):

В вашем Gemfile :

 gem "guard", github: "guard/guard",
                branch: "experimental_fixes", ref: "c6ab8a0"

 gem "listen", require: false, github: "guard/listen",
                branch: "advanced_thread_debugging", ref: "31053de"

  gem "guard-rspec", require: false, github: "guard/guard-rspec",
                     branch: "ctrl_c_workaround", ref: "ee0b21d"

  gem "rb-inotify", require: false, github: "e2/rb-inotify",
                    branch: "e2-fix_ioerror_when_closed", ref: "99d2101"

Это довольно много исправлений - не стесняйтесь просматривать, комментировать и отправлять PR, чтобы помочь мне протестировать и выпустить эти исправления как можно быстрее.

Спасибо!

@ e2 Это поведение намного лучше, вы можете видеть, где я нажимаю ctrl-c, он возвращается в командную строку, но процесс находится в середине выхода. В конце возникает исключение, и кажется, что он выходит из лесоруба, но спецификации перестают работать. Спасибо, что взглянули на это. Надеюсь это поможет!

^CGuard: INT signal, handling inside trap...                                                                                                             |  ETA: 00:02:03
Guard Pry job: handling interrupt
Guard Pry job: no thread, interrupting Guard

RSpec is shutting down and will print the summary report... Interrupt again to force quit.
Guard::RSpec: Interrupted by user. Waiting for RSpec to die...
➜  source_code git:(development) ✗  3/17 |========== 17 ==========>                                                                                                                         |  ETA: 00:02:28
Pending: (Failures listed here are expected and do not affect your suite's status)

  1) items can export items pdf export
     # Temporarily skipped with xit
     # ./spec/features/items_spec.rb:38


Top 3 slowest examples (25.2 seconds, 83.1% of total time):
  items can click export button and walk through modals
    14.92 seconds ./spec/features/items_spec.rb:26
  items appear in proper time periods
    10.28 seconds ./spec/features/items_spec.rb:51
  items can export pdf export
    0.00005 seconds ./spec/features/items_spec.rb:38

Finished in 30.33 seconds (files took 1.14 seconds to load)
3 examples, 0 failures, 1 pending

Randomized with seed 54136

Coverage report generated for RSpec to /Users/justin/dev/source_code/coverage. 1759 / 3324 LOC (52.92%) covered.

➜  source_code git:(development) ✗
10:18:10 - INFO - Inspecting Ruby code style: spec/features/items_spec.rb
Inspecting 1 file
.

1 file inspected, no offenses detected

10:18:11 - INFO - Bye bye...
/Users/justin/.rbenv/versions/2.2.5/lib/ruby/gems/2.2.0/gems/lumberjack-1.0.10/lib/lumberjack/device/writer.rb:89:in `close': closed stream (IOError)
    from /Users/justin/.rbenv/versions/2.2.5/lib/ruby/gems/2.2.0/gems/lumberjack-1.0.10/lib/lumberjack/device/writer.rb:89:in `close'
    from /Users/justin/.rbenv/versions/2.2.5/lib/ruby/gems/2.2.0/gems/lumberjack-1.0.10/lib/lumberjack/logger.rb:140:in `close'
    from /Users/justin/dev/source_code/vendor/cache/guard-c6ab8a0b70a3/lib/guard/aruba_adapter.rb:51:in `execute'
    from /Users/justin/dev/source_code/vendor/cache/guard-c6ab8a0b70a3/lib/guard/aruba_adapter.rb:20:in `execute!'
    from /Users/justin/dev/source_code/vendor/cache/guard-c6ab8a0b70a3/bin/_guard-core:11:in `<main>'

@jetheredge - спасибо за тестирование.

У меня не будет времени разбираться в этом слишком рано :(

Я рад, что он более удобен в использовании.

Основываясь на вашем примере, RSpec должен просто остановиться, а Guard должен вернуться к приглашению Pry.

Я думаю, проблема здесь в том, что Guard перехватывает сигнал INT. Не должно. Его следует использовать только для уничтожения Pry, но он не должен ничего делать, если Pry не запущен (и нет заданий).

Я бы принял пиар за это, если кто-то захочет протестировать. (По сути, «Задание Guard Pry: нет потока, прерывание Guard» не должно происходить - прерывание следует просто игнорировать в PryWrapper).

@ e2 спасибо! На следующей неделе я займусь созданием PR.

@jetheredge - думаю, достаточно заменить эту строчку:

https://github.com/guard/guard/blob/c6ab8a0/lib/guard/jobs/pry_wrapper.rb#L108

с просто «возвратом».

Кроме того, Ctrl-C в любом случае не должен выходить из охраны.

@ e2 - Спасибо за руководство, эта неделя была неожиданно загруженной, скоро создам PR.

Все мы такие, поверьте мне;)

(Если вы мне не верите, ознакомьтесь со списком проблем в Guard -
почти все они фичи).

В четверг, 11 августа 2016 г., в 04:10:08 -0700 Джастин Этередж написал:

@ e2 - Спасибо за руководство, эта неделя была неожиданно загруженной, скоро создам PR.

Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую или просмотрите его на GitHub:
https://github.com/guard/guard/issues/842#issuecomment -239132345

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

Я тоже похоронен. Надеюсь, я завершу работу над исправлениями и выпущу их.

Я не уверен, связано ли это, но когда я CTRL-C во время RSpec, я снова падаю в pry, но Guard никогда больше ничего не запустит. Я не особо пробовал его отлаживать. Поведение одинаково с пакетом exec и без него. Я пробовал работать с ветками, которые вы указали выше, и это действительно имело значение, когда моя охрана выйдет после остановки RSpec.

Любая идея? Это связано с этим? Я счастлив покопаться во внутреннем устройстве, если вы не имеете непосредственного представления об этом. У нас много медленных спецификаций, и возможность остановить спецификацию на полпути сэкономит много времени. :)

У меня также есть эта проблема на MacOs Sierra.

Когда я отменяю тест, следующие изменения в файле не запускают тесты. Он перестает смотреть.

У меня такая же проблема. Есть обновления по этому поводу?

Здесь та же проблема. Используя macOS Catalina.