8 replies to this topic

[theoriginalbit]

I'm having issues iterating the current file system trying to resolve a program path based on the programs name. its to update my API and make it more compatible and easier to use. Here's what I got so far:

local function searchFolder(list, progName, startPath, debug)
for _, v in pairs(list) do
path = (startPath == "/") and startPath..v or startPath.."/"..v
print(path)
if v == progName and not fs.isDir(path) then
if debug then print("File path found.") end
return path
elseif fs.isDir(path) then
return searchFolder(fs.list(path), progName, path, debug)
end
end

return "Not Found"
end

local function resolveProgramPath(progName, startPath, debug)
return searchFolder(fs.list(startPath), progName, startPath, debug)
end

progPath = resolveProgramPath(progName, "/", debug)
print("The programs path is "..progPath)

it seems to always print out "Not Found" even thought previously it printed "File path found"... it seems its not returning down the stack properly and I cant see why, I figure fresh eyes will help

[CoolisTheName007]

If i read correctly, given folders A,B.C, files a,b in the same path, searching for c would check only one folder of A,B,C; i suggest making searchFolder return nil in case of not success and changing return search... to local found=search.... if found return found end
EDIT: you may want to use my search API, or not; it's awfully efficient but the code is ugly.

[theoriginalbit]

it is recessive, so it should search all subfolders.

CoolisTheName007, on 16 December 2012 - 04:24 PM, said:

i suggest making searchFolder return nil in case of not success

yeh its normally nil, but it was throwing an error that will be fix when not in a testing capacity so i just changed it to return a string

CoolisTheName007, on 16 December 2012 - 04:24 PM, said:

and changing return search... to local found=search.... if found return found end

what? o.O

CoolisTheName007, on 16 December 2012 - 04:24 PM, said:

EDIT: you may want to use my search API, or not; it's awfully efficient but the code is ugly.

Ok.... only if you use my version/update API once I got this bug fixed jks.

so with your search api can I search for say "adventure" and it return "/rom/programs/adventure" ??

[Lyqyd]

Does shell.resolveProgram() not do what you're looking for? I'd think that other behavior than requires-absolute-path or uses-shell.resolve/shell.resolveProgram would be undesirable, as it could be highly unexpected.

[theoriginalbit]

Lyqyd, on 16 December 2012 - 04:46 PM, said:

Does shell.resolveProgram() not do what you're looking for? I'd think that other behavior than requires-absolute-path or uses-shell.resolve/shell.resolveProgram would be undesirable, as it could be highly unexpected.

no shell.resolveProgram() does not return anything when i parse in the program name and the program is in a subfolder

[theoriginalbit]

ok I'll define what I'm doing a little more.

currently my version api requires the calling program to parse shell.getRunningProgram() as a parameter so that when the update has been downloaded the file can be overridden. however they also parse the name of the program, so i thought to make it 'easier' to have the version api get the absolute path of the calling program from the name.

Am I just better to leave it as is?

If you want to see the source, follow the API link in my signature.

[CoolisTheName007]

Argh.. y long explanation diidn't get posted!No way I'm re-writing it now.
Anyways, just updated the search api; change the init.lua file to whatever name/extension you want and load it as an API. The code is commented and there's an test file (it's adapted to use loadreq, so it won't work unless you have loadreq, but you still can read it).

[Lyqyd]

TheOriginalBIT, on 16 December 2012 - 05:01 PM, said:

ok I'll define what I'm doing a little more.

currently my version api requires the calling program to parse shell.getRunningProgram() as a parameter so that when the update has been downloaded the file can be overridden. however they also parse the name of the program, so i thought to make it 'easier' to have the version api get the absolute path of the calling program from the name.

Am I just better to leave it as is?

If you want to see the source, follow the API link in my signature.

Better to just leave it as-is. Given two different files in two different locations with the same file name, it is possible that you would find the wrong one. When the calling program passes its own location, you know exactly where it is. It isn't as if adding shell.getRunningProgram() as a parameter is terribly difficult.

[theoriginalbit]

Lyqyd, on 17 December 2012 - 07:06 AM, said:

TheOriginalBIT, on 16 December 2012 - 05:01 PM, said:

ok I'll define what I'm doing a little more.

currently my version api requires the calling program to parse shell.getRunningProgram() as a parameter so that when the update has been downloaded the file can be overridden. however they also parse the name of the program, so i thought to make it 'easier' to have the version api get the absolute path of the calling program from the name.

Am I just better to leave it as is?

If you want to see the source, follow the API link in my signature.

Better to just leave it as-is. Given two different files in two different locations with the same file name, it is possible that you would find the wrong one. When the calling program passes its own location, you know exactly where it is. It isn't as if adding shell.getRunningProgram() as a parameter is terribly difficult.

yeh i know, it isn't, but i was trying to make interfacing with the API as 'idiot proof' as possible and have less parameters parsed.