Change in libosmocore[master]: vty telnet: consistently never change nodes upon CTRL-C

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/gerrit-log@lists.osmocom.org/.

Neels Hofmeyr gerrit-no-reply at lists.osmocom.org
Mon Feb 4 16:44:00 UTC 2019


Neels Hofmeyr has submitted this change and it was merged. ( https://gerrit.osmocom.org/12772 )

Change subject: vty telnet: consistently never change nodes upon CTRL-C
......................................................................

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
---
M src/vty/vty.c
1 file changed, 0 insertions(+), 18 deletions(-)

Approvals:
  Harald Welte: Looks good to me, approved
  Vadim Yanitskiy: Looks good to me, but someone else must approve
  Jenkins Builder: Verified



diff --git a/src/vty/vty.c b/src/vty/vty.c
index abce887..8c89197 100644
--- a/src/vty/vty.c
+++ b/src/vty/vty.c
@@ -1217,24 +1217,6 @@
 	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. */

-- 
To view, visit https://gerrit.osmocom.org/12772
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings

Gerrit-Project: libosmocore
Gerrit-Branch: master
Gerrit-MessageType: merged
Gerrit-Change-Id: I4f339ba61f1c273fa7da85caf77ba116ae2697b1
Gerrit-Change-Number: 12772
Gerrit-PatchSet: 3
Gerrit-Owner: Neels Hofmeyr <nhofmeyr at sysmocom.de>
Gerrit-Reviewer: Harald Welte <laforge at gnumonks.org>
Gerrit-Reviewer: Jenkins Builder (1000002)
Gerrit-Reviewer: Neels Hofmeyr <nhofmeyr at sysmocom.de>
Gerrit-Reviewer: Vadim Yanitskiy <axilirator at gmail.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/gerrit-log/attachments/20190204/f5808383/attachment.htm>


More information about the gerrit-log mailing list