Ariel <asdeb...@dsgml.com> writes:

> On Thu, 1 Mar 2012, Rob Browning wrote:

>> If we want "-b [foo]", I'll need to specify "b" to getopt (no colons)
>> and handle any subsequent oss|alsa value manually (increment optind,
>> etc.).  That works -- or we can just require -balsa/-boss.

> Are you sure about that with getopt? The manual shows differently:
> http://www.gnu.org/software/libc/manual/html_node/Example-of-Getopt.html#Example-of-Getopt
>
> -cfoo and -c foo were parsed the same in the example.

With option pattern "b::", only -bfoo appears to work; "-b foo" works if
the argument to -b is not optional, i.e. if you specify pattern "b:".

Though as I mentioned, with a bit of extra code in the 'b' case in the
getopt() loop, we can implement the "-b [foo]" semantics manually if we
like.

>> For backward compatibility, I imagine we shouldn't require -o, and
>> should just default to oss when -b isn't specified.
>
> Nah, oss is dead, it's not useful as a default and backwards
> compatibility is not really that necessary.

Right, but I'm thinking about existing systems that are still running
saytime, perhaps as part of some larger cron/at based alert system (I
used to use it as a simple alarm).  Say they're calling "saytime -o
/dev/theircard"; I'd rather not force that to break without a good
reason.

>> Of course, if we didn't have to worry about backward compatibility at
>> all, it'd be nicest to have saytime default to sox -d whenever -b and -o
>> aren't specified, since that's probably more portable.
>
> No, don't worry about backward compatibility at all. If it bothers
> you, then put in a NEWS file that lets people know the options
> changed.

If we were fairly certain that "sox -d" was the same or better on the
vast majority of systems, then that might be worth thinking about for
the case where neither -b nor -o is specified.

Thanks
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Reply via email to