Feature proposals

Skip to first unread message

Ingo Albrecht

Oct 17, 2020, 12:18:19 PM10/17/20
to klis...@googlegroups.com
This is a list of specific features that I believe are worth thinking about.

Some of them relate to the design document that Serj sent around.

Most of them should not be very hard to implement.


* comments in interactive shell
** used in shared sessions
** can be used in recordings
** should probably use '#'

* command sequences
** allow several commands on one line
** just for simple sequences
** should probably use ';'
** lower precedence than pipe

* Maybe: multi-line command entry
** improves readability of scripts
** should probably use '\'
** personally I don't use this in sh

* More emacs-like editing commands
** CTRL-cursor to skip words
** Ideally would use command parser
** Other shells just use string skipping

* Generalize forking
** Add an attribute "fork" to ACTION
** Allow any action to fork clish itself
** Remove forking support from lua plugin

* Introduce VIEW actions
** All VIEW actions executed on view entry in load order
** More modular than changing state in the view-switching command
** Can be used as alternative to STARTUP for modular initialization of
language plugins, for example to import or lua python libraries that
will then be available to all actions
** Can be used to change state in a plugin, for example to connect to a
database based on the viewid or to update the

* Add PLUGIN actions
** Should be executed after config
** Should be possible to have several

* Maybe: stop using system()
** allow specifying what shell to run
** Mode 1: Use "-c $command" like /bin/sh
*** This is like system(), but not bound to /bin/sh
** Mode 2: Pipe commands through stdin
*** implies interactive="false"
*** allow using any external interpreter

* Improvements to konfd
** systemd startup notification
** provide systemd unit

* konf should be a plugin
** it implies a config model
** people sometimes want a different model (NETCONF, OpenWRT uci)

* watchdog should be a plugin
** Not everyone needs this

* logging should be a plugin
** Not everyone needs this
** Should be configurable
** Custom logging action (operator messages)

* Support for audit logging
** Implement as a plugin
** Separate thing from logging
** Intended specifically for security purposes
** Could also log clish access control trace
** Feed into Linux auditd

* Pipelines
** if we have paging support then one may as well have actual pipelines
** only truly useful if it works for builtins as well as oactions
** alternative is to use pipe for "modifier" commands as Serj suggested
** pipelines are a type-3 grammar feature, no context required
** only actions with "input" property should be allowed on right side
** Noteworthy: Microsoft PowerShell has object-oriented pipelines
** (basically this is an alternative proposal to the design document)

* Native smartphone client
** Smartphone are the future
** Could work directly over SSH
** Admins want to see/fix things on the go
** Machine interface could allow button-assisted command selection
** Switch to text editor widget when string is required
** Have a selector widget for multiple choice params
** Much more comfortable to use single-handed than touchscreen keyboards
Reply all
Reply to author
0 new messages