makefile with prerequisite on another computer - makefile

I have a makefile on one computer, and I would like to use as a prerequisite a file on another computer that I can connect via ssh (but I am not an administrator). For instance, in this case, make print_hello runs only if the file on the other computer has changed since the last time print_hello ran.
print_hello: res#another_pc:/path_to_file
echo "hello"
touch print_hello
Is something like this possible?

Related

How to script to read user input, then run in background itself even closing terminal in TCSH?

I am looking for a strategy suggestion.
I am very new to Linux shell scripting. Just learning tcsh not more than a month.
I need a script to automatically detects when is the result files are done copied back from a remote server to a folder in a remote machine, then start scp the files back to my workstation.
I do not know in advance when the job will finish run, so the folder could have no result files for a long while. I also do not know when will the last result file done copied back from remote server to the folder (and thus can start the scp).
I had tried crontab. Work fine when I guess correctly, most of the time just disappointing.
So I tried to write a script myself and I have it now. I intend to produce a script that serves me and my colleagues too.
To use the script, the user first need to login to the remote machine manually. Then only execute the script at remote machine. The script first asks for user to input their local machine name and directory where they wish to save the result files.
Then the script will just looping to test when is the total number of files change. When it detected that, which means the first result file is starting to be copied back from the remote server, then it loops again to detect when is the total files size in the folder stop changing, which means last result file is finished copied to the folder. After that it executes scp to send all the result files to the user workstation, at the initially specified directory.
Script works fine but I wish to make the script able to run in background and still running by itself even if the user logout from the remote machine and close the terminal. And also I wish to let the user just type in a simple command in terminal to start the script, something like a simple
./script.tcsh
I tried to run the script by command
./script.tcsh &
but fails, because background process unable to accept user input.
Google and found something called disown, but the command is not found. Apparently the remote machine and my machine does not support this command.
Tried to modify the script to first accept the user input, then attempt to use
cat > temp_script.tcsh << EOF
{rest of my script}
EOF
and then a line of
./temp_script.tcsh &
to try to create another script file and use the first script to initiate the second script in background. Also fail, because cat does not treat $variable as a literal text, it replaces it with values. I have a foreach i(1 2) loop, and the cat command just keep reporting error (missing value of variable i, which is just a counter in foreach loop syntax).
I am out of idea at the moment.
Can anyone enlighten me with some strategy that I can try myself?
The goal is to use only 1 script file, and prompt user for 2 inputs (machine name and directory to save), then no more interaction with user or waiting, and able to run even closing the terminal.
Note: I do not need password to login to remote machine and back.

Execute script in new terminal window on hard drive plugging

I would like to execute a backup script with rsync everytime a specific hard drive is plugged to my computer on ubuntu 16.04.
However I would like the user to be prompted if the backup should run or not and then he should be able to see the rsync output live in a terminal.
What I did so far:
I created a rule at /etc/udev/rules.d/backup_on_mount.rules
ACTION=="add", ATTRS{idVendor}=="1058", ATTRS{idProduct}=="0820", RUN+="/path/to/my/script/backup_on_mount.sh"
I created the backup_on_mount.sh script and made it executable
However I did not succeed in popping a new terminal window with my script running in it when I plug my hard drive.
Does anybody have an idea on how to begin ?
Thank you
You are not supposed to run anything that long from udev rules directly. One way of dissociating your long running script from the udev rule is by scheduling it (with at -M now command for example) instead of running it directly. The proper way of finding the right DISPLAY to open the new terminal depends on your desktop environment

Run a remote bash script on a Mac using PuTTy

I want to run a bash script on a mac remotely from a batch script on a windows machine. On Windows I have this:
#echo off
echo bash /applications/snowflake/table-updater/test2.sh; exit>tmp_file
putty -ssh User#remote_machine -pw password -m tmp_file
And here is test2.sh on the remote machine
#!/bin/bash
# test2.sh
#
#
7za x table-apps.zip -y -o/Applications/snowflake/applications
When the batch file runs it logs in successfully, but for some reason fails to run the bash file. However the bash file runs fine from mac terminal, where it unzips the files perfectly. What could be happening here?
Please note test2.sh is actually in Applications/snowflake/table-updater as specified in the batch file. And the tmp file does write fine as well. My aim is to have a script to access a further 10 remote machines with the same directory structure.
Thanks in advance
The standard program which resembles the scriptable Unix command ssh in the PuTTy suite is called plink, and would probably be the recommended tool here. The putty program adds a substantial terminal emulation layer which is unnecessary for noninteractive scripting (drawing of terminal windows, managing their layout, cursor addressing, fonts, etc) and it lacks the simple feature to specify a command directly as an argument.
plink user#remote_machine -pw password /Applications/snowflake/table-updater/test2.sh
From your comments, it appears that the problem is actually in your script, not in how you are connecting. If you get 7za: command not found your script is being executed successfully, but fails because of a PATH problem.
At the prompt, any command you execute will receive a copy of your interactive environment. A self-sufficient script should take care to set up the environment for itself if it needs resources from non-standard locations. In your case, I would add the following before the 7za invocation:
PATH=$PATH:/Applications/snowflake/table-updater
which augments the standard PATH with the location where you apparently have 7za installed. (Any standard installation will take precedence, because we are adding the nonstandard directory at the end of the PATH -- add in front if you want the opposite behavior.)
In the general case, if there are other settings in your interactive .bashrc (or similar shell startup file) which needs to be set up in order for the script to work, the script needs to set this up one way or another. For troubleshooting, a quick and dirty fix is to add . /Users/you/.bashrc at the top of the script (where /Users/you should obviously be replaced with the real path to your home directory); but for proper operation, the script itself should contain the code it needs, and mustn't depend on an individual user's personal settings file (which could change without notice anyway).

How do I schedule an scp job on Windows?

First of all, I am not an expert programmer, and I don't know much of the programmer's lingo. So please bear with me.
I am using Cygwin on windows, to copy a file from home directory to a remote server (which uses Linux) using SCP. I need to do this every day and so I want to automate it. I know how to schedule tasks in task scheduler, but I don't know what kind of file to save an scp command as. Please help? Oh and I don't have admin access, so I cannot install or use third party applications
First add Cygwin to your Windows Environment Variables. You can find directions on how to do that here (the directions you need are almost all the way at the bottom of the page). Now you should be able to run Linux commands from the command prompt. Simply make a .bat file in notepad with the commands you need to run. It should look something like this:
scp /cygdrive/d/test.txt <linux ip>:/etc/var/test/test.txt
Then use task scheduler to run the .bat file.

Run .bat file as Administrator, get old version?

This is just bizarre. I've got a .bat file that I run using Windows 7's scheduler, and I noticed after I made an update to it, that it was still acting as though it were running the old version of the .bat program.
It's easy to tell which one ran - they output to a .txt file, and the new version dumps a lot more information. So here's what happens under three scenarios:
Open a cmd window (with right-click and "Run As Administrator"). CD to the directory and execute setvispw.bat in the usual way, by typing "setvispw.bat" and hitting Enter.
Result: current version runs as expected.
Right-click setvispw.bat and "Open"
Result: current version runs as expected. But that's not good, because I'm changing another user's password and need Admin privileges.
Right-click setvispw.bat and "Run As Administrator".
Result: something else runs! It looks like it's running the version from before I made changes to the .bat just a few days ago.
So I tried something even more strange. I replaced my functional program with a dummy program... and it was running the dummy program.
Finally, I added some "pause" statements... and that's when I got the answer. Rather than discard this bit of troubleshooting, I'll use the "Answer your own darned question" feature.
It turns out the problem was that I was depending on the output to setvispw.bat to tell me what version of the program had run. Well, both the old and new versions had this line:
echo Random string is !_RndAlphaNum! > C:\pathname\curVisitorPW.txt
But my added line was like this:
echo Sending email: >> curVisitorPW.txt
When I ran from C:\pathname, either in a CMD window or without Admin privileges, it worked just fine. But when I ran with Admin privs, like it does from the Scheduler, the working directory isn't C:\pathname - it's C:\Windows\System32. I didn't see that until I added the "pause" and saw that I wasn't running where I expeted! Sure enough, there's a curVisitorPW.txt sitting there in System32.
The solution, of course, was simple - use the fully qualified pathname.
Hopefully this will come in handy if someone like me is seeing bizarre behavior in a .bat file, and starts wondering if there's some sort of caching, or admin permissions/privileges, or something else crazy. I was ready to pin it on gremlins, myself.

Resources