Получение пути lisp в момент запуска

В том-то и дело, что на момент запуска лиспа (findfile "prog.lsp") возвращает nil - файл гарантированно не лежит в путях доступа.

> ShaggyDoc
Нет, нашел другой вариант. (dos_search <ИмяЛиспа>) возвращает полный путь (DOSLib 6.1.5). А по указанному пути (который кстати тоже еще надо ухитриться получить: для разных версий все, что после слова AutoCAD, отличается, да еще надо и про ADT не забывать, к примеру) хранится вообще непонятно что. В ключе history вообще пусто (по крайней мере, на моей конкретной машине)

> Александр Ривилис
Я не такой "крутой" в программировании, но, извините, ПОЧЕМУ два LISP-файла под одним именем.
Слейете их в один MY_FUNCTION.LSP для вашего проекта и не будет головной боли,
как анекдоте...
Если он интересует, могу рассказать (написать)...

> Александр Ривилис
http://www.maestrogroup.com.ua/support/getlispinfo.zip
Это ARX... Ни описания, ни смысла программы...
Вы быстрее нарветесь на... "Вот если совпадают имена функций в этих файлах, то действительно можно нарваться на неприятности".
Смысла НЕ ВИЖУ в загружаемых Lisp-файлах с одинаковым именем.
ВЫ меня пока не убедили...

Описание единственной функции, которую этот arx-файл экспортирует, в предыдущем моем посте. И это не для Вас, а для kpblc. Он поймет что это и зачем.

А я и не собирался никого и ни в чем убеждать.

Вот поэтому я и не сторонник пихать кучу функций в один файл и не сторонник автозагрузки всех файлов из пользовательской папки. Поэтому я и предлагаю всегда структурно один и тот же макрос для запуска программ:

^C^C^P(if (not C:ФУНКЦИЯ) (load "lisp_файл")) ФУНКЦИЯ

Пусть у меня будет в своей папке 200 файлов, зато я всегда знаю, что откуда загружается и как запускается. И именно поэтому все заумные варианты автозагрузки, предложенные здесь:
https://www.caduser.ru/forum/topic19699.html
не вызывают у меня энтузиазма. Слишком много "Авто"...

Совсем в сторону ушли. У kpblc был вопрос, на который только LISP не может дать ответ. Это легко решается на ObjectARX, что и продемонстрировал Александр Ривилис. Блестяще.
Я не знаю, зачем kpblc понадобилось определять имя файла. Наверное надо. Гораздо интереснее было бы определить, из какого файла загружена функция с известным именем.  Наверное это невозможно.
Само по себе имя файла еще дает мало информации. В одном файле может быть много именованных функций (а может и ни одной не быть). Может в файле быть и одна функция или "команда", но ее имя не обязательно должно совпадать с именем файла. Это зависит от того, как организована система работы. Но ее может вообще не быть (все свое и чужое барахло кидаем в Support).
Каждый волен организовывать работу, как нравится. Желательно при этом учитывать и опыт. Например, вроде бы очевидное

^C^C^P(if (not C:ФУНКЦИЯ) (load "lisp_файл")) ФУНКЦИЯ

обязательно требует, чтобы "lisp-файл" находился на путях поиска. А это совсем не хорошо. Для начала сойдет, для серьезной работы - нет.
"Свои" файлы мы всегда знаем (если есть хоть какой-то порядок в доме), и незачем их искать. А вот чужие могут представлять интерес, особенно что же у них внутри. Там ведь может быть функция намеренно сделанная одноименной с нашей. Чувствуете, какие перспективы у такого поиска?

Спасибо всем откликнувшимся.
Да, задача действительно, во-первых, до конца не описана, а во-вторых, не является универсальной, т.е. нужна лично мне для конкретной ситуации. Прошу прощения, что невольно заставил всех мучаться и догадываться "что же этой заразе требуется" :).

> Александр Ривилис
Дело в том, что у меня нет 2 файлов с одинаковыми именами. В принципе. Имя файла = имени функции, которая в нем описана, и без вариантов. Это закон, который я для себя принял и придерживаюсь примерно как закона тяготения. Мои пользователи самостоятельно грузить лиспы вряд ли будут, им это "ехало-болело", а для меня критично.

> Александр Ривилис
Пока нет, только-только скачал, еще не смотрел. Попросту не успел. Все равно огромадное спасибо. Надеюсь, я могу если что обращаться в почту?

> ShaggyDoc
Мне это надо для самопрописывания программы в момент первого запуска. 30 с гаком пользователей, и для каждого руками прописывать пути поддержки, элементы реестра, да еще и заданные жестко - не, я пас. Если завтра по указанию сверху будет переименован сервак, на котором лежат лиспы и прочая лабудень общего доступа, и что? Предприятие если встанет на сутки, меня съедят. А жить иногда хочется непрожеванным :) Такими задачами занимаюсь я один, так что правила установленные однажды выдерживаются постоянно.

> kpblc
Есть секция APPID, есть "расширенные данные",(не знаю, можно ли их задействовать в APPID), есть "словари", в них точно можно отсебятину впихивать. Все это сохраняется в DWG. При "первом запуске" прописываете пути, связь функции с файлом, ключи реестра, и ещё пожелания пользователю... Это можно и без ARX...