README 6.0 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160
  1. /**
  2. \mainpage
  3. \section abstract Abstract
  4. A modular framework for implementing a CISCO-like CLI on a *NIX system.
  5. Arbitary command menus and actions can be defined using XML files.
  6. This software handles the user interaction, and forks the appropriate system
  7. commands to perform any actions.
  8. - \ref _licence_page
  9. - \ref _changes_page
  10. - \ref _issues_page
  11. \section downloads Downloads
  12. This project is hosted on
  13. <A HREF="http://sourceforge.net/projects/clish/">sourceforge.</A> from where
  14. the source-code can be downloaded.
  15. \section background Background
  16. The CISCO-like CLI has become a de-facto standard in the domain of network
  17. devices. It is a much more restricted interface than traditional *NIX shells,
  18. hence is simpler to use and inherently more secure. As more devices move to
  19. using an embedded *NIX operating systems, a simple, scalable means of producing
  20. such a CLI becomes valuable.
  21. \section existing Existing Solutions
  22. \subsection Libcli
  23. <A HREF="http://libcli.sourceforge.net/">Libcli</A>
  24. provides a similar facility but has the following main limitations:-
  25. 1) In order to add new commands a monolithic executable (which uses the
  26. library) needs to be recompiled, after editing the source code to add the
  27. newly required commands and actions.
  28. 2) libcli takes responsiblity for attaching to a socket (telnet-like). This
  29. limits the usage of the CLI; difficult to use over SSH for example, similarly
  30. cannot get the menus directly from an existing shell.
  31. 3) The implementation of the command actions is hard-linked into the monolithic
  32. executable, this can cause licence concerns/issues when a commercial company
  33. wishes to control proprietry software from within the CLI.
  34. 4) libcli takes responsiblity for the authentication of the user. This is
  35. different from other "shells" which do not deal with authentication, but are
  36. simply spawned as the required user.
  37. \subsection GNU-zebra
  38. <A HREF="http://www.zebra.org/">Zebra</A>
  39. is a routing package, and comes with it's own integrated CLI, to handle its
  40. configuration (VTYSH).
  41. \section project CLISH Project
  42. The project is written (mostly) in ANSI-C and provides two example executables
  43. which can be used as a drop-in replacement for a more conventional "shell".
  44. The software was initially developed as part of some internal work at 3Com and
  45. due to the dependancy on 3rd party open-source packages, and it's self contained
  46. nature, it is being released into the public domain.
  47. It is designed to run on any *NIX system e.g. Linux, BSD, Cygwin and makes use
  48. of the following other opensource packages (glibc,tinyxml,doxygen)
  49. \subsection clish clish (pronounced see-lish)
  50. This application is a standard UNIX shell replacement. The ACTION tags in the XML
  51. specification are mapped to the system() call and hence will be interpreted as
  52. a Bourne-shell script.
  53. \subsection tclish tclish (pronounced tickle-ish)
  54. This application is built if the TCL libraries are present on the build system.
  55. The name of the executable produced will reflect the version of TCL used. e.g.
  56. tclish8.4 will be generated if TCL8.4 is present on the system.
  57. This application will spawn a TCL interpreter when started, and the contents of
  58. the ACTION tags will be interpreted as TCL scripts within that interpreter for
  59. the duration of the shell.
  60. \subsection Features
  61. The "clish" shell has the following features:-
  62. - Provides CLI tree handling facilities
  63. - Tree built from multiple XML encoded files. (uses tinyxml)
  64. This means that XML configuration files can be be made part of
  65. 3rd party packages and simply installing them integrates
  66. commands into the CLI.
  67. - Access permissions are defined as part of the CLI tree definition; a CLI
  68. node/branch may be limited to a specific *NIX group.
  69. - Provides interface to user
  70. - Handles auto-completion of commands
  71. - Only appropriate commands for the current user's "group" will be
  72. available.
  73. - Provides parameter type verification facility
  74. * Each parameter may be of a specific type, which the
  75. framework will ensure is correctly entered by the user.
  76. - Provides key-handling for the interface (uses tinyrl)
  77. * Provides command line editing facilities
  78. * up/down arrow keys
  79. * [TAB] command completion
  80. * [CTRL-A] move to start of command line
  81. * [?] provides context sensitive help.
  82. - Able to be launched non-interactively
  83. - textual scripts can be written to drive the CLI
  84. - Executes a specified CLI command by launching the appropriate
  85. (as defined in the CLI tree) system command line to perform the
  86. required action
  87. - Only commands permitted for the current user are available.
  88. - During execution the I/O streams are handed over to the new
  89. program.
  90. - Able to spawn a 3rd party shell, where necessary
  91. This will take over control of the I/O channel until that
  92. sub-shell exits.
  93. "clish" makes use of multiple XML files to define it's behaviour these...
  94. - Identify scope of the commands (global or specific view(s))
  95. - Include access permissions. By default a command will be
  96. accessible to all users, but the schema will provide
  97. the ability to limit the command based on UNIX group membership.
  98. - Includes help text for menus
  99. - Includes parameter definitions (with types where appropriate)
  100. - Includes prompt modifications (different views)
  101. - Includes full command line which each leaf node should execute
  102. to achieve result.
  103. - Separate set of files for each localization (language) can be
  104. provided and determined by the user logging in.
  105. - "packages" can contribute files to define their facilities
  106. within the CLI; this makes augmentation of the CLI as simple
  107. as including/excluding a particular package.
  108. \section example xml-example directory
  109. \include README
  110. Some of the example files are put here for reference:
  111. \subsection global_xml global-command.xml
  112. \include global-commands.xml
  113. \subsection startup_xml startup.xml
  114. \include startup.xml
  115. \subsection types_xml types.xml
  116. \include types.xml
  117. \subsection debug_xml debug-view.xml
  118. \include debug-view.xml
  119. */