Having just spent a half hour recovering from a mistyped command,
I have a suggestion regarding the UI of the rt command-line tool.
I suspect it’s more oriented towards 2.1 than 2.0, if only because
changing the arguments rt accepts midway through 2.0 might be
inappropriate.
We currently have:
–status=<new|open|stalled|resolved|dead>
–subject=
–owner=
–queue=
and so forth, and we also have
–id=
But --id selects by id, and --queue CHANGES the ticket’s queue!
I propose that --queue should be synonymous with --limit-queue, and
destructive options should be explicitly so, like “–set-queue”.
The command which was messy was this:
/opt/rt2/bin/rt --queue=Hostmaster --summary
which happily went through and changed all of my tickets into the
Hostmaster queue until I noticed something was amiss and hit ^C. 
-Rich
Rich Lafferty --------------±----------------------------------------------
Ottawa, Ontario, Canada | Save the Pacific Northwest Tree Octopus!
http://www.lafferty.ca/ | Save The Pacific Northwest Tree Octopus
rich@lafferty.ca -----------±----------------------------------------------
Rich> But --id selects by id, and --queue CHANGES the ticket’s
Rich> queue! I propose that --queue should be synonymous with
Rich> --limit-queue, and destructive options should be explicitly so,
Rich> like “–set-queue”.
Rich> The command which was messy was this:
Rich> /opt/rt2/bin/rt --queue=Hostmaster --summary
Rich> which happily went through and changed all of my tickets into
Rich> the Hostmaster queue until I noticed something was amiss and hit
Rich> ^C. 
I’d vote that we change this now, since I’m one of the few who use the
command line tool all the time, this would be sure to screw me up.
I’d also like to propose that destructive commands like this prompt
"Are you sure? [y|N] " by default.
This could be turned off by the flag -f to force the command without
any prompting.
John
I’d vote that we change this now, since I’m one of the few who use the
command line tool all the time, this would be sure to screw me up.
Here’s one to hold you over.
-Rich
Rich Lafferty --------------±----------------------------------------------
Ottawa, Ontario, Canada | Save the Pacific Northwest Tree Octopus!
http://www.lafferty.ca/ | Save The Pacific Northwest Tree Octopus
rich@lafferty.ca -----------±----------------------------------------------
— rt-orig/bin/rt Mon Jun 3 08:44:04 2002
+++ rt/bin/rt Mon Jun 3 08:56:05 2002
@@ -130,32 +130,32 @@
“history|show” => $history,
“summary:s” => $summary,
“create” => $create,
-
"keywords=s" => \@keywords,
-
"requestor|requestors=s" => \@requestors,
-
"cc=s" => \@cc,
-
"admincc=s" => \@admincc,
-
"status=s" => \$status,
-
"subject=s" => \$subject,
-
"owner=s" => \$owner,
-
"queue=s" => \$queue,
-
"set-keywords=s" => \@keywords,
-
"set-requestor|set-requestors=s" => \@requestors,
-
"set-cc=s" => \@cc,
-
"set-admincc=s" => \@admincc,
-
"set-status=s" => \$status,
-
"set-subject=s" => \$subject,
-
"set-owner=s" => \$owner,
-
"set-queue=s" => \$queue,
-
"priority=i" => \$priority,
-
"final-priority=i" => \$final_priority,
-
"due=s" => \$due,
-
"starts=s" => \$starts,
-
"started=s" => \$started,
-
"contacted=s" => \$contacted,
-
"set-priority=i" => \$priority,
-
"set-final-priority=i" => \$final_priority,
-
"set-due=s" => \$due,
-
"set-starts=s" => \$starts,
-
"set-started=s" => \$started,
-
"set-contacted=s" => \$contacted,
"comment", \$comment,
"reply|respond", \$reply,
"source=s" => \$source,
"edit!" => \$edit,
-
"depends-on=s" => \@dependson,
-
"member-of=s" => \@memberof,
-
"set-depends-on=s" => \@dependson,
-
"set-member-of=s" => \@memberof,
"merge-into=s" => \$mergeinto,
-
"refers-to=s" => \@refersto,
-
"time-left=i" => \$time_left,
-
"time-taken=i" => \$time_taken,
-
"set-refers-to=s" => \@refersto,
-
"set-time-left=i" => \$time_left,
-
"set-time-taken=i" => \$time_taken,
"verbose+" => \$verbose,
"debug" => \$debug,
"version" => \$version,
@@ -239,51 +239,51 @@
Attributes
Basics
-
--set-admincc=[+|-]<userid|email address>
add or remove this user as a ticket admincc
(When creating tickets, just leave off the + or - )
Keywords
-
--due=<date>
-
--starts=<date>
-
--started=<date>
-
--contacted=<date>
-
--set-due=<date>
-
--set-starts=<date>
-
--set-started=<date>
-
--set-contacted=<date>
-
--depends-on=[+|-]<ticketid>
-
--member-of=[+|-]<ticketid>
-
--refers-to=[+|-]<ticketid>
-
--set-depends-on=[+|-]<ticketid>
-
--set-member-of=[+|-]<ticketid>
-
--set-refers-to=[+|-]<ticketid>
--merge-into=<ticketid>
Comments and replies
Rich> But --id selects by id, and --queue CHANGES the ticket’s
Rich> queue! I propose that --queue should be synonymous with
Rich> --limit-queue, and destructive options should be explicitly so,
Rich> like “–set-queue”.
Rich> The command which was messy was this:
Rich> /opt/rt2/bin/rt --queue=Hostmaster --summary
Rich> which happily went through and changed all of my tickets into
Rich> the Hostmaster queue until I noticed something was amiss and hit
Rich> ^C.
I’d vote that we change this now, since I’m one of the few who use the
command line tool all the time, this would be sure to screw me up.
I’d also like to propose that destructive commands like this prompt
"Are you sure? [y|N] " by default.
This could be turned off by the flag -f to force the command without
any prompting.
Since nearly everyone uses the commandline interface noninteractively,
what about inverting this logic. If there is a --prompt flag or
environment variable then destructive commands prompt, otherwise they just
go an be destructive. The reason I suggest this is because it is usually
harder to debug noninteractive commands, especially for beginners setting
things up for the first time with their particular MTA/webserver/etc.
On the other hand, anyone who habitually does things from the commandline
should be well enough informed to know that he should have an environment
variable set at all times for safety.
Dan Shearer
Open Source Manager
Mob: +61 411 49 1800
Tel: +61 8 8130 3104
dan@tellurian.com.au
On the other hand, anyone who habitually does things from the commandline
should be well enough informed to know that he should have an environment
variable set at all times for safety.
The knowledge should spring forth from their head like Athena from
Zeus’s? That’s just as broken as the current UI. “It’s not a bad UI,
because you should know how it works in advance.”
Blaming the user for not understanding a bad UI on the user leaves you
with a bad UI and an justifiably annoyed user.
-Rich
Rich Lafferty --------------±----------------------------------------------
Ottawa, Ontario, Canada | Save the Pacific Northwest Tree Octopus!
http://www.lafferty.ca/ | Save The Pacific Northwest Tree Octopus
rich@lafferty.ca -----------±----------------------------------------------
On the other hand, anyone who habitually does things from the commandline
should be well enough informed to know that he should have an environment
variable set at all times for safety.
The knowledge should spring forth from their head like Athena from
Zeus’s? That’s just as broken as the current UI. “It’s not a bad UI,
because you should know how it works in advance.”
Blaming the user for not understanding a bad UI on the user leaves you
with a bad UI and an justifiably annoyed user.
I suppose the question is which is likely to bite the most people. Those
that are trying to set up a gateway interface that “keeps hanging for
mysterious reasons” (which means they haven’t spotted the log/error
message that says Shall I Delete [Y/N]") or those that run it in
commandmode and inadvertently do damage?
Dan Shearer
Open Source Manager
Mob: +61 411 49 1800
Tel: +61 8 8130 3104
dan@tellurian.com.au
I suppose the question is which is likely to bite the most people.
No, that’s the Bad UI Question. The Good UI Question is which behavior
is going to be hardest to repair. The second half of the principle of
least surprise is that surprises should be not only infrequent but
small.
Those that are trying to set up a gateway interface that “keeps
hanging for mysterious reasons” (which means they haven’t spotted
the log/error message that says Shall I Delete [Y/N]") or those that
run it in commandmode and inadvertently do damage?
Might I introduce you to isatty(3)? There’s no point in prompting if
you already know you’re in a noninteractive environment.
-Rich
Rich Lafferty --------------±----------------------------------------------
Ottawa, Ontario, Canada | Save the Pacific Northwest Tree Octopus!
http://www.lafferty.ca/ | Save The Pacific Northwest Tree Octopus
rich@lafferty.ca -----------±----------------------------------------------
Changing the behaviour of the standard commandline tools late in the 2.0.x
stable series isn’t going to happen. It’s not that I don’t agree that the
CLI is an abomination, but that one of the primary uses of the CLI is
noninteractive use by scripts. The CLI definitely wants
to get gutted and redone for the next major release. I’d be absolutely
thrilled to see a concrete proposal or two for how the CLI should work and
feel. If you could redo the CLI from scratch, what would you want to see?
-j
http://www.bestpractical.com/products/rt – Trouble Ticketing. Free.
This really sounds like you’re talking about the 1.0 cli. RT doesn’t have
rtq any more. and --create doesn’t prompt you through things.
rtq
-
shows all tickets, starting with the oldest to first. I’d like to
see it default to the most recent ## tickets. For example:
rtq -owner stoffel
Should only give me my last 10 or so. Or at least start from the
newest and work back in time.
-
The output of the header should be made much more compact. If
you’re not on a 48 line xterm, it’s hard to know which ticket number
you are looking at.
rt
-
the create command is ugly. It needs to be made more friendly, or
offer better ways to customize which fields are prompted for.
-
Should rt really have the -publichistory switch? That’s an rtq
function.
Just my off the cuff thoughts.
John
John Stoffel - Senior Unix Systems Administrator - Lucent Technologies
stoffel@lucent.com - http://www.lucent.com - 978-399-0479
http://www.bestpractical.com/products/rt – Trouble Ticketing. Free.
“Dan” == Dan Shearer dan@tellurian.com.au writes:
Dan> Since nearly everyone uses the commandline interface
Dan> noninteractively, what about inverting this logic. If there is a
Dan> --prompt flag or environment variable then destructive commands
Dan> prompt, otherwise they just go an be destructive. The reason I
Dan> suggest this is because it is usually harder to debug
Dan> noninteractive commands, especially for beginners setting things
Dan> up for the first time with their particular MTA/webserver/etc.
I really don’t understand your chain of thought here. If people are
using the command line interface non-interactively, then they should
be the ones who need to add in the -f (or --force) switch to make them
run properly.
Dan> On the other hand, anyone who habitually does things from the
Dan> commandline should be well enough informed to know that he should
Dan> have an environment variable set at all times for safety.
This also doesn’t make sense. Just because I use the CLI all the time
doesn’t mean that my fingers don’t make mistakes, or that I don’t
transpose numbers by accident, etc.
Heck, what I really want is a curses based interface to RT, or even
better, one that’s useable from within Emacs and which looks like the
VM mail reader. But I don’t know enough elisp to do that.
Anyway, I’m proposing that:
John
Jesse> Changing the behaviour of the standard commandline tools late
Jesse> in the 2.0.x stable series isn’t going to happen. It’s not that
Jesse> I don’t agree that the CLI is an abomination, but that one of
Jesse> the primary uses of the CLI is noninteractive use by scripts.
As Rich pointed out, isatty(3) is a possible solution to this issue as
well.
Jesse> The CLI definitely wants to get gutted and redone for the next
Jesse> major release. I’d be absolutely thrilled to see a concrete
Jesse> proposal or two for how the CLI should work and feel. If you
Jesse> could redo the CLI from scratch, what would you want to see?
Generally, the CLI setup isn’t too bad, I rarely have to do anything
from the Web interface that I can’t do from the CLI or via email. But
there are some short comings that I’ve run into:
general comments
-
all distructive commands should require -f to force their behavior,
otherwise they prompt.
-
a curses interface would be wonderful!
-
there should be an undo available for transactions such as merges.
This is a core RT issue really.
-
If you give an invalid ticket number, it should do better bounds
checking up front and then error out, instead of trying to do stuff
with bogus info.
rtq
-
shows all tickets, starting with the oldest to first. I’d like to
see it default to the most recent ## tickets. For example:
rtq -owner stoffel
Should only give me my last 10 or so. Or at least start from the
newest and work back in time.
-
The output of the header should be made much more compact. If
you’re not on a 48 line xterm, it’s hard to know which ticket number
you are looking at.
rt
-
the create command is ugly. It needs to be made more friendly, or
offer better ways to customize which fields are prompted for.
-
Should rt really have the -publichistory switch? That’s an rtq
function.
Just my off the cuff thoughts.
John
John Stoffel - Senior Unix Systems Administrator - Lucent Technologies
stoffel@lucent.com - http://www.lucent.com - 978-399-0479