zephyr: Creating shell with current SHELL_DEFINE() is not practical

I have been porting multiple network related shells to use new shell and noticed some issues how the shells are defined. Currently one needs to do something like this in order to define a shell.

SHELL_CMD_REGISTER(net, &net_commands, "Networking commands", NULL);
SHELL_UART_DEFINE(shell_transport_uart);
SHELL_DEFINE(net_shell, "net:~$ ", &shell_transport_uart, 10, SHELL_FLAG_OLF_CRLF);

Currently this code is called by subsys/net/ip/net_shell.c when CONFIG_NET_SHELL=y is set.

There are other network related shells that can co-exists with this network shell. For example if one defines CONFIG_NET_L2_IEEE802154_SHELL=y then IEEE 802.15.4 specific shell is created. It is also created similar way as generic network shell.

SHELL_CMD_REGISTER(ieee802154, &ieee802154_commands, "IEEE 802.15.4 commands", NULL);
SHELL_UART_DEFINE(ieee802154_shell_transport_uart);
SHELL_DEFINE(ieee802154_shell, "ieee802154:~$ ", &ieee802154_shell_transport_uart, 10, SHELL_FLAG_OLF_CRLF);

It really looks like that the backend configuration should not be done like this for a shell. In these examples, the actual shell implementation is in proper place but how this shell is used should be placed in some shell specific directory and controlled by generic config options. The shells in question do not really care about the backend, they are just generic shells that can be used with any backend.

It looks like that the SHELL_DEFINE() could easily just have the two parameters like this SHELL_DEFINE(net_shell, SHELL_FLAG_OLF_CRLF);. The other parameters should be defined in some other file.

Also noticed that if I enable various shells at the same time, and this is quite common case with networking, the history of the shell stops working.

About this issue

  • Original URL
  • State: closed
  • Created 6 years ago
  • Comments: 15 (15 by maintainers)

Most upvoted comments

I have had totally different usecases in mind. There user does not need to do anything in the main.c to get shell to use it, this is how the old shell worked. It would be very convenient for a user to just say that he/she wants to use a shell in config file, and if the default shell settings are ok, then a shell with UART backend would be created automatically without any extra coding.