That's okay, I think it's kind of insane too. good ol' dos2unix fixed it fine.
On 11 April 2014 10:10, Martti Kühne wrote:
> On Fri, Apr 11, 2014 at 3:52 PM, Calvin Morrison
> wrote:
>>
>> Sorry, next time mar77i, check your damned line endings. This I
>> couldn't see from github website, but
On Fri, Apr 11, 2014 at 3:52 PM, Calvin Morrison wrote:
>
> Sorry, next time mar77i, check your damned line endings. This I
> couldn't see from github website, but I reverted the commit. I don't
> want trailing ^M's everywhere. I merged FRIGNs cleanup instead.
>
Whoa, that's crazy.
I seem to hav
On 11 April 2014 07:39, Calvin Morrison wrote:
> I think you're
>
>
> On Apr 11, 2014 4:33 AM, "Truls Becken" wrote:
>>
>> On 2014-04-08, at 17:48, Calvin Morrison wrote:
>>
>> > The script will either create the lock and exit, or ping the lock
>> > every two seconds until the lock is gone (via r
guys,
I have added a 'try_mkdir' function because we need to check each time
the cause of the failure. I think we should fail out if we don't have
permissions to create the lock during the loop (like during the first
check), rather than it EEXISTS. What do you think?
Calvin
On 11 April 2014 09:5
@ calvin:
fixed version submitted as pull request.
@ truls:
sorry for mistyping your last names.
cheers!
mar77i
On Fri, Apr 11, 2014 at 10:33 AM, Truls Becken wrote:
>
> I'm confused. Surely you also need to lock after old lock goes away?
>
No, mutantturkeys only need the lock state once.
Calling lock twice in the initial state will not wait for any other
lock to appear.
cheers!
mar77i
On 2014-04-08, at 17:48, Calvin Morrison wrote:
> The script will either create the lock and exit, or ping the lock
> every two seconds until the lock is gone (via rmdir).
I'm confused. Surely you also need to lock after old lock goes away?
-Truls
I pushed the rewritten version
http://github.com/mutantturkey/lock
On 10 April 2014 07:02, FRIGN wrote:
> On Thu, 10 Apr 2014 12:46:08 +0200
> hiro <23h...@gmail.com> wrote:
>
>> If one day you discover this script to be some bottleneck in your
>> webscale world-changing app then you can still t
On Thu, 10 Apr 2014 12:46:08 +0200
hiro <23h...@gmail.com> wrote:
> If one day you discover this script to be some bottleneck in your
> webscale world-changing app then you can still take the time and
> rewrite it in C, or create your own CPU with an instruction set
> extension that does just that
If one day you discover this script to be some bottleneck in your
webscale world-changing app then you can still take the time and
rewrite it in C, or create your own CPU with an instruction set
extension that does just that, whatever crazyness is needed to get to
the super important sub nano-secon
Calvin Morrison wrote:
> I added a lock gif. Check it out.
Heyho,
It seems this is a play-once-only gif. How about a loop for the poor slow guys
who missed it and are too lazy to reload the page? ;)
--Markus
That's great Calvin!
On Wed, Apr 09, 2014 at 10:40:43AM -0400, Calvin Morrison wrote:
> I added a lock gif. Check it out.
>
> https://github.com/mutantturkey/lock/blob/master/README.markdown
>
> that should clarify
>
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 wrote:
> On 9 April 2014 09:10, FRIGN wrote:
>> On Wed, 9 Apr 2014 08:47:14 -0400
>> Calvin Morrison wrote:
>>
>>> What is the benefit
On 9 April 2014 09:10, FRIGN wrote:
> On Wed, 9 Apr 2014 08:47:14 -0400
> Calvin Morrison 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 b
On Wed, 9 Apr 2014 08:47:14 -0400
Calvin Morrison 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 t
> first off, I'd definitely rewrite this locking-script in C, given it
> doesn't use Shell-features excessively.
> I see no reason to keep it as a Shell-script.
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 prototy
On Wed, 9 Apr 2014 09:54:33 +0200
Martti Kühne wrote:
> This [0] turned up on Lennart's G+ page recently, and as I understand
> flock()'ing just over DST change can lead to clusterfuck.
>
> Since this is being discussed here and the link beneath is mere FUD,
> someone here could be so nice as to
This [0] turned up on Lennart's G+ page recently, and as I understand
flock()'ing just over DST change can lead to clusterfuck.
Since this is being discussed here and the link beneath is mere FUD,
someone here could be so nice as to clarify.
Thank you in advance.
cheers!
mar77i
[0] http://logicf
Was not aware of flock, thanks!
I agree with you, using more small shell scripts is preferable.
On Tue, Apr 08, 2014 at 12:25:55PM -0400, Calvin Morrison wrote:
> On 8 April 2014 12:19, Amadeus Folego wrote:
> > Hi Calvin,
> >
> > Thanks for sharing it, it's really neat!
> >
> > I have the same
On 8 April 2014 12:19, Amadeus Folego wrote:
> Hi Calvin,
>
> Thanks for sharing it, it's really neat!
>
> I have the same problem with some cron jobs, but I use lockrun[1].
>
> It's source code is quite simple[2] too.
That code is simple enough, but it did leave a poor taste in my mouth.
A clean
Hi Calvin,
Thanks for sharing it, it's really neat!
I have the same problem with some cron jobs, but I use lockrun[1].
It's source code is quite simple[2] too.
The reason why I would still stick with lockrun is that
in the context of cron jobs, it is better that the task does not
runs than pili
Hi,
I've just written lock, a simple little script to ensure that two
programs won't run at once. I am using this to ensure my users don't
overwrite the same shared folder in a set of genomic analysis scripts.
I thought it might be useful.
The script will either create the lock and exit, or ping
22 matches
Mail list logo