» Far Manager

DVall

Ясно. Походу CMD сбит.

VictorVG4

Цитата:

Тогда прошу подсказку куда стоит посмотреть?

...
если пробовали с чистым профилем, настройки фар исключаем.
либо игры c %ComSpec%, либо ищите start.* в вашей системе.

wseventeen

Точно! ведь в Msys/bin есть скрипт start:

Цитата:

#!/bin/sh
# Copyright (C) 2002, Earnie Boyd
# mailto:earnie@users.sf.net
# This file is part of Minimal SYStem.
# http://www.mingw.org/msys.shtml
# File: start

cmd //c start "$@"

про который я и забыл! Попробуем его исключить.

Добавлено:
Низкий поклон - именно этот скрипт и вызывал окно. Для устранения сбоя хватило его переименования в start.sh. А я уже всю систему перерыл - вроде все параметры правильные, а раз так, то кто вызывает окно? А это оказывается его художества. Ну, пусть с ним bash по должности и разбирается.

Цитата:

Для устранения сбоя хватило его переименования в start.sh

Imho, поведение запускателя far в этой ситуации нельзя назвать правильным.

Добавлено:
Создания пустого файла 'start' в текущем каталоге достаточно, чтобы воспроизвести проблему.

Получается что причина накладки тут:

--- execute.hpp rev14175
+++ execute.hpp rev14176
@@ -41,7 +41,7 @@

bool Execute(struct execute_info& Info, bool FolderRun, bool Silent, const std::function<void()>& ConsoleActivator = nullptr);

-bool IsBatchExtType(const string&ExtPtr);
+bool IsExecutable(const string& Filename); // идёт поиск по имени файла без учёта расширения аналогично UNIX, а с типом ОС разбирается, но при наличии одноимённого, но "непонятного" файла получаем непредсказуемый результат обработки команд

bool ExpandOSAliases(string &strStr);

тогда может стоит добавить проверку на то что это реальный файл а не симлинк и что имя файла имеет расширение? Как пример я использую такой набор для проверки обновлений:

./updaterino - симлинк на updaterino.cmd
file://server/upd/updaterino.cmd - собственно проверяющий и получающий обновления скрипт раскладывающий их по каталогам ./1 - ./7

если команда start /i updaterino в b4678 отрабатывалась без вопросов, то покуда я не переименовал С:\Msys\bin\start -> C:\Msys\bin\start.sh в b4679+ она не работала...

Добавлено:
И по поводу левых файлов - я например просто банально забыл, что в составе msysCORE-1.0.17-1-msys-1.0.17-ext.tar.lzma есть скрипт start и именно он и вызвал проблему т.к. данный пакет автоматически устанавливается с компилятором GCC/MinGW64/TDM-GCC.

Добавлено:
По поводу ответа DrKnS в данном случае это ошибка в логике ОС. Кстати ловится элементарно:

WinR -> start cmd

только пробовал - ось ругается. Я тут вчера полазил по её душу и на http://stackoverflow.com/ отыскал - встретил оценку что в WinAPI IsExecutable() реализована с ошибками, а на семёрке ошибки в VCPlatform.IsExecutable Method (String) считаются Know Issues. Сейчас что-то не смог отыскать конкретное место, потому по памяти всё что отыскал...

Собрал и бегло проверил b4690 - проблема сохраняется если в пути поиска исполняемых файлов:

Цитата:

Путь поиска, используемый Windows для обнаружения библиотеки DLL
http://msdn.microsoft.com/ru-ru/library/7d83bc18.aspx

Используя механизмы явного и неявного связывания, Windows сначала выполняет поиск "известных библиотек DLL", таких как Kernel32.dll и User32.dll. Затем Windows выполняет поиск библиотек DLL в следующей последовательности:

1) Каталог, в котором находится исполняемый модуль текущего процесса.
2) Текущий каталог.
3) Системный каталог Windows. Путь к этому каталогу извлекается с помощью функции GetSystemDirectory.
4) Каталог Windows. Путь к этому каталогу извлекается с помощью функции GetWindowsDirectory.
5) Каталоги, указанные в переменной среды PATH.

Примечание

Переменная среды LIBPATH не используется.

встретится одноимённый с командой неисполняемый или пустой файл и решение TI#54 с внесением в конфиг списка команд шелла не помогает. Вносил команды CMD, но всё одно в случае пустого файла с именем START или sh-скрипта с таким именем ось выводит окно - это и есть системная ошибка:

- если в пути поиска встречен файл совпадающим с командой именем, то даже если IsExecutable() и вернёт false дальнейший поиск не продолжается, а выводится окно задания ассоциации - ось не проверяет файл на типы script/executable/link и размер.

VictorVG4

Цитата:

Вносил команды CMD, но всё одно в случае пустого файла с именем START...

Помогает. Вносить лучше через импорт соответствующего файла из Addons/SetUp/

wseventeen

Да, через него и вносил, но коли рядом с Far.exe создать файл start с длинной 0 байт - получаем окно.

Потому у меня возникла (пока сыроватая) такая идея:

C=""
i=0
i=i+1;
do B=subst(1,i,Current.Comstr); if B(i) == "" then Goto M1 end;
m1: C=subst(1,i,Current.Comstr);
if Filelignht(C) == 0 then (Message("Incorrect commad string. Please, edit this.");
edit:<Current.ComStr else OsExecute(Current.ComStr))
end;

т.е. если мы встретили файл нулевой длинны с именем совпадающим именем введённой команды, то отправляем его в редактор чтобы пользователь её исправил, нет передаём на запуск ОС.

Примерно так...

Цитата:

но коли рядом с Far.exe создать файл start с длинной 0 байт - получаем окно.

Нет. Не получаем.

Far.exe -import ...
рестарт
far:config -- проверяем, что настройки есть

wseventeen

Да, это я по привычке вызывал команду Far /import - ну и она не сработала. А с bash/sh/perl - там же первой строкой идёт сигнатура #!/bin/sh или #!/bin/perl -w и почему бы нам не читать эту строку и по ней звать нужный обработчик аналогично UNIX?

Цитата:

6. Рефакторинг. Обновление совместимо с SVN r14193 - SVN r14196

VictorVG4, сорри, если ответ на вопрос где-то здесь есть, но чем ваша сборка бинарей отличается от официальной и почему нельзя ваши фиксы влить в официальный репозиторий?

Почему спрашиваю — как-то думаю, насколько хватит энтузиазма ежедневно обновлять и всё такое. Максимус вон тоже собирает\собирал свои bis-сборки. Но их актуальность со временем терялась за редкостью.

Wave_Blessed

1) Оптимизация. Сравните размеры, скорость в работе, расход ОЗУ.
2) Я сам ими пользуюсь.
3) Пока для них существует задача.

Wave_Blessed
Фиксов для официального репозитория здесь нет (в отличии от сборок Maximus-а).
Могут быть предыдущие версии, если в последней официальной сборке баги (иногда случается).
Сборка отличается наличием огромного зоопарка плагинов и скриптов (и кажется ещё сторонних утилит). Нужен он далеко не всем (и не весь). В этом зоопарке фиксы наверное есть.

Добавлено:

Цитата:

Оптимизация. Сравните размеры, скорость в работе, расход ОЗУ.

Кроме размера (в основном за счет отсутствия отладочной информации) это фантазии.

Цитата:

Сборка отличается наличием огромного зоопарка плагинов и скриптов (и кажется ещё сторонних утилит). Нужен он далеко не всем (и не весь). В этом зоопарке фиксы наверное есть.

Это-то я само-собой посмотрю на предмет позаимствовать макрос-другой, ассоциацию-другую, etc. Меня интересовали именно бинарники фара, почему вся сборка FarUE3.7z из самостоятельно скомпилированного софта, в чём отличие и стоит ли оно того, чтобы самому позаимствовать не только отдельные макросы, но и far.exe.
P.s. Пока остановился на 4670, и с сомнением поглядываю чейнджлог.

wseventeen

Far Manager v3.0 build 4691 x64 (2016-05-24) с farmanager.com



через пять минут после запуска рабочий набор задачи 47,34 МБ

Far Manager v3.0 build 4691 r14205 x64 собранная мной



через пять минут после запуска рабочий набор задачи 16,32 МБ

в обоих случаях весь набор плагинов и скриптов одинаков - распакованный архив Far30-x64-test.7z, запуск производился через Explorer, измерение в Process Hacker 3.0.0.136 осуществлены в среде Win 7 SP1 через пять минут после запуска тестируемой копии, БД настроек перед каждым опытом удалялись и копировались из архива заново. Машина i7-2600 @ 3,4 GHz / Intel Z68 /16 Gb DDR3-1600 / NVIDIA GTX 650 - обычная рабочая машина.

Цитата:

Кроме размера (в основном за счет отсутствия отладочной информации) это фантазии.

VictorVG4
Да фантазии.
Зачем замерять wset у бездействующей программы?
Два моих far.exe через сутки после запуска: 6024K, 21496K -- ни о чём.
Лучше расскажите в чём состоит 'оптимизация'.

wseventeen

Я согласен - если нет желания что-то признать - это "фантазии". Ключи компиляции я не раз выкладывал. Иного нет.

VictorVG4
Пересборка с изменёнными ключами это не оптимизация.
Учитывая, что параметры оптимизация по скорости в стандартной сборке, как минимум не хуже чем у вас.

У меня во время прощупывания багов редактора в недавних билдах сложилось впечатление, что сборка, сделанная GCC, была заметно быстрее, чем ночная сборка.

wseventeen

Я с этим и не собираюсь спорить. Когда я выбирал параметры оптимизации основной проблемой был доступный на рабочей машине объём ОЗУ - приложение могло использовать не свыше 70 Мб и тут приходилось крутится т.к. на ней ещё и консоль управления испытательным комплексом висела, а средств просмотра логов и формируемых в приборах и скидываемых по КАМАК наборов данным в ней просто не было. Так что пришлось выбрать оптимизацию с минимальным размером кода в ОЗУ или машина превращалась во что-то непотребное. И заменить этот аппарат было нечем - ПК Symens-Nixdorf в переносном горно-промышленном исполнении. Внешне чемоданчик размерами с "дипломат" с кучей закрытых от пыли резинками разъёмов и экраном в крышке, внутри Intel Core 2 Duo T9400, iGM31, 576 МБ ОЗУ из которых 64 Мб выделено под фреймбуфер и 2.5" HDD на 80 Гб в гелиевом амортизаторе. Клавиатура на 84 клавиши и тракболл вмонтированы, подключение внешних не предусмотрено. Зато питание считай любое - DC 12/24/27V или AC 36/110/115/230/380V 50/60/400 Hz - встроенный БП любые сети понимал - авто-/авиа- (DC 27V)/бытовые ~110/115/230 /промышленные ~ 36/380V.

shmuz2

Цитата:

сборка, сделанная GCC, была заметно быстрее

Последний раз пробовал сравнивать с gcc пару лет назад.
Тогда gcc почти всегда отставал на несколько процентов.
Он стал сильно лучше или vc набрал вес?

wseventeen

А это что за странный мусор выводится поле Путь: в FarDiskMenu 3.13.0.4040 x64 при выборе настройки плагина Редактор меню дисков по Ins Путь из Реестра:



при наборе теста убрать квадратики не долго, на в 3.12.0 их не было. И в ChangeLog v3.13.0 п2 опечатка в тексте: Увеличерна - лишняя "р" при наборе случайно попала.


Upd:

Исправлено в 3.13.1 .

VictorVG4, не знаю, не знаю. Я вот на свою сборку (в смысле, свой набор плагинов-макросов-прочего) накатил ваши бинарники и сейчас вот вижу, что Far.exe занимает ~63 мб памяти. Это он у меня запущен то ли с утра, то ли с дня. При том, что большинство плагинов у меня лежат в Plugins.off и загружаются-запускаются через Plugin:Load явно, по макросам, вызовам из пользовательского меню. И цифра эта в шестьдесят мегабайт для меня довольно обычная, не больше, но и не меньше, чем ФАР официальной сборки занимает, когда я заглядываю в диспетчер задач обычно. Да и после старта около 25 метров сразу занято. И тоже, кстати, где-то плюс-минус обычные цифры.

Wave_Blessed

И у меня когда я за сутки его основательно погоняю используется 66,93 MB что вполне нормально. По крайней мере для моей машины:

VictorVG4
DiskMenu 3.13.1

wseventeen

Спасибо! Я честно говоря вначале предположил что это от задания ширины поля как W-6 возникло, но потом решил что скорее всего ошибаюсь.

wseventeen

Цитата:

Последний раз пробовал сравнивать с gcc пару лет назад.
Тогда gcc почти всегда отставал на несколько процентов.
Он стал сильно лучше или vc набрал вес?

Что стало лучше, что хуже - этого я не знаю. Но вот конкретные данные, замена в редакторе с регулярками по всему файлу changelog:
Искать: .
Заменить на: $0-$0

Билд 4692 ночная сборка: 4320 msec
Билд 4692 GCC 5.3: 2780 msec

shmuz2
Да gcc существенно быстрее.
Хотя у меня разница меньше: vc=1877, gcc=1448

shmuz2

Цитата:

Билд 4692 ночная сборка: 4320 msec
Билд 4692 GCC 5.3: 2780 msec

Правильно ли я понимаю, что указанная Вами 4692 GCC — это сборка от VictorVG4?

А то я попробовал сегодня на 1,8-миллионной базе поработать макросом Filter Duplicates FileName in Editor версии 1.2.1 от Alexyz21 на ночной сборке 4692 и на сборке 4692 от VictorVG4, и результаты получались одинаковые. А мне бы, конечно, хотелось бы воспользоваться вышеуказанным перевесом в скорости.