Tested now.
>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(-)
d
On 06/07/2013, Galos, David wrote:
> The attached patch shows my current work on adapting sltar
> to sbase. It is functional, but, there are still open questions
> regarding tar. The big deal is the argument parsing: I would
> like to use the ARG macros in tar, but I'm not sure how that
> fits wi
On 04/07/2013, sin wrote:
> On Thu, Jul 04, 2013 at 12:34:14PM +, Robert Ransom wrote:
>> sha1sum.c is very similar to md5sum.c; ideally, more of the common
>> code between those programs would be in a library routine.
>
> Yeah they are very similar, however, the code is very simple and
> ther
;;
esac
done
shift $(dc -e "$OPTIND 1 - p");
for x in "$@"; do sed ${n}q <"$x"; done
# END
pwd:
#!/bin/sh
echo "$PWD"
#END
Why are these in C?
head.sh now needs dc, but could easily rather use intc [1], which we
could include in sbase.
[1] https://github.com/strake/intc
On 07/07/2013, Markus Teich wrote:
>> Why are these in C?
>
> Because shell scripts tend to run many processes compared to only one
> if you don't fork in the C code?
Is this a matter of efficiency alone?
On 17/07/2013, Calvin Morrison wrote:
> I came up with a utility[0] that i think could be useful, and I sent
> it to the moreutils page, but maybe it might fit better here. All it
> does is give a count of files in a directory.
$ ls | wc -l
> I was sick of ls | wc -l being so damned slow on larg
On 22/07/2013, Charlie Paul wrote:
> But now we are looking at an even more obscure situation.
Yep, in practice, we'll never have newlines in filenames. And the
Titanic will never sink.
The answer here is to use null rather than newline as a separator.
Alas, The Standard says otherwise.
I posted about Starch earlier [1]; to remind, it's static-linked
Arch-based Linux distro built against musl. The basic system now works
with a few small glitches. So far, packages for x86_64 are available.
http://starchlinux.org/
[1] http://lists.suckless.org/dev/1210/13050.html
On 05/10/2013, Thorsten Glaser wrote:
> Strake dixit:
>
>>http://starchlinux.org/
>
> “HTTP/1.1 200 Schön”?!
What, is this improper usage?
> One rather important thing: starchlinux.org has got an RR
> but the httpd does not listen on IP, only on Legacy IP. Pl
On 05/10/2013, Thorsten Glaser wrote:
>>Yes, sorry, I missed that it bound to IPv4 alone by default. Should
>>work now. Thanks.
>
> Nope – maybe it’s firewalled (looks like pf block drop)?
>
> tg@blau:~ $ nc -v6 starchlinux.org 80
> nc: connect to starchlinux.org port 80 (tcp) failed: Operation ti
On 10/10/2013, Silvan Jegen wrote:
> A day before Christmas Eve, no less.
and the Linux kernel cares what day it is?
On 10/10/2013, FRIGN wrote:
> On Thu, 10 Oct 2013 08:31:03 -0500
> Strake wrote:
>
>> On 10/10/2013, Silvan Jegen wrote:
>> > A day before Christmas Eve, no less.
>>
>> and the Linux kernel cares what day it is?
>>
>
> Yep[1].
>
> [1]: <
On 16/10/2013, Jochen Sprickerhof wrote:
> I've implemented a (limited) scrollback buffer for st. Thanks to v4hn
> for testing and improving first versions.
Thanks! This was the last reason against my st adoption.
On 16/10/2013, Christoph Lohmann <2...@r-36.net> wrote:
> You can add it as a pat
I am trying to use st, but it fails with the message "XOpenIM failed.
Could not open input device."
I checked the XOpenIM man page, which said that it opens an input
method, so I checked the man page, the X11 header files, the Arch
Linux package repos, and Google hits for "XIM", "X Input Method",
cken wrote:
> On 2013-10-18, at 12:29, sin wrote:
>
>> find: Useless, just do `du -a | grep blabla'
>
> I'm not interested in disk usage, but finding files based on certain
> properties, such as update time, ownership, permissions, etc.
du -a | cut -f 2
Cheers,
Strake
On 17/10/2013, Strake wrote:
> I am trying to use st, but it fails with the message "XOpenIM failed.
> Could not open input device."
>
> ...
Never mind; I wrote my own lookupString function. It's not
particularly good, lacking ability beyond ASCII, but I'll post it if
someone asks.
On 18/10/2013, Szymon Olewniczak wrote:
> I believe that we can make the web the better place without huge revolutino
s/HTML/XML+XSLT/g is quite a revolution.
> (such as changing HTTP to something else)
Which is this about, HTTP or HTML?
> Pages writen in XML has readable source
So have pages
"Asshole vs. reality" would be an appropriate subtitle for "suckless:
the movie".
Alas, the list smells ever of phosphorus and kerosene, as some would
rather flame than argue rationally. But slamming someone for an actual
fault, for example a bottom post, is no flame.
On 12/11/2013, Martti Kühne wrote:
> On Thu, Nov 7, 2013 at 3:54 PM, Strake wrote:
> ...
>> for an actual fault, for example a bottom post, is no flame.
>>
>
> Logical fallacies that are obvious are an edge case, I guess... It's
> top posting we don't like.
Sorry, yes, I meant top post.
On 26/11/2013, Silvan Jegen wrote:
> If you you would rather not take this version, what approach would
> you take for the character set mapping when using UTF-8?
On Linux, one can easily make a sparse array with 1-page granularity
with mmap, and so simply use a (wchar_t []) or (Rune []), but I'm
On 28/11/2013, Silvan Jegen wrote:
> If I understand correctly you would use mmap to allocate a sparse
> memory area into which we could then directly index
Yes.
> (either using UTF-8 or UTF-32 indices), right?
I meant Unicodepoints; those are just Unicodecs.
> Since mmap needs a file descript
On 28/11/2013, Silvan Jegen wrote:
> On Thu, Nov 28, 2013 at 11:45:33AM -0500, Strake wrote:
>> > (either using UTF-8 or UTF-32 indices), right?
>>
>> I meant Unicodepoints; those are just Unicodecs.
>
> UTF-32 is an encoding that is identical to the unicode point as
On 12/12/2013, Strake wrote:
> Rich Felker, author of musl, wrote an init too, but I can't find it now.
Sorry, that ought to be "primary author".
On 12/12/2013, YpN wrote:
> Do you think I could add a section about init? I know ignite and busybox
> init, it might be interesting.
Rich Felker, author of musl, wrote an init too, but I can't find it now.
Here is mine, much alike: https://github.com/strake/init/blob/master/init.c
On 12/12/2013, Neo Romantique wrote:
> C is generally more and efficient, I suppose.
I assume you mean "more efficient".
It may be more for the machine but it's less for the programmer.
We build machines to do tedious work so we needn't.
On 12/12/2013, Troels Henriksen wrote:
> No, that was year 100. 2014 is the year of MMXIV.
Anyhow, this is actually the year 44.
On 13/12/2013, Paul Onyschuk wrote:
> [Markdown] is still non-strict,
I missed this. Where is evaluation order specified?
> Sed, awk, grep and other standard tools work great with sane roff
> document: you can stick to the oneliners (I don't think that this can
> be said about any other document
On 13/12/2013, Nick wrote:
> On a related note, for those who like him, Eben Moglen just did an
> excellent series of talks
It's not the FSF's doctrine that loses; it's GNU's shitty code.
> Browsing the web nowadays feels like having engineers
> and advertisers constantly shouting "fuck you" at
On 20/12/2013, Sylvain BERTRAND wrote:
> That's very bad. Linux kernel devs have not accepted patches to
> allow compilation with alternative C compilers??
Well, Linus is no gcc fan [1], so they might, if a ready alternative
were available.
[1] https://lkml.org/lkml/2006/11/28/206
On 20/12/2013, Rob wrote:
> https://github.com/bobrippling/ucc-c-compiler
Why are you rewriting libc?
On 24/12/2013, Silvan Jegen wrote:
> So I guess the question boils down to whether you would rather use
> libutf or the standardized, POSIX-locale-dependent wchar.h functions for
> the UTF-8 conversion. I see one advantage of the wchar.h functions:
> If we use them we could avoid adding an extern
https://github.com/strake/l9fb
Future goals:
* make a terminal emulator
* make a tiling window organizer with same interface
* make the X window system my ex-window system
On 25/12/2013, Lee Fallat wrote:
> Neat although maybe not so practical. There would be lots of latency
> over a remote network, but locally I can see this being ok.
Yes, this is meant to be local. Remote graphics likely ought to be
vector rather than raster.
> How could you make it so that you
On 26/12/2013, yy wrote:
> You could maybe build such a thing on top of l9fb, but I don't think this
> would be such an improvement over directly using the fb device.
The reason for l9fb is to have a common interface whether it's the raw
framebuffer, an aggregate surface of many framebuffers, a w
101 - 134 of 134 matches
Mail list logo
