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 <mutantturkey_AT_gmail.com> wrote:
> On 9 April 2014 09:10, FRIGN <dev_AT_frign.de> wrote:
>> On Wed, 9 Apr 2014 08:47:14 -0400
>> Calvin Morrison <mutantturkey_AT_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
Received on Wed Apr 09 2014 - 16:40:43 CEST