View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0003223 | Wishes | Command Line/Execute | public | 2016-04-27 15:50 | 2016-06-19 19:13 |
Reporter | heilong | Assigned To | DrKnS | ||
Priority | normal | Severity | minor | Reproducibility | always |
Status | closed | Resolution | fixed | ||
Fixed in Version | 3.0 | ||||
Summary | 0003223: Проблемы с заключением в кавычки при передаче ком. строки ComSpec-у | ||||
Description | Дорабатываю wrapper скрипт для запуска команд ком. строки с помощью bash. Столкнулся с проблемами, если в команде присутствуют кавычки. Для теста сейчас сделал, чтобы скрипт печатал, с какими аргументами он вызван, а потом вызывал команду Пробуем
Команды приходят одним аргументом, как и положено. Но куда деваются все кавычки?Наконец, вот такой вариант не съедает вторую пару одинарных кавычки :
Двойные кавычки съедаются всегда и везде. Получается, первый аргумент (как бы программа для запуска, хотя в данном случае это не команда) фаром обрабатывается особенно. Далее
Вообще что-то непонятное творится, особенно каким образом из двух одинарных кавычек по краями вышла одна двойная в середине (перед пробелом)?Ну ладно, думаю может быть я попрошу фар не заморачиваться с кавычками, и добавлю свой bashcmd.sh в System.Executor.NotQuotedShell, а там уже в своём скрипте разберусь, как мне всё это разобрать.
Двойные кавычки полностью исчезли, одинарные на этот раз остались как раз в первой команде, а в следующей исчезли. Ничего не понимаю... В общем, этот режим тоже не лечит проблему.По сути дела, мне бы получить на вход оригинал ком. строки. То, что фар дописывает путь к первой команде (пишу `ls`, в скрипт передаётся `C:\cygwin\bin\ls.EXE`) - не требуется, и даже создаёт дополнительный гемор (т.к. пути пишутся через \, а для bash это escape-символ). Можно ли добавить опцию System.Executor.RawCmdlineShell или что-нибудь в этом роде? | ||||
Tags | No tags attached. | ||||
Build | 4704 | ||||
|
Вообще лично мне бы хотелось иметь опцию, чтобы все команды, кроме внутренних, выполнялись через 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 дословно с той командной строкой, которую ввёл юзер. |
|
Так надо. Comspec умеет далеко не всё, что умеет ShellExecute. Это уже фантазии. Ваш скрипт запускается не святым духом, а башем, или что у вас там. Посмотрите таскменеджером переданную процессу костроку, там, уверен, кавычки будут. Куда их потом дел баш - вопрос не к нам. |
|
Я уже поставил ComSpec-ом данную программку
Все те же результаты, что и выше я привёл. Какие ещё фантазии?
Вот в чём прикол, что ls с полным путём, а grep нет? На кой такая полуработа нужна? |
|
Я для интереса скачал исходники фара, внёс для тестирования пару изменений в 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 так, как её юзер напечатал, дословно со всеми кавычками и прочим (если есть что-то прочее). Буду благодарен, если тыкнете, где искать инфу/доки по вопросу. |
|
Не спешите вешать всех собак на ShellExecute(). Сначала в вашей програмке распечатайте GetCommandLine(), потом можно CommandLineToArgvW()... |
|
> Вот в чём прикол, что ls с полным путём, а grep нет? На кой такая полуработа нужна? Да, действительно. 4645. Также см. changelog - ключи запуска и кавычки теперь задаются иначе |
|
Здорово, вот спасибо! Новые опции мне нравятся больше старых, да и кода в 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. |
|
Вот что у меня получилось с квотингом: http://pastebin.com/4mGVrnn7 `'` заменяется на `'"'"'`, в рез-те первоначальная кавычка (извне ${0}) закрывается, вставляется в двойных кавычках одинарная кавычка (literally), и далее опять одинарная кавычка открывается. `\` удваиваются - без этого проблемы с `\'` и собственно с `\\` Вот как пример, написал весьма замысловатую (бессмысленную) команду - как ушла, так и пришла. |
|
Ещё такие вопросы 1) Бат файлы, похоже, выполняются ${comspec} /c ${batfile}. Соотв-но comspec=bash - батники не работают в принципе. Нужна отдельная настройка какая-то, чтоб можно было прописать комспек для выполнения бат файлов. 2) Сделал макрос, переключающий по хоткею ComSpec (cmd <-> bash). Но им нужны разные System.Executor.ComspecArguments. Как бы из макроса это переключать? |
|
К сожалению, с отменой System.Executor.NotQuotedShell теряется гибкость с использованием кавычек. А System.Executor.ComspecArguments получается жёстко привязывает ФАР к оболочке - теперь, если я хочу запустить ФАР из-под другой оболочки, нужно каждый раз менять конфигурацию, так получается? |
|
Смотрите в справке вашего шелла. В cmd, например, при указании /S /C "blablabla" всё, находящееся между внешними двойными кавычками, трактуется как есть и ничего эскейпить не надо.Если вдруг ничего подобного не предусмотрено, можно использовать в качестве комспека промежуточную программу или скрипт, которая заэскейпит как вам надо. Добавьте ассоциацию для bat / cmd.
Это вы так предполагаете или так и происходит? Я что-то не вижу в фаре обработки "echo".
Подозреваю, мало кто меняет шелл каждый день и такая гибкость не критична.
far.exe -set:System.Executor.ComspecArguments="/S /C \"{0}\""far.exe -set:System.Executor.ComspecArguments="whatever" |
|
Зачем менять? У меня два ярлыка на рабочем столе. Один запускает ФАР из-под cmd, второй из-под tcc. Сейчас вот, под воздействием тем на форуме, заинтересовало использование из-под bash, даже cygwin установил и враппер написал, чтобы автоматом подменял /c на -c, и тут облом.И вообще, получается, что под каждую оболочку нужна своя строка вызова. Мало ли там ещё что будет, из-под PowerShell, например, запустить.
Может и так придётся выкручиваться. Хотя лучше бы был нормальный доступ на Lua, тогда можно было бы проанализировать из _macroinit что там используется. Или возможность из Lua самостоятельно перехватывать и анализировать командную строку (то что пару лет назад уже начали делать, но потом откатили) |
|
Предложение - возродить ProcessFarCommandLine http://forum.farmanager.com/viewtopic.php?f=15&t=8641 Тогда каждый сможет написать себе свой обработчик с |
|
Ну если запуск всё равно через ярлыки, я не вижу проблем добавить туда -set: |
|
Добавил уже, эксперементирую. |
|
Чем больше думаю и пробую, тем сложнее все кажется в общем случае. Может быть, действительно стоит оставить ComSpec для cmd-совместимых шеллов, а всю кастом логику для произвольных вынести в макроапи или плагин апи? Только по-моему там должны быть две ф-ции - первая (если есть) запускается фаром в самом начале execute(), перед PartCmdLine - она решает, хочет ли макрос/плагин забрать ком строку себе на выполнение, или же он от неё отказывается и возвращает (возможно, с изменениями) фару на выполнение согласно существующей логике (т.е. это кастом версия PartCmdLine). Вторая же ф-ция собственно получает ком строку уже непосредственно на выполнение. |
|
heilong А зачем так сложно? Передали в плагин строку as is. Далее, либо плагин её выполнил и вернул true, либо отказался выполнять, вернул false и строка передаётся дальше. |
|
Мой шелл тут не причём, речь идёт о том, что с ком строкой происходит до того, как она попадёт шеллу в argv. Т.е., видимо, о CommandLineToArgvW(). У меня такая логика - если фар имеет ф-цию подставлять `'${0}'`, то он должен ${0} обработать так, чтоб он не "убежал" за "забор" из кавычек. Простой пример. Юзер ввёл `echo a ' ' b`. Подставляется в шаблон, получается в итоге выполняется команда `bash -c 'echo a ' ' b'` - т.е. после -c идут два аргумента, а не один. Предложение такое - смотрел, какой символ (если есть) идёт непосредственно перед (или после) ${0} в ComspecArguments. Если это ', то надо quote/escape одинарные кавычки в Info.Command, если " - двойные, иначе ничего не делать (наверно?). Обратные слэши же надо удвоить, на входе в шелл они станут одинарными. В небольшом патче, ссылку (pastebin) на который я давал выше, это делается (ComspecArguments = `-c '${0}'`). Провернял на корректность такой ком строкой:
Первый экзешник - простейшая C программа, распечатывающая свой argv. Второй - bash скрипт-wrapper, подгружающий доп. rcfile (алиасы, опция шелла и т.д.),и далее eval команду. С моим патчем в оба эти ComSpec-а приходит полностью та же ком строка, что я и ввёл. Попробовал, добавил `.bat;.cmd` и выполнение через `@cmd.exe /c "$!.!"`. Файлы-то выполняются, но что-то жесть какая-то происходит с выводом - панели фара все съезжают вверх (на столько строчек, сколько вывода напечатал батник), менюшка фара же внизу так и остаётся. Для перерисовки приходится нажимать Ctrl-R или выполнять cls. 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`? Может быть это на практике я и не буду использовать, но на данный момент не все, что надо, работает через bash, возможно было бы удобно в какой-то момент переключиться на cmd, выполнить команду, переключиться обратно. Я сперва написал для этого макрос, в принципе это может быть просто бат-файл. Т.е. хочется одним нажатием хоткея, или же запуском определённой команды или алиаса, быстренько поменить не только ComSpec env var, но и соответствующие переменые конфига фара. Но вроде как я читал, что менять far:config из макроса это дурной тон (если это вообще технически возможно)? |
|
Если посмотреть execute.cpp, то там куча кода - полезна (ну хотя бы folder run по Shift-Enter, консоль для не-silent запуска). Если делать одной ф-цией, и плагин полностью берёт на себя всё, то с высокой вероятностью в плагине помимо нового кода будет копи-пейст имеющегося из execute.cpp (а если нет, то потеряется часть имеющейся функциональности). Если же сделать из двух функций, получится существующий код использовать. По кр мере у меня возникла такая идея после просмотра, что именно происходит и в какой последовательности в execute.cpp:Execute(). |
|
Ваш шелл здесь причём, ещё раз перечитайте написанное. Если echo a " " b запускать как /s /c "a " " b" через cmd, то всё будет выполнено правильно, несмотря на любое количество кавычек. Если ваш шелл трактует 'echo a ' ' b' как два аргумента и не предоставляет возможности трактовать как один, напишите промежуточную программу или скрипт, поторая заэскейпит внутренние кавычки как вам надо. Фар не будет за вас решать, какие кавычки подставлять, какие удваивать, какие эскейпить, что делать со слешами и т. п.
"Жесть какая-то" потому что вы зачем-то засунули туда @.
Если вас не устраивает, что выполняется echo.exe а не интерпретатор, прочитайте справку по System.Executor.ExcludeCmds. |
|
DrKnS Что-то поломалось: Если задан полный путь к исполняемому файлу, но без расширения и в кавычках, расширение автоматически не подставляется (раньше подставлялось). Без кавычек расширение подставляется. Проверить можно вызывая из ком. строки простейший cmd: |
|
Вроде бы починил. |
|
По поводу изменений 4645: `ls | grep word` запускается как есть, без путей, shell сам ищет, где ls, где grep. Но если написать `view:< ls | grep word`, то старое поведение - запускается `C:\cygwin\bin\ls.EXE | grep word`. |
|
view: < - это плагин farcmds. |
|
Ну тут скорее не в шелле дело, а в том, как вообще ком строка в 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 Про ExcludeCmds я видел и уже прописал туда, что надо. Вопрос не в этом, я может быть неправильно акцент поставил, упомянув echo.exe. Предположим, хочу выполнить `SomeProgram.exe $((2**20))`, я хочу передать ей аргумент - результат вычисления арифметического выражения (2 в 20-й степени). Фар выполнит SomeProgram.exe с аргументов "$((2**20))", вместо передачи этого дела ComSpec-у. Приходится писать что-то вроде `...моя команда... | cat`, чтоб форсировать использование ComSpec-а. Хотелось бы иметь какую-то возможность иметь некоторый контроль над процессом. Понял, спасибо, обращусь к авторам. |
|
Ещё обнаружил, что при запуске BAT файлов по-прежнему передаётся полный путь к файлу. |
|
> Предположим, хочу выполнить `SomeProgram.exe $((2**20))` Да, так понятнее. > Понял, спасибо, обращусь к авторам. Он "официальный", обратиться можно на этом же багтрекере (на форуме забудется и потеряется). > Ещё обнаружил, что при запуске BAT файлов по-прежнему передаётся полный путь к файлу. А чем это плохо? |
|
> Он "официальный", обратиться можно на этом же багтрекере (на форуме забудется и потеряется). Сделаю. > А чем это плохо? Может и не плохо... Просто чем принципиально отличается `ls.exe | grep word` от `ls.bat | grep word`... |
|
> Может и не плохо... Просто чем принципиально отличается `ls.exe | grep word` от `ls.bat | grep word`... Ничем. У вас именно в случае "ls.bat | grep word" ls.bat запускается с полным путём? |
|
> У вас именно в случае "ls.bat | grep word" ls.bat запускается с полным путём? Я немного ошибся. Как раз полный путь, если запускать просто file.bat. Т.е. это видимо как раз ветка директ рана, но ComSpec ведь стоит мой, и скрипт запускается через него. У меня в принципе wrapper скрипт это переваривает, не знаю, есть ли смысл менять что-то, может от этого где-то быть польза или вред. |
|
Про farcmds добавил багрепорт http://bugs.farmanager.com/view.php?id=3231 |
|
В виду каких-то последних изменений перестало вдруг работать следующее. Если на командной строке запускаю какой-то скрипт вот так `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` и с прямым слэшом в пути запускался. Поправимо? |
|
У меня *.sh запускать нечем, более распространённый пример есть? |
|
Не связано ли с этим? http://forum.farmanager.com/viewtopic.php?f=9&t=5773&start=2720#p137702 |
|
Ок, запуск несуществующего 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. |
|
Да, это сломалось недавно, вроде поправил. |
|
Ситуация улучшилась, но по-прежнему есть проблемы. Теперь такое впечатление, что стало всё выполняться через ComSpec.
Только давеча scripts/run.sh выдавал ошибку файл не найден, а scripts\run.sh работал.Т.е. такое впечатление, что direct run перестал использоваться для batch файлов и прочих скриптов. Да, System.Executor.BatchType я поставил %PathExt%, хотя пробовал также и дефолтный. Если просто run пишу (есть run.bat, есть run.sh), команда идёт через комспек и результат - команда не найдена. Т.е. похоже PathExt фаром не обрабатывется на данный момент. |
|
4675. |
|
Завтра уезжаю на 2-3 недели в Грузию, если там будет возможность, погляжу. |
|
Вернулся, проверил. Теперь работают все варианты запуска, в т.ч. с прямым и обратным слэшом в пути, без или с указанием расширения файла. Вижу, что в far:config больше нету System.Executor.BatchType, используется PathExt или как? Спасибо за проделанную работу! Вроде как по этому баг репорту теперь всё хорошо. Последнее оставшееся пожелание - поддержка регулярного выражения для определения, возможен ли direct run или `too complex`, что обсуждалось тут http://forum.farmanager.com/viewtopic.php?p=137781&sid=0a48f0d854c2d7f57de746109f48b9e5#p137781 |
|
> больше нету System.Executor.BatchType, используется PathExt или как? Используется анализ ассоциированного приложения. > поддержка регулярного выражения для определения Добавил System.Executor.ComspecCondition. |
|
Теперь ФАР пытается "выполнять" файлы без расширения. Например, если в текущей папке лежит файл cmd (без расширения), то попытка выполнить из ком. строки cmd откроет диалог "Open as". В то же время cmd /? выполнится нормально. |
|
> Теперь ФАР пытается "выполнять" файлы без расширения. > http://forum.farmanager.com/viewtopic.php?p=138017#p138017 |
|
Может и нет, я просто забыл, что активировал ExcludeCmds... |
|
У нас, получается, есть два алгоритма "выполнения" файлов: - То, как это делается через WinR (почти текущее поведение ФАРа) - открываем всё подряд, в том числе и файлы без расширения. Если введена команда без расширения и такого файла без расширения нет, подставляются некоторые расширения по умолчанию. Вот тут поведение ФАРа и системы расходятся: ФАР, похоже, подставляет из PATHEXT, а система только основные. Во всяком случае ассоциированные c TakeCommand .btm файлы ФАР выполняет, а WinR нет. - То, как это делается из командной строки (старое поведение ФАРа) (классический способ) - для файлов без расширения подставляются расширения из PATHEXT, и только файлы с расширениями из PATHEXT выполняются. Мне кажется, второй способ для командной строки ФАРа логичнее. Как минимум, при снятой опции "Use Windows registered types". |
|
> при снятой опции "Use Windows registered types". Ok. |
|
Полёт по-прежнему нормальный, с удовольствием пользуюсь bash-ем в качестве comspec-а, с помощью написанного на С++ wrapper-а. https://dl.dropboxusercontent.com/u/49471027/far_bash_comspec.7z Пару лет назад, когда мне приходила в голову мысль о far+bash, это казалось далёкое и несбыточной мечтой! Спасибо за все проделанные труды :) По-моему, баг можно закрывать. |
|
Ok. Будет совсем здорово, если вы свои наработки также выложите где-нибудь на форуме (если ещё не). |
|
update: http://forum.farmanager.com/viewtopic.php?p=138859#p138859 |
Date Modified | Username | Field | Change |
---|---|---|---|
2016-04-27 15:50 | heilong | New Issue | |
2016-04-27 22:31 | heilong | Note Added: 0014495 | |
2016-04-27 23:20 | DrKnS | Note Added: 0014496 | |
2016-04-27 23:29 | heilong | Note Added: 0014497 | |
2016-04-27 23:41 | heilong | Note Edited: 0014497 | |
2016-04-28 12:00 | heilong | Note Added: 0014499 | |
2016-04-28 12:01 | heilong | Note Edited: 0014499 | |
2016-04-28 13:38 | DrKnS | Assigned To | => DrKnS |
2016-04-28 13:38 | DrKnS | Status | new => assigned |
2016-04-28 13:53 | 2useven10 | Note Added: 0014500 | |
2016-04-28 14:55 | DrKnS | Note Added: 0014501 | |
2016-04-28 22:07 | heilong | Note Added: 0014502 | |
2016-04-28 22:52 | heilong | Note Added: 0014503 | |
2016-04-29 01:41 | heilong | Note Added: 0014504 | |
2016-04-29 01:48 | heilong | Note Edited: 0014502 | |
2016-04-29 08:02 | Smitis | Note Added: 0014505 | |
2016-04-29 08:20 | DrKnS | Note Added: 0014506 | |
2016-04-29 08:56 | Smitis | Note Added: 0014507 | |
2016-04-29 09:00 | Smitis | Note Edited: 0014507 | |
2016-04-29 10:36 | Smitis | Note Added: 0014508 | |
2016-04-29 10:45 | DrKnS | Note Added: 0014509 | |
2016-04-29 10:55 | Smitis | Note Added: 0014510 | |
2016-04-29 13:08 | heilong | Note Added: 0014511 | |
2016-04-29 15:37 | Smitis | Note Added: 0014512 | |
2016-04-30 00:07 | heilong | Note Added: 0014513 | |
2016-04-30 00:28 | heilong | Note Edited: 0014513 | |
2016-04-30 00:43 | heilong | Note Added: 0014514 | |
2016-04-30 09:26 | DrKnS | Note Added: 0014515 | |
2016-04-30 12:41 | Smitis | Note Added: 0014516 | |
2016-04-30 13:28 | DrKnS | Note Added: 0014517 | |
2016-05-07 21:53 | heilong | Note Added: 0014530 | |
2016-05-07 22:36 | DrKnS | Note Added: 0014531 | |
2016-05-07 23:56 | heilong | Note Added: 0014532 | |
2016-05-07 23:58 | heilong | Note Edited: 0014532 | |
2016-05-08 00:18 | heilong | Note Added: 0014533 | |
2016-05-08 00:23 | DrKnS | Note Added: 0014534 | |
2016-05-08 00:30 | heilong | Note Added: 0014535 | |
2016-05-08 00:32 | heilong | Note Edited: 0014532 | |
2016-05-08 00:36 | DrKnS | Note Added: 0014536 | |
2016-05-08 00:48 | heilong | Note Added: 0014537 | |
2016-05-11 01:40 | heilong | Note Added: 0014541 | |
2016-05-14 00:56 | heilong | Note Added: 0014547 | |
2016-05-14 10:35 | DrKnS | Note Added: 0014548 | |
2016-05-14 14:10 | Smitis | Note Added: 0014549 | |
2016-05-14 14:11 | Smitis | Note Edited: 0014549 | |
2016-05-15 18:43 | heilong | Note Added: 0014550 | |
2016-05-15 20:07 | DrKnS | Note Added: 0014551 | |
2016-05-16 10:29 | heilong | Note Added: 0014554 | |
2016-05-16 10:50 | heilong | Note Edited: 0014554 | |
2016-05-16 20:59 | DrKnS | Note Added: 0014555 | |
2016-05-17 00:12 | heilong | Note Added: 0014557 | |
2016-06-08 12:41 | heilong | Note Added: 0014594 | |
2016-06-08 23:57 | DrKnS | Note Added: 0014595 | |
2016-06-10 09:03 | Smitis | Note Added: 0014596 | |
2016-06-10 10:37 | 2useven10 | Note Added: 0014597 | |
2016-06-10 10:51 | 2useven10 | Note Added: 0014598 | |
2016-06-10 10:55 | 2useven10 | Note Edited: 0014598 | |
2016-06-11 12:20 | Smitis | Note Added: 0014599 | |
2016-06-11 20:56 | DrKnS | Note Added: 0014600 | |
2016-06-19 12:31 | heilong | Note Added: 0014616 | |
2016-06-19 12:32 | heilong | Note Edited: 0014616 | |
2016-06-19 12:40 | DrKnS | Build | => 4704 |
2016-06-19 12:40 | DrKnS | Note Added: 0014617 | |
2016-06-19 12:40 | DrKnS | Status | assigned => closed |
2016-06-19 12:40 | DrKnS | Resolution | open => fixed |
2016-06-19 12:40 | DrKnS | Fixed in Version | => 3.0 |
2016-06-19 19:13 | DrKnS | Note Added: 0014618 |