I wrote somethig like a Watchdog in C that whatch for some programs and, if those programs have saty off, it start those programs up.
Ok!
But I have one program that have to write a file, and when I play it works very well, but when my watchdog play it (by shell command), my program don't write the file.
I have the rights to write the file.
Could someone help me?
Thankz!
(in advance sorry for my poor english...)
Related
I'm a Python/programming novice and this is probably an novice mistake, but I've scoured the internet for answers and have found none! I'm learning on a Rosalind module that's about opening data files. http://rosalind.info/problems/ini5/ I'm pretty sure I understand everything clearly, so I'm frustrated about my inability to do this simple task.
I'm using Python 3.6.2 and IDLE. The assignment is to simply open a .txt file and read a few lines.
I downloaded the .txt file to my working directory. Then, I opened up IDLE Shell and made sure I was in the right working directory (using ls & cd). I then opened a new IDLE .py file and wrote a script:
f = open('filename.txt', 'r')
f.readlines()[2]
I saved the script as p5.py. Then, I tried to run the script by calling F5. In the Shell, I got this message:
================ RESTART: /Users/liv/Desktop/Rosalind/p5.py =================
Is that an error? I think it's just a message from IDLE that IDLE has opened p5.py. Therein lies my problem, because now I have the wrong file open.
I started realizing that when I used the Shell and called it to print, and it came back with an empty string.
What am I doing wrong?? How do I get IDLE to open the filename.txt file? ...not the .py file.
The RESTART line means that IDLE has sent p5.py to Python to be run, which is exactly what you want and what you asked. Python should have then opened the text file, read it, retrieved the 3rd line, and stopped. Since p5.py has no output statements and does not raise any exceptions, you will not see anything. If you change the 2nd line to
print('line is ', f.readlines()[2])
then you should see something.
Thanks for taking the time to read this. I'm a beginner programmer with some experience in Python, and I just started reading Zed Shaw's Learn SQL the Hard Way. In exercise 1, he has you create an .sql file type the following command in powershell:
sqlite3 ex1.db < ex1.sql
After running the following in the command-line, I receive the following error message
The '<' operator is reserved for future use.
I checked a few stackoverflow pages for answers.
Unfortunately, I cannot figure out how to bypass this error message and make a .db file from a .sql file. Apologies for any nuisances; I'm very new to stackoverflow. Any help or advice in solving this problem is greatly appreciated!
The examples that you are looking at are running inside of the bash shell on a *NIX platform. You stated that you're using PowerShell which means that the command will be different. I'm guessing it will look something like:
Get-Content ex1.sql | sqlite3 ex1.db
PowerShell is incompatible with any other shell.
If you do not know the syntax of both normal shells and PowerShell, and how to translate from one to the other, you should not user PowerShell in the first place.
Use the standard Windows command prompt (cmd.exe) instead.
I am writing a perl script to parse, for example, /var/log/syslog.
The perl script triggers further subsequent tasks when particular events in the log appear. The log is parsed following the advice of this post:
Command line: monitor log file and add data to database
Which what I believe is the use of a pipe.
Now I'd like this script to forever run in the background.
This sounds like a daemon to me, and the daemon program referenced in the following question seems ideal:
How can I run a Perl script as a system daemon in linux?
But from this post, it seems clear that daemon's have no open file handles. So how can I have a daemon, or a perl script that becomes a daemon, that monitors a logfile?
It sounds like what you want is a daemon. In that case the advise given in the second post you reference is the best practice. However, you do have other options like daemontools, which removes the fork complexity.
Daemons are allowed to have filehandles, but you should close STDIN, STDOUT, and STDERRR because you shouldn't really use them anymore. A lot of this has to do with the way fork works in *nix systems. Just open the pipe filehandle after your second fork, and you shouldn't have any issues.
this doesn't answer your question, but is another route to consider which may or may not be appropriate for you:
rsyslog can execute a program when a certain message is logged
see Filter Conditions for setting up the up the trigger, Templates for formatting the output that's passed to the script, and Actions > Shell Execute for specifying the executable.
Be sure to read the security implications, and that ryslog blocks while the external program runs. But if your script runs reliably quickly, it may be an option.
I use Matlab remotely via ssh, and would like to execute regions of code from an m-file in Emacs without having to cut and paste. How do I configure Emacs to do this?
I tried to follow the solution offered here: I wrote a script that connects to the server and opens Matlab. The script works when I run it in a terminal. I edited matlab.el as explained on that page. Now, if I'm editing my m-file in Emacs and try to start Matlab, I get a message that it can't execute my remoteMatlab.sh file, and that M-shell exited abnormally with code 1.
Thanks in advance for any help.
You can achieve this running a shell from within emacs, starting up your ssh and matlab session in it, and renaming the shell buffer from *term* or whatever to *MATLAB*. You can then use matlab-mode on a script file and run the code.
This is not exactly what you asked for but may achieve the same thing. You can use function dbstop, which allows you to set debug break points through code.
http://www.mathworks.com/help/techdoc/ref/dbstop.html#inputarg_location
I have a Perl script that contains this code snippet, which calls the system shell to get some files by SFTP and unzip them with WinZip:
# Run script to get files from remote server
system "exec_SFTP.vbs";
# Unzip any files that were retrieved
foreach $zipFile (<*.zip>) {
system "wzunzip $zipFile";
}
Even if some files are retrieved, they are never unzipped, because by the time the files are retrieved and the SFTP connection is closed, the Perl script has already completed the unzip step, with the result that it doesn't find anything to unzip.
My short-term fix is to insert
sleep(60);
before the unzip step, but that assumes that the SFTP connection will finish within 60 seconds, which may sometimes be a gross over-estimate, and other times an under-estimate.
Is there a more sound way to cause Perl to pause until the SFTP connection is closed before proceeding with the unzip step?
Edit: Responders have questioned (and reasonably so) the use of a VB script rather than having Perl do the file transfer. It has to do with security -- the VB script is maintained by others and is authorized to do the SFTP.
Check the code in your *.vbs file. The system function waits for the child process to finish before execution continues. It appears that your *.vbs file is forking a background task to do the FTP and returning immediately.
In a perfect world your script would be rewritten to use Net::SFTP::Foreign and Archive::Extract..
An ugly quick-hackish kind of way might be to create a touch-file before your first system call, alter your sftp-fetching script to delete the file once it is done and have a while like so
while(-e 'touch.file') {
sleep 5;
}
# foreach [...]
Of course, you would need to take care if your .vbs fails and leaves the touchfile undeleted and many other bad side effects. This would be for a quick solution (if none of the other suggestions work) until you get the time to rewrite without system() calls.
You need a way for Perl to wait until the SFTP transfer is done, but as your script is currently written, Perl has no way of knowing this. (It looks like you're combining at least two scripting languages and a (GUI?) SFTP client; this can work, but it's not exactly reliable or robust. Why use VBscript to start the SFTP transfer?)
I can think of four options:
Your Perl script could do the SFTP transfer itself, using something like CPAN's Net::SFTP module, rather than spawning an external job whose status it cannot track.
Your Perl script could spawn a command-line SFTP utility (like PSFTP) that doesn't return until the transfer is done.
Or change exec_SFTP.vbs script to not return until the transfer is done.
If you're currently using a graphical SFTP client and can't switch for whatever reason, I'd recommend using a scripting language like AutoIt instead of Perl. AutoIt has features to wait for windows to change state and so on, so it could more easily monitor for an activity's completion.
Options 1 or 2 would be the most robust and reliable.
The best I can suggest is modifying exec_SFTP.vbs to exit only after the file transfer is complete. system waits for the program it called to complete, so that should solve your problem:
system LIST
system PROGRAM LIST
Does exactly the same thing as "exec LIST", except
that a fork is done first, and the parent process
waits for the child process to complete.
If you can't modify the vbs script to stay alive until it terminates, you may be able to track subprocess creation. If you get subprocess ids, you can monitor them thereby know when the vbs' various offspring terminate.
Win32::Process::Info lets you get a subprocess ids from a running process.
Maybe this is a dumb question, but why not just use the Net::SFTP and Archive::Extract Perl modules to download and unzip the files?
system will not return until the shell it's running the command in has returned; this may be wrong for launching graphical programs and file associations.
See if any of the following help?
system('cscript exec_SFTP.vbs');
use Win32::Process;
use Win32;
Win32::Process::Create(my $proc, 'wscript.exe',
'wscript exec_SFTP.vbs', 0, NORMAL_PRIORITY_CLASS, '.');
$proc->Wait(INFINITE);
Have a look at IPC::Open3
IPC::Open3 - open a process for reading, writing, and error handling using open3()