New answers tagged

0

You should setup your inotify daemon to launch rsync only on CLOSE_WRITE and MOVE_FROM/MOVE_TO combo events. If you are listening for CREATE and/or MODIFY events, you will end with rsync called when the file is being written to, which will led to a corrupt/empty copy.


0

The reason mv would probably work, is because the file would actually be the same file. So the upload process would be writing to a given inode, and the mv command simply updates the source and destinations so that the inode is in a different location. But any programs with an open handle to the file would be able to continue working with that inode, so ...


2

set an alias by adding your command in .bashrc file. alias abspath='sh /home/myuser/bin/abspath.sh' And don't forget to source the file.


4

This code is small enough that I would code it as a shell function: abspath() { echo "$(dirname "$(readlink -e "$1")")/$(basename "$1")" } And yes you do want all those quotes.


0

The prefered way to do this is to use pythons logging module and write directly from inside the script instead of redirecting the output.


-1

A 3rd option is to create an alias called abspath that points to your abspath.sh script.


2

I had the same problem (no shell usleep on Solaris) so I wrote my own thus: #include "stdio.h" int main(int argc, char **argv) { usleep(atoi(argv[1])); return 0; } Doesn't check arguments - I'd recommend a properly written one if you wanted to keep it but that (gcc usleep.c -o usleep) will get you out of a hole.


1

I would rename your bash script to abspath then move it to the bin directory. You'll be ablet to call abspath from anywhere then


27

You want to type abspath, but the program is named abspath.sh. The problem is not regarding whether it is in the PATH, but the fact that you are simply not using its name to call it. You have two options: Type abspath.sh instead. Rename the program to abspath.


0

You need to quote what you echo or else echo will interpret wildcard with what it finds in the directory matching a pattern. It is called globbing and can be disabled. box:[~/tmp/test]$ touch file.txt other.txt box:[~/tmp/test]$ foo='*.txt' box:[~/tmp/test]$ echo $foo file.txt other.txt nox:[~/tmp/test]$ echo '$foo' $foo box:[~/tmp/test]$ echo "$foo" *.txt ...


0

It would be possible to use Netcat to listen to a specific port (12345 in the example provided) and then check its output for what was received such as: while test 1 # infinite loop do nc -l localhost 12345 > /tmp/12345.log # check for start grep start /tmp/12345.log > /dev/null if test $? -eq 0 then startJob& ...


0

In order to run an application using a spark context it is first necessary to run a Slurm job which starts a master and some workers. There are some things you will have to watch out for when using Slurm: don't start Spark as a daemon make the Spark workers use only as much cores and memory as requested for the Slurm job in order to run master and worker ...


1

I would suggest executing the script from the sending side and using that to trigger the receive portion. There's no sense in starting a cron job on both ends... You can issue commands on your remote server from the local server using ssh.



Top 50 recent answers are included