[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Option synonims

From: Paolo Redælli
Subject: Re: Option synonims
Date: Wed, 16 Mar 2022 07:31:12 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.1.0

Il 15/03/22 20:07, Raphael Mack ha scritto:
Am Dienstag, dem 15.03.2022 um 14:14 +0100 schrieb Paolo Redælli:
Do we know that we may use "--" instead of "-" and "-" instead of "_"

I.e.: -no_warning --no_warning -no-warning and --no-warning are all 
synonims for the same option.

Shall I make it a little more known, perhaps changing the help
I even do not like to have so many different version of the same thing
:-) and for command line options my personal opinion is that eiffelish
names are not the best practice, we should stick to what is normal on
the command line. -> I would be fine to remove the _ and -xxxx options
from the command line help. One release later we could then issue a
warning that the old names are obsolete and again 1-2 releases later I
would be fine to get rid of these multiple options...

The original version was the dash and underscores version (i.e. "-no_warning").

Some years ago I raised the issue pointing out that those option's names aren't GNU-ish or even POSIXish at all, so code managing it has been changed to accept both single and double dash and both dash and underscores.

BTW, it is implemented in COMMAND_LINE_TOOLS.flag_match (in liberty-eiffel/src/smarteiffel/utils/command_line_tools.e).

I think that it is wise to leave at least for now this separate logic. Shall we progressively switch command line handling to cli cluster (in src/lib/cli: COMMAND_LINE_ARGUMENT )?

reply via email to

[Prev in Thread] Current Thread [Next in Thread]