Re: [dev] What is bad with Python
FRIGN wrote: > You can write beautiful and readable code in any language. [assuming that "you" means the reader in general, not S. Jegen in particular] False. I can't write such code in MATLAB, for example. > A question to everyone on this list: What do you think about the Go-language? I'm not a fan: • Case-sensitive exports seem wonky to me • Interfaces rather than variant types [but not interfaces per se] are weak • Member selection is in some cases cumbersome, in which it would not be in C, which is related to ¬(variant types) Mind, my experience is little, and this is merely what I found writing a λ-calculus interpreter in Go.
Re: [dev] What is bad with Go [formerly: What is bad with Python]
On 04/03/2014, Bobby Powers wrote: > Strake wrote: >> * Member selection is in some cases cumbersome, in which it would not >> be in C, which is related to ¬(variant types) > > Can you explain more what you mean? I can't quite remember the particulars. My case was a λ-calculus interpreter, which had to switch on program structure, and I remember solely that it was cumbersome. Perhaps I wrote unidiomatic code, but I couldn't find the appropriate idiom if any such is.
[dev] situ — change files in situ
Hello all. I wrote a program to mutate files in situ by a given shell program, available here: http://strake.zanity.net:1104/situ/ I thought that it might be useful for some other folks here, ergo this mail. I wrote it to gain the functionality of GNU sed's -i switch in 9base sed. Unlike GNU sed's -i switch, it ought to work with any program. Cheers, strake
Re: [dev] situ — change files in situ
On 13/04/2012, Troels Henriksen wrote: > I wrote a similar program in C: http://sigkill.dk/projects/insitu/ It > also does actual in-replace replacement (which is sometimes not what you > want). I actually found this prior, but wanted a program that would not harm the file on failure. > Note that you can also exploit shell evaluation order: What cls said.
Re: [dev] situ — change files in situ
On 13/04/2012, Connor Lane Smith wrote: > I wonder whether a situ-like could be used to produce a diff of the > original file, rather than a complete second copy. Programs like sed > don't generally make that many changes, so if we were to connect situ > to the file and the cmd's stdout we could compute the diff and then > patch the original file once cmd exits 0. If someone could get that > working it would be pretty sweet. I'm not sure why — this method seems ultimately functionally equivalent to mine. Perhaps I fail to ken your logic here. Cheers, strake
Re: [dev] situ — change files in situ
On 13/04/2012, Connor Lane Smith wrote: > Your method, while simpler, requires 2n space to 'situ' a length n > file. A suitable patch format would require only enough space to store > the changes to the original file. The outcome would be identical, but > if we're trying to sed only a few changes in a large file it would be > more efficient in terms of storage. True, if we trim the start and finish lazily, but worst-case diff algorithm space usage is worse — quadratic, if I'm not mistaken.
Re: [dev] situ — change files in situ
On 13/04/2012, Connor Lane Smith wrote: > On 13 April 2012 16:37, Strake wrote: >> True, if we trim the start and finish lazily > > That depends on the diff format. diff -e, for example, could work well. I meant to trim pre-diff, so it would be quadratic in a lesser argument. >> but worst-case diff >> algorithm space usage is worse — quadratic, if I'm not mistaken. > > That's true. Although, diff is worst-case quadratic in the number of > lines, not bytes. True for line-by-line diff, e.g. Unix diff, though the algorithm is more general. > And the fact is the worst-case can be avoided: we > don't really *need* the longest common subsequence, only an > approximation to it. If we exceed some threshold we can simply > 'plump'. You mean, to terminate the subsequence, and start afresh? > To be clear, I don't mean to dismiss either existing situ, this would > just be nice to have as well. Noted. Cheers, strake
Re: [dev] situ — change files in situ
On 13/04/2012, Truls Becken wrote: > There is also sponge from http://kitenet.net/~joey/code/moreutils/ which would also corrupt file on failure, by what little documentation I can read through the markup.
Re: [dev] situ — change files in situ
On 13/04/2012, Truls Becken wrote: > You are right. I thought that since it only opens the output file > after stdin is fully consumed, it would not touch the file on failure. > The test below reveals that sponge leaves the file alone if the > process is interrupted before end of stdin, but not if a program > before it in the pipe returns non-zero. > > I guess I should test programs before suggesting them to others. (^_^) Actually, it's not wrong — it would do the job, i.e. to mutate file in situ — it's just not quite sure enough. Cheers, strake
Re: [dev] st utf8 printing
On 14/04/2012, Connor Lane Smith wrote: > the distinction between TUIs and GUIs is completely artificial. This. Furthermore, the distinction between text and graphic is totally artificial, and the distinction between natural and artificial is itself totally artificial (^_~) The former distinction is chiefly perpetuated by a moronic but woefully common scheme of programs who fake serial terminalhood to allow old programs written for such to work, and libraries to allow NEW programs to be written for such archaic hardware, which thus operate in the same sham world of limited runes and irksome input methods, while mighty graphics controllers sit idle. *WRATH* I quite hope for ivo. Cheers, strake
Re: [dev] [ii] exposed password on process monitoring
On 19/04/2012, Ivan Kanakarakis wrote:
> because ii takes as an argument
> the password/-k,
> the password is exposed to anyone that can see what processes are running
> (top/htop).
>
> As no process can hide its arguments, how should one go around this ?
>
> - reading the passwd from a file (overkill ?)
Why overkill?
$ ii -k `{cat pwf}
Mind, the password is sent in the clear, so anyone on the same network
segment, or otherwise in the way, can read it anyhow.
Re: [dev] [ii] exposed password on process monitoring
On 19/04/2012, Connor Lane Smith wrote: > How about making 'ii -k -' read the password from stdin? Flags with > optional arguments are bad, imo. Worse yet are flags whose semantics vary by argument. k flag takes literal password, not file name. If we want such a feature we ought to add a new flag, as in attached patch. Cheers, strake pwfile.patch Description: Binary data
Re: [dev] [ii] exposed password on process monitoring
Oops, forgot case "-". pwfile.patch Description: Binary data
Re: [dev] [ii] exposed password on process monitoring
On 19/04/2012, Ivan Kanakarakis wrote:
> I tried the second one, I see the check for '-' in the code, but I get
>
> $ ii -n fooo -j -
> -: No such file or directory
>
> seems the check is faulty
>
> if (keyfile != NULL || stat(argv[i], &s) != 0) {
>
> does it work there ?
Ahhh. *facepalm*
pwfile.patch
Description: Binary data
Re: [dev] recommend suckless mail server
On 20/04/2012, sta...@cs.tu-berlin.de wrote: > Can anyone suggest a suckless mail server? > > We need encrypted IMAP and SMTP. Or a suckless tool chain which achieves > the above (e.g. instead SSL aware IMAP server, rsync a maildir from > server machine to local machine) To take incoming mail, I use netqmail, with these alterations: https://aur.archlinux.org/packages.php?ID=31137 which include TLS. Installation was a little grievous; I can't remember how I did it. Otherwise, it works well. Some documentation can be found at http://lifewithqmail.org To fetch my mail, I use dovecot. Installation was easy, and it works well and does TLS. Mind, my site is small — 1 user. Cheers, strake
Re: [dev] simple dhcp client
On 20/04/2012, pancake wrote: > lot of suckless tools exist nowadays.. mostly prefixed by 's'.. like star, > sdhcp.. i would love to ser them all grouped in a single repo, site or linux > distro. as far as we have 9base and musl can fill the gaps to have a fully > suckless distro. > > i think that those commands should get the standard program name like tar, > dhcp.. when we use them in stalin. > > > anyway.. whats the status of stalin? :) > > On Apr 20, 2012, at 7:38, Christoph Lohmann <2...@r-36.net> wrote: > >> Greetings. >> >> On Fri, 20 Apr 2012 07:38:40 +0200 Kai Hendry wrote: >>> I know this is very lazy of me, though it would be good if you could >>> have hints how to integrate it say with a typical Archlinux system and >>> its /etc/network.d >>> https://wiki.archlinux.org/index.php/Netcfg >> >> Netcfg is hardwired to dhcpcd. You will need to patch the whole netcfg >> system to add sdhcp support. A simple commandline argument wrapper or >> compatibility would work too. >> >> >> Sincerely, >> >> Christoph Lohmann >> >> > >
[dev] System, was: simple dhcp client
On 20/04/2012, pancake wrote: > lot of suckless tools exist nowadays.. mostly prefixed by 's'.. like star, > sdhcp.. i would love to ser them all grouped in a single repo, site or linux > distro. as far as we have 9base and musl can fill the gaps to have a fully > suckless distro. Since we are on the topic anyhow: My very rough, very unfinished such work so far can be found at http://strake.zanity.net:1104/lnx/tutorial.txt I forsook this work, at least for now, while I try to install Plan 9.
[dev] flzip: *FLATE program, can read gz
Hello all. I wrote a program to inflate/deflate data, that can read and write zlib-format data and read gzip-format data. I thought that some here might find it useful. http://strake.zanity.net:1104/flzip.git 2.6 kLoC, public domain. Needs plan9port. Cheers, strake
Re: [dev] flzip: *FLATE program, can read gz
On 10/05/2012, Strake wrote: > I wrote a program to inflate/deflate data, that can read and write > zlib-format data and read gzip-format data. Wow, I'm stupid. gzip is part of plan9port.
Re: [dev] static linking from cat-v on r/linux
Damn, I hoped that this meant that sta.li is ready
Re: [dev] obase - Sta.li moving forward?
On 05/06/2012, Jens Staal wrote: > Hi > > I was playing with packaging Christian's obase for Arch > https://aur.archlinux.org/packages.php?ID=56826 Thanks, never knew that before. > and an easy-to-chroot package to complement it > https://aur.archlinux.org/packages.php?ID=59735 > > The idea I had was that one could use this environment as a gradual > experimental environment to build up a complete alternative OS by a > custom init chrooting into /opt/obase. > When it has been completely assembled and self-hosting, one could make > it into an independent system. > > I hope to update both to musl and complete static in the near future. > > At the moment I have some issues with that the binaries refuse to be > 100% static > an output of ldd gives: > >> ldd ./ksh > linux-vdso.so.1 => (0x7f393000) > libc.so.6 => /lib/libc.so.6 (0x7fd020358000) > /lib/ld-linux-x86-64.so.2 (0x7fd0206f9000) > > as long as those dynamic dependencies are present, the chroot idea > will not work. Against which C library? The first is not a file, but rather code kept in the kernel and loaded in the memory space of every proc on the system. http://www.trilithium.com/johan/2005/08/linux-gate/ Thus, it ought to not make grief, in this way at least. Clearly the others will. > and adding static as CC="$CC -static" or in CFLAGS or LDFLAGS does not help > :( With which linker? If GNU, which is likely on Linux, then it may be broken as designed. One method to build a full system is to build a toolchain unable to dynamic link at all, and itself static-linked, and then with it build the other wares. Crosstool-ng can build such a toolchain. Cheers, strake
Re: Sta.li critical performance question (WAS [dev] obase - Sta.li moving forward?)
On 08/06/2012, Ethan Grammatikidis wrote:
> On the linked page, Johan Petersson wrote:
>
>> It turns out, though, that system calls invoked via interrupts are
>> remarkably slow on the more recent members of the x86 processor
>> family. An int 0x80 system call can be as much as an order of
>> magnitude slower on a 2 GHz Pentium 4 than on an 850 MHz Pentium III.
>
> Will linux-vdso or linux-gate be properly used by a statically linked
> binary? Does it perhaps require /lib/ld-linux.so to link it in?
>
> I ask because I have some reason to believe syscall performance is
> important if you want to work in the unix way, and doubly so if you
> want a suckless system. Petersson here describes an order of magnitude
> difference in syscall performance. I'm not sure of my conclusion but
> it's something to keep an eye on, perhaps timing the piping of data in
> both static and conventional Linux systems on the same hardware.
On my x86 machine:
$ cat test.c
#include
#include
#include
#include
int size = 1<<18;
int n= 1<<16;
void main () {
char x[size];
int ii;
int ifd = open ("/dev/zero", O_RDONLY);
int ofd = open ("/dev/null", O_WRONLY);
for (ii = 0; ii < n; ii++) if (read (ifd, x, size) < 0 ||
write (ofd, x, size) < 0) exit (1);
}
$ ls -l $(which cc)
lrwxrwxrwx 1 root root 3 May 7 01:19 /usr/bin/cc -> gcc
$ cc test.c && ldd a.out
linux-vdso.so.1 => (0x7fffbfbff000)
libc.so.6 => /lib/libc.so.6 (0x7faf905f7000)
/lib/ld-linux-x86-64.so.2 (0x7faf90998000)
$ time ./a.out
./a.out 0.01s user 3.13s system 99% cpu 3.144 total
$ cc -static test.c && ldd a.out
not a dynamic executable
$ time ./a.out
./a.out 0.00s user 3.14s system 100% cpu 3.145 total
No worries, it seems.
Cheers,
strake
Re: [dev] [surf] port for gtk3
Another option would be Clutter: http://trac.webkit.org/wiki/clutter
Re: [dev] [surf] port for gtk3
On 22/06/2012, Strake wrote: > Another option would be Clutter: http://trac.webkit.org/wiki/clutter > Never mind, it's just another GTK. Sorry.
[dev] [PATCH] sbase: add cut
Will now need libutf.
diff -r 8cf300476909 Makefile
--- a/Makefile Sat Jun 09 18:53:39 2012 +0100
+++ b/Makefile Tue Jul 31 23:06:28 2012 -0500
@@ -27,6 +27,7 @@
cksum.c\
cmp.c \
cp.c \
+ cut.c \
date.c \
dirname.c \
echo.c \
diff -r 8cf300476909 config.mk
--- a/config.mk Sat Jun 09 18:53:39 2012 +0100
+++ b/config.mk Tue Jul 31 23:06:28 2012 -0500
@@ -10,7 +10,7 @@
LD = $(CC)
CPPFLAGS = -D_POSIX_C_SOURCE=200112L
CFLAGS = -g -ansi -Wall -pedantic $(CPPFLAGS)
-LDFLAGS = -g
+LDFLAGS = -g -lutf
#CC = tcc
#LD = $(CC)
diff -r 8cf300476909 cut.1
--- /dev/null Thu Jan 01 00:00:00 1970 +
+++ b/cut.1 Tue Jul 31 23:06:28 2012 -0500
@@ -0,0 +1,51 @@
+.TH CUT 1
+.SH NAME
+cut \- select columns of file
+.SH SYNOPSIS
+.B cut -f
+.I ranges
+[
+.B -d
+.I delimiter
+]
+[
+.I file ...
+]
+.br
+.B cut -c
+.I ranges
+[
+.I file ...
+]
+.br
+.B cut -b
+.I ranges
+[
+.I file ...
+]
+.br
+.SH OPERATION
+Cut reads from given files, or stdin if no files given, and for each
line selects
+.TP
+.B columns,
+with -f flag
+.TP
+.B characters,
+with -c flag
+.TP
+.B bytes,
+with -b flag
+.LP
+within given comma- or space-delimited ranges.
+.LP
+.br
+Each range is either a single decimal number, or of this form:
+.br
+.I x
+-
+.I y
+.br
+where x and y are decimal numbers, or empty.
+Empty x means first, and empty y means last column/character/byte on the line.
+.LP
+If -d option given, then the first character of its argument is the
delimiter; otherwise it is tab.
diff -r 8cf300476909 cut.c
--- /dev/null Thu Jan 01 00:00:00 1970 +
+++ b/cut.c Tue Jul 31 23:06:28 2012 -0500
@@ -0,0 +1,192 @@
+#include
+#include
+#include
+#include "text.h"
+
+typedef struct {
+ int min, max;
+} range;
+
+int inRange (range r, unsigned int n) {
+ if ((0 == r.max || n <= r.max) && n >= r.min) return 1;
+ else return 0;
+}
+
+int fputrune (Rune r, FILE *f) {
+ char x[UTFmax];
+ int n;
+ n = runetochar (x, &r);
+ fwrite (x, 1, n, f);
+ return n;
+}
+
+void cutLineF (Rune d, unsigned int s, range *rs, char *x) {
+ int ii, n;
+ if (!utfrune (x, d)) {
+ if (!s) fputs (x, stdout);
+ return;
+ }
+ /* kludge; be warned */
+ for (ii = 0; rs[ii].min; ii++) {
+ char *y;
+ y = x;
+ for (n = 1; y; n++) {
+ char *z;
+ char ch;
+ z = utfrune (y, d);
+ if (z) {
+ ch = *z;
+ *z = 0;
+ }
+ if (inRange (rs[ii], n)) {
+ fputs (y, stdout);
+ fputrune (d, stdout);
+ }
+ if (z) {
+ *z = ch;
+ z += runelen (d);
+ }
+ y = z;
+ }
+ }
+}
+
+void cutLineC (range *rs, char *x) {
+ Rune _r;
+ int ii, n;
+ for (ii = 0; rs[ii].min; ii++) {
+ char *y;
+ y = x;
+ for (n = 1; *y; n++) {
+ int l = chartorune (&_r, y);
+ if (inRange (rs[ii], n)) fwrite (y, 1, l, stdout);
+ y += l;
+ }
+ }
+}
+
+void cutLineB (range *rs, char *x) {
+ int ii, n;
+ for (ii = 0; rs[ii].min; ii++) {
+ for (n = rs[ii].min - 1; rs[ii].max ? n < rs[ii].max : x[n];
n++) {
+ fputc (x[n], stdout);
+ }
+ }
+}
+
+void go (int mode, Rune d, unsigned int s, range *rs) {
+ char *x;
+ size_t size = 0;
+ x = 0;
+
+ while (afgets (&x, &size, stdin)) {
+ int ii;
+ /* must delete newline here, and redo later;
+ otherwise, unknown whether it was included in cut */
+ for (ii = 0; x[ii]; ii++) if (x[ii] == '\n') x[ii] = 0;
+ switch (mode) {
+ case 'f':
+ if (!utfrune (x, d)) {
+ if (!s) {
+ fputs (x, stdout);
+ fputc ('\n', stdout);
+ }
+ }
+ else {
+ cutLineF (d, s, rs, x);
+ fputc ('\n', stdout);
+ }
+ break;
+ case 'c': cutLineC (rs, x); fputc ('\n', stdout); break;
+ case 'b': cutLineB (rs, x); fputc ('\n', stdout); break;
+ }
+ }
+}
+
+int main (int argc, char *argu[]) {
+ int mode = 0;
+ Rune d = '\t';
+ unsigned int s = 0;
+ range *rs = 0;
+ int ii;
+
Re: [dev] [PATCH] sbase: add cut
On 01/08/2012, Martin Kopta wrote: >> Also, I'm really curious why people use cut when awk exists. > > $ du -b /usr/bin/cut /usr/bin/gawk /opt/plan9/bin/awk > 38600 /usr/bin/cut > 400212 /usr/bin/gawk > 105700 /opt/plan9/bin/awk > > Speed and simplicity I guess? > > Why would I use awk of which I don't remember syntax, when I could often > do with trustworthy cut easily? This. Actually just simplicity; I'm not sure which has better speed. Meh.
Re: [dev] [PATCH] sbase: add cut
I rewrote cut cleaner, but am not sure whether I ought to bother to send it, if ye would rather keep sbase sans cut.
[dev] Re: [PATCH] sbase: add cut
So, the new version, cut.c only, all else same:
diff -r 8cf300476909 cut.c
--- /dev/null Thu Jan 01 00:00:00 1970 +
+++ b/cut.c Wed Aug 01 09:41:11 2012 -0500
@@ -0,0 +1,188 @@
+#include
+#include
+#include
+#include
+#include "text.h"
+#include "util.h"
+
+typedef struct {
+ int min, max;
+} range;
+
+int inRange (range r, unsigned int n) {
+ if ((0 == r.max || n <= r.max) && n >= r.min) return 1;
+ else return 0;
+}
+
+int fputrune (Rune r, FILE *f) {
+ char x[UTFmax];
+ int n;
+ n = runetochar (x, &r);
+ fwrite (x, 1, n, f);
+ return n;
+}
+
+void cutLineF (Rune d, unsigned int s, range *rs, char *x) {
+ int ii, n, nMax;
+ char **xs;
+ if (!utfrune (x, d)) {
+ if (!s) fputs (x, stdout);
+ return;
+ }
+ xs = malloc (sizeof (char *) * (strlen (x) + 2));
+ if (!xs) eprintf ("cut:");
+ for (n = 1; x; n++) {
+ xs[n] = x;
+ x = utfrune (x, d);
+ if (x) x += runelen (d);
+ }
+ nMax = n;
+ xs[nMax] = xs[0] + strlen (xs[0]);
+ for (ii = 0; rs[ii].min; ii++) {
+ if (nMax <= rs[ii].min) continue;
+ for (n = rs[ii].min; (rs[ii].max ? n <= rs[ii].max : 1) && n <
nMax; n++) {
+ char ch = *xs[n+1];
+ *xs[n+1] = 0;
+ fputs (xs[n], stdout);
+ *xs[n+1] = ch;
+ }
+ }
+ free (xs);
+}
+
+void cutLineC (range *rs, char *x) {
+ Rune _r;
+ int ii, n;
+ for (ii = 0; rs[ii].min; ii++) {
+ char *y;
+ y = x;
+ for (n = 1; *y; n++) {
+ int l = chartorune (&_r, y);
+ if (inRange (rs[ii], n)) fwrite (y, 1, l, stdout);
+ y += l;
+ }
+ }
+}
+
+void cutLineB (range *rs, char *x) {
+ int ii, n;
+ for (ii = 0; rs[ii].min; ii++) {
+ for (n = rs[ii].min - 1; rs[ii].max ? n < rs[ii].max : x[n];
n++) {
+ fputc (x[n], stdout);
+ }
+ }
+}
+
+void go (int mode, Rune d, unsigned int s, range *rs, FILE *f) {
+ char *x;
+ size_t size = 0;
+ x = 0;
+
+ while (afgets (&x, &size, f)) {
+ int ii;
+ /* must delete newline here, and redo later;
+ otherwise, unknown whether it was included in cut */
+ for (ii = 0; x[ii]; ii++) if (x[ii] == '\n') x[ii] = 0;
+ switch (mode) {
+ case 'f':
+ if (!utfrune (x, d)) {
+ if (s) break;
+ fputs (x, stdout);
+ }
+ else cutLineF (d, s, rs, x);
+ fputc ('\n', stdout);
+ break;
+ case 'c': cutLineC (rs, x); fputc ('\n', stdout); break;
+ case 'b': cutLineB (rs, x); fputc ('\n', stdout); break;
+ }
+ }
+}
+
+int main (int argc, char *argu[]) {
+ int mode = 0;
+ Rune d = '\t';
+ unsigned int s = 0;
+ range *rs = 0;
+ int ii;
+
+ /* parse options */
+ for (ii = 1; ii < argc; ii++) {
+ int jj;
+ if (argu[ii][0] != '-' || argu[ii][1] == 0) break;
+ if (argu[ii][1] == '-' && argu[ii][2] == 0) {
+ ii++;
+ break;
+ }
+ for (jj = 1; argu[ii][jj]; jj++) switch (argu[ii][jj]) {
+ case 'b':
+ case 'c':
+ case 'f':
+ mode = argu[ii][jj];
+
+ if (++ii >= argc) {
+ fputs ("cut: No range argument\n", stderr);
+ return 1;
+ }
+
+ rs = malloc (sizeof (range) * (utflen (argu[ii]) + 1));
+ if (!rs) eprintf ("cut:");
+
+ /* ensure space delimitation for strtoul */
+ for (jj = 0; argu[ii][jj]; jj++) if (argu[ii][jj] ==
',')
argu[ii][jj] = ' ';
+
+ /* parse ranges */
+ /* max = 0 to denote last */
+ {
+ char *p;
+ p = argu[ii];
+ jj = 0;
+ while (*p) {
+ rs[jj].min = *p == '-' ? 1 : strtoul
(p, &p, 10);
+ rs[jj].max = *p == '-' ? strtoul (++p,
&p, 10) : rs[jj].min;
+ switch (*p) {
+ case '\0':
+
[dev] [PATCH] sbase: add chroot
diff -r 8cf300476909 chroot.8
--- /dev/null Thu Jan 01 00:00:00 1970 +
+++ b/chroot.8 Wed Aug 01 04:46:43 2012 -0500
@@ -0,0 +1,25 @@
+.TH CHROOT 8
+.SH NAME
+chroot \- change root directory
+.SH SYNOPSIS
+.B chroot
+.I path
+[
+.I x
+[
+.I argument ...
+]
+]
+.SH OPERATION
+.B chroot
+changes the root directory to
+.I path
+and starts
+.I x
+with
+.I arguments
+, or
+.B $SHELL -i
+if no
+.I x
+given.
diff -r 8cf300476909 chroot.c
--- /dev/null Thu Jan 01 00:00:00 1970 +
+++ b/chroot.c Wed Aug 01 04:46:43 2012 -0500
@@ -0,0 +1,22 @@
+#include
+#include
+#include
+#include "util.h"
+
+int main (int argc, char *argu[]) {
+ if (argc < 2) {
+ fputs ("No new root path given\n", stderr);
+ exit (1);
+ }
+ if (chroot (argu[1])) eprintf ("chroot:");
+ if (argc == 2) {
+ char *x;
+ x = getenv ("SHELL");
+ if (!x) {
+ fputs ("chroot: SHELL not set\n", stderr);
+ return 1;
+ }
+ if (execl (x, x, "-i", (char *)0) < 0) eprintf ("chroot: %s:",
x);
+ }
+ else if (execv (argu[2], argu + 2) < 0) eprintf ("chroot: %s:",
argu[2]);
+}
Re: [dev] [PATCH] sbase: add chroot
On 01/08/2012, pancake wrote:
> That is vulnerable on linux. Proper use is:
>
> chdir (path); chroot(".");
Ah, sorry.
--- /dev/null Thu Jan 01 00:00:00 1970 +
+++ b/chroot.8 Wed Aug 01 05:09:36 2012 -0500
@@ -0,0 +1,25 @@
+.TH CHROOT 8
+.SH NAME
+chroot \- change root directory
+.SH SYNOPSIS
+.B chroot
+.I path
+[
+.I x
+[
+.I argument ...
+]
+]
+.SH OPERATION
+.B chroot
+changes the root directory to
+.I path
+and starts
+.I x
+with
+.I arguments
+, or
+.B $SHELL -i
+if no
+.I x
+given.
diff -r 8cf300476909 chroot.c
--- /dev/null Thu Jan 01 00:00:00 1970 +
+++ b/chroot.c Wed Aug 01 05:09:36 2012 -0500
@@ -0,0 +1,22 @@
+#include
+#include
+#include
+#include "util.h"
+
+void main (int argc, char *argu[]) {
+ if (argc < 2) {
+ fputs ("No new root path given\n", stderr);
+ exit (1);
+ }
+ if (chdir(argu[1]) || chroot (".")) eprintf ("chroot:");
+ if (argc == 2) {
+ char *x;
+ x = getenv ("SHELL");
+ if (!x) {
+ fputs ("chroot: SHELL not set\n", stderr);
+ exit (1);
+ }
+ if (execl (x, x, "-i", (char *)0) < 0) eprintf ("chroot: %s:",
x);
+ }
+ else if (execv (argu[2], argu + 2) < 0) eprintf ("chroot: %s:",
argu[2]);
+}
Re: [dev] [PATCH] sbase: add cut
On 01/08/2012, Kurt H Maier wrote: > In fact, I'm fairly > certain I could implement cut in sed. with shell script wrapper?
Re: [dev] [PATCH] sbase: add chroot
On 01/08/2012, Džen wrote:
> why argu?
>
> On Wed, Aug 1, 2012 at 5:11 PM, Strake wrote:
> [...]
>> +void main (int argc, char *argu[]) {
> [...]
Habit of mine.
Re: [dev] [PATCH] sbase: add cut
On 03/08/2012, Connor Lane Smith wrote: > % head -n -10 Not sbase head. $ seq 0 7 | head -n -2 $
Re: Regarding "dogma" words [Was: Re: Regarding "make"-systems [Was: Re: [dev] Build system: redo]]
On 10/08/2012, hiro <23h...@gmail.com> wrote: > well, this is an elitist list of mothafockas who don't give a shit > about others. that's why communication theorists can go away. > Yep. We're so elite, we're not bound by any mere laws of physics. Just watch us squeeze many GB of entropy into this tiny 4 kB memory chip.
Re: [dev] any update on stali?
On 23/08/2012, Joaquim Pedro França Simão wrote: > I wonder if there is any news about stali. I searched the mail list, but had > no activity on this recently. Most activity about stali seems to be such as this. > I started to hate autotools further. Yes, no wonder. GNU Autotools is a system to cause build failures and other grief, portably. > Basically I started to see many setbacks, not to mention faults in the > current system of distributions. I'd really like to help any project > doesn't sucks. I have for quite a while been trying to build a static-linked Arch-based system with, as its core, linux, pacman, sbase, and some tools from OpenBSD. It is highly experimental, not ready for general use, with no warranty, quite possibly likely to kill or maim, etc, etc. Not sure whether it will meet your criteria, but nevertheless it can be found here: Built packages, x86_64: http://strake.zanity.net:1104/starch/pkg/core/ Build scripts, i.s. PKGBUILDS: http://strake.zanity.net:1104/starch/abs.git Packages built against uClibc. Short-term goals are these: * make pacman and the associated tools and scripts, mainly makepkg, work with said core * diversify architecturally, e.g. i686, Loongson
Re: [dev] any update on stali?
On 27/08/2012, Kurt H Maier wrote: > On Mon, Aug 27, 2012 at 10:30:32PM +, Bjartur Thorlacius wrote: >> Why Loongson? > He means MIPS. Yes, sorry. OpenBSD calls it "loongson" rather than "mips" so I thought that binaries must be built for Loongson specifically, which now rather seems false.
Re: [dev] [st] Patches
On 19/09/2012, Roberto E. Vargas Caballero wrote: > Maybe a good solution could be > integrate tmux inside of st (for example if STTMUX is defined, run tmux in > starup). Yeah! Oh, we could have a variable for everything that one could wish to start in st: STTMUX, STGNUSCREEN, STAALIBKDE... or we could just use -e.
Re: [dev] libixp questions
On 21/09/2012, hiro <23h...@gmail.com> wrote: > if you want reliability don't use a computer. > if you want reliability don't use the world.
Re: [dev] Hall of shame of the web
On 29/09/2012, Christoph Lohmann <2...@r-36.net> wrote: > What would you think about some kind of hall of shame for websites that > waste most resources? "meh"
[dev] [sbase/grep] [PATCH]: add z flag to use NULL separators
Not sure which would be better choice of flag: 'z' or '0', so I
arbitrarily chose 'z'.
commit 474a73ae118e6791fc56e616233dd9ccb5c8e92f
Author: strake
Date: Thu Oct 4 19:50:23 2012 -0500
grep: add z flag to use NULL separators
diff --git a/grep.c b/grep.c
index 9716328..48a54c0 100644
--- a/grep.c
+++ b/grep.c
@@ -18,6 +18,8 @@ static bool many;
static bool match = false;
static char mode = 0;
+static char delim = '\n';
+
int
main(int argc, char *argv[])
{
@@ -41,6 +43,9 @@ main(int argc, char *argv[])
case 'v':
vflag = true;
break;
+ case 'z':
+ delim = '\0';
+ break;
default:
usage();
} ARGEND;
@@ -73,7 +78,7 @@ grep(FILE *fp, const char *str, regex_t *preg)
long n, c = 0;
size_t size = 0, len;
- for(n = 1; afgets(&buf, &size, fp); n++) {
+ for(n = 1; getdelim(&buf, &size, delim, fp) >= 0; n++) {
if(buf[(len = strlen(buf))-1] == '\n')
buf[--len] = '\0';
if(regexec(preg, buf, 0, NULL, 0) ^ vflag)
@@ -92,7 +97,7 @@ grep(FILE *fp, const char *str, regex_t *preg)
printf("%s:", str);
if(mode == 'n')
printf("%ld:", n);
- printf("%s\n", buf);
+ printf("%s%c", buf, delim);
break;
}
match = true;
Re: [dev] uriel is gone
On 14/10/2012, Kurt H Maier wrote: > Sorry to have to let you guys know, uriel passed away peacefully a > couple days ago. We'll miss him. > > Kurt > I am very sorry to hear this. I never knew him in person, but I shall miss his keen commentary. Strake
Re: [dev] [surf] [patch] Multiple views, one process
On 19/10/2012, Calvin Morrison wrote: > I think the largest benefit is the cache. Loading up many > http://google.com's would mean you'd have to reload all of the images > and such, whereas with one process, you wouldn't have an opportunity > of overlap cache. So make a local HTTP caching proxy. Alternatively, to save memory perhaps, one could use local shared cache files, e.g. /var/cache/surf/ > for unix-tooly-ness with kill, you could intercept signals and only > have them apply to the current window. So to kill some window, I must first switch to it, then kill it. Not so bothersome interactively, but quite difficult in a script. That, and KILL is uncatchable, so it would kill them all; same for STOP.
Re: [dev] Wayland
On 23/10/2012, Hugues Moretto-Viry wrote: > What do you think about Wayland? Guess: http://wayland.freedesktop.org/docs/html/chap-Protocol.html
[dev] [announce] Starch Linux: static-linked Arch Linux
Starch is a static-linked, Arch-based, highly experimental Linux distro. I thought that some folks here may care to try it. Packages: http://strake.zanity.net:1104/starch/pkg/(core, extra) Build Scripts: http://strake.zanity.net:1104/starch/ports.git To install, one can just use the stock Arch image and point pacman to the Starch repo. So far, the base system works and is bootable, on my qemu VM at least. Binaries are linked against uClibc or musl; I hope to use musl alone in near future. It can't yet build itself, but has a toolchain available, taken from sabotage, which links against musl. Packages are built for amd64. I may add legacy x86_32 packages if someone builds them, and I mean to add loongson packages when I get one. Short-term goals: * Switch to musl * Build self as host * Find a mirror Longer-term goals: * Trash GNU gcc, binutils, bash * Ergo, port all scripts to mksh * Install media Forever goals: * Not lose Cheers, Strake
Re: [dev] [announce] Starch Linux: static-linked Arch Linux
On 25/10/2012, Calvin Morrison wrote: > You're sticking with initscripts I presume? Yes.
Re: [dev] [announce] Starch Linux: static-linked Arch Linux
On 25/10/2012, Calvin Morrison wrote: > Excellent work. > > Carry on good lad Thanks, I mean to (^_^)
Re: [dev] [announce] Starch Linux: static-linked Arch Linux
On 25/10/2012, Strake wrote: > Packages: http://strake.zanity.net:1104/starch/pkg/(core, extra) > Build Scripts: http://strake.zanity.net:1104/starch/ports.git Someone just told me that my server is unreachable. I thought I had it working again, but clearly I was wrong. Sorry about this; I'll try to unbreak it or find an alternative soon. Cheers, Strake
Re: [dev] [announce] Starch Linux: static-linked Arch Linux
On 25/10/2012, Strake wrote: > Someone just told me that my server is unreachable. I thought I had it > working again, but clearly I was wrong. Sorry about this; I'll try to > unbreak it or find an alternative soon. Sorry about this. Ought to be reachable now. Got new IP, forgot to change DNS. Ports now also available on github: https://github.com/strake/starch-ports
Re: [dev] Troff for typsetting e-mails
On 28/10/2012, Luis Anaya wrote: >>> On Sun, Oct 28, 2012 at 01:21:40PM +0100, hiro wrote: >>> > typesetting? raw text can be typeset just fine with a keyboard. not >>> > sure what you're really up to. >>> > >>> >>> It is suckless answer to HTML email. >>> >> It might as well *be* HTML email. > > Because it is. A rose of any other name is... ? Troff ≠ HTML.
Re: [dev] [st] 0.3 release
On 05/11/2012, Brandon Invergo wrote: > First, to see what I'm talking about: > 1) Open a terminal and start some CPU monitor (ie top or htop) > 2) Open another terminal and load a rather large man page (try > termcap(5)) > 3) Start scrolling down on the man page and watch your Xorg process's > CPU usage spike. Depending on how fast your computer is, this can be > anywhere from ~10%-75% CPU usage (15% on this quad-core Intel Core2Pro, > 75% on my 800mhz Arm Cortex A8) > 4) Try the same experiment with xterm or urxvt: no CPU spike I tried this and found that st version 386 actually does better, i.e. lower CPU usage, than urxvt.
Re: [dev] [st] 0.3 release
On 05/11/2012, Brandon Invergo wrote: > The mission then is to put on some deep sea diving gear and wade into the > murky depths of xterm code s/deep sea diving/hazmat/
Re: [dev] [announce] rat - ridiculously abysmal tar
On 06/11/2012, Alex Hutton wrote: > Which languages qualify as suckless? Only Unicode-extended Lazy K. λ is for wimps.
Re: [dev] [announce] rat - ridiculously abysmal tar
On 07/11/2012, Joerg Zinke wrote: > Loglan is way to over-engineered and bloated. > toki pona to the rescue! "Training your mind to think in Toki Pona can lead to many deeper insights about yourself or the world around you." [1] Well, it can lead to many shallow insights about its creator. [1] http://en.tokipona.org/wiki/What_is_Toki_Pona%3F
Re: [dev] [announce] rat - ridiculously abysmal tar
On 07/11/2012, hiro <23h...@gmail.com> wrote: >> Which languages qualify as suckless? > > C, body language. Language
Re: [dev] I'm back
Jens Staal wrote: > I agree with this. As an example distribution, Sabotage does things pretty > well. One detail that I like a lot (but it sort of depends on your stance on > symlinks) is the way applications usually are placed in it: > Each application gets its own directory under /opt and then installed files > get symlinks in / (the file system hierarchy is stali-inspired with > everything in root and usr just pointing back to root). > > For me, this is a nicer solution than for example pacman to keep track on > which files that belong to which package (no fragile databases needed). One may use stacking bind mounts rather than symlinks. I know no decent such fs in Linux kernel space, as aufsn and unionfs seem cumbersome, but it ought to not be too difficult in user space, as 9p server. > What I have noticed lately is however how much of the broken stuff that are > expected to build also relatively fundamental technologies. For example, mesa > (which is needed if one ever wants to run wayland instead of X) expects > libudev to build, and if the version requirements will increase further that > will basically force systemd on peopole. Free software, captive society. > I am starting to think of this as the Fragile X syndrome, which usually refers > to a genetic disease causing mental retardation > (http://en.wikipedia.org/wiki/Fragile_X_syndrome ). > I am starting to feel that Linux is having a serious case of its digital > variant. Ha! Nice. Anselm Garbe wrote: > I'm back in the game ;) Welcome back! It's your move.
Re: [dev] I'm back
On 18/11/2012, Bjartur Thorlacius wrote: > GNU Stow also. Oh, yeah, that's what we need: more perl.
Re: [dev] [suckless] Migration to git
On 27/11/2012, Raphael Proust wrote: > darcs? > > (Yes, I know, it's not written in C. The interface is very clean > though. There is no branching, no history rewritting, no bells and > whistles.) It's not in C, but Haskell code can be easily compiled and distributed in binary form. Darcs has no history edition, as it essentially keeps no history, which is a win in my book. The main difficulty seems to be the corner-case exponential-time merge algorithm.
[dev] Starch has a web site
Hello all. Starch Linux has its own web site now: http://starchlinux.org so further announcements will be made there. As a reminder, the earlier thread: http://lists.suckless.org/dev/1210/13050.html Ports: https://github.com/StarchLinux/starch-ports Cheers, Strake
[dev] Re: Starch has a web site
Hugues Moretto-Viry wrote: > Dude, I can tell you I'm very interested about this project. > I will follow you. > Good work! Thanks! James Christopher Hogg wrote: > I am interested too. > If you'll avoid systemd, dbus and similar stuff, I'll think about > contribution. Like the plague. Prakhar Goel wrote: > Have you thought of using something like NIX? Yes. > The implementation sucks Horribly. > but the idea there: completely reproducible builds is incredible. Yes, and easy portable configuration. These are neat ideas, and could be done well, but that's another distro. Raphael Proust wrote: > Any plan to integrate an RSS feed? No. > (or similar?) Maybe a 9p feed. Prakhar Goel wrote: > Also, may I recommend s6 as the init system? It follows the suckless > philosophy: > mionimal, does exactly what is needed and is stable. Yes, thanks for the tip. I must further study the options. Cheers, Strake
[dev] Re: Starch has a web site
Julian Dammann wrote: > What's a 9p feed? that I serve my news directory over 9p (^_~) Truls Becken wrote: > Where should discussions take place? > The home page does not mention any community links. Well, we have none yet, but we have a few options: * Mailing list My preferred, but as the site is on someone else's server, and unfortunately I had to delegate them the whole domain, this may be difficult. * werc bridge Tried it; not sure how to configure it. I had the form but posting a comment failed. I may try further in future, but mind, I will be busy with exams for the next 11 days or so. > The installation guideline suggests using the Arch installer. That's fine, > but I'd just like to mention that I always found it fascinating how you can > install Arch by booting any Linux system you have at hand (an existing > installation or some live cd), download a static build of pacman, mount the > partition you want to install on, and simply run; ./pacman -S base -r /mnt Yes, true. I added a note to InstallationGuide. > All the best with this new distro. Thanks. Cheers, Strake
[dev] Re: Starch has a web site
On 07/12/2012, Hugues Moretto-Viry wrote: > A lightweight forum could be useful too. I agree. Ergo, I added one. http://starchlinux.org/Forum/
[dev] Re: Starch has a web site
On 07/12/2012, hiro <23h...@gmail.com> wrote: > it asked me if tux is cute and after I answered it isn't the web site > said I'm a robot. please just go on using mailing lists. forums (and > most other web shit) suck. Try now (^_~)
Re: [dev] Re: Starch has a web site
On 07/12/2012, hiro <23h...@gmail.com> wrote: > forums and the plural is "fora".
Re: [dev] Re: Starch has a web site
On 08/12/2012, lordkrandel wrote: > On 08/12/2012 05:30, Kai Hendry wrote: >> Stick to a mailing list with Web archives. > > I've always thought that forums, bbs and mailing lists are > "plain old hierarchical filesystems" gone astray. These tools represent > bad implementations of written communication between users. > > Imagine threads as folders, mails as files, subthreads as subfolders. > Users should be able to create their topics and posts, but not to modify > or delete anything. The mantainer can compress the topics with gz when > it's time to make an archive. > > If you do not care about their user base, and also do not care about > integration with mail clients, just share a folder over 9p, FTP, HTTP or > whatever. > > SMTP and POP suck hard. Well, web fora, yes, but a mailing list is actually a decent model of written communication between users. True about SMTP. I never use BBSs or POP so I can make no worthy comment. The forum could be a mere sticky directory, which would allow all normal forumnal activities. The difficulty is how to share it: the only user ID is the server's, so UID checks are in vain; even with 9p, which can authenticate a remote user, it must then set its UID, and I will not have such a server working as root! I could check UIDs in the server, but that means more code... A mailing list is easier to configure. In this case, I'm limited too by the host machine, which is not mine.
[dev] Starch has a mailing list
What it says. d...@lists.starchlinux.org http://lists.starchlinux.org/listinfo.cgi/dev-starchlinux.org Cheers, Strake
Re: [dev] Starch has a mailing list
On 08/12/2012, Hugues Moretto-Viry wrote: > Subscribed. > About installer, why not fork Arch-Install-Scripts? > https://github.com/falconindy/arch-install-scripts I may at some time, but my priority is a full self-hosted build.
Re: ls -s vs. du (was: Re: [dev] [st] font fallback)
On 06/01/2013, pancake wrote: > Didnt checked, but i guess that ls -s show size in bytes and du in block > bytes, which depends on filesystem. Nope. Both show size in blocks [1]. It seems proper to do so in ls alone, with a flag of whether to add sizes of all files below; thus we could drop du. One may argue that the job of ls is not to add sizes, but now we have 2 utilities what list files, which loses. [1] http://www.openbsd.org/cgi-bin/man.cgi?query=(ls, du)
Re: ls -s vs. du (was: Re: [dev] [st] font fallback)
On 07/01/2013, Raphael Proust wrote: > Real difference is du handles hard links (i.e. shows actual disk usage > (as one would expect) by counting hard-linked files only once) while > ls list files (as one would expect) (and optionally gives some > information about them). Which wins. Ah, yes, I missed this. Unix wins again. Plan 9 ls has no R flag, which makes sense if truly ls's job is to list directories and du's job is to delve deep, tho Unix 8th ls has the flag. On another note, I find it sadly amusing how "an unbelievable number of options" [1] is fewer than most have today. [1] http://man.cat-v.org/unix_8th/1/ls
Re: [dev] [st] Shift+F1 should by F11?
On 10/01/2013, Mihail Zenkov wrote: >> I have also tested in the virtual terminal of the kenel (you called it >> 'pure console') and I get the values you said: >> >> >> Shift-F1 = ^[[25~ >> F11 = ^[[23~ > > I check again - in my system I have ^[[23~ for Shift+F1 and F11. Can > some one else also check this? I get the same as k0ga: F11 = ^[[23~ Shift-F1 = ^[[25~ Linux 3.4.6-1-ARCH This makes sense if indeed Shift-F1 = F13.
Re: [dev] Suckless generic diagram creation software?
On 06/02/2013, Peter Hartman wrote: > 2013/2/6 Manolo Martínez : >> On 02/06/13 at 03:29pm, Peter Hartman wrote: >>> LaTeX >>> >> I use and love LaTeX, but LaTeX is *not* lightweight. > > Depends on the measure, but it is lighter both in terms of its source, > memory footprint, and deps than any app based on gtk. That is a poor measure.
Re: [dev] Suckless and Wayland
On 13/02/2013, Hugues Moretto-Viry wrote: > I already started a similar topic some months ago where I asked you your > opinion. > Now, the project seems to move fast, this is why I start another > subject. > The aim is different now, and I want to have some details from Suckless > community / developpers about the upcoming technology. > > After reading many Wayland articles, I think it will completely change > Linux ecosystem and I'm a bit worried. Well, what is its natural predator? > Wayland introduces fuzzy aspects and they're not very clear for me (POSIX > compliant, KMS and network transparency). > > Since I like many softwares like dwm & st, I wonder how I'll do when Wayland > will become the norm (as systemd). > I really hope you consider porting your essentials softwares on Wayland, I really hope we don't. > because major distribs like Fedora or Ubuntu plan to use it. They can use clay tablets for all I care. > I think it's a dilemma: using your work on non-Wayland distribs or dropping > my favorites softwares for Wayland... No dilemma here. > Here my concerns (I'm not the only one, I guess). The only one in this thread so far.
[dev] [announce] linuxutils
rather than util-linux, which is crap. https://github.com/strake/linuxutils Very incomplete yet, just mount, umount, mountpoint, setsid, and pivot_root, but ultimately I hope to have a full tool set. Cheers, Strake
Re: [dev] [announce] linuxutils
On 02/03/2013, Chris Down wrote: > I like the idea. mountpoint.sh could be improved. Do you prefer > patches as a GitHub pull request or by git format-patch? The former, tho either is cool. Cheers, Strake
Re: [dev] web browsers
On 10/03/2013, hiro <23h...@gmail.com> wrote: > are there any other new usable browsers lately? other ideas, > recommendations? Netsurf, maybe? It's written in pure C, at least. http://netsurf-browser.org Cheers, Strake
Re: [dev] Re: [slcon] Call for Papers 2013
On 21/03/2013, Christian Neukirchen wrote: > I would like to give a talk called "runit & ignite - a suckless init > system?", but I'm asking whether there is interest first since I noticed > these projects in the suckless context yet. > > runit is a reliable init system based on service supervision, and ignite > is a set of shell scripts to convert the init system of a well-known > Linux distribution starting with "A" to use runit. (No worries, the > concepts are generic enough to be applied on every Linux or *BSD > system.) > > I think a 30min talk would be enough to present it, and I'd like to have > enough time for discussion later since this is a topic that is getting > increasingly relevant given the current introduction of systemd > everywhere. It's also interesting for the sta.li plans, I think. I won't be there but I would be very interested. initscripts are weak.
Re: [dev] Re: [slcon] Call for Papers 2013
On 23/03/2013, hiro <23h...@gmail.com> wrote: >> initscripts are weak. > > what do you need them to do? what does weak really mean here? Sorry, my comment was indeed vague. I meant the Arch initscripts, tho this may well be true of many: * won't automatically re-start service that dies; network services in particular, e.g. tunnels, may fail due to transient network phenomena * can't automatically start services what another service needs * can't easily start non-root user services
Re: [dev] Re: [slcon] Call for Papers 2013
On 25/03/2013, hiro <23h...@gmail.com> wrote: > That's all fixable without creating huge systems or frameworks. I agree. I never said that I want a huge system or framework. > I think you're just confused from what ubuntu made you think is useful. I think you're just confused about whether you're talking to a now or former Ubuntu user. > I have no need for any of this shit to be done automagically. Acknowledged.
Re: [dev] Re: [slcon] Call for Papers 2013
On 25/03/2013, hiro <23h...@gmail.com> wrote: > So then weak is rather sufficient. Sorry, it sounded like this up > there was your wishlist. It was. > Now it got to be a good example of what I really don't need in my init > scripts :) Glad to help.
Re: [dev] [st] New feature idea
On 29/03/2013, Calvin Morrison wrote: > See opening images is not the same as having images on your buffer, namely > for the reason > of being able to look back in your buffer and see the images that have been > opened > > say I wanted all my photos in my collection from 2012, 3rd month, for > me this is now trivial, plus > I can easily scroll up and down my buffer to look at them. but st has no scrollback buffer.
Re: [dev] [st] st 0.4 slow startup
On 06/04/2013, Igor Šarić wrote: > Pardon my ignorance, but how do I find commit 9c44229c? All the commits on > git webpage have longer (sha1?) hashes. That string should be a prefix of the hash.
Re: [dev] [st] windows port?
On 11/04/2013, Max DeLiso wrote: > I completely agree that Windows is a legacy OS, but plenty of people are > still forced to use it for many legitimate reasons. Forced? How? At knifepoint?
Re: [dev] [st] windows port?
On 12/04/2013, Max DeLiso wrote: > I really only still run windows because I play > some games which only run on windows. Wine?
Re: [dev] web benchmark
On 14/04/2013, Christoph Lohmann <2...@r-36.net> wrote: > The benchmark consists of running every website on a RPi Model B in > surf, count how long it takes to load the website and compare the value > of reaction time and loading time to a reference website. If the website > is unusable (reaction time > 0.1s) automatically send a bomb threat to > postmaster@website. Why loading time? Latency may well be due to the network between, not their server. Measuring the web's sanity with WebKit; the irony... > All of this might result in websites offering a stripped down website > (not just for mobile or tablets) for embedded devices or us just being > ignored. ... or thrown in jail.
Re: [dev] [st] wide characters
On 15/04/2013, random...@fastmail.us wrote:
> On Mon, Apr 15, 2013, at 10:58, Martti Kühne wrote:
>> According to a quick google those chars can become as wide as 6
>> bytes,
>
> No, they can't. I have no idea what your source on this is.
In UTF-8 the maximum encoded character length is 6 bytes [1]
[1] Linux docs: man 7 utf-8
This is more than a four-byte integer ('‿')
Re: [dev] [surf] add 3-finger back and forward control
On 21/04/2013, Christoph Lohmann <2...@r-36.net> wrote: > Btw. »3 fingers« is really racist to people only having two or just one > finger. Which race has n fingers | n < 3?
Re: [dev] [surf] add 3-finger back and forward control
On 21/04/2013, Uli Armbruster wrote: > * Strake [21.04.2013 18:37]: >> Which race has n fingers | n < 3? > > Seriously?!?!?! No.
[dev] [st][patch] SWAP macro
>From d3455f61a5caaf5d94e2b6c1056fb03713772029 Mon Sep 17 00:00:00 2001
From: Strake
Date: Tue, 30 Apr 2013 23:53:04 -0500
Subject: [PATCH] swap
---
st.c | 38 ++
1 file changed, 10 insertions(+), 28 deletions(-)
diff --git a/st.c b/st.c
index 5251e70..8cf3483 100644
--- a/st.c
+++ b/st.c
@@ -72,6 +72,7 @@ char *argv0;
#define DEFAULT(a, b) (a) = (a) ? (a) : (b)
#define BETWEEN(x, a, b) ((a) <= (x) && (x) <= (b))
#define LIMIT(x, a, b)(x) = (x) < (a) ? (a) : (x) > (b) ? (b) : (x)
+#define SWAP(t, x, y) { t __SWAP_TEMPORARY; __SWAP_TEMPORARY =
(x); (x) = (y); (y) = __SWAP_TEMPORARY; }
#define ATTRCMP(a, b) ((a).mode != (b).mode || (a).fg != (b).fg ||
(a).bg != (b).bg)
#define IS_SET(flag) ((term.mode & (flag)) != 0)
#define TIMEDIFF(t1, t2) ((t1.tv_sec-t2.tv_sec)*1000 +
(t1.tv_usec-t2.tv_usec)/1000)
@@ -1358,10 +1359,7 @@ tnew(int col, int row) {
void
tswapscreen(void) {
- Line *tmp = term.line;
-
- term.line = term.alt;
- term.alt = tmp;
+ SWAP(Line *, term.line, term.alt);
term.mode ^= MODE_ALTSCREEN;
tfulldirt();
}
@@ -1369,16 +1367,13 @@ tswapscreen(void) {
void
tscrolldown(int orig, int n) {
int i;
- Line temp;
LIMIT(n, 0, term.bot-orig+1);
tclearregion(0, term.bot-n+1, term.col-1, term.bot);
for(i = term.bot; i >= orig+n; i--) {
- temp = term.line[i];
- term.line[i] = term.line[i-n];
- term.line[i-n] = temp;
+ SWAP(Line, term.line[i], term.line[i-n]);
term.dirty[i] = 1;
term.dirty[i-n] = 1;
@@ -1390,15 +1385,12 @@ tscrolldown(int orig, int n) {
void
tscrollup(int orig, int n) {
int i;
- Line temp;
LIMIT(n, 0, term.bot-orig+1);
tclearregion(0, orig, term.col-1, orig+n-1);
for(i = orig; i <= term.bot-n; i++) {
-temp = term.line[i];
-term.line[i] = term.line[i+n];
-term.line[i+n] = temp;
+SWAP(Line, term.line[i], term.line[i+n]);
term.dirty[i] = 1;
term.dirty[i+n] = 1;
@@ -1531,12 +1523,12 @@ tsetchar(char *c, Glyph *attr, int x, int y) {
void
tclearregion(int x1, int y1, int x2, int y2) {
- int x, y, temp;
+ int x, y;
if(x1 > x2)
- temp = x1, x1 = x2, x2 = temp;
+ SWAP(int, x1, x2);
if(y1 > y2)
- temp = y1, y1 = y2, y2 = temp;
+ SWAP(int, y1, y2);
LIMIT(x1, 0, term.col-1);
LIMIT(x2, 0, term.col-1);
@@ -1711,15 +1703,9 @@ tsetattr(int *attr, int l) {
void
tsetscroll(int t, int b) {
- int temp;
-
LIMIT(t, 0, term.row-1);
LIMIT(b, 0, term.row-1);
- if(t > b) {
- temp = t;
- t = b;
- b = temp;
- }
+ if(t > b) SWAP(int, b, t);
term.top = t;
term.bot = b;
}
@@ -2886,7 +2872,7 @@ xdraws(char *s, Glyph base, int x, int y, int
charlen, int bytelen) {
FcPattern *fcpattern, *fontpattern;
FcFontSet *fcsets[] = { NULL };
FcCharSet *fccharset;
- Colour *fg, *bg, *temp, revfg, revbg;
+ Colour *fg, *bg, revfg, revbg;
XRenderColor colfg, colbg;
Rectangle r;
@@ -2954,11 +2940,7 @@ xdraws(char *s, Glyph base, int x, int y, int
charlen, int bytelen) {
}
}
- if(base.mode & ATTR_REVERSE) {
- temp = fg;
- fg = bg;
- bg = temp;
- }
+ if(base.mode & ATTR_REVERSE) SWAP(Colour *, fg, bg);
if(base.mode & ATTR_BLINK && term.mode & MODE_BLINK)
fg = bg;
--
1.7.11.1
[dev] [st][patch] not roll our own utf functions
>From c40205fe15f0da048128f8735fd2140605de5e9e Mon Sep 17 00:00:00 2001
From: Strake
Date: Sun, 5 May 2013 09:35:58 -0500
Subject: [PATCH] not roll our own utf functions
---
README| 2 +-
config.mk | 2 +-
st.c | 129 +-
3 files changed, 11 insertions(+), 122 deletions(-)
diff --git a/README b/README
index 25606a2..2bbb859 100644
--- a/README
+++ b/README
@@ -5,7 +5,7 @@ st is a simple virtual terminal emulator for X which sucks less.
Requirements
-In order to build st you need the Xlib header files.
+In order to build st you need libutf and the Xlib header files.
Installation
diff --git a/config.mk b/config.mk
index 9431de2..36a0424 100644
--- a/config.mk
+++ b/config.mk
@@ -14,7 +14,7 @@ X11LIB = /usr/X11R6/lib
INCS = -I. -I/usr/include -I${X11INC} \
`pkg-config --cflags fontconfig` \
`pkg-config --cflags freetype2`
-LIBS = -L/usr/lib -lc -L${X11LIB} -lX11 -lutil -lXext -lXft \
+LIBS = -L/usr/lib -lc -lutf -L${X11LIB} -lX11 -lutil -lXext -lXft \
`pkg-config --libs fontconfig` \
`pkg-config --libs freetype2`
diff --git a/st.c b/st.c
index 8cf3483..da0b6b7 100644
--- a/st.c
+++ b/st.c
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -394,10 +395,7 @@ static void selcopy(void);
static void selscroll(int, int);
static void selsnap(int, int *, int *, int);
-static int utf8decode(char *, long *);
-static int utf8encode(long *, char *);
static int utf8size(char *);
-static int isfullutf8(char *, int);
static ssize_t xwrite(int, char *, size_t);
static void *xmalloc(size_t);
@@ -506,115 +504,6 @@ xcalloc(size_t nmemb, size_t size) {
}
int
-utf8decode(char *s, long *u) {
- uchar c;
- int i, n, rtn;
-
- rtn = 1;
- c = *s;
- if(~c & B7) { /* 0xxx */
- *u = c;
- return rtn;
- } else if((c & (B7|B6|B5)) == (B7|B6)) { /* 110x */
- *u = c&(B4|B3|B2|B1|B0);
- n = 1;
- } else if((c & (B7|B6|B5|B4)) == (B7|B6|B5)) { /* 1110 */
- *u = c&(B3|B2|B1|B0);
- n = 2;
- } else if((c & (B7|B6|B5|B4|B3)) == (B7|B6|B5|B4)) { /* 0xxx */
- *u = c & (B2|B1|B0);
- n = 3;
- } else {
- goto invalid;
- }
-
- for(i = n, ++s; i > 0; --i, ++rtn, ++s) {
- c = *s;
- if((c & (B7|B6)) != B7) /* 10xx */
- goto invalid;
- *u <<= 6;
- *u |= c & (B5|B4|B3|B2|B1|B0);
- }
-
- if((n == 1 && *u < 0x80) ||
- (n == 2 && *u < 0x800) ||
- (n == 3 && *u < 0x1) ||
- (*u >= 0xD800 && *u <= 0xDFFF)) {
- goto invalid;
- }
-
- return rtn;
-invalid:
- *u = 0xFFFD;
-
- return rtn;
-}
-
-int
-utf8encode(long *u, char *s) {
- uchar *sp;
- ulong uc;
- int i, n;
-
- sp = (uchar *)s;
- uc = *u;
- if(uc < 0x80) {
- *sp = uc; /* 0xxx */
- return 1;
- } else if(*u < 0x800) {
- *sp = (uc >> 6) | (B7|B6); /* 110x */
- n = 1;
- } else if(uc < 0x1) {
- *sp = (uc >> 12) | (B7|B6|B5); /* 1110 */
- n = 2;
- } else if(uc <= 0x10) {
- *sp = (uc >> 18) | (B7|B6|B5|B4); /* 0xxx */
- n = 3;
- } else {
- goto invalid;
- }
-
- for(i=n,++sp; i>0; --i,++sp)
- *sp = ((uc >> 6*(i-1)) & (B5|B4|B3|B2|B1|B0)) | B7; /* 10xx
*/
-
- return n+1;
-invalid:
- /* U+FFFD */
- *s++ = '\xEF';
- *s++ = '\xBF';
- *s = '\xBD';
-
- return 3;
-}
-
-/* use this if your buffer is less than UTF_SIZ, it returns 1 if you can decode
- UTF-8 otherwise return 0 */
-int
-isfullutf8(char *s, int b) {
- uchar *c1, *c2, *c3;
-
- c1 = (uchar *)s;
- c2 = (uchar *)++s;
- c3 = (uchar *)++s;
- if(b < 1) {
- return 0;
- } else if((*c1&(B7|B6|B5)) == (B7|B6) && b == 1) {
- return 0;
- } else if((*c1&(B7|B6|B5|B4)) == (B7|B6|B5) &&
- ((b == 1) ||
- ((b == 2) && (*c2&(B7|B6)) == B7))) {
- return 0;
- } else if((*c1&(B7|B6|B5|B4|B3)) == (B7|B6|B5|B4) &&
- ((b == 1) ||
- ((b == 2) && (*c2&(B7|B6)) == B7) ||
- ((b == 3) && (*c2&(B7|B6)) == B7 && (*c3&(B7|B6)) == B7))) {
- return 0;
- } else {
- return 1;
- }
-}
-
-int
utf8size(char *s) {
uchar c = *s;
@@ -1230,7
Re: [dev] [st][patch] not roll our own utf functions
On 05/05/2013, Christoph Lohmann <2...@r-36.net> wrote: > Greetings. > > On Sun, 05 May 2013 16:49:06 +0200 Strake wrote: >> From c40205fe15f0da048128f8735fd2140605de5e9e Mon Sep 17 00:00:00 2001 >> From: Strake >> Date: Sun, 5 May 2013 09:35:58 -0500 >> Subject: [PATCH] not roll our own utf functions > > Rejected due to dependency hell. It ain't even dependency heck, but meh.
Re: [dev] [st] minor fix
On 06/05/2013, Johannes Hofmann wrote:
> Hi,
>
> there is a small glitch in the error handling of the select() call
> in st.c. See patch below.
>
> Regards,
> Johannes
>
> diff --git a/st.c b/st.c
> index 5251e70..689de26 100644
> --- a/st.c
> +++ b/st.c
> @@ -3481,7 +3481,7 @@ run(void) {
> FD_SET(cmdfd, &rfd);
> FD_SET(xfd, &rfd);
>
> - switch(select(MAX(xfd, cmdfd)+1, &rfd, NULL, NULL, tv) < 0) {
> + switch(select(MAX(xfd, cmdfd)+1, &rfd, NULL, NULL, tv)) {
> case -1:
> if(errno == EINTR)
> continue;
>
Why are we even using switch here?
>From 8cf77d2d081702c7e0db2bb8724732ca0fa85410 Mon Sep 17 00:00:00 2001
From: Strake
Date: Mon, 6 May 2013 06:29:21 -0500
Subject: [PATCH] (if rather than switch) select ...
---
st.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/st.c b/st.c
index bd157af..1191969 100644
--- a/st.c
+++ b/st.c
@@ -3347,12 +3347,12 @@ run(void) {
FD_SET(cmdfd, &rfd);
FD_SET(xfd, &rfd);
- switch(select(MAX(xfd, cmdfd)+1, &rfd, NULL, NULL, tv) < 0) {
- case -1:
+ if(select(MAX(xfd, cmdfd)+1, &rfd, NULL, NULL, tv) < 0) {
if(errno == EINTR)
continue;
die("select failed: %s\n", SERRNO);
- default:
+ }
+ else {
if(FD_ISSET(cmdfd, &rfd)) {
ttyread();
if(blinktimeout) {
@@ -3364,7 +3364,6 @@ run(void) {
if(FD_ISSET(xfd, &rfd))
xev = actionfps;
- break;
}
gettimeofday(&now, NULL);
drawtimeout.tv_sec = 0;
--
1.7.11.1
Re: [dev] Re: Why HTTP is so bad?
On 24/05/2013, Nick wrote: > On Fri, May 24, 2013 at 02:02:42PM +0200, Dmitrij Czarkoff wrote: > Yes. Some site map or apache index style thing that was wholely > standard and couldn't be "styled" would be very useful. Over 9p, this would be the directory structure, so it would come for free.
Re: [dev] Re: Why HTTP is so bad?
On 24/05/2013, Bjartur Thorlacius wrote: > On 05/24/2013 02:11 PM, Christian Neukirchen wrote: >> Types can't be declared properly in Unix. > In Unix, filetype are defined on a per file basis. Yes — file type, not data type. > Delimeters in IPC text streams are defined using $IFS. > Rc is hailed exclusively because it makes less use if $IFS. Well, that and > the Plan 9 label. It has saner syntax, too.
Re: [dev] Re: Why HTTP is so bad?
On 24/05/2013, Dmitrij Czarkoff wrote: > There is mime, which can be combined with mailcap in a useful way. Yes. A web browser ought to have a component to fetch documents and start the appropriate viewer, as in mailcap. The whole monolithic web browser model is flawed.
Re: [dev] Re: Why HTTP is so bad?
On 24/05/2013, random...@fastmail.us wrote: > On Fri, May 24, 2013, at 16:02, Strake wrote: >> Yes. A web browser ought to have a component to fetch documents and >> start the appropriate viewer, as in mailcap. The whole monolithic web >> browser model is flawed. > > And you spend a day on wikipedia or tvtropes and you've got two hundred > HTML viewers open? Yes. > You need _something_ monolithic to manage a linear (or, rather, > branching only when you choose to, via open new window or new tab) > browsing history, even if content viewers aren't part of it. When you > click a link within "the appropriate viewer", it needs to be _replaced_ > with the viewer for the content at the link you clicked on. The viewer sends a "go" message back to the fetcher, which kills the old viewer and loads the new one, and can keep a URL log.
Re: [dev] Re: Why HTTP is so bad?
On 24/05/2013, Random832 wrote: > On 05/24/2013 07:13 PM, Strake wrote: >>> And you spend a day on wikipedia or tvtropes and you've got two hundred >>> HTML viewers open? >> Yes. > > I meant as opposed to the usual dozen. >> The viewer sends a "go" message back to the fetcher, which kills the >> old viewer and loads the new one, and can keep a URL log. >> > So the fetcher (which presumably also has UI elements such as an address > bar, back/forward button, etc) Such functions, yes. > is the monolithic browser I described. If that's what you meant, yes. I just meant the fetcher-viewer integration. > How exactly is this different from the current model? That the two > components communicate via IPC rather than an in-process API? Yes. Thus I can easily swap out any component, or insert mediators between components. For example, I could write my own fetcher to scrub the HTTP headers, or block ads; and I wouldn't need plug-ins to view PDFs or watch movies.
Re: [dev] Is there any plan on a shell for sbase?
On 31/05/2013, Fernando C.V. wrote: > Would it make sense to create a whole shell infrastructure based on > little small commands? > > I mean, not just replacing no-brainer builtin things like "echo", etc, > but also things like "if", "while", "for", "set", by doing system() > calls to an extremelly minimal shell. Would it make sense? maybe even > a command for creating pipes. I tried this lately. Actually, I tried no shell at all. The basic idea was this: a program is a list of arguments. Each utility parses the first few arguments and spawns the rest by its operational scheme, like chroot and setsid. This was the dawn of grief, for many utilities, for example if, must take many argument lists. I first tried '--' as list separator, but thus I had to quote '--'s in the argument list, which I did with another '-'; as I soon learned, this is very cumbersome. I mean to try again, this time with s-expressions, which, as they are balanced, need no quotation. Cheers, Strake
Re: [dev] [st] Enter unicode symbol
On 12/06/2013, Thuban wrote: > Hello, > stupid question : how can you enter an unicode character in st? > In vim, you do it with ctrl-u+ (where is the code) > In some terminal, you do this with ctrl-shift-u+ Define a compose key.
Re: [dev] Re: Maintaining sbase
On 25/06/2013, Martti Kühne wrote: > On Tue, Jun 25, 2013 at 4:58 PM, Calvin Morrison > wrote: >> my votes are for at a minimum are for: >> >> sponge >> tee >> pee > > And a cloth to clean up the mess... No, that's what sponge is for.
[dev] [swerc][PATCH] bin/handlers: roll up repeated code; factorize out suffixes
>From 309ffdb318e67014b8565335cc1d95e4ff5d506c Mon Sep 17 00:00:00 2001
From: Strake
Date: Wed, 3 Jul 2013 07:26:16 -0500
Subject: [PATCH 1/2] bin/handlers: roll up repeated code
---
bin/handlers.rc | 21 +
1 file changed, 9 insertions(+), 12 deletions(-)
diff --git a/bin/handlers.rc b/bin/handlers.rc
index cca6495..2055ed4 100644
--- a/bin/handlers.rc
+++ b/bin/handlers.rc
@@ -54,6 +54,10 @@ fn man_handler {
echo ''
}
+fn 1_handler {
+man_handler $*
+}
+
fn dir_listing_handler {
d=`{basename -d $1}
if(~ $#d 0)
@@ -65,19 +69,12 @@ fn dir_listing_handler {
}
fn setup_handlers {
-if(test -f $local_path.md) {
-local_file=$local_path.md
-handler_body_main=(md_handler $local_file)
-}
-if not if(test -f $local_path.1) {
-local_file=$local_path.1
-handler_body_main=(man_handler $local_file)
-}
-if not if(test -f $local_path.tpl) {
-local_file=$local_path.tpl
-handler_body_main=(tpl_handler $local_file)
+local_file=()
+for(suffix in md 1 tpl) if(test -f $local_path.$suffix) {
+local_file=$local_path.$suffix
+handler_body_main=($suffix^_handler $local_file)
}
-if not if(test -f tpl^$req_path^.tpl)
+if(~ $#local_file 0 && test -f tpl^$req_path^.tpl)
handler_body_main=(tpl_handler tpl^$req_path^.tpl)
if(! ~ $#handler_body_main 0)
{ } # We are done
--
1.7.11.1
>From de7dfb66068fe2feddcb7d30e95db24712bfe176 Mon Sep 17 00:00:00 2001
From: Strake
Date: Sun, 18 May 2003 15:11:04 -0500
Subject: [PATCH 2/2] factorize out suffixes
---
bin/handlers.rc | 8 ++--
bin/werc.rc | 4 ++--
2 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/bin/handlers.rc b/bin/handlers.rc
index 2055ed4..b68cff6 100644
--- a/bin/handlers.rc
+++ b/bin/handlers.rc
@@ -1,5 +1,9 @@
# Werc builtin handlers
+suffixes=(md 1 tpl)
+
+suffix_alternation='('^`{echo $"suffixes | tr ' ' '|'}^')'
+
fn nav_tree {
echo ''
if(! ~ $#menuTitle 0) {
@@ -12,7 +16,7 @@ fn nav_tree {
# /./ to deal with p9p's ls failure to follow dir symlinks otherwise
ls -F $sitedir/./$req_paths_list >[2]/dev/null \
| {
-sed $dirfilter'/\/[^_.\/][^\/]*(\.(md|1)|\/)$/!d;
s!^'$sitedir'!!; '$dirclean
+sed
$dirfilter'/\/[^_.\/][^\/]*(\.'^$suffix_alternation^'|\/)$/!d;
s!^'$sitedir'!!; '$dirclean
if(! ~ $#synth_paths 0) echo $synth_paths | tr ' ' $NEW_LINE
} | sort -u | awk -F/ '
function p(x, y, s) { for(i=0; i < x-y; i+=1) print s }
@@ -70,7 +74,7 @@ fn dir_listing_handler {
fn setup_handlers {
local_file=()
-for(suffix in md 1 tpl) if(test -f $local_path.$suffix) {
+for(suffix in $suffixes) if(test -f $local_path.$suffix) {
local_file=$local_path.$suffix
handler_body_main=($suffix^_handler $local_file)
}
diff --git a/bin/werc.rc b/bin/werc.rc
index 01f4714..dd77207 100755
--- a/bin/werc.rc
+++ b/bin/werc.rc
@@ -9,8 +9,8 @@ difs=$ifs # Used to restore default ifs when needed
# Expected input: ls -F style, $sitedir/path/to/files/
#
-dirfilter='s/\*$//; s,/+\./+,/,g; s,^\./,,; /\/[._][^\/]/d;
/'$forbidden_uri_chars'/d; /\/sitemap\.xml$/d; /\/index\.(md|tpl)$/d;
/\/(robots|sitemap)\.txt$/d; /_werc\/?$/d; '
-dirclean=' s/\.(md|1)$//; '
+dirfilter='s/\*$//; s,/+\./+,/,g; s,^\./,,; /\/[._][^\/]/d;
/'$forbidden_uri_chars'/d; /\/sitemap\.xml$/d;
/\/index(\.'^$suffix_alternation^')+$/d; /\/(robots|sitemap)\.txt$/d;
/_werc\/?$/d; '
+dirclean=' s/\.'^$suffix_alternation^'$//; '
# Careful, the proper p9p path might not be set until initrc.local is sourced
path=(. $PLAN9/bin ./bin /bin /usr/bin)
--
1.7.11.1
[dev] Re: [swerc][PATCH] bin/handlers: roll up repeated code; factorize out suffixes
On 03/07/2013, Strake wrote: > ... Sorry, I thought that I tested both, but actually only tested the first. Second needs work yet.
