How to derive the script's own directory path?

[Gan Uesli Starling]

Wanting to get a return of the file path (or string of same) where the running VI is currently in.

I can do this in Perl easily. If I wrote a Perl script named "Where_am_I.pl", having only three lines like so...

use File::Basename;

print dirname(__FILE__) . "\n";

sleep 5;

...and called it via MSDOS from the C: drive, like so...

C:\>perl -e U:\foo\bar\Where_am_I.pl

U:/foo/bar

C:\>

...I'd get the dir where the script resides rather than the current dir from which I called it.

I've tried a bunch of ways to do that in LabVIEW, but all I ever get is the CWD, not the script's own directory. How may I get the script's own directory, please?

Why I want this: I want my VI to read and write *.INI files from and to it's own directory...no matter where that directory is...and no matter where or how it was originally called. Likewise I have Perl scripts in said directory. I want to also burn an *.exe from said VI which will be in a portable directory I can plunk down anywhere.

[asbo]

A combination of two primitives does exactly what you're looking for.

[crossrulz]

or if you have an executable, use a property node.

[Gan Uesli Starling]

or if you have an executable, use a property node.

If I am writing a VI now from which I'll burn an Application later, will the first example work in the VI and not the App while the second example works in the App but not the VI?

I'm a bit confused on the distinction. Enlightenment please?

[Mark Smith]

The first (from asbo) will work in either the dev environment or a built exe - it will just give different results. In the dev env, the return path might be something like \myFolder\mySubFolder (for a VI at \myFolder\mySubFolder\myVI.vi) and in the built exe it would return \myFolder\mySubFolder\myVI.vi (for an app at \myFolder\mySubFolder\myEXE.exe that contains myVI.vi - the current VI's path in the exe is \myFolder\mySubFolder\myVI.vi\myEXE.exe)- the VI is contained in the exe. The second (from crossrulz) would return the LabVIEW.exe directory in the dev environment and your exe's directory from the built app. So, a common practice is to use the Application.Kind property to see which environment you're running in (run time or development) and you can handle it from there.

Mark

[Shaun Hayward]

If your using LabVIEW 2009 there is another useful tool to throw in the mix:

This little guy, found in the File IO:File Constants palette will do one of two things:

1. In development environment it will return the folder containing your Project (*.lvproj) file

2. In a built application is will return the folder containing your application's EXE

[vugie]

If I am writing a VI now from which I'll burn an Application later, will the first example work in the VI and not the App while the second example works in the App but not the VI?

I'm a bit confused on the distinction. Enlightenment please?

There is an OpenG VI "Current VIs Parent Directory" which abstracts from running environment. It uses same method as asbo showed, but strips the path until it becomes valid directory name. Optionally it adds some relative path. Veeeery useful.

BTW, Jim, what happened to your "OpenG VIs I couldn't live without" series?

[Yair]

There is an OpenG VI "Current VIs Parent Directory" which abstracts from running environment. It uses same method as asbo showed, but strips the path until it becomes valid directory name. Optionally it adds some relative path.

Note that this actually breaks in 2009 EXEs, because of the new EXE-as-ZIP scheme - the folders which are inside the EXE are recognized as actual folders and so the stripping stops while still inside the EXE. The function Shaun pointed to works around this.

[vugie]

Note that this actually breaks in 2009 EXEs, because of the new EXE-as-ZIP scheme - the folders which are inside the EXE are recognized as actual folders and so the stripping stops while still inside the EXE. The function Shaun pointed to works around this.

Except for situation when VI was dynamically called from outside the EXE... A lot of things to check to have general way. Looks like OpenG package needs to be updated...

[Gan Uesli Starling]

If your using LabVIEW 2009 there is another useful tool to throw in the mix:

This little guy, found in the File IO:File Constants palette will do one of two things:

1. In development environment it will return the folder containing your Project (*.lvproj) file

2. In a built application is will return the folder containing your application's EXE

I am using 2009, thank you. This one works just fine in the development environment. So I'll stick with it and hold the other ideas in reserve. My thanks to everyone for their input. All replies have brought me a measure of enlightenment. Thank's again.