[syslinux] correct "--help' options

Ady Ady ady-sf at hotmail.com
Sat Sep 1 07:18:54 PDT 2012



> Date: Sat, 1 Sep 2012 07:58:50 -0400
> From: gene.cumm at gmail.com
> To: syslinux at zytor.com
> Subject: Re: [syslinux] correct "--help' options
> 
> On Sat, Sep 1, 2012 at 5:56 AM, Ady Ady <ady-sf at hotmail.com> wrote:
> 
> > differently in each installer. Also "--offset" doesn't appear for EXTLINUX.
> 
> It should not.
> 
 
 If I understand correctly, it's because the fs is already mounted, so
 "--offset" makes no sense for such situation, making "--offset" a specific
 option for syslinux only. Right?
 
  
> Historically, only short options existed. -o was used up to 3.86 for
> the offset.
> 
> > <snip>... The alternative would be not to use
> > "-o" in none of the installers.
> 
> This probably would help prevent confusion.
> 
 The "-o" now is used in installers that were previously
 not using it for anything else, but is not used in syslinux, which was
 indeed using it in older versions. If the previous decision was to change
 the old "-o" to the new "-t", then the same principle could be said about
 either:
 _ not using "-o" at all in any installer ("breaking" the current use); or,
 _ using "-o" also in syslinux ("re-using" it in syslinux too, but different
 from syslinux 3.8x ).
 
 Of course the third possibility is to leave it as it is currently, but that
 goes against the "closeness" between installers, so beneficial for usage,
 troubleshooting and documentation (and, I guess, also for development).
 The problem is that "-o" is still documented as "--offset" in too many
 places (in different websites). Someone using the old command line options
 with a newer syslinux installer could easily think "I add "-i" and I'm good
 to go". Even in such case, the old "-o" for "--offset" needs a numerical
 value, while the new "-o" for "--once" needs "something else". I would tend
 to think that the possibility for mixing old an "-o" in a command line for
 a newer syslinux is small (safe) enough, so "-o" can be used for "--once"
 in syslinux too, as it is used in the other installers.
 If the installer fails, then the user needs to learn that "-o" is not
 "offset" in newer versions, exactly as he learned about "-i".
 Developers (hpa?) might think different.
> From the man page:
> extlinux [options] directory
> 
> This directory is where ldlinux.sys is dropped. It's also the first
> directory search for a config file. It also dictates the file system
> into which the first sector boot code is installed.
> 
 
 If "--directory" for syslinux gives the same result as the "directory" for
 exlinux, then maybe both alternative command line options could be
 potentially available in extlinux, as equivalents; but this duplicity would
 be not really necessary, So "--directory" is even less "common" between
 installers than I though :(.
  
 
> >> > In addition to those requests, I'd like to know if there is any specific
> >> > "logic" for the order of appearance of the options when running
> >> > "<installer> --help".
> >>
> >> Perhaps libinstaller/syslxopt.c:usage() needs to have the common
> >> options resorted.
> >>
> >> --
> >> -Gene
> > At least "some" kind of logic would make it easier for the final user (who
> > needs the "--help" screen). For example (and I also have in mind other
> > different possible sorting orders, not just this one, so this is just one
> > idea among several), first the options that are common to the different
> > installers, and then the specific ones, alphabetically sorted.
> > But before re-sorting, the common options should be really common.
> 
> If sorted, the most logical decision is to use the long option within
> each category. With regards to common options first, specific options
> first or just mix them, that's a wide debate. There are some apps
> where I see the specific first while others the common first.
> 
> -- 
> -Gene
 
 Well, for final users, "any" logical sort would be better than "random".
 The specific logic for each program is always arguable.
Thanks for the replies,
Ady. 		 	   		  



More information about the Syslinux mailing list