I added a lock gif. Check it out. https://github.com/mutantturkey/lock/blob/master/README.markdown
that should clarify On 9 April 2014 09:12, Calvin Morrison <mutanttur...@gmail.com> wrote: > On 9 April 2014 09:10, FRIGN <d...@frign.de> wrote: >> On Wed, 9 Apr 2014 08:47:14 -0400 >> Calvin Morrison <mutanttur...@gmail.com> wrote: >> >>> What is the benefit of using a C program? For me it would be easier to >>> implement sane flags, but I am lazy. bash makes it easy to prototype >>> and run with a very small feedback loop and low boilerplate to product >>> ratio. >> >> Well, every time you run a shell-script you launch a sub-shell, import >> all environment variables and, most importantly, depend on the >> shell-implementation. >> Using C on the other hand, you are able to optimize the program even >> more (shell is good for prototyping, but not for long-term-usage if you >> have the time to port it to C). >> The only reason to use a shell-skript is if you write things that often >> need to be changed (like configure-skripts, Makefiles, ...) or if you >> depend on shell-functions (which sometimes is pretty neat). >> >> The dead simple lock-software you propose is almost as dead simple to >> write in C. I guess you could even stay at the same SLOC or a little >> bit more. > > Fair enough I think I will implement it in C at some point then. > >>> I don't see another option. Even using poll, you're still somewhere >>> checking every x interval if the directory is gone. >> >> That depends on the implementation. I wonder why the Kernel-folks >> didn't partially implement poll() using inotify. >> This way, you would both be able to write POSIX-compliant software and >> benefit from the nive inotify-interface. >> > > Doesn't i-notify work via some polling in itself as well? > >>> i-notify rocks but is linux only afaik. >> >> Yep. >> >>> Hmm, how can I do this? I have trouble making it clear without using >>> two terminals and a video (that would be very easy) >> >> Well, don't depend on Terminal quirks too much. Why not just take my >> example and annotate it a bit better? > > Okay will do
