View Issue Details

IDProjectCategoryView StatusLast Update
0003223WishesCommand Line/Executepublic2016-06-19 21:13
ReporterheilongAssigned ToDrKnS 
PrioritynormalSeverityminorReproducibilityalways
Status closedResolutionfixed 
Product Version 
Target VersionFixed in Version3.0 
Summary0003223: Проблемы с заключением в кавычки при передаче ком. строки ComSpec-у
DescriptionДорабатываю wrapper скрипт для запуска команд ком. строки с помощью bash. Столкнулся с проблемами, если в команде присутствуют кавычки. Для теста сейчас сделал, чтобы скрипт печатал, с какими аргументами он вызван, а потом вызывал команду

Пробуем

C:\usr\bin # shell=$SHELL; echo $shell
2=`shell=$SHELL; echo $shell`
/bin/bash

C:\usr\bin # shell="$SHELL"; echo $shell
2=`shell=$SHELL; echo $shell`
/bin/bash

C:\usr\bin # shell=\"$SHELL\"; echo $shell
2=`shell=$SHELL; echo $shell`
/bin/bash

C:\usr\bin # shell='$SHELL'; echo $shell
2=`shell=$SHELL; echo $shell`
/bin/bash

C:\usr\bin # shell=\'$SHELL\'; echo $shell
2=`shell=\$SHELL';" echo $shell"`
C:\cygwin\usr\local\bin\bashcmd.sh: eval: line 31: unexpected EOF while looking for matching `''

Команды приходят одним аргументом, как и положено. Но куда деваются все кавычки?

Наконец, вот такой вариант не съедает вторую пару одинарных кавычки :

C:\usr\bin # shell='$SHELL'; echo '$shell:' $shell
2=`shell=$SHELL; echo '$shell:' $shell`
$shell: /bin/bash


Двойные кавычки съедаются всегда и везде.
Получается, первый аргумент (как бы программа для запуска, хотя в данном случае это не команда) фаром обрабатывается особенно.

Далее

C:\usr\bin # foo="bar baz"; echo $foo
2=`foo=bar`
3=`baz; echo $foo`

C:\usr\bin # foo='bar baz'; echo $foo
2=`foo=bar" baz;`
3=`echo`
4=`$foo`
C:\cygwin\usr\local\bin\bashcmd.sh: eval: line 31: unexpected EOF while looking for matching `"'


Вообще что-то непонятное творится, особенно каким образом из двух одинарных кавычек по краями вышла одна двойная в середине (перед пробелом)?

Ну ладно, думаю может быть я попрошу фар не заморачиваться с кавычками, и добавлю свой bashcmd.sh в System.Executor.NotQuotedShell, а там уже в своём скрипте разберусь, как мне всё это разобрать.

C:\usr\bin # shell="$SHELL"; echo "$shell:" $shell
2=`shell=$SHELL;`
3=`echo`
4=`$shell:`
5=`$shell`

C:\usr\bin # shell='$SHELL'; echo '$shell:' $shell
2=`shell='$SHELL';`
3=`echo`
4=`$shell:`
5=`$shell`

Двойные кавычки полностью исчезли, одинарные на этот раз остались как раз в первой команде, а в следующей исчезли. Ничего не понимаю... В общем, этот режим тоже не лечит проблему.

По сути дела, мне бы получить на вход оригинал ком. строки. То, что фар дописывает путь к первой команде (пишу `ls`, в скрипт передаётся `C:\cygwin\bin\ls.EXE`) - не требуется, и даже создаёт дополнительный гемор (т.к. пути пишутся через \, а для bash это escape-символ).
Можно ли добавить опцию System.Executor.RawCmdlineShell или что-нибудь в этом роде?
TagsNo tags attached.
Build4704

Activities

heilong

2016-04-28 00:31

reporter   bugnote:0014495

Вообще лично мне бы хотелось иметь опцию, чтобы все команды, кроме внутренних, выполнялись через ComSpec. Вот в чём прок, например, что фар сам ищет в PATH команду и заменяет её на полный путь, до передачи ComSpec-у?
В случае произвольного ComSpec-а, первое *слово* на ком. строке - далеко не обязательно команда, это может быть встроенная команда ComSpec-а, или иная его синтаксическая конструкция (например [[ ... ]] - conditional в bash). Искать команду в PATH в этом случае напрасный труд. Пусть ComSpec это делает сам. Тем более, вот например пишу `cat file1 file2 | grep word`. Фар заменит `cat` на полный путь, а `grep` так и останется. Ну bash его сам найдёт, не проблема.
Опять же алиасы (doskey) работают так себе - если я пишу `igrep word file | less`, то фар находит igrep (=grep -i) в алиасах и подменяет. А вот `set | igrep comspec` - igrep неизвестная команда. В общем, как-то так. Имхо нужная опция, чтоб фар максимально не вмешивался ни в поиск команд, ни в вопросы с кавычками, а запускал все не внутренние ф-ции через ComSpec дословно с той командной строкой, которую ввёл юзер.

DrKnS

2016-04-28 01:20

administrator   bugnote:0014496

heilong wrote

в чём прок

Так надо. Comspec умеет далеко не всё, что умеет ShellExecute.

heilong wrote

Фар заменит `cat` на полный путь, а `grep` так и останется

Это уже фантазии.

heilong wrote

Для теста сейчас сделал, чтобы скрипт печатал, с какими аргументами он вызван, а потом вызывал команду ... куда деваются все кавычки?

Ваш скрипт запускается не святым духом, а башем, или что у вас там. Посмотрите таскменеджером переданную процессу костроку, там, уверен, кавычки будут. Куда их потом дел баш - вопрос не к нам.

heilong

2016-04-28 01:29

reporter   bugnote:0014497

Last edited: 2016-04-28 01:41

View 2 revisions

Я уже поставил ComSpec-ом данную программку

#include <stdio.h>
#include <stdlib.h>

int main(int argc, char **argv) {
    for (int i = 1; i < argc; ++i)
        printf("%d=`%s`\n", i, argv[i]);
    exit(0);
}


Все те же результаты, что и выше я привёл.
Какие ещё фантазии?

C:\ # ls | grep word
1=`/C`
2=`C:\cygwin\bin\ls.EXE | grep word`

Вот в чём прикол, что ls с полным путём, а grep нет? На кой такая полуработа нужна?

heilong

2016-04-28 14:00

reporter   bugnote:0014499

Last edited: 2016-04-28 14:01

View 2 revisions

Я для интереса скачал исходники фара, внёс для тестирования пару изменений в execute.cpp - устанавливаю `PipeOrEscaped = 4` всегда, чтоб почти всё шло через ComSpec, далее передаю ComSpec-у оригинал ком. строки в кавычках `ComSpecParams.append(L"\"").append(Info.Command).append(L"\"");`
Для верности ещё поставил Message(..., ComSpecParams, ...).
Изменений требуется буквально немножко, если бы добавить в far:config опцию для этого (что я и прошу), то это можно было бы делать опционально без особых усилий и без усложнения существующего кода. Если бы не вот что:

В общем, ComSpecParams ещё имеет все нужные кавычки, а моя сишная программа (поставленная для теста ComSpec-ом) принимает уже с похеренными кавычками (согласно приведённым ранее примерам).

В общем, вся эта муть с квотированием происходит в самом ShellExecuteEx, вины фара тут нету. Я, если честно, в шоке, что в ShellExecuteInfo нет параметров, позволяющих запустить процесс и передать ему параметры как есть, в виде массива. Стока опций присутствует, а этой нет, неужто это не важная вещь? ShellExecuteEx похож на юниксовый `system` (юзать который почти во всех случаях считается плохим тоном, дырой в безопасности и т.д.), а не `exec`. Есть ли в винде что-либо вроде `exec`-а?

Как вариант щас поищу документацию по тому, как именно ShellExecute обрабатывает полученные lpParams, надеюсь такая инфа есть, а то придётся экспериментально выяснять. И тогда попробую написать функцию для quote/escape ком. строки, чтоб она приходила в ComSpec так, как её юзер напечатал, дословно со всеми кавычками и прочим (если есть что-то прочее). Буду благодарен, если тыкнете, где искать инфу/доки по вопросу.

2useven10

2016-04-28 15:53

developer   bugnote:0014500

Не спешите вешать всех собак на ShellExecute().
Сначала в вашей програмке распечатайте GetCommandLine(), потом можно CommandLineToArgvW()...

DrKnS

2016-04-28 16:55

administrator   bugnote:0014501

> Вот в чём прикол, что ls с полным путём, а grep нет? На кой такая полуработа нужна?

Да, действительно. 4645.
Также см. changelog - ключи запуска и кавычки теперь задаются иначе

heilong

2016-04-29 00:07

reporter   bugnote:0014502

Last edited: 2016-04-29 03:48

View 2 revisions

Здорово, вот спасибо! Новые опции мне нравятся больше старых, да и кода в execute.cpp приятно убавилось.
Теперь можно юзать ComSpec=bash.exe без всяких wrapper скриптов.

Вариант `'{0}'` работает очень неплохо. Двойные кавычки все как надо приходят, с одинарными по-прежнему проблематично, можно и без них обойтись в принципе, но хочется разобраться. Пример команды, которую я хочу послать bash-у: `echo '$TERM is' $TERM`. Очевидно, когда она подставляется заместо `{0}`, кавычки конфликтуют с тему, что вокруг `{0}`, в рез-те bash получает параметры ..., `echo $TERM`, `is $TERM`. Как можно эти кавычки за-escape-ить? Пробовал `\`, `%`, но это ничего не работает. Удаётся через `'"'"'` - на выходе одна одинарная кавычка, но вряд ли же это самый короткий вариант. И как вы считает, по логике не должен ли сам фар ком. строку так подготовить (quote/escape нужные кавычки), чтоб заключение её в кавычки гарантированно передало comspec-у именно один параметр - правда это может быть доп. гемор с опциями - как фар будет узнавать, какие кавычки квотить?

2useven10, да, я попробовал по вашему совету GetCommandLine() (о существовании которого услышал впервые, я на С программил только в UNIX и пользовался исключительно argc/argv), и действительно - эта ф-ция возвращает оригинал ком. строки со всеми кавычками как есть, а вот CommandLineToArgvW() уже разделывает эту строку под орех, и в argv попадает уже не совсем то, что ожидалось. Полагаю, единственное универсальное решение - как-то quote/escape кавычки, чтоб они не портили ситуацию.

А ещё можно ли всё-таки добавить опцию, чтоб комспек юзался во всех случаях? А то фар ведь не поймёт всяких бэшовых фич. Например пишу я `echo $TERM`, фар попробует сам выполнить, отобразит строчку $TERM.

heilong

2016-04-29 00:52

reporter   bugnote:0014503

Вот что у меня получилось с квотингом: http://pastebin.com/4mGVrnn7
`'` заменяется на `'"'"'`, в рез-те первоначальная кавычка (извне ${0}) закрывается, вставляется в двойных кавычках одинарная кавычка (literally), и далее опять одинарная кавычка открывается.
`\` удваиваются - без этого проблемы с `\'` и собственно с `\\`

Вот как пример, написал весьма замысловатую (бессмысленную) команду - как ушла, так и пришла.

C:\project\svn\farmanager\unicode_far # set comspec=c:\cygwin\usr\local\bin\printfcmd.exe

C:\project\svn\farmanager\unicode_far # shell=\\k\'$SHELL\'; echo \'$shell: \'$shell; echo "a b" 
'a b' a\ b
1=`-c`
2=`shell=\\k\'$SHELL\'; echo \'$shell: \'$shell; echo "a b" 'a b' a\ b`

heilong

2016-04-29 03:41

reporter   bugnote:0014504

Ещё такие вопросы
1) Бат файлы, похоже, выполняются ${comspec} /c ${batfile}. Соотв-но comspec=bash - батники не работают в принципе. Нужна отдельная настройка какая-то, чтоб можно было прописать комспек для выполнения бат файлов.
2) Сделал макрос, переключающий по хоткею ComSpec (cmd <-> bash). Но им нужны разные System.Executor.ComspecArguments. Как бы из макроса это переключать?

Smitis

2016-04-29 10:02

reporter   bugnote:0014505

К сожалению, с отменой System.Executor.NotQuotedShell теряется гибкость с использованием кавычек. А System.Executor.ComspecArguments получается жёстко привязывает ФАР к оболочке - теперь, если я хочу запустить ФАР из-под другой оболочки, нужно каждый раз менять конфигурацию, так получается?

DrKnS

2016-04-29 10:20

administrator   bugnote:0014506

Как можно эти кавычки за-escape-ить?
Смотрите в справке вашего шелла. В cmd, например, при указании /S /C "blablabla" всё, находящееся между внешними двойными кавычками, трактуется как есть и ничего эскейпить не надо. Если вдруг ничего подобного не предусмотрено, можно использовать в качестве комспека промежуточную программу или скрипт, которая заэскейпит как вам надо.
Бат файлы, похоже, выполняются ${comspec} /c ${batfile}. Соотв-но 
comspec=bash - батники не работают в принципе
Добавьте ассоциацию для bat / cmd.
Например пишу я `echo $TERM`, фар попробует сам выполнить, 
отобразит строчку $TERM
Это вы так предполагаете или так и происходит? Я что-то не вижу в фаре обработки "echo".
К сожалению, с отменой System.Executor.NotQuotedShell теряется гибкость 
с использованием кавычек

Подозреваю, мало кто меняет шелл каждый день и такая гибкость не критична.
если я хочу запустить ФАР из-под другой оболочки, нужно 
каждый раз менять конфигурацию, так получается?

far.exe -set:System.Executor.ComspecArguments="/S /C \"{0}\""
far.exe -set:System.Executor.ComspecArguments="whatever"

Smitis

2016-04-29 10:56

reporter   bugnote:0014507

Last edited: 2016-04-29 11:00

View 2 revisions

Подозреваю, мало кто меняет шелл каждый день и такая 
гибкость не критична.
Зачем менять? У меня два ярлыка на рабочем столе. Один запускает ФАР из-под cmd, второй из-под tcc. Сейчас вот, под воздействием тем на форуме, заинтересовало использование из-под bash, даже cygwin установил и враппер написал, чтобы автоматом подменял /c на -c, и тут облом. И вообще, получается, что под каждую оболочку нужна своя строка вызова. Мало ли там ещё что будет, из-под PowerShell, например, запустить.
far.exe -set:System.Executor.ComspecArguments="/S /C \"{0}\""
far.exe -set:System.Executor.ComspecArguments="whatever" 


Может и так придётся выкручиваться. Хотя лучше бы был нормальный доступ на Lua, тогда можно было бы проанализировать из _macroinit что там используется.

Или возможность из Lua самостоятельно перехватывать и анализировать командную строку (то что пару лет назад уже начали делать, но потом откатили)

Smitis

2016-04-29 12:36

reporter   bugnote:0014508

Предложение - возродить ProcessFarCommandLine
http://forum.farmanager.com/viewtopic.php?f=15&t=8641
Тогда каждый сможет написать себе свой обработчик с бекджеком и шлюхами нужными кавычками, слешами и путями.

DrKnS

2016-04-29 12:45

administrator   bugnote:0014509

У меня два ярлыка на рабочем столе

Ну если запуск всё равно через ярлыки, я не вижу проблем добавить туда -set:

Smitis

2016-04-29 12:55

reporter   bugnote:0014510

Добавил уже, эксперементирую.

heilong

2016-04-29 15:08

reporter   bugnote:0014511

Чем больше думаю и пробую, тем сложнее все кажется в общем случае. Может быть, действительно стоит оставить ComSpec для cmd-совместимых шеллов, а всю кастом логику для произвольных вынести в макроапи или плагин апи? Только по-моему там должны быть две ф-ции - первая (если есть) запускается фаром в самом начале execute(), перед PartCmdLine - она решает, хочет ли макрос/плагин забрать ком строку себе на выполнение, или же он от неё отказывается и возвращает (возможно, с изменениями) фару на выполнение согласно существующей логике (т.е. это кастом версия PartCmdLine). Вторая же ф-ция собственно получает ком строку уже непосредственно на выполнение.

Smitis

2016-04-29 17:37

reporter   bugnote:0014512

heilong
А зачем так сложно?
Передали в плагин строку as is. Далее, либо плагин её выполнил и вернул true, либо отказался выполнять, вернул false и строка передаётся дальше.

heilong

2016-04-30 02:07

reporter   bugnote:0014513

Last edited: 2016-04-30 02:28

View 2 revisions

DrKnS wrote

Смотрите в справке вашего шелла. В cmd, например, при указании /S /C "blablabla" всё, находящееся между внешними двойными кавычками, трактуется как есть и ничего эскейпить не надо. Если вдруг ничего подобного не предусмотрено, можно использовать в качестве комспека промежуточную программу или скрипт, которая заэскейпит как вам надо.


Мой шелл тут не причём, речь идёт о том, что с ком строкой происходит до того, как она попадёт шеллу в argv. Т.е., видимо, о CommandLineToArgvW().
У меня такая логика - если фар имеет ф-цию подставлять `'${0}'`, то он должен ${0} обработать так, чтоб он не "убежал" за "забор" из кавычек.
Простой пример. Юзер ввёл `echo a ' ' b`. Подставляется в шаблон, получается в итоге выполняется команда `bash -c 'echo a ' ' b'` - т.е. после -c идут
два аргумента, а не один. Предложение такое - смотрел, какой символ (если есть) идёт непосредственно перед (или после) ${0} в ComspecArguments. Если
это ', то надо quote/escape одинарные кавычки в Info.Command, если " - двойные, иначе ничего не делать (наверно?). Обратные слэши же надо удвоить,
на входе в шелл они станут одинарными. В небольшом патче, ссылку (pastebin) на который я давал выше, это делается (ComspecArguments = `-c '${0}'`).
Провернял на корректность такой ком строкой:

C:\ > set comspec=c:\cygwin\usr\local\bin\printfcmd.exe
C:\ > echo a "b" 'c' \"d\" \'e\' '"' "'" \f \\g
1=`/c`
2=`echo a "b" 'c' \"d\" \'e\' '"' "'" \f \\g`
C:\ > set comspec=c:\cygwin\usr\local\bin\bashcmd.sh
C:\ > set BASHCMD_DEBUG=1
C:\ > echo a "b" 'c' \"d\" \'e\' '"' "'" \f \\g
cmd: `echo a "b" 'c' \"d\" \'e\' '"' "'" \f \\g`
a b c "d" 'e' " ' f \g

Первый экзешник - простейшая C программа, распечатывающая свой argv. Второй - bash скрипт-wrapper, подгружающий доп. rcfile (алиасы, опция шелла и т.д.),
и далее eval команду. С моим патчем в оба эти ComSpec-а приходит полностью та же ком строка, что я и ввёл.

DrKnS wrote


Добавьте ассоциацию для bat / cmd.

Попробовал, добавил `.bat;.cmd` и выполнение через `@cmd.exe /c "$!.!"`. Файлы-то выполняются, но что-то жесть какая-то происходит с выводом - панели фара все съезжают вверх (на столько строчек, сколько вывода напечатал батник), менюшка фара же внизу так и остаётся. Для перерисовки приходится нажимать Ctrl-R или выполнять cls.

DrKnS wrote


Это вы так предполагаете или так и происходит? Я что-то не вижу в фаре обработки "echo".

C:\cygwin\bin\echo.exe это команда, делающая то же, что и встроенный echo в bash. Для чего нужно, хз - там ещё неск-ко есть, может быть как раз чтоб в cmd можно было использовать. Я предполагаю, что `echo.exe $TERM` будет выполнено через фар (direct run), в итоге напечатается `$TERM` - это не так? Протестить не могу, почему-то у меня версия, скомпилённая из свн с моим патчем (который не затрагивает direct/external run логику, только квотирование), выполняет практически всё, даже просто `ls` через ComSpec. На пойму, что такое произошло. Но не всё - вот скажем скриптик MessageBox.vbs запускается direct, но `MessageBox.vbs text title` - уже через ComSpec, при этом проверял, в конце концов перед выполнением команды (строка `if (Info.ExecMode == Info.direct)`) значение Info.ExecMode в этом случае - Info.detect. Не нужно ли в этом месте добавить код `if (Info.ExecMode == Info.detect) Info.ExecMode = Info.direct`?

DrKnS wrote


Подозреваю, мало кто меняет шелл каждый день и такая гибкость не критична.

Может быть это на практике я и не буду использовать, но на данный момент не все, что надо, работает через bash, возможно
было бы удобно в какой-то момент переключиться на cmd, выполнить команду, переключиться обратно. Я сперва написал для этого макрос,
в принципе это может быть просто бат-файл. Т.е. хочется одним нажатием хоткея, или же запуском определённой команды или алиаса,
быстренько поменить не только ComSpec env var, но и соответствующие переменые конфига фара. Но вроде как я читал, что менять far:config из макроса это дурной тон (если это вообще технически возможно)?

heilong

2016-04-30 02:43

reporter   bugnote:0014514

Smitis wrote


А зачем так сложно?
Передали в плагин строку as is. Далее, либо плагин её выполнил и вернул true, либо отказался выполнять, вернул false и строка передаётся дальше.


Если посмотреть execute.cpp, то там куча кода - полезна (ну хотя бы folder run по Shift-Enter, консоль для не-silent запуска). Если делать одной ф-цией, и плагин полностью берёт на себя всё,
то с высокой вероятностью в плагине помимо нового кода будет копи-пейст имеющегося из execute.cpp (а если нет, то потеряется часть имеющейся функциональности). Если же сделать из двух функций, получится существующий код использовать. По кр мере у меня возникла такая идея после просмотра, что именно происходит и в какой последовательности в execute.cpp:Execute().

DrKnS

2016-04-30 11:26

administrator   bugnote:0014515

Мой шелл тут не причём
Ваш шелл здесь причём, ещё раз перечитайте написанное. Если echo a " " b запускать как /s /c "a " " b" через cmd, то всё будет выполнено правильно, несмотря на любое количество кавычек. Если ваш шелл трактует 'echo a ' ' b' как два аргумента и не предоставляет возможности трактовать как один, напишите промежуточную программу или скрипт, поторая заэскейпит внутренние кавычки как вам надо. Фар не будет за вас решать, какие кавычки подставлять, какие удваивать, какие эскейпить, что делать со слешами и т. п.
Попробовал, добавил `.bat;.cmd` и выполнение через `@cmd.exe /c "$!.!"`. 
Файлы-то выполняются, но что-то жесть какая-то происходит 
с выводом


"Жесть какая-то" потому что вы зачем-то засунули туда @.

Я предполагаю, что `echo.exe $TERM` будет выполнено через фар 
(direct run), в итоге напечатается `$TERM` - это не так?

Если вас не устраивает, что выполняется echo.exe а не интерпретатор, прочитайте справку по System.Executor.ExcludeCmds.

Smitis

2016-04-30 14:41

reporter   bugnote:0014516

DrKnS
Что-то поломалось: Если задан полный путь к исполняемому файлу, но без расширения и в кавычках, расширение автоматически не подставляется (раньше подставлялось). Без кавычек расширение подставляется.
Проверить можно вызывая из ком. строки простейший cmd:
@echo "%~0"

DrKnS

2016-04-30 15:28

administrator   bugnote:0014517

Вроде бы починил.

heilong

2016-05-07 23:53

reporter   bugnote:0014530

По поводу изменений 4645: `ls | grep word` запускается как есть, без путей, shell сам ищет, где ls, где grep.
Но если написать `view:< ls | grep word`, то старое поведение - запускается `C:\cygwin\bin\ls.EXE | grep word`.

DrKnS

2016-05-08 00:36

administrator   bugnote:0014531

view: < - это плагин farcmds.

heilong

2016-05-08 01:56

reporter   bugnote:0014532

Last edited: 2016-05-08 02:32

View 3 revisions

DrKnS wrote


Ваш шелл здесь причём, ещё раз перечитайте написанное. Если echo a " " b запускать как /s /c "a " " b" через cmd, то всё будет выполнено правильно, несмотря на любое количество кавычек. Если ваш шелл трактует 'echo a ' ' b' как два аргумента и не предоставляет возможности трактовать как один, напишите промежуточную программу или скрипт, поторая заэскейпит внутренние кавычки как вам надо. Фар не будет за вас решать, какие кавычки подставлять, какие удваивать, какие эскейпить, что делать со слешами и т. п.


Ну тут скорее не в шелле дело, а в том, как вообще ком строка в argv преобразовывается. Не думаю, что shell как-то отлично это делает от любых других программ состава Cygwin, скажем. В общем, по вашему совету я написал маленькую С++ программку, которую и ставлю ComSpec-ом. Она эксейпит кавычки и бэкслеши так, как надо, и уже запускает bash, в результате bash выполняет в точности то, что написал юзер.

http://forum.farmanager.com/viewtopic.php?p=137582#p137582
https://dl.dropboxusercontent.com/u/49471027/far_bash_comspec.7z

DrKnS wrote


Если вас не устраивает, что выполняется echo.exe а не интерпретатор, прочитайте справку по System.Executor.ExcludeCmds.

Про ExcludeCmds я видел и уже прописал туда, что надо. Вопрос не в этом, я может быть неправильно акцент поставил, упомянув echo.exe. Предположим, хочу выполнить `SomeProgram.exe $((2**20))`, я хочу передать ей аргумент - результат вычисления арифметического выражения (2 в 20-й степени). Фар выполнит SomeProgram.exe с аргументов "$((2**20))", вместо передачи этого дела ComSpec-у. Приходится писать что-то вроде `...моя команда... | cat`, чтоб форсировать использование ComSpec-а. Хотелось бы иметь какую-то возможность иметь некоторый контроль над процессом.

DrKnS wrote


view: < - это плагин farcmds.

Понял, спасибо, обращусь к авторам.

heilong

2016-05-08 02:18

reporter   bugnote:0014533

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

DrKnS

2016-05-08 02:23

administrator   bugnote:0014534

> Предположим, хочу выполнить `SomeProgram.exe $((2**20))`

Да, так понятнее.

> Понял, спасибо, обращусь к авторам.

Он "официальный", обратиться можно на этом же багтрекере (на форуме забудется и потеряется).

> Ещё обнаружил, что при запуске BAT файлов по-прежнему передаётся полный путь к файлу.

А чем это плохо?

heilong

2016-05-08 02:30

reporter   bugnote:0014535

> Он "официальный", обратиться можно на этом же багтрекере (на форуме забудется и потеряется).
Сделаю.

> А чем это плохо?
Может и не плохо... Просто чем принципиально отличается `ls.exe | grep word` от `ls.bat | grep word`...

DrKnS

2016-05-08 02:36

administrator   bugnote:0014536

> Может и не плохо... Просто чем принципиально отличается `ls.exe | grep word` от `ls.bat | grep word`...
 
Ничем.
У вас именно в случае "ls.bat | grep word" ls.bat запускается с полным путём?

heilong

2016-05-08 02:48

reporter   bugnote:0014537

> У вас именно в случае "ls.bat | grep word" ls.bat запускается с полным путём?
Я немного ошибся. Как раз полный путь, если запускать просто file.bat. Т.е. это видимо как раз ветка директ рана, но ComSpec ведь стоит мой, и скрипт запускается через него.
У меня в принципе wrapper скрипт это переваривает, не знаю, есть ли смысл менять что-то, может от этого где-то быть польза или вред.

heilong

2016-05-11 03:40

reporter   bugnote:0014541

Про farcmds добавил багрепорт http://bugs.farmanager.com/view.php?id=3231

heilong

2016-05-14 02:56

reporter   bugnote:0014547

В виду каких-то последних изменений перестало вдруг работать следующее.
Если на командной строке запускаю какой-то скрипт вот так
`scripts/backup.sh`, то вылезает виндовый диалог ошибки "windows cannot find 'C:\path\to\current_working_directory/scripts/backup.sh'", после нажатия ок в самом фаре вылезает красный диалог "system cannot find the file specified". Через backslash, конечно, работает. Но раньше этот `scripts/backup.sh` и с прямым слэшом в пути запускался. Поправимо?

DrKnS

2016-05-14 12:35

administrator   bugnote:0014548

У меня *.sh запускать нечем, более распространённый пример есть?

Smitis

2016-05-14 16:10

reporter   bugnote:0014549

Last edited: 2016-05-14 16:11

View 2 revisions

Не связано ли с этим? http://forum.farmanager.com/viewtopic.php?f=9&t=5773&start=2720#p137702

heilong

2016-05-15 20:43

reporter   bugnote:0014550

Ок, запуск несуществующего xxx.vbs даёт такой же результат - сначала виндовый диалог, что файл не найден, затем уже диалог в фаре. Если добавить .vbs в System.Executor.BatchType, тогда команда передаётся comspec-у и ошибку о ненайденном фале печатает уже он.

Вторая странность, почему-то не работает поиск pathext, что-то сломалось в FindModule?
В директории лежит build.bat или build.sh (пробовал оба), пишу команду build, она передаётся comspec-у (bash, который не работает с PathExt, и выдаёт сообщение, что команда не найдена). Если comspec - cmd, то тогда build.bat (или build.sh) запускается (видимо уже самим cmd). Но по идее ведь должен напрямую фаром, там же есть pathext поиск в FindModule.

DrKnS

2016-05-15 22:07

administrator   bugnote:0014551

Да, это сломалось недавно, вроде поправил.

heilong

2016-05-16 12:29

reporter   bugnote:0014554

Last edited: 2016-05-16 12:50

View 2 revisions

Ситуация улучшилась, но по-прежнему есть проблемы. Теперь такое впечатление, что стало всё выполняться через ComSpec.

cd scriptsrun.sh (в текущей директории - запускается через комспек, 
а не напрямую)
cd ..
scripts/run.sh (запускается через комспек)
scripts\run.sh (запускается через комспек, который не понимает 
\)

Только давеча scripts/run.sh выдавал ошибку файл не найден, а scripts\run.sh работал.
Т.е. такое впечатление, что direct run перестал использоваться для batch файлов и прочих скриптов. Да, System.Executor.BatchType я поставил %PathExt%, хотя пробовал также и дефолтный.

Если просто run пишу (есть run.bat, есть run.sh), команда идёт через комспек и результат - команда не найдена. Т.е. похоже PathExt фаром не обрабатывется на данный момент.

DrKnS

2016-05-16 22:59

administrator   bugnote:0014555

4675.

heilong

2016-05-17 02:12

reporter   bugnote:0014557

Завтра уезжаю на 2-3 недели в Грузию, если там будет возможность, погляжу.

heilong

2016-06-08 14:41

reporter   bugnote:0014594

Вернулся, проверил. Теперь работают все варианты запуска, в т.ч. с прямым и обратным слэшом в пути, без или с указанием расширения файла.
Вижу, что в far:config больше нету System.Executor.BatchType, используется PathExt или как?
Спасибо за проделанную работу! Вроде как по этому баг репорту теперь всё хорошо. Последнее оставшееся пожелание - поддержка регулярного выражения для определения, возможен ли direct run или `too complex`, что обсуждалось тут http://forum.farmanager.com/viewtopic.php?p=137781&sid=0a48f0d854c2d7f57de746109f48b9e5#p137781

DrKnS

2016-06-09 01:57

administrator   bugnote:0014595

> больше нету System.Executor.BatchType, используется PathExt или как?

Используется анализ ассоциированного приложения.

> поддержка регулярного выражения для определения

Добавил System.Executor.ComspecCondition.

Smitis

2016-06-10 11:03

reporter   bugnote:0014596

Теперь ФАР пытается "выполнять" файлы без расширения.
Например, если в текущей папке лежит файл cmd (без расширения), то попытка выполнить из ком. строки cmd откроет диалог "Open as". В то же время cmd /? выполнится нормально.

2useven10

2016-06-10 12:37

developer   bugnote:0014597

> Теперь ФАР пытается "выполнять" файлы без расширения.
>
http://forum.farmanager.com/viewtopic.php?p=138017#p138017

2useven10

2016-06-10 12:51

developer   bugnote:0014598

Last edited: 2016-06-10 12:55

View 2 revisions

Впрочем, после последних изменений уже лучше чем было.
Может и нет, я просто забыл, что активировал ExcludeCmds...

Smitis

2016-06-11 14:20

reporter   bugnote:0014599

У нас, получается, есть два алгоритма "выполнения" файлов:

- То, как это делается через WinR (почти текущее поведение ФАРа) - открываем всё подряд, в том числе и файлы без расширения. Если введена команда без расширения и такого файла без расширения нет, подставляются некоторые расширения по умолчанию. Вот тут поведение ФАРа и системы расходятся: ФАР, похоже, подставляет из PATHEXT, а система только основные. Во всяком случае ассоциированные c TakeCommand .btm файлы ФАР выполняет, а WinR нет.

- То, как это делается из командной строки (старое поведение ФАРа) (классический способ) - для файлов без расширения подставляются расширения из PATHEXT, и только файлы с расширениями из PATHEXT выполняются.

Мне кажется, второй способ для командной строки ФАРа логичнее. Как минимум, при снятой опции "Use Windows registered types".

DrKnS

2016-06-11 22:56

administrator   bugnote:0014600

> при снятой опции "Use Windows registered types".

Ok.

heilong

2016-06-19 14:31

reporter   bugnote:0014616

Last edited: 2016-06-19 14:32

View 2 revisions

Полёт по-прежнему нормальный, с удовольствием пользуюсь bash-ем в качестве comspec-а, с помощью написанного на С++ wrapper-а.
https://dl.dropboxusercontent.com/u/49471027/far_bash_comspec.7z
Пару лет назад, когда мне приходила в голову мысль о far+bash, это казалось далёкое и несбыточной мечтой! Спасибо за все проделанные труды :)

По-моему, баг можно закрывать.

DrKnS

2016-06-19 14:40

administrator   bugnote:0014617

Ok.
Будет совсем здорово, если вы свои наработки также выложите где-нибудь на форуме (если ещё не).

DrKnS

2016-06-19 21:13

administrator   bugnote:0014618

update:
http://forum.farmanager.com/viewtopic.php?p=138859#p138859

Issue History

Date Modified Username Field Change
2016-04-27 17:50 heilong New Issue
2016-04-28 00:31 heilong Note Added: 0014495
2016-04-28 01:20 DrKnS Note Added: 0014496
2016-04-28 01:29 heilong Note Added: 0014497
2016-04-28 01:41 heilong Note Edited: 0014497 View Revisions
2016-04-28 14:00 heilong Note Added: 0014499
2016-04-28 14:01 heilong Note Edited: 0014499 View Revisions
2016-04-28 15:38 DrKnS Assigned To => DrKnS
2016-04-28 15:38 DrKnS Status new => assigned
2016-04-28 15:53 2useven10 Note Added: 0014500
2016-04-28 16:55 DrKnS Note Added: 0014501
2016-04-29 00:07 heilong Note Added: 0014502
2016-04-29 00:52 heilong Note Added: 0014503
2016-04-29 03:41 heilong Note Added: 0014504
2016-04-29 03:48 heilong Note Edited: 0014502 View Revisions
2016-04-29 10:02 Smitis Note Added: 0014505
2016-04-29 10:20 DrKnS Note Added: 0014506
2016-04-29 10:56 Smitis Note Added: 0014507
2016-04-29 11:00 Smitis Note Edited: 0014507 View Revisions
2016-04-29 12:36 Smitis Note Added: 0014508
2016-04-29 12:45 DrKnS Note Added: 0014509
2016-04-29 12:55 Smitis Note Added: 0014510
2016-04-29 15:08 heilong Note Added: 0014511
2016-04-29 17:37 Smitis Note Added: 0014512
2016-04-30 02:07 heilong Note Added: 0014513
2016-04-30 02:28 heilong Note Edited: 0014513 View Revisions
2016-04-30 02:43 heilong Note Added: 0014514
2016-04-30 11:26 DrKnS Note Added: 0014515
2016-04-30 14:41 Smitis Note Added: 0014516
2016-04-30 15:28 DrKnS Note Added: 0014517
2016-05-07 23:53 heilong Note Added: 0014530
2016-05-08 00:36 DrKnS Note Added: 0014531
2016-05-08 01:56 heilong Note Added: 0014532
2016-05-08 01:58 heilong Note Edited: 0014532 View Revisions
2016-05-08 02:18 heilong Note Added: 0014533
2016-05-08 02:23 DrKnS Note Added: 0014534
2016-05-08 02:30 heilong Note Added: 0014535
2016-05-08 02:32 heilong Note Edited: 0014532 View Revisions
2016-05-08 02:36 DrKnS Note Added: 0014536
2016-05-08 02:48 heilong Note Added: 0014537
2016-05-11 03:40 heilong Note Added: 0014541
2016-05-14 02:56 heilong Note Added: 0014547
2016-05-14 12:35 DrKnS Note Added: 0014548
2016-05-14 16:10 Smitis Note Added: 0014549
2016-05-14 16:11 Smitis Note Edited: 0014549 View Revisions
2016-05-15 20:43 heilong Note Added: 0014550
2016-05-15 22:07 DrKnS Note Added: 0014551
2016-05-16 12:29 heilong Note Added: 0014554
2016-05-16 12:50 heilong Note Edited: 0014554 View Revisions
2016-05-16 22:59 DrKnS Note Added: 0014555
2016-05-17 02:12 heilong Note Added: 0014557
2016-06-08 14:41 heilong Note Added: 0014594
2016-06-09 01:57 DrKnS Note Added: 0014595
2016-06-10 11:03 Smitis Note Added: 0014596
2016-06-10 12:37 2useven10 Note Added: 0014597
2016-06-10 12:51 2useven10 Note Added: 0014598
2016-06-10 12:55 2useven10 Note Edited: 0014598 View Revisions
2016-06-11 14:20 Smitis Note Added: 0014599
2016-06-11 22:56 DrKnS Note Added: 0014600
2016-06-19 14:31 heilong Note Added: 0014616
2016-06-19 14:32 heilong Note Edited: 0014616 View Revisions
2016-06-19 14:40 DrKnS Build => 4704
2016-06-19 14:40 DrKnS Note Added: 0014617
2016-06-19 14:40 DrKnS Status assigned => closed
2016-06-19 14:40 DrKnS Resolution open => fixed
2016-06-19 14:40 DrKnS Fixed in Version => 3.0
2016-06-19 21:13 DrKnS Note Added: 0014618