Phil Kos wrote:
> What's wrong with the traditional `date' syntax? Why are we arguing about
> changing it?
Phil, we're not arguing about changing anything, I just did it!
no, this was a joke. now seriously.
as I wrote in the message you quote, I believe that using this shorthand makes
parsing parameters a lot easier. it doesn't save much more than a few bites,
maybe, so it is actually questionable if we should aim to reduce executables
sizes almost at any cost or if we should try to keep beauty and compatibility
with real linux (and thus with most other unices) at the cost of disk space.
obviously the answer to this question lies somewhere in between the two
extremes, how close to one or the other can be a source of arguments and flames
or subject for a centralist democratic directive from some instance above both
of us.
secondly, I'm using this one option in common with linux' `date':
-s datestr, --set datestr
Set the time and date to datestr, which can be in
almost any common format. It can contain month
names, timezones, `am' and `pm', etc.
the description for elks-date would sound like:
-s datestr, --set datestr
Set the time and date to datestr, which must be in
ISO format yyyy-MM-ddThh:mm:ss.
century and any trailing parameters are optional.
the two options I'm adding are needed on a system, like the one I have, where I
can't trust the CMOS clock and where I need to interactively set the date each
time I switch the system on. I don't want to forget to do that, so I put it
into the inittab as a sysinit action.
yes, we could use `-i' (and `--inquire'), `-c' (and `--conditional_inquire')
for the two options, maybe I'll try that to see how much larger becomes the
binary produced. Actually, since these are non standard options, we should
probably stick to the long format, in order to avoid collisions with other
extensions. I'm not trying to start an other argument, I'm just trying to
explore the extreme consequences of this way of clean developing, if applied in
a consistent way.
well, are there any central directives on how to develop -system- software for
ELKS?
my point is: if it works, it is documented and it is small, it is good.
comments are highly appreciated, but, please, no flames.
Mario.
> > > Yes probably -i for interactive input or -s for set or something like
> > > that.
> >
> > [...] I don't like the `-s' and `-i' idea, it makes parsing parameters that
> bit
> > more complicated that we don't need on ELKS.
> > shall I substitute the `?' with a `a' (for Ask)? and thus `aa'. it makes
> the
> > code a bit easier, I believe.
> >
> > thanks for the suggestions/comments.
> >
> > Mario.
