[asterisk-bugs] [Asterisk 0013969]: Need tab completion of "core set debug X filename.c"
Asterisk Bug Tracker
noreply at bugs.digium.com
Thu Dec 4 14:57:50 CST 2008
A NOTE has been added to this issue.
======================================================================
http://bugs.digium.com/view.php?id=13969
======================================================================
Reported By: jtodd
Assigned To: mvanbaak
======================================================================
Project: Asterisk
Issue ID: 13969
Category: General
Reproducibility: always
Severity: trivial
Priority: low
Status: assigned
Asterisk Version: SVN
SVN Branch (only for SVN checkouts, not tarball releases): trunk
SVN Revision (number only!): 159221
Disclaimer on File?: N/A
Request Review:
======================================================================
Date Submitted: 2008-11-25 13:00 CST
Last Modified: 2008-12-04 14:57 CST
======================================================================
Summary: Need tab completion of "core set debug X filename.c"
Description:
There is a method by which debugging can be activated for particular C
files by typing something like this from the CLI:
core set debug 2 chan_sip.c
There is no indication that this is possible in the tab completion of the
command line. After typing "2" in the example above, hitting "tab" gives a
beep instead of something like "<filename.c>" or a list of available files.
For that matter, the idea that a number can be put in as a debug level is
not clear, either.
======================================================================
----------------------------------------------------------------------
(0095793) jtodd (administrator) - 2008-12-04 14:57
http://bugs.digium.com/view.php?id=13969#c95793
----------------------------------------------------------------------
I don't consider missing portions of tab-completion documentation to be
"missing functionality", since most (but perhaps not all) commands are
expected and do behave in a way that describes hints. I think this is
splitting semantic hairs over a specific hint feature, though if other
debug commands are similarly missing tab hinting perhaps this is worthy of
a janitor request for other elements (indeed, that may already be on the
list, and I am just picking one out that became obvious to me.)
If it is a difficult proposition to create an exact list of all possible
modules that can be displayed, and this is a rarely-used element, then it
is possible that the additional effort to create a full list is not worth
the development time.
However, if it is not overly difficult to list all of the modules (taking
eliel's suggestion of replacing ".so" with ".c") then that perhaps is also
a possible solution. The full list is optimal, but I suspect if it
requires significant effort then perhaps only the hint of "<modulename.c>"
would be sufficient for the reasonable person to determine what is
required.
When I type "show ip route ?" on a Cisco, it doesn't show me all possible
routes in the table. (granted, the "?" replaces what we use [tab] for) It
shows me a list of possible options, including options which represent a
table or unspecified list of other items, such as IP addresses.
core1.sjc1>sh ip route ?
Hostname or A.B.C.D Network to display information about or hostname
bgp Border Gateway Protocol (BGP)
connected Connected
dhcp Show routes added by DHCP Server or Relay
eigrp Enhanced Interior Gateway Routing Protocol (EIGRP)
isis ISO IS-IS
list IP Access list
mobile Mobile routes
odr On Demand stub Routes
ospf Open Shortest Path First (OSPF)
profile IP routing table profile
rip Routing Information Protocol (RIP)
static Static routes
summary Summary of all routes
supernets-only Show supernet entries only
vrf Display routes from a VPN Routing/Forwarding
instance
| Output modifiers
<cr>
core1.sjc1>sh ip route
While I am not advocating that we reproduce the Cisco method in it's
entirety, I am using the case to describe what one might argue is the most
well-known appliance vendor's take on the methods to describe options in a
command line. Listing tables full of options is not always required or
expected, though it is useful to do so when it is convenient for the
developer or makes a significant ease-of-use improvement for the user. It
is sufficient in many cases to simply indicate that further options are
available, even if they are not explicitly outlined in the hint.
In the case of debugging individual .c files, I think that typically the
user would know what file they wish to obtain debugging information from,
therefore listing the entire possible array of .c files available may not
be required (though I wouldn't discourage anyone from doing it.) I would
not say at all that a lack of a list in this instance isn't "do[ing] it
right" and that the opposite ("not at all") would suggest a method of
development under which that many components of Asterisk would have never
been implemented at all.
Issue History
Date Modified Username Field Change
======================================================================
2008-12-04 14:57 jtodd Note Added: 0095793
======================================================================
More information about the asterisk-bugs
mailing list