[syslinux] PATH directive

[Matt Fleming]

On Fri, 02 Jan, at 02:23:48AM, Ady wrote:
>  
> Hmm, I thought it was decided to consider the colon (":") character as 
> deprecated, and instead we should be using a space character as 
> separator for the PATH directive (or multiple lines). Well, at least as 
> for the current MASTER HEAD, Syslinux 6.03.
  
Are you referring to commit 1945579 ("PATH: use a linked list
internally")? Looking at the code in master, it appears as though the
colon character is still the separator.
  
> > 
> >   /boot/absolute/path/to/my/file.c32
> >   /foobar/absolute/path/to/my/file.c32
> > 
> > Which is totally bogus, and contrary to what "absolute path" means.
> > 
> > I've created the following bug report to track this issue,
> > 
> >   http://bugzilla.syslinux.org/show_bug.cgi?id=58
>  
>  
> Was/is this behavior really undesired?
 
Yes, we need to provide users with some method of specifying absolute
paths, i.e. regular file system semantics.

> And, what _should_ had been the correct behavior?
  
Quoting from http://en.wikipedia.org/wiki/Path_(computing),

 "Systems can use either absolute or relative paths. A full path or
  absolute path is a path that points to the same location on one file
  system regardless of the present working directory or combined paths. As
  such it must always contain the root directory."

> For paths (in a cfg or in CLI) other than in the PATH directive: any 
> path not prefixed with a slash character (nor with a colon character, 
> indicating a TFTP root) is to be parsed as relative to the CWD. But...
> 
> For the PATH directive (only), the following (alternative) lines:
> 
>  _ PATH some/path
>  _ PATH /some/path
>  _ PATH some/path/
>  _ PATH /some/path/
> 
> tested separately / independently (not together / not simultaneously / 
> not in the same boot attempt), seem to be treated all as an absolute 
> path (if I remember my old tests correctly, but please don't trust my 
> memory).
 
I'd really need to see an example config file to understand what's going
on here.

> Then the statement that "the CWD is *always* searched-for first" is 
> inaccurate.
> 
> The statement (as included in the official documentation) seems to be 
> directed to c32 dependencies, but then this is one of the reasons why 
> the PATH rules _seemed_ to be relevant for c32 dependencies only. Since 
> the PATH rules apply to all c32 files (not just c32 dependencies), then 
> the wording for the PATH rules should account for each-and-all cases, 
> not just for dependencies.
> 
> From users' perspective...
> 
> The statement might be accurate for c32 *dependencies*, but not as much 
> for explicitly-referenced c32 files (because it seems to depend on the 
> way the c32 file is referenced; in absolute or relative notation). 
> Which means that the other statement, "all c32 files are treated 
> equally, whether they are dependencies or not", is also not 100% 
> accurate.
> 
> So I have to go back to a prior question: what _should_ be the adequate 
> behavior? 
> Do we want the same (or a different) behavior(s) for 
> explicitly-referenced c32 files comparing to c32 dependencies?
> Do we want a different behavior for explicitly-referenced c32 files 
> depending on the type of path notation?
> Do we want the same behavior for explicitly-referenced c32 files 
> independently of the type of path notation?
 
We want to align with the expected POSIX semantics of file system paths.
If you do not prepend your path with a "/" on UNIX systems, it's taken
as relative to your current working directory.

At the moment the ELF linking code specifies dependencies using relative
filenames in the ELF headers.

> So my first attempt to write a complete set of PATH rules failed (plus, 
> we have a bug and I am not sure what the correct behavior should had 
> been).
> 
> If I understood correctly, the behavior of the c32 *dependencies* (WRT 
> to the PATH directive / rules) is not influenced by the path notation 
> of the explicitly-referenced file; but these questions are also about 
> the behavior of those explicitly-referenced c32 files (WRT to the PATH 
> directive / rules).
  
Dependencies *are* influenced by the usual path notation, there's
nothing special about dependencies.
  
-- 
Matt Fleming, Intel Open Source Technology Center