6 Oct
2018
6 Oct
'18
12:54 p.m.
Hi Keith,
On Sat, Oct 06, 2018 at 11:33:01AM +0100, Keith wrote:
Was just thinking today about if it was ever
considered to write the VTY
history out to a file on exiting (and load it on startup)
Interesting idea!
I'm quite the fan of the up arrow and it's
been something that sometimes
annoys that I have no history after leaving the VTY.
It would seem reasonably trivial to implement, and I suppose you could
write out to files in $HOME/.osmo-bsc_history or $HOME/.config or somesuch.
Not sure if $HOME is such a good idea for "system services/daemons" like
the osmocom daemons. I wouldn't be surprised if that would either point
to a read-only mount or /tmp in various configurations.
So it would probably rather be something in /var/lib/osmocom/$program-vty_history.txt
or whatever...
$HOME/... would work better if we had an actual client program rather than
just telnet. In that case, of course, it would be logical to store the history
with the client, and not the server.
Just wondering if this was ever discussed before, if
there's any
unforseen problem with it on my part + if it would be a desirable
feature for anybody else?
I don't think it has been discussed before.
The only problem that I can see is that there can be any number of users
using any number of VTY sessions in parallel. So which history do we store?
How do we keep them separate/disentangled? Or should we create one shared
history?
Slighty unrelated: zebra/quagga also has many programs and each with their
own VTY. They then introduced something called vtysh, whihc I only read
about but never used myself. It supposedly allows you to talk
to all of the various daemons from one frontend:
https://www.systutorials.com/docs/linux/man/1-vtysh/
Definitely worth investigating if somebody is lookning for VTY usability
improvements..
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)