A bug has been reported to me, as follows. When using the "oven" program and when a person decides to edit a value, they have to type blind. There is no echo of what they are typing.
This sounds simple enough and is no doubt related to the software being ported from the IRAF environment to being a native linux executable that uses the curses library instead of the unique IRAF calls.
When I am testing at home, I have even more liberty as it is not possible to write anything to the oven at the mirror lab. I can certainly save to disk, but unless I went out of my way to copy files to one of the control room computers, this also would be harmless.
So, type "oven" at the command line. Use a down-arrow to go to "configuration and status", then type a left arrow to go there. Now just for fun, type "e" as if you wanted to edit something. You should briefly see the message "cannot enter data" at the bottom of the screen. Now use a down arrow to drop down to the "Thermocouple" line. Type "e" here and you should see "? : " appear. This indicates that the software is waiting for you to type a value. Type several digits and they will no echo. This is the bug.
Just for the record, there is another pair of magic characters.
They are dangerous and rarely used.
If you type "P" you enable the ability to edit parameters.
If you type "PK" you enable the ability to edit biparameters.
All of this works better and is more realistic if you have shared memory set up and holding a database. On my home system I use "cleaner" to do this. For whatever reason the "Load from disk" button doesn't work at home. Actually, the reason is obvious enough. When I launch "cleaner", it shows the message:
Changed to directory /u1/home/tom/Casting for user tomSo, it is looking for the file "database" in that directory and not finding it. What I can do is to just type "oven_shm -dload" in my current directory (which is /u1/oven/testing) and it does find database there. It gives no messages as to success or failure. The way to find out if it works is to launch cleaner again after this command and it shows "11 zones" now. With uninitialized shm it showed "0 zones". You may be asking, "where do I get a database file?". If you don't conveniently have one laying around, you will have to copy one from one of the control room computers at the mirror lab.
With a database loaded, running "oven" is much more interesting. For example under "Configuration and Status, I can go down to TIC, which displays 0000. I can type "e", then 0001 and I see the TIC value change to 0001. Note that 1, 01, and 001 do nothing. Likewise for changing it back to 0000, typing 0, 00, or 000 do nothing, I must type 0000.
I should mention the file "console.c". This is a file I added back in 2019. It it an interface to libcurses (I actually link against -lncurses). All the routines in this file have names that begin with "con_", the idea being to make it easy to track them down in the rest of the code. I hit what may be the jackpot here when I find "con_getstr()" which leads off with the comment:
This is used to enter values when the user types "e"Indeed con_getstr() has a call to "echo()" to start, to "noecho()" at the end, and to getstr() in the middle.
This raises another question. Just when did this bug show up? I had the idea that the bug has been there from the start when I migrated the code from the IRAF environment on the old Sun machines. A fellow at the mirror lab thinks it arose later on linux. If the latter is true (and I truly cannot say) this bug may be due to some change in the ncurses API.
There is only one call to con_getstr() in the file domenus.c. Apparently when the menu system allows data entry, there will be an "input function" specified. This is one of the functions in scans.c. Before calling that function (a function pointer is used), the routine con_getstr() is called to get the string, which then gets handed to sscanf in some input function. This makes con_getstr() a single choke point where all of this gets handled, which is very nice.
./configure makeThe make gets some crazy error with a C++ file, but that apparently happens after the library I want is built, so I don't care. I look in the "lib" directory and among other things, I see:
libncurses.aI copy this into my "newoven" directory and after a small tweak to the Makefile to use this rather than the system -lncurses I do:
make clean makeIt fails due to cfitsio header files being missing, so I do:
su dnf install cfitsio-develThe package "cfitsio" itself is already installed. After this the make finishes, but when I try running "./oven" I get:
Error opening terminal: xterm-256colorThe fix (for this experiment) is to do this:
export TERM=xterm ./ovenAnd then with this "retro" version of oven, the bug is gone, I get echo of the characters I type after I type "e" just as I should.
What about this xterm-256color nonsense? One suggestion is:
su ln -sf /usr/share/terminfo/x/xterm-color /usr/share/terminfo/x/xterm-256colorBut I have /usr/share/terminfo/x/xterm-256color on my system. I also did this, but I still get the error.
su dnf install ncurses-term
It does not change a thing.
I learn about the command "infocmp xterm-256color". I try it, and it spews out a whole bunch of stuff. So the issue is not that I don't have this in my database, but that this stupid ncurses is broken and clueless and doesn't know where to look.
For fun I run "strace -o oven.trace ./oven" (I have to install strace first) and I see:
newfstatat(AT_FDCWD, "/usr/share/terminfo", {st_mode=S_IFDIR|0755, st_size=4096, ...}, 0) = 0
newfstatat(AT_FDCWD, "/home/tom/.terminfo", 0xb991280, 0) = -1 ENOENT (No such file or directory)
access("/usr/share/terminfo/x/xterm-256color", R_OK) = 0
openat(AT_FDCWD, "/usr/share/terminfo/x/xterm-256color", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=4071, ...}) = 0
brk(0xb9b3000) = 0xb9b3000
read(3, "\36\2%\0&\0\17\0\235\1Z\6xterm-256color|xterm"..., 4096) = 4071
read(3, "", 4096) = 0
close(3) = 0
brk(0xb9b2000) = 0xb9b2000
write(2, "Error opening terminal: xterm-25"..., 40) = 40
I check the file and it is 4071 bytes in length, as the read above also shows.
cd /usr/share/terminfo/x ls -l xterm-256color -rw-r--r-- 1 root root 4071 Jul 17 17:00 xterm-256colorSo it reads the file, then declares that it cannot open the terminal, which makes no sense.
#!/bin/bash export TERM=xterm; xxxoven $@I in fact did just this and it seems to work. I forgot the "$@" business the first time and that led to confusing problems.
This does confirm that this bug arose due to some change in the ncurses library, as surprising as that is. It also shows that my sources are correct. This was not something that arose when we moved from the suns to linux, but it arose due to a change in the ncurses library on linux itself.
I don't really want to have to keep some 7 year old version of ncurses around, so I will investigate how to make our software work with the latest library.
I do have one thing to say after looking at the ncurses source distribution.
What a mess!
Apart from this bug with echo, and this second bug with xterm-256color, the whole source tree is a complex maze of twisty passages. No wonder this ends up being buggy software. The developers probably cannot keep straight whether they are coming or going.