I would like a R code that access a program and send a command to it. More specifically, this programm connect to a server and changes my IP address and I would like to change the IP sometimes during my R routines.
I using this kind of code below to open and close the program, but I can't figure out how to connect (press the button in Windows 10, but using code in R).
shell("start windscribe.exe")
close<-"TASKKILL /IM windscribe.exe"
shell(close)
Related
I'm writing an app that allows an Arduino plugged in via USB to send serial data to the app to graph it in realtime. It can scan available ports for the Arduino and attempt to connect to it, but I'm running into permissions issues whether I use pyserial or QtSerialPort. I have added my user to the groups tty, uucp, and dialout. (When listing ports I see that they belong to uucp.) This doesn't seem to do anything. I can chmod a+rw the port every time the Arduino is plugged in but this is not practical because less technical users (i.e. my kids) need to be able to plug it in and use it via a GUI that I'm writing. I've seen suggestions to run the whole script with sudo but this seems less safe than it needs to be, and also requires typing in the command line.
Is there a way to read from the serial port without resetting permissions every time I plug the USB cable in? Or if not, is there an accepted way to do this from the GUI to make sure the permissions are right before the attempt to connect, without running the whole program as sudo? I'm building this on Linux (Arch) btw.
I solved this using udev rules. I created the rules file, which I called /etc/udev/rules.d/80-arduino.rules, and inside I put the following:
SUBSYSTEMS=="usb", ACTION=="add", DRIVERS=="usb", ATTRS{idProduct}=="0042", ATTRS{idVendor}=="2341", ATTRS{manufacturer}=="Arduino (www.arduino.cc)", ATTRS{serial}=="85734323231351404021", RUN+="/bin/arduino_added.sh", RUN+="/bin/device_added.sh", MODE="0660"
This selects for my specific device by serial number as well as manufacturer (ATTRS{serial}=="85734323231351404021"), runs a little script that writes something to a logfile it creates in /tmp (for debugging), and the MODE="0660" opens the port with permissions to let it be accessed.
I had to mess with it a bit to get it to work. Running sudo udevadm control --reload was enough to get the script to write to the logfile each time it was plugged in, but I had to reboot the computer to get it to work with the permissions for some reason.
I have an application written in C which uses qemu and its output is continuously displaying itself on the qemu window.
Now what I want is to get this output over the network.
I need some changing in the overall command of qemu. I have read the documentation.
But it is not happening the way I want.
I am trying to run some Rscripts on a remote server which has a fixed IP-Adress.
Background is the following.
I connected a Front-end web app with R and am able to insert different values, which are then passed to R, where different outcomes are evaluated.
Everything works fine when I run it locally.
I want to be able to run the Web-app from every location, so I set up an RServer with username, password etc.
What I want to next is to establish a connection between R and the server.
I wasn't able to find anything on that topic yet, so I hope you can help me with this.
Establish a connection to the Rserver with some IP.
Login with my username and password
Tell my R script where to find the Rscript.exe file
Doing that locally I just tell my php-file:
$command = '"C:\Users\Username\Documents\R\R-3.3.1\bin\Rscript.exe" "'.__DIR__.'\rfile.R" '.$json;
So I tell him where to find my RScript.exe and to read with that my rfile.R.
Thanks for your help.
We are trying to transfer file using minicom (in host pc) and picocom(in arm based evaluation board) combination.
On evaluation board side we have /dev/ttygserial and on host pc side we have /dev/ttyUSB0.
Host side minicom setup is as follows,
Serial device - /dev/ttyUSB0
Baud Rate - 115200
Steps to set minicom in receiving mode.
press ctrl+a R , select zmodem.
Now minicom will start waiting for file from other end.
On evaluation board side we use picocom as follows to send the file.
On command line execute picocom -b 115200 -s "sz -vv" /dev/ttygserial
Now press Ctrl+A and Ctrl+S.
Picocom will ask for filename by printing **file
Once file name is provided and enter is pressed file is sent to host.
All this steps works and we are able to transfer different types of files from evaluation board to pc but now we want to put this procedure into C code. For that I have following doubts,
Is it possible to set minicom in file reception mode using single command? (meaning noninteractively) ?
Is it possible to send file using picocom in single command (meaning noninteractively)?
Any other suggestions?
In other sites also people have asked this kind of question but questions unanswered yet.
So I decided to look into picocom code and found that it is very simple to make a change in that code.
I have made send command non-interactive, I will make receive command too non-interactive and post full code here so that it can be referred by anyone who has a similar problem.
I wanna write a remote console, working like a telnet server. User is able to use telnet to log into the server, then write some commands to do some works.
A good example for this is the console of router os. What I'm confusing right now is, I can accept user's input, do someting then print some texts back, but I wanna use ncurses to make the console has more features(such as "cmd auto-complete", syntax color...), so how can I do that? Because the console is in user side, if the server calls ncurses APIs it'll just change stuffs on server...
Maybe this is a stupid question but I'm really newbie on this. Any suggestions are appreciated.
This is more difficult than you might think.
You need to understand how terminals work - they use special control sequences for e.g. moving the cursor or color output. This is described by a terminfo file which is terminal-specific. Ncurses translates API calls (e.g. move cursor to a certain position) to such control sequences using terminfo.
Since the terminal (nowadays xterm, gnome-terminal, screen, tmux, etc) is on the client side, you have to pass the type of terminal from the client to the server. That's why e.g. ssh passes this information from the ssh client to the server (try echo $TERM in your ssh session - it might be 'linux' if you are logged in via the console, or 'xterm', if you are using X and an xterm). Also, you better have the respective terminfo available on the server.
Another piece of the puzzle is pseudo terminals. As nowadays relatively few people use serial terminals, their semantics are emulated so that applications and libraries (e.g. curses and its friends) originally developed for serial consoles keep working. This is achieved via pseudo terminals - these are like pipes, a master and a slave device communicates, anything written on one side comes out on the other side. For a login process, getty, for example, can just use one side of a pty device and think it's a serial line - your server program must handle the other side of the pty, sending everything it gets from the pty to your client via the network.
Terminal emulators also use ptys, type tty into your terminal, and you'll get something like /dev/pts/9 if you're using a terminal emulator. On the other side of the pty it's usually your shell, communicating with your terminal emulator via the pty.
Your client program can more or less just use standard input and standard output. If your terminal information is correct, the rest will be handled by your terminal emulator, just pass anything you receive from your server program to stdout, and send anything you read from stdin to your server program.
Hopefully I haven't left out any important detail. Good luck!
It is possible to have ncurses operate on streams other than stdin and stdout. Call newterm() before initscr() to set the input and output file handles for ncurses.
But you will need to know what sort of terminal is on the remote end of the connection (ssh and telnet both have mechanisms for communicating this to the server) and you will also want a fall back to a non-ncurses interface in case the remote end is not a supported terminal type (or if you can't determine the terminal type).