Как использовать вывод readProcess в привязке клавиш xmonad?

Итак, некоторое время назад я думал об основе эффекта привязки клавиш в моем xmonad на основе вывода скрипта на моем компьютере. В конце концов я решил не делать этого по несвязанным причинам, но недавно я попытался сделать что-то подобное просто в качестве упражнения в изучении Haskell.

Итак, учитывая функцию:

test = readProcess "echo" ["-n", "gvim"] []

Это вызывает, потому что test возвращает строку ввода-вывода, а spawn ожидает строку.

((modm, xK_y), spawn ("xmessage " ++ test))

В порядке. Это классно. Я понимаю, что операции ввода-вывода непредсказуемы, поэтому их следует хранить отдельно. Отлично. Итак, я немного покопался в Интернете и добрался до этого (отбросил xmessage и просто хочу сам пройти вывод теста):

((modm, xK_y), liftIO test >>= spawn)

Это хуже. Он раздражающе компилируется, но ничего не происходит, когда я пробую привязку. (Я также заменил его просто порождающим «xmessage test», и это сработало)

Итак, затем я подумал: «Может быть, что-то не так с моей функцией», поэтому я повторил ее, но от GCHi я получил «gvim», что правильно. Итак, я пишу это в файл haskell:

main = test >>= putStrLn
test = readProcess "echo" ["-n", "gvim"] []

Тоже работает корректно.

Итак, где я ошибся?

РЕДАКТИРОВАТЬ: Решение состояло в том, чтобы использовать runProcessWithInput вместо readProcess. Связанная ссылка: https://ghc.haskell.org/trac/ghc/ticket/5212 привязка xmonad io не работает


person HokieGeek    schedule 11.05.2016    source источник


Ответы (1)


Обновить

По-видимому, решение (см. комментарии ниже) заключается в использовании readProcessWithInput

Исходный ответ

Вы сказали, что:

liftIO test >>= spawn

не сработало, а как насчет:

liftIO test >>= (\m -> spawn ("xmessage " ++ m))

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

Еще несколько вещей, которые можно попробовать в этом духе:

return "gvim" >>= (\m -> spawn ("xmessage " ++ m))


import Data.Char

do { m <- liftIO test;  spawn ("xmessage " ++ (filter isAlpha m)) }

Первый должен быть успешным, так как он эквивалентен spawn "xmessage grim". Второй удалит все новые строки (действительно, любые небуквы) из вывода test.

Некоторые дополнительные вещи, которые могут пролить свет на происходящее:

  1. Создайте скрипт с именем /tmp/report со следующим содержимым:

    #!/bin/sh
    ( date; echo "/tmp/report was called with args" "$@") >> /tmp/output
    
  2. Сделайте /tmp/report исполняемым.

  3. Запустите /tmp/report и убедитесь, что к /tmp/output добавлены две строки.
  4. В конфигурации вашей монады сделайте действие spawn "/tmp/report A". Проверьте действие, проверив, добавлена ​​ли ожидаемая строка к /tmp/output.
  5. Попробуйте сделать действие монады следующим образом:

    liftIO (readProcess "/tmp/report" ["B"] "") >> spawn "/tmp/report A"
    

    (Обратите внимание, что мы используем здесь >>, а не >>=.) Когда вы запускаете действие, вы должны увидеть строку отчета для вызова B, а также одну для вызова A.

Основываясь на том, что вы видите в файле /tmp/output, вы сможете определить, выполняется ли команда readProcess, а также срабатывает ли команда spawn.

person ErikR    schedule 11.05.2016
comment
Никакой разницы, к сожалению. - person HokieGeek; 12.05.2016
comment
Добавлено несколько новых идей для опробования. - person ErikR; 12.05.2016
comment
Я отредактировал свой вопрос, но в текущем примере эхо с -n, похоже, не возвращает новую строку, по крайней мере, когда я пытаюсь это сделать в отдельной программе. Собираюсь попробовать другие предложения. - person HokieGeek; 12.05.2016
comment
Никакой радости :-/ Первый действительно удался, но второй не дал ответа на мою привязку. - person HokieGeek; 12.05.2016
comment
Добавил еще несколько вещей, чтобы попробовать. - person ErikR; 12.05.2016
comment
Судя по всему, проблема заключалась в том, как xmonad обращается со своими дочерними элементами. Решение состоит в том, чтобы заменить readProcess на runProcessWithInput. - person HokieGeek; 12.05.2016