I'm trying to require files in Lua, in one case it is working, but when I want to simplify the requirements in updating the LUA PATH the file is not found, but it is in the trace!
To reproduce my require problem I did the test with the package.searchpath function, which takes the required key and the Lua path in arguments.
So the code :
print('MY LUA PATH')
local myLuaPath = "?;?.lua;D:\\Projets\\wow-addon\\HeyThere\\?;D:\\Projets\\wow-addon\\HeyThere\\src\\HeyThere\\?;D:\\Projets\\wow-addon\\HeyThere\\test\\HeyThere\\?"
print(myLuaPath)
print('package search core.add-test')
print(package.searchpath('core.add-test', myLuaPath))
print('package search test.HeyThere.core.add-test')
print(package.searchpath('test.HeyThere.core.add-test', myLuaPath))
The result :
MY LUA PATH
?;?.lua;D:\Projets\wow-addon\HeyThere\?;D:\Projets\wow-addon\HeyThere\src\HeyThere\?;D:\Projets\wow-addon\HeyThere\test\HeyThere\?
package search core.add-test
nil no file 'core\add-test'
no file 'core\add-test.lua'
no file 'D:\Projets\wow-addon\HeyThere\core\add-test'
no file 'D:\Projets\wow-addon\HeyThere\src\HeyThere\core\add-test'
no file 'D:\Projets\wow-addon\HeyThere\test\HeyThere\core\add-test'
package search test.HeyThere.core.add-test
test\HeyThere\core\add-test.lua
So the first try with 'core.add-test' should work with the 'D:\Projets\wow-addon\HeyThere\test\HeyThere\?' value in the path but fails...
In the trace, there is the file I want!
no file 'D:\Projets\wow-addon\HeyThere\test\HeyThere\core\add-test'
But with the same LUA PATH but starting in a parent folder the file is found... Second test with 'test.HeyThere.core.add-test' found from the 'D:\Projets\wow-addon\HeyThere\?'
-> test\HeyThere\core\add-test.lua
Can someone explains to me why it doesn't work the first time?
EDIT :
My current directory is D:\Projets\wow-addon\HeyThere
My lua.exe is in D:\Projets\wow-addon\HeyThere\bin\lua but is added to my PATH variable (I'm on Windows)
I set the LUA_PATH environment variable and execute
lua "test\test-suite.lua" -v
The code inside test-suite.lua is the test code described above
As #EgorSkriptunoff suggested, adding file extansion in the path resolve the problem...
Ex:
Wrong path D:\Projets\wow-addon\HeyThere\?
Good path D:\Projets\wow-addon\HeyThere\?.lua
The extension should be in the path variable because in the require the dot is replace and used as a folder separator.
I have my doxygen in my /utils directory, and my source is in another directory in the root(/code_with_doxygen), how could i make a relative path name for that since it's in a repository that will be on different places on other computers. I can't document the whole root because i don't want the directory /code_without_doxygen build too.
the project tree looks like this:
root
utils
code
code_with_doxygen
code_without_doxygen
documentation
right now i have the settings, but that doesn't seem to work:
FULL_PATH_NAMES = YES
STRIP_FROM_PATH = ../
i can't seem to figure it out with: Relative files paths in doxygen-generated documentation
The relative paths depend on the directory from which directory you are executing doxygen. For example if you have the following project tree:
+ project_root
+ documentation
+ config
- doxyfile
+ pictures
+ output
- run_doxygen.bat
+ code
+ code_with_doxygen
+ code_without_doxygen
In this case all relative paths have they root in the folder "documentation" because you are running the script "run_doxygen.bat" from this folder. So you would set the INPUT tag in the "doxyfile" to
INPUT = ./../code
and the OUTPUT_DIRECTORY tag in the doxyfile to
OUTPUT_DIRECTORY = ./output
The misleading thing is that even if the doxyfile is in the subfolder "config" the paths are NOT relative to the location of the doxyfile because the paths are relative to the location from where doxygen is called. In this case it is the folder "documentation" because this is the location of the script which is calling doxygen.
Doxygen allows for including files into doxyfile. You can generate a file using a script before actually calling doxygen. The content of this file has to look like this:
INPUT += path1
INPUT += path2
...
You seem to to run Linux, I don't know the correct bash-commands.
The file has to be integrated into your doxyfile:
INPUT = (project path)
#INCLUDE = generated filename
This will lead to doxygen using the content of your generated file.
#gmug was right. Don't forget to add comment blocks in your code as specified by doxygen For python I needed to add this: """#package docstring""" at the beginning of the file.
I have been able to use relative paths in my doxygen.cfg file by setting INPUT to a string or set of strings. For example:
INPUT = "." "src"
will tell doxygen to look in both the current directory and its subdirectory, $HERE/src.
Let's say I have x.y file in /mydir/a/b (on Linux)
When I run waf, it does not find the file.
def configure(context):
pass
def build(build_context):
build_context(source='/mydir/a/b/x.y',
rule='echo ${SRC} > ${TGT}',
target='test.out')
Result: source not found: '/mydir/a/b/x.y' in bld(features=[], idx=1, meths=['process_rule', 'process_source'] ...
Ok, maybe you want a relative path, Waf? And you are not telling me?
def build(context):
path_str = '/mydir/a/b'
xy_node = context.path.find_dir(path_str)
if xy_node is None:
exit ("Error: Failed to find path {}".format(path_str))
# just refer to the current script
orig_path = context.path.find_resource('wscript')
rel_path = xy_node.path_from(orig_path)
print "Relative path: ", rel_path
Result: Error: Failed to find path /mydir/a/b
But that directory exists! What's up with that?
And, by the way, the relative path for some subdirectory (which it can find) is one off. e.g. a/b under current directory results in relative path "../a/b". I'd expect "a/b"
In general there are (at least) two node objects in each context:
- path: is pointing to the location of the wscript
- root: is pointing to the filesystem root
So in you case the solution is to use context.root:
def build(context):
print context.path.abspath()
print context.root.abspath()
print context.root.find_dir('/mydir/a/b')
Hmm, looks like I found an answer on the waf-users group forum, answered by Mr. Nagy himself:
The source files must be present under the top-level directory. You
may either:
create a symlink to the source directory
copy the external source files into the build directory (which may cause problem if there is a structure of folders to copy)
set top to a common folder such as '/' (may require superuse permissions, so it is a bad idea in general)
The recommendation in conclusion is to add a symlink to the outside directory during the configuration step. I wonder how that would work, if I need this on both, Linux and Windows...
Just pass the Node to the copy rule instead of passing the string representing the path:
def build(build_context):
source_node = build_context.root.find_node('/mydir/a/b/x.y')
build_context(source=source_node,
rule='echo ${SRC} > ${TGT}',
target='test.out')
Waf will be able to find the file even if outside of the top level directory.
I need a way to get the path of the running script (the directory that contains the source file), but
(current-directory)
never points there (in this case an external drive), but rather to some predefined location.
I created a file to try all the 'find-system-path's, but none of them are the running file! The Racket docs are not helping.
#lang web-server/insta
(define (start request)
(local [{define (build-ul items)
`(ul ,#(map itemize items))}
{define (itemize item)
`(li ,(some-system-path->string (find-system-path item)))}]
(response/xexpr
`(html
(head (title "Directories"))
(body (h1 ,"Some Paths")
(p ,(build-ul special-paths)))))))
(define special-paths (list 'home-dir
'pref-dir
'pref-file
'temp-dir
'init-dir
'init-file
;'links-file ; not available for Linux
'addon-dir
'doc-dir
'desk-dir
'sys-dir
'exec-file
'run-file
'collects-dir
'orig-dir))
The purpose is for a local web-server application (music server) that will modify sub-directories under the directory that contains the source file. I will be carrying the app on a USB stick, so it needs to be able to locate its own directory as I carry it between machines and operating systems with Racket installed.
Easy way: take the running script name, make it into a complete path,then take its directory:
(path-only (path->complete-path (find-system-path 'run-file)))
But you're more likely interested not in the file that was used to execute things (the web server), but in the actual source file that you're putting your code in. Ie, you want some resources to be close to your source. An older way of doing this is:
(require mzlib/etc)
(this-expression-source-directory)
A better way of doing this is to use `runtime-path', which is a way to define such resources:
(require racket/runtime-path)
(define-runtime-path my-picture "pic.png")
This is better since it also registers the path as something that your script depends on -- so if you were to package your code as an installer, for example, Racket would know to package up that png file too.
And finally, you can use it to point at a whole directory:
(define-runtime-path HERE ".")
... (build-path HERE "pic.png") ...
If you want the absolute path, then I think this should do it:
(build-path (find-system-path 'orig-dir)
(find-system-path 'run-file))
I keep getting myself in knots when I am manipulating paths and file names because I don’t follow a naming standard for path components.
Consider the following toy problem (Windows example, but hopefully the answer should be platform independent). You have been given the path of a folder:
C:\Users\OddThinking\Documents\My Source\
You want to walk the folders underneath and compile all the .src files to .obj files.
At some point you are looking at the following path:
C:\Users\OddThinking\Documents\My Source\Widget\foo.src
How would you name the following path components?
A. foo
B. foo.src
C. src
D. .src
E. C:\Users\OddThinking\Documents\My Source\ (absolute path of the root)
F. Widget\foo.src (relative path of the file to absolute path of the root)
G. Widget\
H. C:\Users\OddThinking\Documents\My Source\Widget\
I. C:\Users\OddThinking\Documents\My Source\Widget\foo.src
Here is my attempt:
A. Base name? Basename?
B. File name? Filename? The difference is important when choosing identifier names, and I am never consistent here.
C. Extension?
D. Extension? Wait, that is what I called C. Should I avoid storing the dot, and just put it in when required? What if there is no dot on a particular file?
E. ?
F. ?
G. Folder? But isn’t this a Windows-specific term?
H. Path name? Pathname? Path?
I. File name? Wait, that is what I called C. Path name? Wait, that is what I called H.
I think your search for a "standard" naming convention will be in vain. Here are my proposals, based on existing, well-known programs:
A) C:\users\OddThinking\Documents\My Source\Widget\foo.src
---
Vim calls it file root (:help filename-modifiers)
B) C:\users\OddThinking\Documents\My Source\Widget\foo.src
-------
file name or base name
C) C:\users\OddThinking\Documents\My Source\Widget\foo.src
___ (without dot)
file/name extension
D) C:\users\OddThinking\Documents\My Source\Widget\foo.src
____ (with dot)
also file extension. Simply store without the dot, if there is no dot on a file, it has no extension
E) C:\users\OddThinking\Documents\My Source\Widget\foo.src
-----------------------------------------
top of the tree
No convention, git calls it base directory
F) C:\users\OddThinking\Documents\My Source\Widget\foo.src
--------------
path from top of the tree to the leaf
relative path
G) C:\users\OddThinking\Documents\My Source\Widget\foo.src
------
one node of the tree
no convention, maybe a simple directory
H) C:\users\OddThinking\Documents\My Source\Widget\foo.src
------------------------------------------------
dir name
I) C:\users\OddThinking\Documents\My Source\Widget\foo.src
-------------------------------------------------------
full/absolute path
Good question first of all, my +1. This thing bugged me when I had to create a slew of functions in Utility class once. GetFileName? or GetFullName? GetApplicationPath means full path or the directory name? and so on. I come from .NET background, so I think I can add little more to otherwise excellent answer by #blinry.
Summary: (In italics is what I would not use as a programmer)
Path: Path specifies a unique location in the file system (unless its relative path). Path name is less often used, but I would stick with path - it pretty much explains what it is. Path can point to a file or a folder or even nothing (C:\). Path can be:
Relative Path: My Source\Widget\ is relative path as well as Widget\foo.src. Self explanatory.
Absolute Path or Full Path: Is the fully qualified path that points to the target. I tend to use the latter more often. C:\users\OddThinking\Documents\My Source\Widget\foo.src is hence full path. See at the end what I call full path that points to a file and that ends as a directory.
The wiki page and .NET naming for path is consistent.
Root Path or Root Directory: Former is .NET convention while latter is more heard in UNIX circles. Though I like both I tend to use the former more. In windows, unlike UNIX, has many different root paths, one for each partition. Unix systems have one root directory which holds information on other directories and files. Eg. C:\ is root path.
Folder or Folder Name: Widget, OddThinking etc in your case. This might be a Windows only convention (in fact its my own odd thinking :)), nevertheless I strongly object to blinry`s answer "Directory". Though for a normal user directory means the same as a folder (like subfolders, subdirectories), I believe from a technical angle "directory" should sound like a qualified address to the target and not the target itself. More below.
Sub Folders: With respect to users OddThinking and Documents are sub folders.
Sub Directories: With respect to users OddThinking\, OddThinking\Documents\ and OddThinking\Documents\My Source\Widget\ are sub directories. But we do not often need to bother about it, do we?
Child Folder: With respect to users OddThinking is a child folder (as well as sub folder)
Parent Folder: For OddThinking users is its parent folder (Just mentioning different terminologies, no big deal).
Directory or Directory Name: The former to use generally in real life, the latter to be in code. This refers to the fully qualified path (or simply full path) till the target's parent folder. In your case, C:\users\OddThinking\Documents\My Source\Widget (Yes a directory is never meant to point to a file). I use directory name in my code since directory is a class in .NET and Directory Name is what the library itself calls it. Its quite consistent with dirname used in UNIX systems.
File Name or Basename: Name of the file along with extension. In your case: foo.src. I would say that for a non technical use I prefer file name (it is what it means for an end user) but for technical purposes I would strictly stick with basename. File Name is often used by MS, but I am surprised how they are not consistent not just in documentation but even in library. There filename could mean either basename or full path of the file. So I favour basename, that's what I call them in code. This page on wiki too says file name could mean either full path or the basename. Surprisingly even in .NET I can find the usage basename to mean the root name of the file.
Extension or Filename Extension or File Extension: I like the last one. All refers to the same thing but what is it is again a matter of debate! Wiki says it is src while back then I remember reading that many of the languages interprets it as .src. Note the dot. So once again my take is, for casual uses it doesn't matter what it is, but as a programmer I always see extension as .src.
Ok I might have tried to fetch some standard usages, but here are two of my conventions I follow. And it is about full paths.
I generally call a full path that point to a file as file path. To me file path is clear cut, it tells me what it is. Though with file name I find it as the name of the file, in my code I call it file name. It's also consistent with "directory name". From the technical side, name refers to the fully qualified name! Frustratingly .NET uses the term file name (so I have my case here) and sometimes file path for this.
I call a full path that ends as a directory a directory. In fact one can call any piece of address that doesn't point to a file a directory. So C:\users\OddThinking\Documents\My Source\ is a directory, C:\users\OddThinking\ is a directory, or even OddThinking\Documents\My Source\ (better to call it sub directory or even better relative path - all that depends on the context you are dealing with it). Well above I mentioned something different about directory which is directory name. Here is my take on it: I'll get a new path to avoid confusion. What is this D:\Fruit\Apple\Pip\? A directory. But if the question is what is the directory or even better directory name of D:\Fruit\Apple\Pip\, the answer is D:\Fruit\Apple\. Hope its clear.
I would say it's better not to worry about the final two terms as that is what create the most confusion (for me personally). Just use the term full path!
To answer you:
with respect to the path you have given
A) No idea. Anyways I never needed to get that one alone.
B) basename
C) I would just call it file extension for time being, I am least worried since I never needed that alone to be named in my code.
D) file extension surely.
E) I do not think this is a general purpose requirement. No idea. In .NET base directory is the same as directory name.
F) relative path
G) folder (parent folder to basename foo.src)
H) directory name
I) full path (or even file name)
in general (sorry for being a bit verbose, just to drive the point home) but assuming foo.src is indeed a file
A) NA
B) basename
C) NA
D) extension
E) directory or simply path
F) relative path
G) NA
H) directory or simply path
I) full path (or even file name)
Further driving with one example from my side:
Consider the path C:\Documents and Settings\All Users\Application Data\s.sql.
C:\Documents and Settings\All Users\Application Data\s.sql is the full path (which is a file name)
C:\Documents and Settings\All Users\Application Data\ is the directory name.
Now consider the path C:\Documents and Settings\All Users\Application Data
C:\Documents and Settings\All Users\Application Data is the full path (which happens to be a directory)
C:\Documents and Settings\All Users is the directory name.
Two tips of mine:
I follow this rule of thumb that when it comes to addressing a full address irrespective of its type, I almost always call it "full path". This not only eliminates the use of two terminologies for file path and folder path, it also avoids the potential confusion if you are going to name that of file as file name (which for most users right away translates to basename). But yes if you have to be specific about the type of path, its better to name then file name or directory instead of more generic "path".
Whatever it is you would have your own idea in mind, be consistent with it throughout. Have a consensus among team members that this means this and not that.
Now that just from the circle I have some practice. A new brand of terms would be what is used on OS X and android machines. And all these are just about physical paths in filesystem. A whole new set of terminologies would arise in case of web addresses. I expect someone to fill the void in this same thread :) I would be glad to hear the convention with which you have went ahead..
In C++, Boost.Filesystem has devised a nomenclature for the various parts of a path. See the path decomposition reference documentation for details, as well as this tutorial.
Here's a summary based on the tutorial. For:
Windows path: c:\foo\bar\baa.txt
Unix path: /foo/bar/baa.txt
you get:
Part Windows Posix
-------------- --------------- ---------------
Root name c: <empty>
Root directory \ /
Root path c:\ /
Relative path foo\bar\baa.txt foo/bar/baa.txt
Parent path c:\foo\bar /foo/bar
Filename baa.txt baa.txt
Stem baa baa
Extension .txt .txt
C++ standard ISO/IEC 14882:2017
Moreover Boost.Filesystem terminology has been adopted by C++17 => See std::filesystem
Function name Meaning
---------------- -------------------------------
root_name() Root-name of the path
root_directory() Root directory of the path
root_path() Root path of the path
relative_path() Path relative to the root path
parent_path() Path of the parent path
filename() Path without base directory (basename)
stem() Filename without extension
extension() Component after last dot
The Pathlib standard library in Python follows this naming convention for path components:
A. /x/y/z.tar.gz: stem.
B. /x/y/z.tar.gz: name.
C. /x/y/z.tar.gz (excluding dot): N/A.
D. /x/y/z.tar.gz (including dot): suffix.
E. /x/y/z.tar.gz: grand parent path.
F. /x/y/z.tar.gz: relative path to grand parent path.
G. /x/y/z.tar.gz: parent name.
H. /x/y/z.tar.gz: parent path.
I. /x/y/z.tar.gz: path.
No you're not crazy.
In Windows systems, sometimes the path of the directory containing the file is called path, which is how it was from the beginning. So, for example,
x:\dir1\dir2\myfile.txt
Windows:
--------
PATH: x:\dir1\dir2
FILE: myfile.txt
Unix/Linux:
-----------
PATH: /dir1/dir2/myfile.txt
FILE: myfile.txt
The Unix/Linux approach is a lot more logical, and that's what everyone mentioned above: path including the file name itself. However, if you type "call /?" in the Windows command line, you get this:
%~1 - expands %1 removing any surrounding quotes (")
%~f1 - expands %1 to a fully qualified path name
%~d1 - expands %1 to a drive letter only
%~p1 - expands %1 to a path only
%~n1 - expands %1 to a file name only
%~x1 - expands %1 to a file extension only
So there it is, "path only" and "file name only". At the same time, they refer to the whole string as "fully qualified path name" which is understood as drive letter plus path plus file name. So there's no real truth. It's futile. You've been betrayed.
Anyway,
To answer your question
This is how I'd name your examples:
A: -
B: basename
C: extension
D: -
E: -
F: -
G: -
H: pathname (or dirname or containing path)
I: full name
A-D-E-F have no simple nicknames. And since php is probably the most widely known cross-platform language, everyone understands "basename" and "dirname" so I'd stick with that naming. Full name is also obvious; full path would be a bit ambiguous but most of the time it means the very same thing.
After 10 years of hacking around my two pence is:
Be consistent
Think recursion
Example on a Windows machine:
File separator: \
Line separator:
Base name: file
Extension: txt
Filename: file.txt
Drive name: C
Root name: C: (empty on linux)
Root dir: \
Root path: C:\
Base dir: Source\
Base path: C:\Source\
Sub dir: project\
Sub-sub dir: docs\
Relative dir: project\docs\
Relative path: project\docs\file.txt
Working dir: C:\Source\project\docs\
Full path: C:\Source\project\docs\file.txt (also 'Absolute path' or 'File path')
Linux drive dir: C\
Linux root path: \C\
Linux base path: \C\Source\
Parent dir: ..\
Current dir: .\
The linux stuff near the bottom is how bash mounts the drive on Windows systems.
The current directory, or working "directory", is really wherever your program is, but let's use it to keep track of where the current file is we are working on. Type pwd into powershell and the result is called a path!
Directories always end with the file separator and never include the filename. They can easily be appended.
"Directory name" could refer to any directory in any position (dirName + sep = dir).
Paths include the root, the filename, or both.
That is, paths can be formed by adding either the root, filename, or both, to a directory. (you could differentiate between paths and file paths, the 'relative path' would then exclude the file name but give the directories from the base to the working directory, though the term becomes redundant as this is properly called the relative directory).
Notice the distinct meanings of keywords:
name
directory
path
separator
These are then combined with the parts of the full path:
root
base
relative
file
Example: root path = root name + root directory
Notice how this works for both Windows and Linux (where the root path is the same as the root directory because the root name is empty).
In Java, the output is produced by:
package io;
import java.io.File;
import java.util.logging.Logger;
/**
* Directory, File, and Path conventions.
*
* Directories always end with the file separator and never include the filename. They can easily be appended.
* - "Directory name" could refer to any directory in any position (dirName + sep = dir).
*
* Paths include the root, the filename, or both.
*
* <em>On Windows, base directory names can be capitalised.</em>
*/
public class Main {
private static Logger logger = Logger.getLogger("io");
public static void main(String[] args) {
final String sep = File.separator;
final String lf = System.lineSeparator();
logger.info("File separator: " + sep);
logger.info("Line separator: " + lf);
String baseName = "file";
String ext = "txt";
String fileName = baseName + "." + ext;
String driveName = "C";
String rootName = driveName + ":";
String rootDir = sep;
String rootPath = rootName + rootDir;
String baseDir = "Source" + sep;
String basePath = rootPath + baseDir;
String subDir = "project" + sep;
String subSubDir = "docs" + sep;
String relDir = subDir + subSubDir;
String relPath = relDir + fileName;
String workDir = basePath + relDir;
String fullPath = basePath + relPath;
logger.info("Base name: " + baseName);
logger.info("Extension: " + ext);
logger.info("Filename: " + fileName);
logger.info(lf);
logger.info("Drive name: " + driveName);
logger.info("Root name: " + rootName + " (empty on linux)");
logger.info("Root dir: " + rootDir);
logger.info("Root path: " + rootPath);
logger.info(lf);
logger.info("Base dir: " + baseDir);
logger.info("Base path: " + basePath);
logger.info("Sub dir: " + subDir);
logger.info("Sub-sub dir: " + subSubDir);
logger.info("Relative dir: " + relDir);
logger.info(lf);
logger.info("Relative path: " + relPath);
logger.info("Working dir: " + workDir);
logger.info("Full path: " + fullPath + " (also 'Absolute path' or 'File path')");
logger.info(lf);
String linuxDriveDir = driveName + sep;
String linuxRootPath = rootDir + linuxDriveDir;
String linuxBasePath = linuxRootPath + baseDir;
logger.info("Linux drive dir: " + linuxDriveDir);
logger.info("Linux root path: " + linuxRootPath);
logger.info("Linux base path: " + linuxBasePath);
logger.info(lf);
String parentDir = ".." + sep;
String currDir = "." + sep;
logger.info("Parent dir: " + parentDir);
logger.info("Current dir: " + currDir);
}
}
To give an answer to the OP's question:
A) foo = base name
B) foo.src = file name
C) src = extension
D) .src = ? (file extension separator + extension)
E) C:\users\OddThinking\Documents\My Source\ = base path
F) Widget\foo.src = relative (file) path
G) Widget = directory name
H) C:\users\OddThinking\Documents\My Source\Widget\ = working path aka "working directory"
I) C:\users\OddThinking\Documents\My Source\Widget\foo.src = full path, absolute path, file path
foo Filename Without Extension
foo.src Filename
src Extension
.src Maybe Extension With Dot, but this should not be used. As written this could be a directory name or a filename.
C:\users\OddThinking\Documents\My Source\ [Absolute] Directory Path
Widget\foo.src Relative File Path
Widget Directory Name
C:\users\OddThinking\Documents\My Source\Widget\ This is still an Absolute Directory Path. If one is root and the other isn't, its up to your variable names to keep track of that, there isn't really a semantic difference there.
C:\users\OddThinking\Documents\My Source\Widget\foo.src [Absolute] File Path
"Filename" is a word, so generally we should use "filename" and not "file name" (and Filename not FileName).
The word "Directory" can be replaced with the word "Folder". (Maybe we should use "Directory" at a lower level, but "Folder" is shorter which I prefer.)
It's actually possible to create a semantic framework of all of these types, with semantically valid functions for combining them. For example, a FolderName and a Filename can be combined to give a RelativeFilePath. A FolderPath (absolute is implied) and a RelativeFilePath can be combined to give a FilePath (absolute is implied).
Also, some of these are related; for example a FilenameWithoutExtension is a kind of Filename, so should be convertible. A FolderName is a RelativeFolderPath, so should be convertible. Etc.
Simple answer you could adopt for simple projects:
Have not used the word path because its useful to differentiate it with web paths if working with URLs/path too.
| name | example |
|------------|------------------|
| file | /foo/bar/baa.txt |
| filename | baa.txt |
| stem | baa |
| suffix | .txt |
| ext | txt |
| dir | /foo/bar/ |
| dirname | bar |
| parent | /foo/bar/ |
| parentname | bar |