Syslinux - Sep 2010 - CONFIG and appended directory; current directory

I've been testing the CONFIG directive and config.c32 module and I've
found a possible issue.  It seems to ignore the directory of "/" but
can otherwise go up and down a directory tree perfectly.  Executing
COM32 chdir("/") does seem to work.

Also, I noticed that the config file name is relative to the old
present working directory (herein pwd) and not the new pwd (good
behavior that should be noted in documentation).  Fortunately, it does
change directories before processing the config file such that
directives like INCLUDE and DISPLAY work.  It also silently fails to
change the pwd if it doesn't exist (disk-based; as opposed to
PXELINUX).

In PXELINUX, I'm also noticing that any specified file/path (including
calls to chdir()) is merely appended to the pwd unless it starts with
"::" (although I haven't testing using multiple TFTP servers or
using
gpxelinux.0).  When using CONFIG/config.c32 and chdir(), the pwd is
also not tailed properly with a trailing "/" unless specified.

-- 
-Gene

On 09/14/2010 11:23 PM, Gene Cumm wrote:
> 
> In PXELINUX, I'm also noticing that any specified file/path (including
> calls to chdir()) is merely appended to the pwd unless it starts with
> "::" (although I haven't testing using multiple TFTP servers
or using
> gpxelinux.0).  When using CONFIG/config.c32 and chdir(), the pwd is
> also not tailed properly with a trailing "/" unless specified.
> 
This is by design.  Keep in mind the TFTP server might not use / as
directory separator!

	-hpa

On Wed, Sep 15, 2010 at 02:23, Gene Cumm <gene.cumm at gmail.com>
wrote:
> I've been testing the CONFIG directive and config.c32 module and
I've
> found a possible issue. ?It seems to ignore the directory of "/"
but
> can otherwise go up and down a directory tree perfectly. ?Executing
> COM32 chdir("/") does seem to work.
Appending "/" as the target directory for config.c32 or CONFIG calls
pm_is_config_file().  In pm_is_config_file(),  before mangle_name(),
*p == "/ ".  mangle_name() changes "/ " to "",
hence the issue.

I'm going to try to look at this this afternoon.

-- 
-Gene