@kvichans
если можно, то хорошо бы встроить как-то описанный метод (для Лин) в плагин Ext Tools. может галочку сделать в св-вах тула [x] Run in terminal. старую галочку [x] Shell можно оставить.
Выполнение программ через External Tools
> Опишите, что нужно сделать. В обсуждении много лишних деталей.
Что по существу нужно сделать, я бы сформулировал так. Нужно встроить скрипт в ExtTools так, чтобы он выполнялся с аргументом {FileDir}/{FileNameNoExt} в качестве значения параметра $1. Предполагается, что выполнение будет иметь место, когда пользователь хочет выполнить программу «в терминале» (консоли).
Надеюсь, что так Вам понятнее, и благодарю за содействие.
Как это облачить в форму инструмента для ExtTools я затрудняюсь сказать.
Дело в том, что многое и многое в задании инструментов в ExtTools мне непонятно.
Например, что понимать под Shell command? Что программа запускается в терминале? Не видно, чтобы так было. Не видно и разницы между выполнением обычной программы с отметкой и без нее.
Непонятно и что означает Capture output: Console. Что здесь названо Console и чем оно отличается от Output panel? Связано ли это слово с выполнением в терминале, что нормально ожидать, или нет? Если да, то в чем состоит связь?
С другой стороны, если я действительно выполняю программу в терминале, то вообще бессмыссленно выбирать что-либо для Capture output: тогда вывод идет в stdout, он может быть перенаправлен, но Capture output ничего общего с этим не имеет.
Непонятно и почему при таком количестве возможностей (пере)направить стандартный вывод программы, вообще не предусматривается указать, откуда берется ввод. И, как уже замечал, ввод на самом деле игнорируется, а потому программы выполняются ошибочно (и значит, без смысла), о чем даже не сказано в вики-документации. Не поможет и попытка перенаправить ввод, записав <infile в поле Parameters инструмента.
Впрочем, у меня есть идея, как переделать к очень простому и общему виду организацию запуска и перенаправливания ввода и вывода программ при построении инструментов, но об этом как-нибудь в другой раз.
Что по существу нужно сделать, я бы сформулировал так. Нужно встроить скрипт
Code: Select all
for term in $TERMINAL x-terminal-emulator gnome-terminal xterm mate-terminal rxvt urxvt xfce4-terminal terminator termite terminology qterminal konsole guake; do
if command -v $term > /dev/null 2>&1; then break; fi
done
$term -e sh -c "$1; echo 'Press <Enter> to continue ... '; read -r x"Надеюсь, что так Вам понятнее, и благодарю за содействие.
Как это облачить в форму инструмента для ExtTools я затрудняюсь сказать.
Дело в том, что многое и многое в задании инструментов в ExtTools мне непонятно.
Например, что понимать под Shell command? Что программа запускается в терминале? Не видно, чтобы так было. Не видно и разницы между выполнением обычной программы с отметкой и без нее.
Непонятно и что означает Capture output: Console. Что здесь названо Console и чем оно отличается от Output panel? Связано ли это слово с выполнением в терминале, что нормально ожидать, или нет? Если да, то в чем состоит связь?
С другой стороны, если я действительно выполняю программу в терминале, то вообще бессмыссленно выбирать что-либо для Capture output: тогда вывод идет в stdout, он может быть перенаправлен, но Capture output ничего общего с этим не имеет.
Непонятно и почему при таком количестве возможностей (пере)направить стандартный вывод программы, вообще не предусматривается указать, откуда берется ввод. И, как уже замечал, ввод на самом деле игнорируется, а потому программы выполняются ошибочно (и значит, без смысла), о чем даже не сказано в вики-документации. Не поможет и попытка перенаправить ввод, записав <infile в поле Parameters инструмента.
Впрочем, у меня есть идея, как переделать к очень простому и общему виду организацию запуска и перенаправливания ввода и вывода программ при построении инструментов, но об этом как-нибудь в другой раз.
1. Нам нужен переводчик. Вы пишете "что нужно сделать" на языке, которым я не владею. Плагин написал на Питоне и вызов программ происходит через средства библиотеки subprocess. У меня нет идей, как команды терминала перевести в API.
2. "Shell". Я так же как и вы не знаю глубокового смысла этого флага. По простому (на Win) я себе это понимаю так: запустить программу "без окна".
3. В CudaText есть несколько вкладок в нижней панели. Среди них две: Console и Output подходят для выдачи результатов работы. Исторически первой применялась Output. Потом и в Console разрешили помещать, так как данные в ней организованы как простой текст - ими удобней манипулировать.
4. В планах большая переделка ExtTools. Так что ваши идеи могут пригодится.
2. "Shell". Я так же как и вы не знаю глубокового смысла этого флага. По простому (на Win) я себе это понимаю так: запустить программу "без окна".
3. В CudaText есть несколько вкладок в нижней панели. Среди них две: Console и Output подходят для выдачи результатов работы. Исторически первой применялась Output. Потом и в Console разрешили помещать, так как данные в ней организованы как простой текст - ими удобней манипулировать.
4. В планах большая переделка ExtTools. Так что ваши идеи могут пригодится.
CudaText 1.163, TC9.51x32, Win10x64(1920x1080)
галочка Shell дает включение параметра shell в API subprocess.
The shell argument (which defaults to False) specifies whether to use the shell as the program to execute. If shell is True, it is recommended to pass args as a string rather than as a sequence.
On POSIX with shell=True, the shell defaults to /bin/sh. If args is a string, the string specifies the command to execute through the shell. This means that the string must be formatted exactly as it would be when typed at the shell prompt. This includes, for example, quoting or backslash escaping filenames with spaces in them. If args is a sequence, the first item specifies the command string, and any additional items will be treated as additional arguments to the shell itself. That is to say, Popen does the equivalent of:
Popen(['/bin/sh', '-c', args[0], args[1], ...])
On Windows with shell=True, the COMSPEC environment variable specifies the default shell. The only time you need to specify shell=True on Windows is when the command you wish to execute is built into the shell (e.g. dir or copy). You do not need shell=True to run a batch file or console-based executable.
Идея не в том, чтобы переводить, нужно всего-навсего вызывать. То, что дал выше – скрипт на языке sh, который есть стандартный командный интерпретатор всех POSIX систем. Если этот скрипт поместить в файл, скажем, runinterm, и если пользовательская программа находится в файле pgm, то требуется запустить sh с командой runinterm, у которой, в свою очередь, аргумент – pgm. В программе на языке C или C++ это делается вызовом
Обратите внимание на внутренние кавычки. Они нужны для того, чтобы runinterm pgm воспринималось как единый аргумент sh.
Файл со скриптом, конечно, можно порождать и динамически, если это нужно.
Я Питон подробно не знаю, но думается, что функция, равнозначная system в C/C++ (т.е. функция запуска любой указанной программы) должна иметься. В худшем случае можно вызвать именно функцию в C, пользуясь питоновским интерфейсом к C, но вряд ли это понадобится.
Code: Select all
system("sh -c \"runinterm pgm\"");Файл со скриптом, конечно, можно порождать и динамически, если это нужно.
Я Питон подробно не знаю, но думается, что функция, равнозначная system в C/C++ (т.е. функция запуска любой указанной программы) должна иметься. В худшем случае можно вызвать именно функцию в C, пользуясь питоновским интерфейсом к C, но вряд ли это понадобится.
Как написал раньше, предложу возможную организацию вызовов пользовательских программ через редактор.
Как принцип примем, что запускаемая программа может работать как со стандартным вводом, так и со стандартным выводом, и пользователю нужно предоставить возможность перенаправлять каждый из них.
Если и stdin, и stdout программы перенаправлены, ее можно запускать самостоятельно, так как у нее нет прямого, видимого общения с пользователем.
Если же хотя бы одно из stdin и stdout не перенаправлено, значит, программу нужно запускать в терминале (консоли).
Когда программа запускается в терминале, после ее завершения должно быть обеспечено выжидание реакции пользователя (нажатие клавиши), после чего терминал закрывается.
Кстати, терминал не обязательно должен быть настоящим терминалом, а, например, Output panel, который тогда окажется, скажем, Dialogue panel (так как уже не только output) и вообще будет еще одним доступным редактору файлом. Если возможно реализовать это, то даже лучше. Именно так сделано в некоторых других редакторах текста.
Перенаправливания, в том числе добавляющее перенаправливание вывода, лучше всего задавать вместе с параметрами запуска программы, как и делается в (независимо каком) командном языке о.с., и с тем же синтаксисом (<, > и >>). Для перенаправливания от или в место, для которого нет стандартного обозначения как файл, можно ввести особые, понятные плагину имена. Например, «пустое устройство» в Linux называется /dev/null, а в Windows – nul, но лучше придумать особое имя, которое невозможно понять как имя файла, и которое будет переводиться плагином соответственно в /dev/null или nul. Так все перенаправливания происходят в одном месте и однообразно, и при этом для задания не требуют никакого места и диалога. В частности, если перенаправливание не требуется, ничего вообще и не пишем и не выбираем.
В этом рассмотрении присутствие отметки Shell command мне кажется несущественным и я бы ее удалил.
Подобная организация должна иметь и то благоприятное последствие, что исчезнет разница в способах составления инструментов для Linux и для Windows. Сейчас для достижения одного и того же в разных о.с. приходится считаться с их особенностями, но ведь эти особенности не каждый пользователь редактора текста должен знать.
Как принцип примем, что запускаемая программа может работать как со стандартным вводом, так и со стандартным выводом, и пользователю нужно предоставить возможность перенаправлять каждый из них.
Если и stdin, и stdout программы перенаправлены, ее можно запускать самостоятельно, так как у нее нет прямого, видимого общения с пользователем.
Если же хотя бы одно из stdin и stdout не перенаправлено, значит, программу нужно запускать в терминале (консоли).
Когда программа запускается в терминале, после ее завершения должно быть обеспечено выжидание реакции пользователя (нажатие клавиши), после чего терминал закрывается.
Кстати, терминал не обязательно должен быть настоящим терминалом, а, например, Output panel, который тогда окажется, скажем, Dialogue panel (так как уже не только output) и вообще будет еще одним доступным редактору файлом. Если возможно реализовать это, то даже лучше. Именно так сделано в некоторых других редакторах текста.
Перенаправливания, в том числе добавляющее перенаправливание вывода, лучше всего задавать вместе с параметрами запуска программы, как и делается в (независимо каком) командном языке о.с., и с тем же синтаксисом (<, > и >>). Для перенаправливания от или в место, для которого нет стандартного обозначения как файл, можно ввести особые, понятные плагину имена. Например, «пустое устройство» в Linux называется /dev/null, а в Windows – nul, но лучше придумать особое имя, которое невозможно понять как имя файла, и которое будет переводиться плагином соответственно в /dev/null или nul. Так все перенаправливания происходят в одном месте и однообразно, и при этом для задания не требуют никакого места и диалога. В частности, если перенаправливание не требуется, ничего вообще и не пишем и не выбираем.
В этом рассмотрении присутствие отметки Shell command мне кажется несущественным и я бы ее удалил.
Подобная организация должна иметь и то благоприятное последствие, что исчезнет разница в способах составления инструментов для Linux и для Windows. Сейчас для достижения одного и того же в разных о.с. приходится считаться с их особенностями, но ведь эти особенности не каждый пользователь редактора текста должен знать.