463 posts
Location
Star Wars
Posted 07 April 2016 - 01:22 PM
I found some path prefixes, when I browsed throw the bios of CC:
'/'
'.:'
':'
What they do and are there more path prefixes? =)
Edited on 07 April 2016 - 11:24 AM
2427 posts
Location
UK
Posted 07 April 2016 - 01:40 PM
From bash:
I know / is root, I don't know what the others are.
I know that .. is the parent directory but you are showing .:
Additionally . is the current directory but again you're asking about :
Note sure if these could be the same from bash.
1080 posts
Location
In the Matrix
Posted 07 April 2016 - 01:53 PM
Lupus you're right, .: and : don't show up in that context for files. . and .. show up in the bios for fs.complete. Lines 705 and 707.
1426 posts
Location
Does anyone put something serious here?
Posted 07 April 2016 - 02:01 PM
":" is the separator for the shell path. For instance "rom/programs:rom/programs/advanced" would look in "rom/programs" and then "rom/programs/advanced" to find the program. ".:rom/programs" would first look in the current directory (".") and then in "rom/programs" if it cannot be found.
Edited on 07 April 2016 - 12:02 PM
1080 posts
Location
In the Matrix
Posted 07 April 2016 - 02:07 PM
So what you're saying is that
: is a sort of "If I don't find it here, check here as well" kind of operator? Is it possible to nest it in such a way like ternary?
"." .. ":.." .. ":../.."
Check current, then up one, then up two?
Edited on 07 April 2016 - 12:07 PM
1426 posts
Location
Does anyone put something serious here?
Posted 07 April 2016 - 02:11 PM
So what you're saying is that : is a sort of "If I don't find it here, check here as well" kind of operator? Is it possible to nest it in such a way like ternary?
It isn't an "operator" as such, the shell program splits the path on the character ":" and tries each one in turn.
"." .. ":.." .. ":../.."
Check current, then up one, then up two?
I'd guess that would work. You'd have to try.
Edited on 07 April 2016 - 12:11 PM
463 posts
Location
Star Wars
Posted 07 April 2016 - 06:57 PM
thaks
463 posts
Location
Star Wars
Posted 07 April 2016 - 07:11 PM
I tested it in the interactive lua, because in my program it doesn't worked:
lua> dofile('./shell')
lua:1: File not found
I wonder, because '.' is the current directory and the current directory of lua is rom/programs, isn't?
Edited on 07 April 2016 - 05:12 PM
1426 posts
Location
Does anyone put something serious here?
Posted 07 April 2016 - 07:14 PM
dofile does not use these prefixes, only the shell program. Were you to do dofile(shell.resolve("./shell")) it will work (though the ./ is implicit here).
463 posts
Location
Star Wars
Posted 07 April 2016 - 07:27 PM
*headbang*
Fun fact:
dofile does not use these prefixes, only the shell program. Were you to do dofile(shell.resolve("./shell")) it will work (though the ./ is implicit here).
doesn't works from the running path.
fs.getDir(shell.getRunningProgram()) works
Edited on 07 April 2016 - 05:28 PM
7083 posts
Location
Tasmania (AU)
Posted 07 April 2016 - 07:39 PM
the current directory of lua is rom/programs, isn't?
The current directory of the Lua console is whatever directory you started it from, not the directory it's stored in (that is to say, it's
the shell's working directory), assuming you don't later
set it to something else.
dofile() always uses an absolute path and doesn't care about the working directory (most path-based commands in ComputerCraft behave this way). If you use shell.resolve() then the working directory will be included in the returned path.
Truth be told, ComputerCraft doesn't handle the other fancy relative paths correctly - . stands for the current directory, .. stands for the parent, and it gets that right. But …, …., …….., etc should all
also point to the current directory, and last I checked they've never been properly accounted for - you can actually crash shell with "cd …….." as a result of this.