Вопросы Теги

xsel </tmp/xselection не работающий в сценарии

Я не знаю, является ли это тем, что Вы ищете, но можно использовать ssh -D4545 domain.com для открытия, носки проксируют туннель в порте 4545 к желаемой машине от компьютера.

Можно затем настроить тот прокси в приложении (скажите, что Firefox), и используют плагин, чтобы быстро начать и расцепить настройки прокси (что-то как TorButton).

Существует один недостаток хотя: когда Ваш целевой узел имеет больше чем одно сетевое устройство, Вы не можете управлять, который будет Ваши данные брать для отъезда машины, к которой Вы туннелируете.

Это может обойтись путем установки нормального прокси-сервера на той машине, маршрутизации трафика от, скажем, localhost:3128 к желаемому сетевому интерфейсу и затем выполнению a ssh -L4545:localhost:3128 и указание на все приложения к 4 545, который должен использовать прокси.

Это дает Вам больший контроль на стороне прокси, поскольку интегрированный прокси SSH не действительно настраивается.

2
28.02.2012, 01:13
4 ответа

Вы пропускаете то, что вызов к gvim не блокируется, пока Вы не выходите из gvim, он сразу возвращается. Так xsel < /tmp/xselection обрабатывает файл перед редактированием его.

4
27.01.2020, 21:51

Я закончил тем, что включил информацию от и/весь три ответа для генерации следующего:

#!/usr/bin/env bash
# Edit xselection in gvim

xsel > /tmp/xselection
gvim -f /tmp/xselection
xsel -i < /tmp/xselection
2
27.01.2020, 21:51

Необходимо использовать -i опция. (-o значение по умолчанию), 

xsel -i </tmp/xselection
# -o, --output  write the selection to standard output.  
# -i, --input  read standard input into the selection.*

Эти опции работают над X основными выборами (не буфер обмена), таким образом, Вы должны к центральному щелчку видеть результат. Я протестировал его с паузой перед заключительной командой. Это позволило мне вручную выбирать некоторый другой текст перед заключительной выполняемой командой. Нажатый центром я и это хорошо работало..., и это работает без задержки.

Однако тестирование его без задержки не доказывает очень, becaust исходный выбор все еще выбран... и, конечно, если Вы выберете что-то еще тем временем, то Вы потеряете основной выбор сценария.

Возможно, Вашей проблемой является комбинация обоих -i опция и ответ Paul Tomblin о пути gvim отсоединения от процесса сценария.

1
27.01.2020, 21:51
  • 1
    Нет, Вам не нужно -i здесь: если stdin не является терминалом, xsel устанавливает выбор от стандартного входа. Но это вовсе не значит это явно передача -i не хорошая идея, но это не может быть источник проблемы. –  Gilles 'SO- stop being evil' 28.02.2012, 01:12
  • 2
    @Gilles: Спасибо за указание на это; я не знал о том синтаксисе. Я теперь перечитал страницу справочника, и да, она делает (кажитесь), заявите, что никакие опции не необходимы, но это не то, что я испытываю во всех ситуациях (на моем тесте система Ubuntu). Те stdin/out управляют, только применяются, когда скрипт запущен от терминала. Когда сценарий запускается с помощью "Запущенного Приложения" диалоговое окно, или через сочетание клавиш, этому определенно нужно -i опция. Теперь я понимаю, почему я получал странные результаты (пока я не использовал -i). Я добавил другой ответ, который занимается обеими проблемами: опции и отсоединение. –  Peter.O 28.02.2012, 08:23

Мой предыдущий ответ становился немного переполненным и был неполным (и имел только одно редактирование-itteration в запасе). Таким образом, вот исправленный ответ, который включает обе идеи... опции и отсоединение.

Поскольку я упомянул в последующие аферисты к комментарию Giles (предыдущий ответ), -i опция определенно необходима в некоторых ситуациях (на тесте система Ubuntu).. так -i и -o используются здесь.

Поскольку 'gvim' отсоединяется от процесса сценария, он не ожидает, и следующая команда сразу выполняется. (Paul Tomblin уже указал на thos в ответе hes).

Вы не можете использовать удар wait команда, поскольку это только работает на дочерние процессы. Как обходное решение, можно настроить цикл, который ожидает недочернего процесса для завершения. Это работает на редактора, который запускается с нового процесса каждый раз (как 'gvim' делает в этом случае).

Вот измененный сценарий 

xsel -o >/tmp/xselection

gvim /tmp/xselection 2>/dev/null
pid=$(pgrep -n "gvim")  # get gvim's pid and wait
while kill -0 "$pid" 2>/dev/null; do sleep 0.5; done

xsel -i </tmp/xselection

Вышеупомянутое предполагает, что gvim' pid уже устанавливается к тому времени, когда управление пасуется назад к сценарию. Если при высокой системной нагрузке pid не был установлен после выполнения следующей команды, то этот метод ожидания gvim должен работать. 

xsel -o >/tmp/xselection

pre=$(pgrep -n gvim)    # get previous gvim pid
gvim /tmp/xselection 2>/dev/null
while pid=$(pgrep -n "gvim"); [[ "$pid" == "$pre" ]]; do sleep .1; done
while kill -0 "$pid" 2>/dev/null; do sleep 0.5; done

xsel -i </tmp/xselection
1
27.01.2020, 21:51
  • 1
    я нашел gvim также, имеет флаг-f, который заставляет его остаться на переднем плане, который сохраняет сценарий немного более простым. Спасибо за оба из Ваших ответов, хотя! –  camilla.greer 28.02.2012, 17:52

Теги

Похожие вопросы