Is there a way to match terminal/console features with entries in terminfo database?
For example, to find a closest match to Windows console or other type of non-traditional terminal.
There are no online services, so I expect that the problem is non-trivial and it is interesting to know why.
UPDATE: Terminfo database gives a set of features for a known terminal type or name. I am trying to do the reverse task - match features of unknown terminal against existing terminfo entries.
UPDATE2: How it should work...
I select my terminal capabilities from a long list
Matcher finds profiles that are either
2.1. implement all those capabilities exactly with no other capabilities
2.2. implement almost all capabilities exactly with no other capabilities
2.3. implement capabilities exactly with some other capabilities
2.4. implement almost all capabilities and adds some other capabilities
Thanks for your question. Try this, with ncurses package installed:
infocmp | grep _Cap_name_
or
infocmp _terminfo_name_ | grep _Cap_name_
and
infocmp [-d|-c|-n] _wanted_ _have_
infocmp compares the contents of two terminfo terminals, or displays the terminfo entry (binary) as termcap (human readable text)
On my system terminfo(s) are here:
/usr/share/terminfo
/lib/terminfo
I reference _Cap_name_ here at opengroup.org
Because you are on Windows (probably without Cygwin) you may have to manually check the capabilities of the TERMs you expect, and build in workarounds based on that pre-knowledge, but its Windows, so there can't be that many.
TERMINFO=/user/share/terminfo toe
This gets you a list of terminals. If you have control over the server, add a terminfo file yourself, write it as text in either termcap format then convert it or in terminfo info format and then compile it. That way you can start with dummy+linewrap. Or try ansi+idl.
NOTE: I agree with the other comment about using a VT100/VT102 library.
According to your revised OP, again using ncurses library, C you can query the terminal using tget. I am not aware of a way to iterate the capabilities without knowing what they might be before making a call to tget, however I know that it will return 0 for capabilities that return integer values and are not found, eg. cMax = tget("max_colors");.
According to terminfo, when compiling a terminal info configuration, it is possible to provide, (1st) over-rides, (2nd) included terminals, optionally (3rd) excluding included terminals with certain capabilities. This however still requires write access to the target server terminfo database directory, so your resulting terminfo file can be uploaded.
The terminfo database provides both a way for servers to provide a terminal, AND for programs (including remote ones) to interpret a provided terminal.
So far the answer is http://man7.org/linux/man-pages/man5/terminfo.5.html so I will post better results when I get more time.
Related
autoscan produced a series of function checks (AC_FUNC_* and AC_CHECK_FUNCS), and AC_CHECK_HEADERS. Now I need to pull in gnulib code. Do I just try to import every function and header that autoscan identified? Half of them don't show up in the gnulib-tool --list output. Or do I wait until ./configure fails on some platform?
My suggestion would be to ignore autoscan entirely and instead try to figure out which platform you're targeting.
In particular autoscan will try to add tests for functions that are available in every single platform since 1990, but might be missing on a non-SysV OS for instance.
Start with a base platform target (such as C99 and the latest POSIX), and then figure out which other OSes you want to target and what they are missing.
Don't try to cover bases for OSes you have no access to, it's likely you won't actually know what is needed for them to build, let alone run.
Full disclosure: I have changed my opinion on gnulib over the years and not suggest it to be used anymore, if at all possible.
There are two ways to determine which list of gnulib modules you might need:
You can scan your source code or your object files (with nm) by hand.
You can import all the POSIX header file modules via gnulib-tool, then add -DGNULIB_POSIXCHECK to the CFLAGS, compile your package, and analyze the resulting warnings.
Also, some gnulib overrides exist for the sake of old platforms only. You can read the list of what each override fixes, and apply your own judgement.
I sometimes test Python modules as I develop them by running a Python interactive prompt in a terminal, importing my new module and testing out the functionality. Of course, since my code is in development there are bugs, and frequent restarts of the interpreter are required. This isn't too painful when I've only executed a couple of interpreter lines before restarting: my key sequence when the interpreter restart looks like Up Up Enter Up Up Enter... but extrapolate it to 5 or more statements to be repeated and it gets seriously painful!
Of course I could put my test code into a script which I execute with python -i, but this is such a scratch activity that it doesn't seem quite "above threshold" for opening a text editor :) What I'm really pining for is the Ctrl-r behaviour from the bash shell: executing a sequence of 10 commands in sequence in bash involves finding the command in history (repeated Up or Ctrl-r for a search -- both work in the Python interpreter shell) and then just pressing Ctrl-o ten times. One of my favourite bash shell features.
The problem is that while lots of other readline binding functionality like Ctrl-a, Ctrl-e, Ctrl-r, and Ctrl-s work in the Python interpreter, Ctrl-o does not. I've not been able to find any references to this online, although perhaps the readline module can be used to add this functionality to the python prompt. Any suggestions?
Edit: Yes, I know that using the interactive interpreter is not a development methodology that scales beyond a few lines! But it is convenient for small tests, and IMO the interactiveness can help to work out whether a developing API is natural and convenient, or too heavy. So please confine the answers to the technical question of whether readline history-stepping can be made to work in python, rather than the side-opinion of whether one should or shouldn't choose to (sometimes) work this way!
Edit: Since posting I realised that I am already using the readline module to make some Python interpreter history functions work. But the Ctrl-o binding to the operate-and-get-next readline command doesn't seem to be supported, even if I put readline.parse_and_bind("Control-o: operate-and-get-next") in my PYTHONSTARTUP file.
I often test Python modules as I develop them by running a Python interactive prompt in a terminal, importing my new module and testing out the functionality.
Stop using this pattern and start writing your test code in a file and your life will be much easier.
No matter what, running that file will be less trouble.
If you make the checks automatic rather than reading the results, it will be quicker and less error-prone to check your code.
You can save that file when you're done and run it whenever you change your code or environment.
You can perform metrics on the tests, like making sure you don't have parts of your code you didn't test.
Are you familiar with the unittest module?
Answering my own question, after some discussion on the python-ideas list: despite contradictory information in some readline documentation it seems that the operate-and-get-next function is in fact defined as a bash extension to readline, not by core readline.
So that's why Ctrl-o neither behaves as hoped by default when importing the readline module in a Python interpreter session, nor when attempting to manually force this binding: the function doesn't exist in the readline library to be bound.
A Google search reveals https://bugs.launchpad.net/ipython/+bug/382638, on which the GNU readline maintainer gives reasons for not adding this functionality to core readline and says that it should be implemented by the calling application. He also says "its implementation is not complicated", although it's not obvious to me how (or whether it's even possible) to do this as a pure Python extension to the readline module behaviour.
So no, this is not possible at the moment, unless the operate-and-get-next function from bash is explicitly implemented in the Python readline module or in the interpreter itself.
This isn't exactly an answer to your question, but if that is your development style you might want to look at DreamPie. It is a GUI wrapper for the Python terminal that provides various handy shortcuts. One of these is the ability to drag-select across the interpreter display and copy only the code (not the output). You can then paste this code in and run it again. I find this handy for the type of workflow you describe.
Your best bet will be to check that project : http://ipython.org
This is an example with a history search with Ctrl+R :
EDIT
If you are running debian or derivated :
sudo apt-get install ipython
So at work, we check computer's specifications, and need to print these in a standard format. I know how to set up a PXE server already, but I was wondering if it were easy to get a program (or write a script) that will check the computer's hardware (processor, memory, hard drive), and print it over the network.
My thoughts are that I can boot a very simple linux os over PXE, and run a script to do the dirty work. However, I'm not sure how to set it up to use a network printer, or which script to use for that matter.
All the computers have the same architecture, (x86), so a single implementation should work for all of them.
I would be inclined to avoid using a printer directly here and use something like scp or netcat to send back the information you discover.
Edit:
There are a number of tools that might help collecting the data itself, depending on what exactly you want to collect. I've found dmidecode to be very useful. Potientally it can tell you the version of the BIOS, memory stick size/speed/locations and quite a lot of very detailed information. It is buggy on some older hardware with broken DMI tables though. lshal, lshw, lspci and lsusb are all fairly common on linux installations and rather useful for these things.
Have a look at GLPI. It's a good open source software used to manage IT tickets, but, it also integrates a IT infrastructure management that could turn our to be useful in your case.
There is a small piece of software to be installed on each remote client (this could be done remotely and silently) and then you can collect a lot of information and match it by IP addresses
We use 'pdsh' to manage our global network. We have a naming convention of hosts that makes the host expression easy to write. So to continue the ls### suggestion to collect the info on a collection of hardware, we would write a command like this:
[root#admin-console ~]# pdsh -R exec -w china-[1-1024] ssh %h lshal > china-lshal-cabinet-01.log
pdsh prefixes the host name to the output lines and as it runs as a concurrent operator the lines will collate. A simple sorting script using the, say "china-[1-1024]:" tag is needed to get them organized. You could also make the pdsh run sequentially by limiting its concurrency but if you are running large configurations you would want the concurrency.
I want to examine exactly how my code operates when using other libraries to which I do not have the code for. Whilst I can do this online (i.e. with FileMon, RegMon and TCPView from SysInternals), I was wondering if there was a good offline method that would allow me to run up my code in a virtual machine, shutdown the virtual machine and diff the entire VM image?
Since persistent modifications to the system is either in the filesystem on in the registry, you could have a little program that list all the files on the hard drive and also dump the registry.
Then you can also do it after program operation and do a simple file diff.
If you are using virtualbox, I think that you can do the mounting of the disk image offline (i.e. virtual machine not running). However dumping the registry from offline files may be harder.
See "Mount vdi" on google.
All integration testing surely will use code for which you don't have the source, your framework libraries, database drivers, databases, comms libraries. Some of which may not even be on the same machine your code is. I'm not clear exactly what you would hope to achieve. You make some calls to a queueing system, it does all manner of secret squirrel stuff. You diff before and after, now what can you say? Do you know what data formats there ought to be represent your request?
I see tests as being defined in terms of the published behaviours of the libraries and systems I'm working with. Example for a database: I execute some business actions which are supposed to create Orders. I know the orders I defined, do they appear in the database? In defining my tests I can specify explict expected outcomes in terms of records in a database. I can then even automate the tests - compare an extract from the database with expected results.
I want to work with a modem interfaced on a serial port on an embedded platform.
Here are some solutions I have rejected so far :
Expect plus a terminal program :
My (cross)build system does not have any package rules for expect, and according to the installation instructions from the expect sources, the configure script needs to be interactive because it does some test with the terminale it is invoked in. Thid does not look like something you want to do when cross compiling.
Python plus pyserial :
I would love to use this, but the size of the whole thing won't fit on my limited flash space.
Chat (from the pppd package):
Well, I may give it a try but it is very, very limited
So I am looking for some sort of lightweight, embeddable expect replacement. I have no knwoledge of lua. Would it be a good candidate for expect like scipting ?
Well, Expect is just Tcl plus extensions to drive other programs via pseudo-terminals and do pattern-matching on the results. If you just want to drive a serial port you can drop the external terminal program and have Tcl drive the serial port directly - see sample code. See also the Tcl Wiki page on cross-compiling.