[syslinux] correct "--help' options

[Gene Cumm]

On Sat, Sep 1, 2012 at 10:18 AM, Ady Ady <ady-sf at hotmail.com> wrote:
>
>
>> 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?

Yes, both linux/syslinux and mtools/syslinux are the only places the
offset is useful as they are the only two that can use an unmounted
file system.

>> 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.

Using "-o" again in linux/syslinux or mtools/syslinux would be
extremely bad.  It should probably either be maintained as-is or
removed entirely.  Reusing it for a completely different purpose would
cause a user to see unexpected behavior.  hpa would be the final
authority (of course).

>> 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 :(.

It's similar to --offset.  It's only desirable on unmounted file
systems or DOS/Windows environments.  The 3 DOS/Windows installers
want a drive letter ("e:") to know what file system/drive to install
the VBR and MBR code.

>> >> > 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.

My guess would be new options getting added to the bottom instead of
inserted in order.

> Thanks for the replies,
> Ady.

You're welcome.  I'm glad there's a better understanding now.

-- 
-Gene