Murga-Projects Forums

Full Version: Function to return the current directory
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
This is what I'm trying to do:
launch murgaLua,
discover the folders and files in the same directory
return their paths after selecting their file/folder names from menus.

I can fill them menus and return the file names fine..but their long path??
ie, "/volumes/hard drive/somefolder/etc/etc/etc/thefile.lua"

How to return that based on where murgaLua is currently running from?
I have had the same desire, and so far have not found a reasonable solution. For an application that would be targeted to Linux systems, I have wrapped up the lua script inside a shell script, having the shell commands check the directory and then send it to murgaLua as a variable or commandline parameter, but it's not very portable. Even that requires some extra work, since you also have to check whether the file is actually the script or just a link to the script.

EDIT: There must be something within Lua that can be used for this purpose. It already is aware of where the script is, considering it uses relative paths for dofile(), so I guess the question must be where does it store that info?
Here's one possible solution. It works in Unix systems, but I think a forward slash will not translate to Windows. The gsub function will probably need to be modified or replaced for something more universal, but the main point is that arg[0] stores the full path to the script.


Again, this is probably not the cleanest or most useable code, but it might work...

function dirname(f)
if not f then f=arg[0] end
local s
if murgaLua.getHostOsName() == "windows" then s="\\" else s="/" end
local dirname=string.gsub(f,"(.*"..s..").*","%1")

The function was designed so that it would work on the current script if no arguments are given, and can also be used on other files similar to the dirname command in linux (except this one keeps the trailing slash)

Soooo.....does it work?
Anyone have any feedback on whether (and how) it can be made better, more efficient/portable?
The dirname variable on my local copy has been changed to 'd' to avoid confusion with the function name, but apart from that I'm not sure how to improve it. Also still not sure if it works on Windows or Mac.

The gsub grabs everything up to and including the last slash or backslash in the filename. I assume that's pretty much the same thing that the dirname command does, since both appear to simply work on a given string rather than check whether or not it's actually an existing file or directory. The fl_filename_ext() function seems to work the same way.
In my experiments I didn't get the result I was looking for.
I don't think I'm passing scripts the way you are.
What do your results look like?

For what I was looking to do I should be able to export the current application path to  a variable and retrieve it from the system via the running murgaLua.

I'll share the results soon although they are for OS X.

Did I read John has plans for compiling scripts into executable murgaLua apps?
As I said I don't have any idea if it works on Windows or Mac, but it *should* do the same on Linux and MacOS...grab everything from the beginning of a string to the final slash (i haven't thought to test with a filename without a slash...i'll need to do that next).

my_dir=dirname() --for the dirname of the current script
my_other_dir=dirname(some_other_file) -- for the dirname of an external file

If your script is /usr/local/bin/my_script.lua, the first example should return "/usr/local/bin/"
You could also use my_dir=dirname(arg[0]) for the first example, but that's redundant.

Did I read John has plans for compiling scripts into executable murgaLua apps?

I think you might already have that ability with Lua proper, but I'm not sure if non-Lua stuff would be supported. As far as I can tell, it looks like something John put on his List Of Things To Explore.

Ok I was initially getting a blank when checking dirname at the start of a script, once the script was running it returned the path of the script, but ideally whats needed is the path to the murgaLua executable.

What I have is an application bundle that launches murgaLua, special thanks to Marielle for going through the Xcode tutorial and developing it. Here's what it looks like at the desktop, a peek inside the package, and running.

The 'main.scpt' is an Applescript that originally simply launched murgaLua and a file called script.lua. I keep this script seperate from Lua scripts as it truly belongs to the Applescript executable "applet" and not to murgaLua.

In the script I added a step to write the current application path to a file which
murgaLua will load and set a global variable "bundleroot"
You can see the Applescript here

It generates file bundleroot.lua:


start.lua at its most basic:

if bundleroot==nil then os.exit() end

Console.lua loads the directory contents of Data/Scripts/ into a menu
and the callback of that menu feeds the whole path of the chosen
script to a dofile command.  The console script also re-directs all print
commands into the console output so I don't have to find another app to
see what is happening.

iGame3D has an engine level method of finding the path to itself:

bundleroot=getSceneInfo(IG3D_ROOT) --  retrieves application path

--- by default I script in this variable immediately after:

--bundleroot doesn't get changed , gameroot can be set by the user:


Now I have somewhat the same functionality in a standalone murgaLua solution
and a fairly snappy murgaLua script launching mechanism.

Now to figure out dynamic submenus and clean up that scripts folder.

The dirname function is not as reliable as I had hoped. It worked fine with my preliminary test, but when testing a few possible variations (such as running the script in the current directory) it failed quickly. I want to make it work dependably for my own uses as well, so it'll be something I'll look into further sometime in the next few days. Might just need a little tweaking, or might need to be rewitten.

Dynamic submenus look terribly complicated. I was looking at the menu stuff in Erco's FLTK cheat page last night, and nothing was making much sense to me =op

EDIT: it seems that the function was doing what it should; my problems were coming from trying to use the result in a way it's not intended...namely, trying to dofile() with a filename path other than ./
I assume there's a way to modify the dofile/require search path, but i haven't looked into it yet.

EDIT2: Of course I assumed incorrectly again. The error was caused by the script that was being loaded with dofile(). Since it required files found in a subdirectory, I needed to pass the base directory on to it. Seems to work again.

On the subject of dynamic menus, it seems to be a little bit easier than I thought, assuming you keep track of the number which represents each menu item. I'm thinking there must be a way to utilize the item's label, but haven't experimented with that yet (maybe the menu is a table?).
The Fl_Menu_Item documentation contains a list of constants that apply to various flags, which can be modified with Fl_Menu:mode(item_number,flag). Zero is not listed, but it refers to the active state of an item. It seems you can use other Fl_Menu methods to remove, rename, and replace items, but that's something else I haven't looked into yet.
An update on the dynamic menus.
You can use Fl_Menu_Bar:find_item(my_menu_item_string) to get a pointer to a specific menu item, which is much more pleasant than trying to determine the index of a particular menu item.
I still have no idea how to use Fl_Menu_Item, but this seems to work with menu items created with my_menu:add(my_menu_item_string).


Now you can disable the "save" item when it's not needed:


This can also be used to perform (most?) other actions that can be applied to the Fl_Menu_ class, such as replacing/renaming items. The only things i've tested so far is changing font properties and item labels.

I got an opportunity to see murgaLua work on a Windows XP machine, and the function works there.

Windows has some other dumb issues, though, like no preset "HOME" environment variable and no toleration for dotfiles, which pose an unnecessary problem for several of my scripts.
Pages: 1 2 3
Reference URL's