diff options
author | Neels Hofmeyr <neels@hofmeyr.de> | 2019-02-01 00:25:55 +0100 |
---|---|---|
committer | Neels Hofmeyr <nhofmeyr@sysmocom.de> | 2019-02-04 16:43:57 +0000 |
commit | 8d04f95d96f869543a99b18fd3326ea84e9f5366 (patch) | |
tree | 4cba29140ead2a5124dbec7aea826985a65fa6d6 /src | |
parent | 9ea9dd0d5fdad50d9b2ea2bdddd9d919efab31ca (diff) |
vty telnet: consistently never change nodes upon CTRL-C
Remove any special node exiting from the VTY CTRL-C handling.
From a curious VTY transcript test glitch, I noticed weird behavior by the VTY
telnet shell: usually, when the user hits CTRL-C, that means to cancel the
current command line and present a fresh, clean prompt. However, only on the
CONFIG_NODE and CFG_LOG_NODE, a CTRL-C also exits the current node and moves up
by one level. This behavior is unexplainable and makes zero sense.
No other nodes exit on CTRL-C:
- on the ENABLE node, a CTRL-C stays on the ENABLE_NODE and doesn't exit to the
VIEW_NODE.
- any sub-nodes of the CONFIG_NODE stay unchanged, e.g. 'network' or 'bts' /
'trx', etc.
There is no apparent special meaning of CTRL-C on CONFIG_NODE nor CFG_LOG_NODE
to justify this odd choice.
Particularly, the vty transcript tests using osmo_verify_transcript_vty.py rely
on sending CTRL-C to clear the command prompt, so that we can properly test
sending '?' to the VTY during transcripts. In a live session, a '?' prints
available options and then updates the prompt with identical command arguments.
In a transcript test, that doesn't make sense, because each time the transcript
writes out a new command to run. Consider e.g. a transcript test like:
tdef_vty_test(config)# timer ?
tea Tea time
test Test timers
software Typical software development cycle
tdef_vty_test(config)# timer tea ?
[TNNNN] T-number, optionally preceded by 't' or 'T'.
To be able to issue a fresh command after '?', osmo_verify_transcript_vty.py
explicitly sends a CTRL-C to clear the command buffer. Hence there we rely on
predictable behavior of CTRL-C.
More particularly, the upcoming osmo_tdef_vty transcript tests are apparently
the first that want to test '?' behavior on the CONFIG_NODE's root level and
fall on their face, because of the implicit exit that happens only there.
Change-Id: I4f339ba61f1c273fa7da85caf77ba116ae2697b1
Diffstat (limited to 'src')
-rw-r--r-- | src/vty/vty.c | 18 |
1 files changed, 0 insertions, 18 deletions
diff --git a/src/vty/vty.c b/src/vty/vty.c index abce8871..8c89197e 100644 --- a/src/vty/vty.c +++ b/src/vty/vty.c @@ -1217,24 +1217,6 @@ static void vty_stop_input(struct vty *vty) vty->cp = vty->length = 0; vty_clear_buf(vty); vty_out(vty, "%s", VTY_NEWLINE); - - switch (vty->node) { - case VIEW_NODE: - case ENABLE_NODE: - /* Nothing to do. */ - break; - case CONFIG_NODE: - case VTY_NODE: - vty_config_unlock(vty); - vty->node = ENABLE_NODE; - break; - case CFG_LOG_NODE: - vty->node = CONFIG_NODE; - break; - default: - /* Unknown node, we have to ignore it. */ - break; - } vty_prompt(vty); /* Set history pointer to the latest one. */ |