Re: [dev] lock (1) - a dead simple lock script
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
Re: [dev] lock (1) - a dead simple lock script
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
Re: [dev] lock (1) - a dead simple lock script
@ calvin: fixed version submitted as pull request. @ truls: sorry for mistyping your last names. cheers! mar77i
[dev] [st][PATCH] Fix Backspace and Delete characters
Backspace key must generate the backspace character (\010) and
Delete key must generate the delete character (\0177). In
some systems the kernel configuration for erasing previous character
is \0177, so some programs (for example cat, ed, mail, ...), can not
understand the correct meaning of backspace. In this cases it is only
needed this command:
stty erase
---
config.def.h | 3 ---
st.info | 2 +-
2 files changed, 1 insertion(+), 4 deletions(-)
diff --git a/config.def.h b/config.def.h
index 58b470e..d69c9ba 100644
--- a/config.def.h
+++ b/config.def.h
@@ -192,7 +192,6 @@ static Key key[] = {
{ XK_KP_Delete, ControlMask,"\033[3;5~",+1,0,0},
{ XK_KP_Delete, ShiftMask, "\033[2K", -1,0,0},
{ XK_KP_Delete, ShiftMask, "\033[3;2~",+1,0,0},
- { XK_KP_Delete, XK_ANY_MOD, "\033[P", -1,0,0},
{ XK_KP_Delete, XK_ANY_MOD, "\033[3~", +1,0,0},
{ XK_KP_Multiply, XK_ANY_MOD, "\033Oj", +2,0,0},
{ XK_KP_Add,XK_ANY_MOD, "\033Ok", +2,0,0},
@@ -212,7 +211,6 @@ static Key key[] = {
{ XK_KP_7, XK_ANY_MOD, "\033Ow", +2,0,0},
{ XK_KP_8, XK_ANY_MOD, "\033Ox", +2,0,0},
{ XK_KP_9, XK_ANY_MOD, "\033Oy", +2,0,0},
- { XK_BackSpace, XK_NO_MOD, "\177", 0,0,0},
{ XK_Up,ShiftMask, "\033[1;2A", 0,0,0},
{ XK_Up,ControlMask,"\033[1;5A", 0,0,0},
{ XK_Up,Mod1Mask, "\033[1;3A", 0,0,0},
@@ -248,7 +246,6 @@ static Key key[] = {
{ XK_Delete,ControlMask,"\033[3;5~",+1,0,0},
{ XK_Delete,ShiftMask, "\033[2K", -1,0,0},
{ XK_Delete,ShiftMask, "\033[3;2~",+1,0,0},
- { XK_Delete,XK_ANY_MOD, "\033[P", -1,0,0},
{ XK_Delete,XK_ANY_MOD, "\033[3~", +1,0,0},
{ XK_Home, ShiftMask, "\033[2J", 0, -1,0},
{ XK_Home, ShiftMask, "\033[1;2H", 0, +1,0},
diff --git a/st.info b/st.info
index 4e60a89..3a01a08 100644
--- a/st.info
+++ b/st.info
@@ -53,7 +53,7 @@ st| simpleterm,
ka3=\E[5~,
kc1=\E[4~,
kc3=\E[6~,
- kbs=\177,
+ kbs=\010,
kcbt=\E[Z,
kb2=\EOu,
kcub1=\EOD,
--
1.8.5.3
Re: [dev] lock (1) - a dead simple lock script
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:52, Calvin Morrison wrote: > 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 rmdir). >>> >>> I'm confused. Surely you also need to lock after old lock goes away? >>> >>> -Truls >>> >> >> I think you're right thought, shouldn't another lock be established? I think >> the code I'll merge at some point today resolves that. >> >> Calvin > > 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.
Re: [dev] lock (1) - a dead simple lock script
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 rmdir). >> >> I'm confused. Surely you also need to lock after old lock goes away? >> >> -Truls >> > > I think you're right thought, shouldn't another lock be established? I think > the code I'll merge at some point today resolves that. > > Calvin 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.
Re: [dev] lock (1) - a dead simple lock script
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 have been too lazy using github's web editor and I'm flabberghasted it would CRULF everything. Sorry. cheers! mar77i
Re: [dev] lock (1) - a dead simple lock script
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 I reverted the commit. I don't >> want trailing ^M's everywhere. I merged FRIGNs cleanup instead. >> > > > Whoa, that's crazy. > I seem to have been too lazy using github's web editor and I'm > flabberghasted it would CRULF everything. Sorry. > > cheers! > mar77i >
Re: [dev] [st] [patch] redundant gettimeofday
Christoph, are you again to apply this patch now? Regards, -- Roberto E. Vargas Caballero
[dev] lock (1) - where does it go?
new program, new tools, new thread. I'd like lock to belong somewhere. FRIGN and I privately discussed submitting it to moreutils, a package which contains unix utilities which didn't quite make it into coreutils, but are still useful. He says: > Frankly, I don't like the idea. Moreutils is licensed under the GPL, which is > not favorable. I agree that GPL is a sucky license, but moreutils is widely distributed and available for most all linux systems via package manager. This gives the tool more popularity. > I'd suggest we do this job and then submit it to the _suckless-repo_ > (including a proper Makefile for easy installation) ;)." I agree with this, I love suckless, i've been using these tools for years. What would I do without it? yet we are doomed to obscurity. so 1) submit it to the suckless repository, if the community so desires 2) submit to moreutils, sacrifice license (well technically anyone could use my current version under its current BSD like license) 3) do nothing, let it sit on my website. Thoughts?
Re: [dev] lock (1) - where does it go?
On Fri, Apr 11, 2014 at 10:25:48AM -0400, Calvin Morrison wrote: > 1) submit it to the suckless repository, if the community so desires Personally I'd like to see something like miscutils, rutils (random utils) or similar under MIT/X. I am sure more programs will pop up.
Re: [dev] [st] [patch] redundant gettimeofday
Greetings. On Fri, 11 Apr 2014 18:01:40 +0200 "Roberto E. Vargas Caballero" wrote: > Christoph, are you again to apply this patch now? No, this patch can be applied safely. Sincerely, Christoph Lohmann
Re: [dev] lock (1) - where does it go?
Greetings. On Fri, 11 Apr 2014 18:02:55 +0200 Calvin Morrison wrote: > I'd like lock to belong somewhere. FRIGN and I privately discussed > submitting it to moreutils, a package which contains unix utilities > which didn't quite make it into coreutils, but are still useful. Submit it to ubase. Sincerely, Christoph Lohmann
Re: [dev] [st] [patch] redundant gettimeofday
On Fri, Apr 11, 2014 at 04:25:26PM +0200, Roberto E. Vargas Caballero wrote: > Christoph, are you again to apply this patch now? Bad typo, I wanted to say "are you going to ...". Sometimes my dislexia makes bad things, sorry. -- Roberto E. Vargas Caballero
Re: [dev] [st] [patch] redundant gettimeofday
Greetings. On Fri, 11 Apr 2014 18:11:47 +0200 "Roberto E. Vargas Caballero" wrote: > On Fri, Apr 11, 2014 at 04:25:26PM +0200, Roberto E. Vargas Caballero wrote: > > Christoph, are you again to apply this patch now? > Bad typo, I wanted to say "are you going to ...". > Sometimes my dislexia makes bad things, sorry. Just train harder. Dyslexia is just an excuse. The patch has been applied. Sincerely, Christoph Lohmann
[dev][sbase][RFC] "tr" with -d option or without?
Heyho Recently the '-d' flag was added to the 'tr' program. I liked the simplicity of not having to specify the '-d' flag to delete characters specified in set1 and the TODO entry (still to be deleted) does not mention it. I can see the need for a '-d' flag for compatibility reasons but my preference would be to just ignore the flag if it is specified. What are peoples opinion on the '-d' flag? In any case, the tr.1 man page should be updated and the TODO item removed which I will do as soon as the decision has been made. Have a nice weekend, everyone! Cheers, Silvan
Re: [dev][sbase][RFC] "tr" with -d option or without?
On Fri, Apr 11, 2014 at 09:07:10PM +0200, Silvan Jegen wrote: > I can see the need for a '-d' flag for compatibility reasons but my > preference would be to just ignore the flag if it is specified. What are > peoples opinion on the '-d' flag? I suspect we can do that yes, Hiltjo might be able to shed some more light on this but I do not see why what you suggest would not work.
Re: [dev][sbase][RFC] "tr" with -d option or without?
On Fri, Apr 11, 2014 at 09:07:10PM +0200, Silvan Jegen wrote: > I can see the need for a '-d' flag for compatibility reasons but my > preference would be to just ignore the flag if it is specified. What are > peoples opinion on the '-d' flag? One thing that is different is the breaking conditions for when to consider the invocation as invalid usage (in the -d case we check for >= 2 in any other case we check for != 2). So in that case we cannot consider -d as a no-op as far as I uderstand it. We can still share the rest of the code though.
Re: [dev] lock (1) - where does it go?
On Fri, Apr 11, 2014 at 06:02:55PM +0200, Christoph Lohmann wrote: > Greetings. > > On Fri, 11 Apr 2014 18:02:55 +0200 Calvin Morrison > wrote: > > I'd like lock to belong somewhere. FRIGN and I privately discussed > > submitting it to moreutils, a package which contains unix utilities > > which didn't quite make it into coreutils, but are still useful. > > Submit it to ubase. I guess we can do that yes. So Calvin, send me a patch for lock to be included in ubase and I will apply it. Cheers, sin
