Path Lisp File Loaded

how to know the directory where the file was loaded Lisp?

Ok.

If the lisp loads and runs and does not remain in memory for further use need real smarts, if loaded and ready to use simple APPLOAD HISTORY

That is a useful observation; I wasn't aware that now in that list appear also routines loaded in other ways then APPLOAD/Startup suite. Thank you!

It will be interesting to find if the content of said list can be parsed programmatically.

I know a lot of people think this is lacking in AutoLisp. Especially C programmers who are used to argument[0] containing the full path name of the EXE file. But due to how AutoLisp works it doesn't actually make sense that a file is the app (in most cases), the file simply contains the app and is loaded into RAM then interpreted from there.

As for the AppLoad's list: unfortunately that only shows the loaded files. The history tab only shows those loaded through AppLoad, at least this you can get to through the registry. But the loaded list does not appear to be accesible (from lisp at least). I wonder if the AppLoad.ARX exposes some function which can be called to return the list of loaded apps to another ARX/DotNet then passed to lisp from there. Though still that would only solve half the problem: the rest (which is much harder) would be to figure out which of the files in that list is the source of the currently executing defun.

Anyhow, here's a long thread about this: http://www.cadtutor.net/forum/showthread.php?58650-Ask-the-name-of-running-program

IMO, if you need to know the LSP file's folder programatically, then you need to look at some other way to make this simpler. E.g. setting the support paths, or using CUI files as per my post in the above thread.

Consider the case in which a LISP function is 'loaded' (defined) by entering the code directly at the AutoCAD command-line, or VLIDE console...

I'm mostly in agreement with Irneb on this topic, the LISP file is not an application, but simply houses the AutoLISP code; a single LISP file may contain many applications, and conversely, applications do not necessarily require a LISP file in order to be 'loaded'.

I use the term 'loaded' loosely, since, by loading a LISP file, the load function is simply reading the text file and evaluating any AutoLISP code it finds therein, usually resulting in a number of functions being defined upon their defun expressions being evaluated by the interpreter.