[dev] [dmenu] patch and new release of dclip
Hi,
Last weekend Delta and I were playing with dclip, fixing some bugs and
finally, we think there are no more corner cases handling selections.
For those of you, who don't know what dclip is:
http://tecnoprawn.wordpress.com/2009/12/17/dclip/
dclip is a lightweight clipboard manager (19 LOC in sh) that uses dmenu
as frontend to show the stored selections and depends on xclip. It
tries to unify the mess with different X selections.
For example in dwm, in order to copy with M+C+c and paste with M+C+v
you can add the following in your config.h:
/* commands */
static const char *dclipcmd[] = { "dclip", "paste", "-fn", font, "-nb",
normbgcolor, "-nf", normfgcolor, "-sb", selbgcolor , "-sf",
selfgcolor, NULL };
and in the keys[] section:
{ MODKEY|ControlMask, XK_c, spawn, SHCMD("exec dclip copy") },
{ MODKEY|ControlMask, XK_v, spawn, {.v = dclipcmd } },
Furthermore, using dclip I noticed that dmenu cannot create items larger
than 1024 bytes, so I've modified the function readstdin in order
to solve this issued. It was very bouring to copy a selection larger
than 1024 chars with dclip and then have to paste several items from
dmenu instead of just one.
I attached the patch for dmenu-4.0 (last stable release) and dmenu-tip
and the last release of dclip.
Kind regards,
-- Nibble
dclip
Description: Binary data
diff -r 78f9f72cc9c6 dmenu.c
--- a/dmenu.c Sat Feb 21 19:21:54 2009 +
+++ b/dmenu.c Mon Dec 21 12:23:19 2009 +0100
@@ -519,24 +519,31 @@
void
readstdin(void) {
char *p, buf[1024];
- unsigned int len = 0, max = 0;
+ unsigned int len = 0, blen = 0, max = 0;
Item *i, *new;
- i = 0;
+ i = 0, p = NULL;
while(fgets(buf, sizeof buf, stdin)) {
- len = strlen(buf);
- if (buf[len - 1] == '\n')
- buf[len - 1] = 0;
- if(!(p = strdup(buf)))
- eprint("fatal: could not strdup() %u bytes\n", strlen(buf));
+ len += (blen = strlen(buf));
+ if(!(p = realloc(p, len))) {
+ eprint("fatal: could not realloc() %u bytes\n", len);
+ return;
+ }
+ memcpy (p + len - blen, buf, blen);
+ if (p[len - 1] == '\n')
+ p[len - 1] = 0;
+ else if (!feof(stdin))
+ continue;
if(max < len) {
maxname = p;
max = len;
}
+ len = 0;
if(!(new = (Item *)malloc(sizeof(Item
eprint("fatal: could not malloc() %u bytes\n", sizeof(Item));
new->next = new->left = new->right = NULL;
new->text = p;
+ p = NULL;
if(!i)
allitems = new;
else
diff -r 4684b2cf4eab dmenu.c
--- a/dmenu.c Sat Dec 05 16:52:53 2009 +
+++ b/dmenu.c Mon Dec 21 12:23:37 2009 +0100
@@ -625,24 +625,31 @@
void
readstdin(void) {
char *p, buf[1024];
- unsigned int len = 0, max = 0;
+ unsigned int len = 0, blen = 0, max = 0;
Item *i, *new;
- i = 0;
+ i = 0, p = NULL;
while(fgets(buf, sizeof buf, stdin)) {
- len = strlen(buf);
- if (buf[len - 1] == '\n')
- buf[len - 1] = 0;
- if(!(p = strdup(buf)))
- eprint("fatal: could not strdup() %u bytes\n", strlen(buf));
+ len += (blen = strlen(buf));
+ if(!(p = realloc(p, len))) {
+ eprint("fatal: could not realloc() %u bytes\n", len);
+ return;
+ }
+ memcpy (p + len - blen, buf, blen);
+ if (p[len - 1] == '\n')
+ p[len - 1] = 0;
+ else if (!feof(stdin))
+ continue;
if(max < len) {
maxname = p;
max = len;
}
+ len = 0;
if(!(new = (Item *)malloc(sizeof(Item
eprint("fatal: could not malloc() %u bytes\n", sizeof(Item));
new->next = new->left = new->right = NULL;
new->text = p;
+ p = NULL;
if(!i)
allitems = new;
else
Re: [dev] slock with non-system auth
Hi, * Moritz Wilhelmy [2009-12-20 16:16]: > On Sun, Dec 20, 2009 at 12:29:48PM +0100, markus schnalke wrote: > > [2009-12-20 12:03] Moritz Wilhelmy > > > On Sun, Dec 20, 2009 at 11:53:02AM +0100, markus schnalke wrote: > > > > > > > > Maybe we could give slock a system account to check the password > > > > against. Thus it must not to be the own account, but can be a special > > > > slock system user, which exists just for this task. > > > > > > > > Unfortunately only root users will have the ability to set different > > > > passwords then. > > > > > > And only root-users will be able to use slock then, so it doesn't > > > work for people working on public machines, for instance at university. > > > > They still can use it with their account password, but not with a > > different one. > > > > It is no solution to the problem. It was more a thought to the topic. > > doesn't work at my university because we have NIS shared accounts > and afaik slock just reads shadow No this is wrong, it's using getpw*() which is querying the name service switch (nss). Cheers Nico -- Nico Golde - http://www.ngolde.de - n...@jabber.ccc.de - GPG: 0xA0A0 For security reasons, all text in this mail is double-rot13 encrypted. pgpsfF6aqBvW1.pgp Description: PGP signature
Re: [dev] [dmenu] patch and new release of dclip
Very cool! Thanks for this.
I haven't patched dmenu yet, but will probably do it first time I have
to put something huge into the clipboard (I don't think I have that
use case yet).
Everything else works great. Had to install xclip though.
Cheers,
Alex
On 12/21/09, Nibble wrote:
> Hi,
>
> Last weekend Delta and I were playing with dclip, fixing some bugs and
> finally, we think there are no more corner cases handling selections.
> For those of you, who don't know what dclip is:
>
> http://tecnoprawn.wordpress.com/2009/12/17/dclip/
>
> dclip is a lightweight clipboard manager (19 LOC in sh) that uses dmenu
> as frontend to show the stored selections and depends on xclip. It
> tries to unify the mess with different X selections.
>
> For example in dwm, in order to copy with M+C+c and paste with M+C+v
> you can add the following in your config.h:
>
> /* commands */
> static const char *dclipcmd[] = { "dclip", "paste", "-fn", font, "-nb",
> normbgcolor, "-nf", normfgcolor, "-sb", selbgcolor , "-sf",
> selfgcolor, NULL };
>
> and in the keys[] section:
>
> { MODKEY|ControlMask, XK_c, spawn, SHCMD("exec dclip copy") },
> { MODKEY|ControlMask, XK_v, spawn, {.v = dclipcmd } },
>
> Furthermore, using dclip I noticed that dmenu cannot create items larger
> than 1024 bytes, so I've modified the function readstdin in order
> to solve this issued. It was very bouring to copy a selection larger
> than 1024 chars with dclip and then have to paste several items from
> dmenu instead of just one.
>
> I attached the patch for dmenu-4.0 (last stable release) and dmenu-tip
> and the last release of dclip.
>
> Kind regards,
> -- Nibble
[dev] suckless real time file sync system (or dropbox alternative)
Hi. I'm needing a simple wait to do real time (or near real-time) file synchronization between a bunch of remote machines. Any host should be "master", so any master-slave architecture is just inadequate. Any suggestions? -htr smime.p7s Description: S/MIME cryptographic signature
Re: [dev] suckless real time file sync system (or dropbox alternative)
Inotify+rsync a guy from the company I work on wrote an app to do this, and it is somewhere in the internets. I don't remember the name, but I can ask for it. This app is written in python, so a C replacements would be good. On Dec 22, 2009, at 8:36 AM, Hugo Tavares Reis wrote: Hi. I'm needing a simple wait to do real time (or near real-time) file synchronization between a bunch of remote machines. Any host should be "master", so any master-slave architecture is just inadequate. Any suggestions? -htr
