I am using Tera term to control multiple serial channels (6).
I am connected to all of them at the same time.
I would like to apply the macro at the same time on all the windows.
I have been looking around but not been able to find a solution.
I wrote a batch file that call teramacro.exe and connect to each port. But the macro is done one port at the time while I would like to see it synchronously. If I cut my script in single actions, the batch file then try to open a new window (unsuccessful since a previous one is already connected).
Regards,
Marc
Try this in your batch and it works
start ttermpro.exe /F=config1.ini
start ttermpro.exe /F=config2.ini
you can open multiple teraterm windows. All the opened windows are shown as tabs below the window (just like task manager in windows OS)
Related
I'm aware of the use of lisp funcitons window-configuration-to-register and jump-to-register, and also packages like desktop.el and winner-mode.
These can all be used to save a layout during a session and recover it sometime later. I can get these to work nicely.
However if I'm running in daemon mode and am attached via emacsclient - if I try save a layout to a register, for example - I do not seem to be able to recover this layout in a separate emacsclient on the same daemon using any of the above methods - even though they share exactly the same windows.
Can anyone suggest a lisp function or any other methodology to allow to persisting of a client window layout after closing the original emacsclient session?
I should add I have no option but to use use emacs in console.
Update:
To half-answer my own question -
Saving the frame configuration to a register seems to work:
C-x r f – frame-configuration-to-register
C-x r j – jump-to-register
It's a bit shakey - when you jump back to the register you seem to have to exit the frame using 'C-x 5 0'.... after that you're still left with an underlying client frame that you can exist using 'C-x C-c' without killing the daemon.
If you try to directly exit the register stored frame using other methods it will either not work at all, or you'll kill the daemon entirely!
So it looks to me like jumping to the register seems to kinda grab ownership of the daemon process.
So follow-up questions:
1) Is there a way to make this play a bit nicer with the daemon?
2) Is there a way to automatically save your frame to a register (which will persist on the daemon) when emacs client exits or dies?
2nd Update
Actually having used it for a day - the above doesn't really work at all - the behaviour is random when restoring windows - sometimes it works, and it is often impossible to quit the emacsclient using any command!
I often find myself running kill on the emacsclient - which in-turn kills the daemon process as well as the client!
To answer my own question and having tried many ways to achieve the above, I've only found one method that at least so far has proved stable/reliable even when using the daemon - this is to use the workgroups2 pacakge that is available on Melpa.
I also noted that the original workgroups package (of which workgroups2 is a more recent fork) also works, but has more limited funcitonality. This is also available from Melpa.
The key default commands on workgroups2 that will interest you are:
C-c z c - create
C-c z v - view
I refer you to the manuals for more details - I've included reference links below to the 2 packages
https://github.com/tlh/workgroups.el
http://workgroups2.readthedocs.io/en/latest/
I have started running a script on MATLAB that takes days to finish. Usually, if I changed my mind and I don't want wait for it to finish and I get content with the intermediate results, I highlight the command window and press Ctrl-C to break the code.
Now, I have run MATLAB. But its desktop got kinda stuck in the background. When I try to restore the desktop from the toolbar, it does not restore. But I know from the task manager that the process is running and is consuming Memory and CPU performance. So, I am kinda stuck. I don't want to kill the process because I need the intermediate values in the workspace, and I can't open the desktop to break the code using ctrl-c.
Is there any solution? For example, is there any command that can be used in the command prompt to act as ctrl-c for MATLAB?
I am using MATLAB R2012b and Windows 8.
Quick try to fix the recent Problem:
Try ty set a higher priority to matlab.exe in the Task Manager. (Right click -> Priority -> Higher than normal). Then see if you can get the window to front.
Some approaches to avoid this problem in future:
Try to optimize your code. For starters look at: http://de.mathworks.com/help/matlab/matlab_prog/vectorization.html
Use Matlab compiler for faster execution: http://de.mathworks.com/products/compiler/
Include some drawnow commands at stratetic positions in the code. This allows matlab to process the Event Queue and capture ctr-C commands.
Save intermediate results to output files. For example you could write an output file all 30 min with your intermediate results. Easyiest way would be just save(filename). Then a .matfile with all your workspace variables is generated. You can than kill the process in the task manager, without loosing too much results.
I need to know when the database server has been started, something like when the dbsrv*.exe has been launched. (* for version 9 - 12).
There is a log accessible from the tray icon but with a limited number of rows so I can't see the start time.
Simply that: PowerShell command
I am using run-octave in Emacs to trigger octave. Something is acting abnormally.
Every time I hit TAB to complete, there would be a tailing ^M; If I edit a .m file using edit a.m, it would start a new frame instead of a new buffer and the prompt is waiting for the closure of that frame so it would not respond to any input. How could I configure .emacs so that run-octave would behave normally?
Any comment is appreciated!
You seem to have two problems. I'm not sure about the trailing ^M, which seems to be caused by some sort of Windows/Unix CR/LF problem, but maybe I can help with the second problem.
The edit command uses the EDITOR environment variable to decide what to run. It seems that yours is either set to emacsclient or has defaulted to it. You haven't said whether you're on Unix or Windows, so I'm going to assume the former: you'll have to change this a bit for Windows.
To avoid the waiting thing, try running octave with a different EDITOR. For example, try out running
EDITOR='emacsclient -n' octave
When you type edit foo, it should bring up an Emacs buffer (if you want a new frame as well, use -c too) but not wait until you're done.
If this fixes things for you, you could change your ~/.bashrc to include the line
export EDITOR='emacsclient -n'
From within a MATLAB GUI application, I'm starting an external program (a console application on Windows) that takes care of reading data from a measurement system. The data is stored in several files that are processed by the MATLAB application as soon as the external program has finished. The problem is this:
The external program, when run on the command line, can be gracefully stopped by issuing a SIGINT (i.e. by pressing Ctrl + C). A signal handler traps the SIGINT and shuts down the program. Is there a way to do this from within the MATLAB GUI application, by pushing an "abort" button?
After many hours of searching I stumbled upon http://www.caam.rice.edu/~wy1/links/mex_ctrl_c_trick/ which shows how to detect SIGINT in a MEX file. Letting a MEX call the external program might work (although I'm not sure about the details yet). However, it still requires Ctrl + C to stop the program. How can I send the SIGINT via push button in my GUI?
If you start your external program in Cygwin, then Cygwin will give it a PID. Using this PID you can use Cygwin's kill command to send signals to the process. So start the program from Cygwin. In MATLAB you can use !ps (where ! means call external shell command) to get a list of Cygwin PID's and then !kill -s signal pid to send a signal to the program. To make it happen from a MATLAB GUI let the callback from some button call !kill.