You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your enhancement proposal related to a problem? Please describe.
Issue raised by @stig-bjorlykke: #24138 (comment)
A user would like to select a command (in that particular example it is AT modem commands) but still use all shell commands available in the system.
Describe potential solutions @stig-bjorlykke proposed a default handler which is called when no command match is found. The default handler would be the one from selected command. However, imo this is not generic enough since that opens door for conflicts if selected command accepts strings which match registered commands.
Another option is to use some kind of user defined escaping which when used as prefix opens access to all set of commands despite being in select mode (e.g. shell as escape code and shell log status to envoke log command). Escape string would be user defined to prevent conflicts.
Last alternative is see is to do nothing and stay where we are. alt+r terminates selection. Maybe add shortcut to suspend selection for next command or one to resume?
The text was updated successfully, but these errors were encountered:
Maybe if command starts with a special character, not allowed in the command syntax, it would indicate that we want to access the root commands tree? This should be feasible for implementation.
For example: selected_cmd_tree_cmd argument1 argument2
Calling root command despite other command is selected: ! shell colors off or ~ shell colors off or something similar.
From the implementation it looks like select is solving a different use case than originally requested. The use case for AT commands is to register a shell command handler which will be called instead of printing the text "command not found". This will not conflict with any other registered commands, and will allow the given command handler to determine if it can make use of the command or not. Doing this will coexist with all other shell commands.
In the AT use case the "default" command handler will reject everything not starting with AT+ or AT%, and when rejected this should give "command not found". I think using select for this is overengineering.
Having to use a different prefix for regular shell commands, or enter and exit a special mode, will not really solve the use case.
Is your enhancement proposal related to a problem? Please describe.
Issue raised by @stig-bjorlykke: #24138 (comment)
A user would like to select a command (in that particular example it is AT modem commands) but still use all shell commands available in the system.
Describe potential solutions
@stig-bjorlykke proposed a default handler which is called when no command match is found. The default handler would be the one from selected command. However, imo this is not generic enough since that opens door for conflicts if selected command accepts strings which match registered commands.
Another option is to use some kind of user defined escaping which when used as prefix opens access to all set of commands despite being in select mode (e.g.
shell
as escape code andshell log status
to envoke log command). Escape string would be user defined to prevent conflicts.Last alternative is see is to do nothing and stay where we are.
alt+r
terminates selection. Maybe add shortcut to suspend selection for next command or one to resume?The text was updated successfully, but these errors were encountered: