[syslinux] config.c32 fails in 5.00pre12

Matt Fleming matt at console-pimps.org
Fri Nov 30 03:26:03 PST 2012


On Thu, 2012-11-29 at 21:06 +0200, Ady wrote:
> > On Thu, 2012-11-29 at 09:25 -0800, H. Peter Anvin wrote:
> > > Maybe we should make the install directory (or config file root 
> > > directory) the default PATH instead?
> > 
> > Yeah, that makes sense.
> > 
> 
> How would that change affect config.c32 and the CONFIG directive when 
> changing to a new working directory?
> 
> I am thinking about different situations.
> 
> One is the use of relative paths (which usually make the cfg files 
> more "portable" regarding the directory tree).

The current working directly is always searched first, before PATH, when
looking up filenames.

> A second situation is using CONFIG (and there are other alternatives) 
> as a "connector" between different cfg files, which originally were 
> part of different ISO images (for example). In this case, c32 modules 
> (and other files related to Syslinux) might be located in different 
> directories, according to each cfg file.
> 
> A third situation could be similar to the second one, but with all 
> modules in one central directory ("/boot/syslinux/" for example) and 
> each cfg file (each one located in different directories) using the 
> appropriate absolute (or even relative) path.

Note you can have different versions of say, pwd.c32, in different
directories and if you access them with absolute paths it will Do The
Right Thing.

Where using the installation directory for PATH makes the most sense is
for a module's dependencies, e.g. libcom32.c32. By placing the libraries
in the installation directory we don't have to look them up relative to
the absolute path of the module we're loading (the absolute path isn't
readily available in the core of Syslinux at the point where we load
deps).

> So, is the default PATH set only at boot? Or is it automatically 
> "updated" (or "re-set") with each change of working directory (or in 
> any other situation)? Are there any situations where PATH is 
> automatically "updated"? (I mean "updated" without having to use a 
> new PATH directive in each cfg file.) If such situation exist, is the 
> new PATH replaced, or is it merged (appended) with the previous 
> values?

'PATH' is initialised once, on boot. It is never automatically updated
unless you're using the PATH directive.

> The reason I bring this up is because having to explicitly set PATH 
> in each cfg file (where each cfg file may have a different working 
> directory) _might_ be inconvenient in certain cases, specially if 
> using relative paths in the cfg files (with "portability" in mind).

Yes, I've just fixed this, using Peter's suggestion.

> And speaking about relative paths, can relative notation be used for 
> the PATH directive?

No.

> Can a new directory be added to whatever the PATH value was before, 
> without having to repeat (or even know) the previous PATH value(s)? 
> Or instead, each PATH directive completely replaces any previous 
> value(s) and there is no means to "add" ("merge", "append")?

Each PATH directive appends to the previous value. Which means that the
directories specified earlier are searched first.

> Evidently, the user could manually set a new PATH directive in each 
> cfg file to match the (relative) directory tree used in the rest of 
> the directives in that cfg file. Are there any other alternatives?
> 
> Is there any need for a "path.c32" (or some other less-ambivalent 
> name) so to change the PATH value(s) directly from the prompt?

I think writing that code would be more trouble than it's worth.

-- 
Matt Fleming, Intel Open Source Technology Center




More information about the Syslinux mailing list