Program that I write often crashes leaving terminal in a S-Lang library state (similar to ncurses). I would want to add a check into development's branch Makefile main all target for such an improper state and and an automatic invocation of reset command. How to approach this task?
reset does two things; you can write a shell script which detects one of them:
it resets the terminal I/O modes (which a shell script can inspect using stty)
it sends escape sequences to the terminal (which more often than not will alter things in the terminal for which there is no suitable query/report escape sequence).
For the latter, you would find it challenging to determine the currently selected character set, e.g., line-drawing. If the terminal's set to show line-drawing characters, that's the usual reason for someone wanting to run reset (e.g., cat'ing a binary file to the screen).
There happens to be a VT320 feature (DECCIR) which can provide this information (which xterm implements):
but with regard to other terminals, you're unlikely to find it implemented:
(iTerm2 doesn't do it)
(nor does VTE). You can read an extract from the VT510 manual describing the feature on vt100.net
Related
I was wondering if it is possible to get a list of windows in Tk, and destroy specific ones. I am working in R using the tcltk interface, and am calling a function written by someone else a long time ago (that I cannot edit) which is producing additional windows that I don't want.
From the documentation here, it seems that new Toplevel windows are children of .TkRoot by default. I know that Python has a winfo_children method, which I was thinking of trying to call on .TkRoot but I don't think that method is implemented in the tcltk library. I tried using tcl("winfo", "children", .TkRoot) but I am getting an error: [tcl] bad window path name "{}" (I'm not familiar with actual tcl, so I'm probably messing this command up).
Additionally, if there is a way to call winfo children, what's the best way to process the result to identify specific windows and then destroy them?
Looking at the R sources, I see that you should be doing:
tkwinfo("children", .TkRoot)
Except that I think that won't work either, as .TkRoot doesn't have a corresponding widget on the Tk side of things. Instead, use the string consisting of a single period (.) as the root of the search; that's the name for the initial window on the Tcl side of things. And I suspect that you'll just get back a raw Tcl list of basic Tk widget names without the R wrapping as I just can't see where that conversion is applied…
Be aware that the results may include widgets that you don't expect, and that you need to call it on every window recursively if you want to find everything.
I am working on a project that involves GNU Radio/GRC and am not very familiar with the software. I am trying to output data to a serial port in GNU Radio using a block, but have not found a way to do so.
I was wondering if there is a pre-defined block that I can use to put this information to a serial port (USB on a Raspberry Pi 3), or if I had to create my own block. And if I had to create my own block, what that code would look like.
I have been able to write the data to a file using the File Sink to make sure I was getting data, and was wondering if the fix is something as simple as changing the File sink to an serial port sink. See picture below:
http://imgur.com/a/BdaMZ
I also did some research and found a github repo that looks like what I need -- unfortunately, the repository that it links to is no longer there. It did mention using pyserial, which is what I believe is meant for creating my own block in python. The link to this repo is below:
https://github.com/jmalsbury/gr-pyserial
… was wondering if the fix is something as simple as changing the File sink to an serial port sink.
Yes! Or No, it's even easier:
So, in fact, you could even simply use your file sink to write to e.g. /dev/ttyS0 (or /dev/ttyUSB0, or whatever is the device name of your serial port), but you'd have to set up the serial port to work like you want it to separately first. A way of doing that would be using stty, e.g.
stty -F /dev/ttyS0 115200
prior to running your flow graph.
Note that practically all in your flow graph point points to you not being sufficiently proficient with GNU Radio to successfully exchange data. I can't cover everything here, please read the official Guided Tutorials, but:
In a flow graph like yours, where the IO is the inherently rate-limiting element, you must not use "Throttle". Throttle is really just a tool to avoid a flowgraph consuming all your CPU (and to slow down simulations)
Giving your files a .grc ending is bad practice, as that is the ending reserved for GNU Radio flow graphs.
Giving it a .txt ending is plain misleading, since there's no text involved whatsoever. The "file format" (I wouldn't even call it a format) is really just plain binary numbers, as your computer handles them; not decimal ASCII representations of these floating point binary numbers
I also did some research and found a github repo that looks like what I need -- unfortunately, the repository that it links to is no longer there. It did mention using pyserial, which is what I believe is meant for creating my own block in python. The link to this repo is below:
Don't know what you're referring to, https://github.com/jmalsbury/gr-pyserial is perfectly existing!
The program that I am trying to run takes the form program_name --arg=/some/path/goes/here, but zsh cannot perform tab completion on that path when it is in the argument flag. I end up having to type progra<TAB> /so<TAB>/pa<TAB>... to complete the path and then go back to add the --arg= part of the command. Is there a more efficient way to go about doing this?
It's likely that zsh is still trying to do file completion in your situation, it's just considering the --arg= to be the initial part of the file name causing it to not find any matches. Since there aren't any universal rules for how commands will interpret their arguments the safest option is for the shell to not make any assumptions about those arguments.
Many commands which use that type of syntax will work the same if you use a space rather than the = sign, such as program_name --arg /some/path/goes/here. Since that would be a separate argument the shell should be able to do file completion without issues.
Depending on how you have zsh configured, it may also work to use setopt MAGIC_EQUAL_SUBST. I normally have that option set and get the behavior that you are looking for, but get the behavior that you currently experience if I unset that option. But, if I use zsh -f to skip loading my configuration just enabling that option isn't sufficient so there is apparently something else in my config that was necessary, possibly just the enabling of the completion system which you would likely have done already. There could be cases where this would result in undesirable behavior, but I haven't run into any in the many years that I've been using zsh with that option set.
A more complicated option would be to write a completion function for that command which tells zsh that that option takes a file name as the argument.
I must embedd the shell of an interpreter language (most likely it will be python) inside my application. So i need a console widget in my GUI toolkit. I want to write this from ground up myself.
I know that i must start the process with pipes redirecting the standard input/output/error to my console widget. I have to set the environment variable TERM=vt100 and send a SIGWINCH signal whenever i resize my terminal.
For the output of the program i have to check the octet stream for vt100 control characters as explained here VT100 commands.
This sounds to be easy and a nice weekend hack.
But what do i do about the input? Who is responsible for echoing the characters and the line mode editing?
Do i miss something else which is serious?
To control the input in console, you have set it to canonical mode. Please check this like link, it may help you:
Canonical vs. non-canonical terminal input
I am implementing my own shell. But to supprt for command history, I need to use monitor up/down arrow key as in standard shells. Please tell me how to handle arrow keys as input or does these keys generate signals? Please elaborate.
Arrows and other special keys send you special strings that depend on the terminal being used or emulated. To deal with this most simply, you could use a library such as termcap. Even simpler, given your stated purpose (command history support), would be to use readline, which basically does it for you (and lets the user customize aspects of their preferred mode of working across the many applications that link to the same library).
It depends on how gnarly you're expected to go. Worse case, you're writing the keyboard interrupt handler. Best case, something like readline.
Check with your prof for direction here. Also check your course materials to see if the prof has given links/examples regarding this.
Does the assignment specifically say you need to have a "cursor key driven" command history?
Simple option is to mimic the shells fc e.g.
$ ls
... file listing ...
$ fc -l
1 ls
2 fc -l
$ fc -r 1
... file listing ...
and (while I'm presenting established ideas as my own, might as well go all the way) to be able to edit the command line you could use
fc -e start end
to write the history from start to end into a file, launch an editor and then execute the resulting file as a script. This way your shell is not using a library, but launching commands and executing scripts, which is what shells are supposed to do anyway.