Re: RFS: mkat - transparent CLI frontend to burn, catalog data and audio CDs
On Tue, Sep 28, 2004 at 11:11:10PM -0400, Nathaniel W. Turner wrote:
> > You understand it right, however, I didn't want to put "and" there
> > because it is not necessary to burn *and* catalog, you can do either or
> > both, so I thought that a comma would be more appropriate.
>
> Unfortunately, a comma there is still grammatically incorrect (and confusing).
> In this case it really just means "and" anyway. I do understand your
> hesitation, but I think users will understand that they don't have to do
> both, especially if this is made clear in the long description.
Ok.
> > Yep, I've changed the description to "transparent CLI frontend to burn,
> > catalog data and audio CDs".
>
> Hmm... or maybe say "command line tool for burning and cataloging CDs", and
> then mention in the long description that (a) it is a front end to something
> and (b) it can handle both audio and data CDs? Both xcdroast and k3b are
> front ends to cdrecord et al. but neither mentions this in its short
> description (which I think is reasonable). Also, maybe "writing" is better
> than "burning" (it's more accurate, after all =).
The latest version is "transparent CLI frontend for burning and
cataloging data and audio CDs". 2 "and"s may be confusing though.
I'm not completely sure if "frontend" is appropriate word here. My
burn(1) is able to passthrough options to both cdrecord and mkisofs, it
also feautures shortcut options for blanking CDRW, for example. Also, it
is indicated in documentation when it uses grep, so it is possible to
use grep regular expressions. I meant it to be transparent in this way.
I mention that it is "transparent frontend" in the short description
because that's why I wrote mkat in the first place. Catalog is stored in
text files, so it's pretty transparent too. I believe my description
stands out compared with "yet another frontend for burning CDs".
As of "write" vs "burn" I prefer burn, it seems to be term most people
use. "Write" is too generic.
--
/Dmitry <ledestin@amur.ru>
Reply to: