Shmuel wrote:gene.pavlovsky wrote: action=Что писать тут?
Например так:
action = function() win.SetEnv("ComSpec", "/path/to/bashcmd.sh") end;
Благодарю!
Karagy wrote:Я далёк от темы, но меня настораживают следующие вопросы, который топикпастер почему-то не задал:
- чем будет отрисовываться окно для Far?
- чем будет отрисовываться консоль для bash?
Не пойму, при чём тут это? Far запускается или сам по себе, или через ConEmu (можно в mintty/putty через winpty, но не вижу смысла городить этот огород). Т.е. консоль не юниксовая. Что значит отрисовать консоль для bash? Bash это не полноэкранная программа. Есть ввод, есть вывод. Всё и так нормально работает в фаре. Полноэкранные программы cygwin-а - например просмотрщик текстовых файлов less, или редактор vi - и так отлично работают из-под фара (сигвиновцы постарались). Фар же из-под сигвиновской юниксоподобной консоли без winpty (эмулятора виндовой консоли) не работает, так что вижу смысл именно запускать фар первично, а из него выполнять команды через bash, или же запускать сам bash при необходимости (чем я регулярно занимаюсь, а хочу, чтоб это надобилось реже).
siberia-man wrote: путь к внешней команде ls прописан в переменной окружения PATH
siberia-man wrote: чтобы выполнить эту команду необходим командный интерпретатор - создать конвейер, а установкой в неправильное значение вы лишились его.
Это всё понятно, хотелось бы узнать, в каких случаях фар решает, что сам справится, а в каких запускает ComSpec. Предположим, что вместо bash может быть некий совершенно с иным синтаксисом shell (да пусть хоть какой-нибудь интерпретатор python, мало ли маньяков-извращенцев на свете). Что для far-а вроде бы понятно (он так думает), может для ComSpec-а означать нечто совершенно своё. Имхо была бы не вредна опция выполнять всё-всё, кроме внутренних команд, cd/chdir, через ComSpec.
siberia-man wrote: это естественно - ведь для каждой команды запускается новый экземпляр шелла
С точки зрения и производительности, и ощущения "сессии" было бы лучше запустить долгоживущий шелл, и кормить ему команды по одной. Понятно, что это целая новая ф-циональность, и для шелла типа cmd она не особо полезна, так что мало кто захочет этим заниматься. К примеру в mc на командной строке можно легко засунуть какое-либо значение, или скажем рез-т выполнения программы, в переменную, а потом далее ей пользоваться. Именно "локальная" переменная в рамках сессии, не экспортируемая в окружение. Или можно определить ф-цию, и далее ей воспользоваться. Бывает нужно что-то такое на раз сделать, обработать как-то замысловато группу файлов (в одну команду не выходит). Но не так, чтоб это стоило сохранять на будущее в файл.
siberia-man wrote:алиасы в баше и доскей различаются и существенно. Но можно попробовать что-то вроде `bash --rcfile FILENAME -i`. При этом прописать где-то путь до файла алиасов и минимизировать различия в описании алисов разных систем.
Это я скорее просто упомянул факт, нежели чем пожаловался. Ясно, что по хорошему придётся держать два файла с алиасами в форматах для bash и cmd (хотя если переключиться на один bash, то второй не нужен мне лично), или написать скрипт-конвертор, это несложно.
siberia-man wrote:А в целом мне не очень нравится идея стыковать нестыкуемое (или плохо стыкуемое)
Понимаю ваше мнение. Мне кажется, что добиться полной интеграции, как скажем mc, весьма сложно и трудозатратно. Но в какой-то мере к этому приблизиться можно с хорошим соотношением цена/качество, так сказать. Уже даже то, что я получил сейчас, вместе с ComSpec и моим wrapper скриптом, позволяет наконец делать такие вещи, которых меня давно напрягало, что их не сделать в cmd. Т.е. уже profit имеется, без изменений к фару. Думаю, одними существующими фичами да макросами получить ощутимую выгоду, а если б ещё разработчики фара приложили руку, от результата можно было бы вообще писать кипятком от щастья.