Well, more accurately, “where on the filesystem is the source for the currently scoped routine?”, but that’s not a catchy title. In IDL 8.2.2, the ROUTINE_FILEPATH function was modified to return this information when called without any parameters. Here’s a simple program demonstrating this behavior:
pro routine_filepath_no_params compile_opt idl2 print, 'I''m called from a program in the file: ' + routine_filepath() end
When I run this program, I get:
IDL> routine_filepath_no_params
I'm called from a program in the file: /home/mpiper/VIS/IDL/8/22/demos/src/routine_filepath_no_params.pro
Jim Pendleton, for example, has found this helpful in determining whether a program is being run from a SAVE file or a PRO file. I’ve used it to save a visualization to a PNG file with the same base name as the PRO file in which it’s generated.
(This is, I think, my last 8.2.2 post before 8.2.3 comes out next week!)
The IDL Data Point 
The most useful case for me is finding resource files (icons, template files, custom color tables, shapefiles, etc.) that accompany your program.
Anyone who’s using my old code contrib SOURCEPATH or SOURCEROOT function should switch to this new syntax.
I agree with Mike. This is very useful for bootstrapping when your app’s installed resource files are situated in directories that are relative to the source (or .sav). There should never be a need to force end users to install your application into a specific directory due to IDL constraints.
To maximize cross-platform code, the FILEPATH function is also your friend in this situation. Use syntax such as