Re: [dev] interested in issue tracker dev
On Wed, 8 Feb 2012 20:15:52 +0100 Anselm R Garbe garb...@gmail.com wrote: Btw. I would like you to use C and rc, not C and bash or something similar. There were once discussion about blessed rc version, but AFAIR there were no simple conclusion. What version of rc is good enough? What I remember: Byron's version is cursed and p9p version is too big. So which one is good? I don't intend to make another thread out of this, but I would really appreciate simple answer. IMHO sh is acceptable also, but only for simplistic version.
Re: [dev] cat unique deice identifier e.g. serial number
Ah, cool. That's exactly what I needed. On 09.02.2012, Benjamin R. Haskell suckl...@benizi.com wrote: On Thu, 9 Feb 2012, hiro wrote: mhm, so there's no native way on a linux? Depending on your kernel, the DMI information may be available via sysfs. You asked for the serial number before. I have that at: /sys/class/dmi/id/board_serial Contents are equivalent to `dmidecode -s baseboard-serial-number`. The equivalent of Christoph's suggestion (dmidecode -s system-uuid) is available at: /sys/class/dmi/id/product_uuid -- Best, Ben
Re: [dev] [st] 0.2 is out
The SHELL macro from config.h isn't used; instead, the shell is grabbed with getenv(SHELL). I guess this was the default behavior before, but the last time I used st-0.1.1 I didn't mind having bash as my shell, so I didn't catch it--sorry. The macro should be removed from config.def.h if it's not used; attached is a patch for st-0.2 that doesn't use getenv(), which works for me because I don't have a choice of setting $SHELL when dwm is launched. I'm sure someone will have a better idea for handling this, or I could have changed the termcmd in dwm's config.h, or whatever. --Andrew Hills st-use-shell-macro.patch Description: Binary data
Re: [dev] [st] 0.2 is out
On Thu, Feb 09, 2012 at 09:22:45AM -0500, Andrew Hills wrote: I don't have a choice of setting $SHELL when dwm is launched. Why can't you set $SHELL?
Re: [dev] [st] 0.2 is out
On Thu, Feb 9, 2012 at 9:31 AM, Kurt H Maier khm-suckl...@intma.in wrote: Why can't you set $SHELL? Stupid restrictions on the environment at work. I telnet into some silly interface to launch a VNC server; all I can specify is the window manager executable's path, and it tests to make sure it's a binary. I guess I could write a program to set $SHELL and launch dwm, but changing st is faster, and the only place it matters. --Andrew Hills
Re: [dev] Hosting services for projects under public domain, ISC, MIT/X or BSD licenses
Thank you! Do you only accept software projects?
Re: [dev] [st and terminals] About escape sequences and stuff
Thanks for the pointer. I just read Chapter 6 and I agree with most of it. Is there any plans for st to go towards a ``good direction ? I mean using maybe unusual but saner control or escape sequences, support all colors (2^24 or 2^32) at the same time ? Writing a saner library than ncurses that knows only st and try to convince other terminal emulator writers to do the same: support exactly the same sequences. I don't know what a ``good direction would be, I was just thinking aloud. Guillaume. 2012/2/9, Kurt H Maier khm-suckl...@intma.in: Please see the Unix Haters' Handbook[1], Part 1, Chapter 6. [1] - http://www.simson.net/ref/ugh.pdf
Re: [dev] [st and terminals] About escape sequences and stuff
On Thu, Feb 09, 2012 at 05:25:08PM +0100, Guillaume Quintin wrote: Writing a saner library than ncurses that knows only st and try to convince other terminal emulator writers to do the same: support exactly the same sequences. The logical conclusion of this approach is e.g. NeWS. NeWS failed as a commercial product. No idea how something like it would fare in the modern world.
Re: [dev] [st and terminals] About escape sequences and stuff
| Writing a saner library than ncurses that knows only st and try to | convince other terminal emulator writers to do the same: support | exactly the same sequences. Replacing ncurses with a hardcoded library is not a workable approach. Unix systems today are accessed from far more environments than simply X Windows terminal emulators. Even if all such programs were updated to the new escape sequences, an ncurses-equivalent library that only supports them would not work for everyone ssh'ing in to Unix systems from Mac OS X, from Windows, from various smartphones and other devices, and for those quixotic people who are still using real serial terminals (or in some cases emulations of them). More precisely, any program that used this new library would be nonfunctional for such people. - cks
Re: [dev] [st and terminals] About escape sequences and stuff
you may probably want to look at my r_cons and r_line libraries from r2. i do buffering, autocomplete, screen filling, and works on w32 console, and most of terminals (st, xterm...) without guessing the termcodes. i just hardcode them. http://radare.org On Feb 9, 2012, at 18:02, Chris Siebenmann c...@cs.toronto.edu wrote: | Writing a saner library than ncurses that knows only st and try to | convince other terminal emulator writers to do the same: support | exactly the same sequences. Replacing ncurses with a hardcoded library is not a workable approach. Unix systems today are accessed from far more environments than simply X Windows terminal emulators. Even if all such programs were updated to the new escape sequences, an ncurses-equivalent library that only supports them would not work for everyone ssh'ing in to Unix systems from Mac OS X, from Windows, from various smartphones and other devices, and for those quixotic people who are still using real serial terminals (or in some cases emulations of them). More precisely, any program that used this new library would be nonfunctional for such people. - cks
Re: [dev] sbase TODO patch
On Thu, Feb 09, 2012 at 12:15:32PM +, stateless wrote:
Hi all,
Implemented yes(1), sync(1) and printenv(1). Source is attached,
haven't had time to write the manpage yet.
Cheers,
stateless
These are slightly shorter and printenv() returns 1 when it can't find
the environment variable.
Thanks,
Rob
#include stdio.h
#include stdlib.h
#include string.h
#include util.h
int main(int argc, char **argv)
{
char *print_me;
if(argc 2){
print_me = y;
}else{
char *arg, *p;
int i, len = 1;
for(i = 1; i argc; i++)
len += 1 + strlen(argv[i]);
p = arg = malloc(len);
if(!arg)
eprintf(malloc():);
for(i = 1; i argc; i++)
p += sprintf(p, %s%s, argv[i], argv[i + 1] ? : );
print_me = arg;
}
for(;;)
printf(%s\n, print_me);
}
#include stdio.h
#include stdlib.h
int main(int argc, char **argv, char **environ)
{
int ret = 0;
if(argc = 1){
char **ep;
for(ep = environ; *ep; ep++)
printf(%s\n, *ep);
}else{
int i;
for(i = 1; i argc; i++){
char *env = getenv(argv[i]);
if(env)
printf(%s\n, env);
else
ret = 1;
}
}
return ret;
}
Re: [dev] please test slock tip
On Wed, Feb 08, 2012 at 11:00:09PM +0100, Anselm R Garbe wrote: I would like to ask you to test the slock tip. I haven't fixed the multiply numpad combo issue, however I believe I have fixed the issue that new clients appear on top of the black windows. $ ./slock ( sleep 1 ; st ) will show a terminal window on top of the black slock window. Not that I could use the terminal, but it's shown. Also the reply to -v lacks a \n. -- Eckehard Berns
Re: [dev] please test slock tip
On 9 February 2012 19:50, Eckehard Berns ecki-suckl...@ecki.to wrote: On Wed, Feb 08, 2012 at 11:00:09PM +0100, Anselm R Garbe wrote: I would like to ask you to test the slock tip. I haven't fixed the multiply numpad combo issue, however I believe I have fixed the issue that new clients appear on top of the black windows. $ ./slock ( sleep 1 ; st ) will show a terminal window on top of the black slock window. Not that I could use the terminal, but it's shown. Not for me, I can't reproduce this. Also the reply to -v lacks a \n. Fixed in hg tip. Cheers, Anselm
[dev] stest review
Hi there, I heavily dislike the fact that dmenu now contains a reference to getopt(). Not exactly dmenu, but stest. Can we please remove the getopt() dependency? Thanks, Anselm
Re: [dev] interested in issue tracker dev
On 9 February 2012 10:16, Hadrian Węgrzynowski hadr...@hawski.com wrote: On Wed, 8 Feb 2012 20:15:52 +0100 Anselm R Garbe garb...@gmail.com wrote: Btw. I would like you to use C and rc, not C and bash or something similar. There were once discussion about blessed rc version, but AFAIR there were no simple conclusion. What version of rc is good enough? What I remember: Byron's version is cursed and p9p version is too big. So which one is good? Of course http://tools.suckless.org/9base IMHO sh is acceptable also, but only for simplistic version. If it is plain sh, it is ok, but 9base would be preferred. There will be a new 9base-7 release soon as well. Cheers, Anselm
Re: [dev] please test slock tip
On Thu, Feb 09, 2012 at 08:19:35PM +0100, Anselm R Garbe wrote: On 9 February 2012 19:50, Eckehard Berns ecki-suckl...@ecki.to wrote: $ ./slock ( sleep 1 ; st ) will show a terminal window on top of the black slock window. Not that I could use the terminal, but it's shown. Not for me, I can't reproduce this. Hmm, maybe my 64bit system again? I tried several things to get this working. First, on my system slock would not see any event besides KeyPress/KeyRelease (and mybe mouse movement - didn't test), then after explicitly requesting a VisibilityChangeMask, slock worked until I restarted xcompmgr again (stopped it for testing purposes). Now I added a call to XSelectInput(dpy, lock-root, SubstructureNotifyMask); That did work for me every time (with and without xcompmgr, no further changes to slock.c required). -- Eckehard Berns
Re: [dev] please test slock tip
On Thu, Feb 09, 2012 at 08:57:56PM +0100, Anselm R Garbe wrote: Ok, I must admit I don't use xcompmgr. *Cough* *mumble some excuse*... Nevertheless selecting for SubstructureNotifyMask makes sense and I applied a fix accordingly. Does vanilla hg tip works for you now? Yes. I tried it several times. Couldn't see any problems. -- Eckehard Berns
Re: [dev] sbase TODO patch
malloc() in yes(1) is definitely overkill. I've attached a simple
version.
#include stdio.h
int
main(int argc, char **argv)
{
const char *y[] = {,y};
int i;
if(argc 2)
argv=y, argc=2;
for(;;){
for(i=1; iargc; i++)
printf(%s%s\n, argv[i], (i==argc-1)?: );
}
}
Re: [dev] sbase TODO patch
Hi,
here is a version of rmdir(1) in the spirit of mkfifo.c.
Felix#include stdlib.h
#include unistd.h
#include util.h
int
main(int argc, char *argv[])
{
while(getopt(argc, argv, ) != -1)
exit(EXIT_FAILURE);
for(; optind argc; optind++)
if(rmdir(argv[optind]) == -1)
eprintf(remove %s:, argv[optind]);
return EXIT_SUCCESS;
}
Re: [dev] sbase TODO patch
On Thu, Feb 09, 2012 at 04:06:59PM -0500, Galos, David wrote:
malloc() in yes(1) is definitely overkill. I've attached a simple
version.
Invoking malloc() once (resulting in O(1) additional time and space) is
overkill but using printf() in every iteration (which means firing up
the printf() parser over and over again) isn't? I think you're a tad off
base, sir...
There's only two ways to implement this properly:
* Build the string during program initialization and use puts() (or
something similar) to print that string over and over again.
* Call the output routine once for each token in each iteration. If we
use buffered streams, this shouldn't make much difference. We should
probably do some quick performance tests to be sure, though.
#include stdio.h
int
main(int argc, char **argv)
{
const char *y[] = {,y};
int i;
if(argc 2)
argv=y, argc=2;
for(;;){
for(i=1; iargc; i++)
printf(%s%s\n, argv[i], (i==argc-1)?: );
}
}
Re: [dev] sbase TODO patch
On Thu, Feb 09, 2012 at 10:37:51PM +0100, Lukas Fleischer wrote: On Thu, Feb 09, 2012 at 04:06:59PM -0500, Galos, David wrote: malloc() in yes(1) is definitely overkill. I've attached a simple version. Invoking malloc() once (resulting in O(1) additional time and space) is overkill but using printf() in every iteration (which means firing up the printf() parser over and over again) isn't? I think you're a tad off base, sir... There's only two ways to implement this properly: * Build the string during program initialization and use puts() (or something similar) to print that string over and over again. * Call the output routine once for each token in each iteration. If we use buffered streams, this shouldn't make much difference. We should probably do some quick performance tests to be sure, though. What's more, that version prints a\nb\n for ./yes a b, instead of a b\n. Forgot completely about puts() though. Rob
Re: [dev] sbase TODO patch
Do we really need multiple arguments for yes(1)? BSD doesn't. while(puts(argv[1]) != EOF); cls
Re: [dev] sbase TODO patch
On Thu, Feb 09, 2012 at 10:19:55PM +, Connor Lane Smith wrote: Do we really need multiple arguments for yes(1)? BSD doesn't. while(puts(argv[1]) != EOF); Yeah. 'if (!argv[1]) argv[1] = y;' and this gets a +1 from me :) cls
Re: [dev] sbase TODO patch
On 9 February 2012 22:44, Lukas Fleischer suckl...@cryptocrack.de wrote: Yeah. 'if (!argv[1]) argv[1] = y;' and this gets a +1 from me :) It'd probably be more like, const char *s = (argc 2) ? y : argv[1]; while(puts(s) != EOF); cls
Re: [dev] sbase TODO patch
On Thu, Feb 09, 2012 at 10:52:57PM +, Connor Lane Smith wrote: On 9 February 2012 22:44, Lukas Fleischer suckl...@cryptocrack.de wrote: Yeah. 'if (!argv[1]) argv[1] = y;' and this gets a +1 from me :) It'd probably be more like, const char *s = (argc 2) ? y : argv[1]; while(puts(s) != EOF); Agreed :) cls
Re: [dev] stest review
On 9 February 2012 19:20, Anselm R Garbe garb...@gmail.com wrote: Can we please remove the getopt() dependency? If someone writes an ARGBEGIN-style flag parser with clustering, that's fine. Seems a bit of a waste considering getopt is POSIX, but never mind. cls
[dev] Suckless.org Man page links
The links to Man pages are broken for some tools. For example, http://tools.suckless.org/sic links to http://man.suckless.org/tools/1/sic which doesn't exist -- David Krauser
