[syslinux] config_cwd can be killed?

[Ady Ady]

> I asked before about config_cwd and after some more digging, it looks
> like it could be removed...
> 
> Specifically, the documentation
> http://www.syslinux.org/wiki/index.php?title=Config#CONFIG says:
> 
> ----------
> * CONFIG config_file [new_WD]
> 
> Load a new configuration file. The new configuration file is read, the
> Working Directory is optionally changed (if specified via an optional
> second parameter), and then the new configuration file is parsed.
> 
> If new_WD is not specified, then the Current Working Directory is
> maintained, unchanged.
> 
> The Working Directory may be different from the path to the config file.
> ----------
> 
> But looking at the actual code, it doesn't *read* so much as just
> *open* the config file.
> 
> So presumably, the open() implementations (by filesystem type?) would
> look for the config file with a relative filename in the old current
> directory and not the new current directory.
> 
> Is that a useful or necessary feature?
> 
> Is Matt Fleming (author of the original code) still lurking on this
> list to explain?
> 
> Or could IMAGE_TYPE_CONFIG set the directory before processing the config file.
 
 
The CONFIG directive first changes the CWD and then it parses the new 
cfg file; or at least it is supposed to.

For network setups, I would humbly suggest avoiding absolute paths, and 
using [MENU] INCLUDE (instead of CONFIG) whenever possible.

FWIW, years ago (circa 2012-2014) I tested the CONFIG directive with 
many, many variations using ISOLINUX and SYSLINUX in several versions 
(4.05+, 5+,6+). Several improvements were introduced back then.

If the CONFIG directive fails (now, or in the future) in SYSLINUX or in 
ISOLINUX, I hope someone else will step up for testing.
 
 
> 
> Both menu.c32 and ldlinux.EXT have parse_configs() functions that they
> send the argc/argv list they receive.  Both functions handle multiple
> arguments as multiple config files to be processed (with either
> parse_one_config() or parse_main_config()).  The documentation
> (http://www.syslinux.org/wiki/index.php?title=Menu#Alternative_configuration_file)
> shows examples of this for the menu.c32 case.
> 
> But this highlights that we have two different config file parsers
> with different behavior.  I haven't looked closely to completely
> confirm but, menu.c32 probably doesn't handle INCLUDE directives and
> LDLINUX doesn't support the "~" shorthand for config file names.
 
 
There are several parsers: CLI, [vesa]menu.c32, GFX, the Complex Menu 
System, and there are external parsers too.

About "[MENU] INCLUDE", see first:
 http://www.syslinux.org/wiki/index.php/Config#INCLUDE 
read it and then follow the "see also" link to "Menu#INCLUDE".

Although I wish for the CLI parser to support "~" too, I would not be 
surprised if it doesn't, even in older versions -- I haven't tested it 
in years. If I were to express wishes / priorities, I would rather see 
the long-time regressions being fixed (e.g. LSS16 background; updating 
dependencies such as lwip, gnu-efi, png...; dealing with pending 
patches...; booting optical media in UEFI mode and so on). There is a 
reason for so many Linux distros still using Syslinux 4.xx and older, 
instead of updating. Of course, it is easy to just wish and hope.
 
 
> 
> What about if the CONFIG (LDLINUX)  and MENU.c32 (and gfxboot.c32?)
> modules looked for arguments like "cwd=path/to/dir" (cwd relative and
> possibly including .. to drop parent directories?) or
> "cwd=/abs/path/to/dir" to change directories at that point in the
> parsing of the config files.  (Similar to the way initrd=filename is
> special for KERNEL types)  Then we wouldn't need this config_cwd
> private buffer and we could delete it and save some bytes of memory
> and simplify code.
> 
> Phil P.
> 
 
Regards,
Ady.