How to send multiple keystrokes via telnet. In daily routine, I connect to a server which accept "ESC+3" and "ESC+E" like keystrokes. Now I am trying to automate the process using some programs. For that I have to give keystrokes via programatically. If it is a single line command means, it doesn't make that much complex. But the application expect keystrokes also. So, is there any way to solve this problem.
ESC is just a normal (non printable) character with ASCII code 0x1b. So, if you have an open file descriptor fd to your service, for sending ESC+E the following will do:
write(fd, "\x1bE", 2);
For interactive ttys, there is a program called expect. I haven't used it for a long time, but I was able to find this link: https://www.lifewire.com/linus-unix-command-expect-2201096.
It'll do what you want, I think. It was originally written in TCL (back before Linux was invented). There might be newer versions in something like Python, or some such.
Here's the "blurb":
INTRODUCTION
Expect is a program that "talks" to other interactive programs
according to a script. Following the script, Expect knows what
can be expected from a program and what the correct response
should be. An interpreted language provides branching and
high-level control structures to direct the dialogue.
Related
When I run the Snowflake CLI and it is returning a large result set, if I press Ctrl-C or Ctrl-Z, it does not have the normal behaviors of either breaking the program or pushing it to the background where I could then kill it manually.
How can I get Ctrl-C and Ctrl-Z to work correctly on the Snowflake CLI?
This is in a Linux environment. And well-behaved command line tools should behave as described above.
The exact command is 'snowsql'. I'm using the standard SNOWSQL_* environmental variables to send the CLI configuration information.
The big result set is often the result of me asking for more data than I intended. So it's mostly about dumb user error, but still, we all do it.
This is not a problem if it's a long running query. Long queries easily break with Ctrl-C.
Is there some kind of setting? That setting could either be in Snowflake, or something strange I'm doing in my bash session--though no other major CLIs are having issues.
If this is normal product behavior, I'd appreciate confirmation of that to. If that is the case, I'll submit a product enhancement request.
Workaround are acceptable. If this is just how snowsql will behave, I'm open to Bash tricks since it would be easy enough to "wrap" the snowsql in a function.
This is not a complete solution, but using 'rlwrap' will at least handle Ctrl-Z as desired, which then makes it easy to kill. Just do something like this:
rlwrap snowsql --foo --bar
Using whatever parameters you need of course.
When you press Ctrl-Z, it will immediately push the job to the background. From there, kill it like any other job.
Still a bit more work than just handling the characters correctly, but it's a decent work-around.
The 'rlwrap' command is a little utility that I've used in a number of situations that have strange CLI behavior. I'm not sure what it's intended to do, but it handles Ctrl-* characters the way you'd expect, and it can make the arrow keys behave better in some situations.
I've even used rlwrap to make my own command prompts. E.g. S3 has brutal syntax, so I wrote an S3 prompt for myself using rlwrap, and it's because of rlwrap that all the control and arrow keys work right in that handy little home-grown prompt.
For snowcli, rlwrap is a decent workaround.
I wanted to create a program that could open another program and interact with it. For exemple, would it be possible to create a C program that opens mysql.exe with its right parameters and "paste" or print the password required for it to run? If its too hard to do in C, is there any other language that could do it easier?
IF youe are talking about command line programs, then you should look at pipes and how to use them from within C.
If we are talking about graphical/GUI programs: There is no standard way doing this, because it depends on the operating system and the GUI-Framework.
In Windows you can start a program, get its process Id, get the windows of the process and post messages to the window.
But for such tasks i would try to use some autmation language/frameworks.
Maybe have a look at autoit.
Controlling other programs UI and inputs is exactly that it is made for
I have a set of independent programs that I wrote in C. I would like all of them to write their log to the same file. Obviously comes the issue of control access. Two or more of them could end up writing simultaneously.
What is the most pragmatic way to achieve this?
I came across solutions using pthread/mutexes/etc but that sounds overkill implementation for something like that.
I am also looking at syslog but wonder if this is really for the purpose of what I need to do?
I feel that I need a daemon service taking the message and control when they are written. I wonder if that already exists.
I am also looking at syslog but wonder if this is really for the purpose of what I need to do?
Yes
I feel that I need a daemon service taking the message and control when they are written. I wonder if that already exists.
It exists in the Unix derivatives (including Linux) and is called... syslogd
More seriously, the syslog function is intended to pass a message to a syslogd daemon that will route it according to its configuration file. Most common uses include writing it down to a file or to the system console (specially for panic level messages when nobody can be sure whether the file system is still accessible). The syslog system may come with more features than what you are asking for, but it is an extremely robust and extensively tested piece of software. In addition, it is certainly already active on your system, so you should have a strong reason to roll your own instead of using it.
You have two way :
First : Using something that already exist.
For the logging part, syslog (and syslog-ng) are well-know and well-used.
From that point, you can parametre syslog-ng to listen to an ip connection, and scan a dir for new file.
Your program can, when they will want to log, either connect to syslogng directly and send the log, and if the connection fail, write a new file in the directory that syslogng watch.
That allow to not have the loss of the log is syslog-ng are interrupted for a reason or another.
Second : Develop something really similar to syslog-ng.
In that case, it's up to you.
I want to make a program that reads a serial port (V.24).
with the info from the serial port I need to split a string up, and add it to a MySQL database.
I don't know C very well, so I need some help with what functions I should use
The program has to run under windows XP, and I have to make it an service.
thanks,
Sebastian
Services are a pain to debug. I suggest writing your code as a normal application first - command line will do - and then, once it works, converting it to a service (which is a mechanical process).
In general, Windows GUI based apps in C are a PITA to write for the first time. Very finicky, very sensitive. A command line app or a service will be quite a bit easier.
I recommend reading this. As for if this will work as a service, I am not sure, but it should.
You can also look at existing open source projects, to see if you can take that source as a starting point, or if they already solve your problems.
Is it possible to listen for a certain hotkey (e.g:Ctrl-I) and then perform a specific action? My application is written in C, will only run on Linux, and it doesn't have a GUI. Are there any libraries that help with this kind of task?
EDIT: as an example, amarok has global shortcuts, so for example if you map a combination of keys to an action (let's say Ctrl-+, Ctrl and +) you could execute that action when you press the keys. If I would map Ctrl-+ to the volume increase action, each time I press ctrl-+ the volume should increase by a certain amount.
Thanks
How global do your hotkeys need to be? Is it enough for them to be global for a X session? In that case you should be able to open an Xlib connection and listen for the events you need.
Ordinarily keyboard events in X are delivered to the window that currently has the focus, and propagated up the hierarchy until they are handled. Clearly this is not what we want. We need to process the event before any other window can get to it. We need to call XGrabKey on the root window with the keycode and modifiers of our hotkey to accomplish this.
I found a good example here.
I think smoofra is on the right track here; you're looking to register a global hotkey with X so that you can intercept keypresses and take appropriate action. Xlib is probably what you want, and XGrabKey is the function, i think.
It's not easy to learn, I'm afraid; I did locate this example that seems useful: TinyWM. I also found an example using Java/JNI (accessing the same underlying Xlib function).
You should look at the source code of xbindkeys.
Xlib programming is pretty arcane, documentation is hard to find, and there are subtle portability issues. You'll be better off copying some battle-hardened code.
One way to do it is to have your application listen on a certain port, or socket file, for incoming requests.
Then you can write a small client application that connects to that port or socket file and sends commands to the running application.
Then you can configure your window manager to bind certain key combinations to launch your small client app.
In UNIX, your access to a commandline shell is via a terminal. This harks back to the days when folks accessed their big shared computers literally via terminals connected directly to the machines (e.g. by a serial cable).
In fact, the 'xterm' program or whatever derivative you use on your UNIX box is properly referred to as a terminal emulator - it behaves (from both your point of view and that of the operating system) much like one of those old-fashioned terminal machines.
This makes it slightly complicated to handle input in interesting ways, since there are lots of different kinds of terminals, and your UNIX system has to know about the capabilities of each kind. These capabilities were traditionally stored in a termcap file, and I think more modern systems use terminfo instead. Try
man 5 terminfo
on a Linux system for more information.
Now, the good news is that you don't need to do too much messing about with terminal capabilities, etc. to have a commandline application that does interesting things with input or windowing features. There's a library, curses, that will help. Lookup
man 3 ncurses
on your Linux system for more information. You will probably be able to find a decent tutorial on using curses online.