Re: [dev] [sbase] sponge
[2013-06-25 20:22] Jakob Kramer jakob.kra...@gmx.de
I wrote a sponge program, but I am not fully convinced of it yet. What
do you think?
I think you shouldn't rename(2). Renaming a file and replacing it's
contents are quite different things. Take for example:
$ mkdir a
$ chmod 600 a/b
$ touch a/b
$ chmod 100 a
$ echo foo a/b# this goes well
$ echo bar c
$ mv c a/b# this not
mv: cannot move `c' to `a/b': Permission denied
Special permissions and owner/group-ships are lost as well.
Either keep the contents in memory or read-write the contents
back.
Or better use what's already available: sort(1).
#!/bin/sh
if $# -ne 1 ; then
echo Usage: ${0##*/} outfile 2
exit 1
fi
sort -m -o $1
;-)
meillo
Re: [dev] mail clients
[2013-06-10 18:12] Michael Stevens mstev...@etla.org Are there any mail clients that don't suck? You might want to have a look at mmh. It's far from perfect, but it does some things quite well. http://marmaro.de/prog/mmh http://marmaro.de/docs/master meillo btw: If someone likes to write an MH storage view for some imapfs, I'd welcome that much. ;-)
Re: [dev] Is there any plan on a shell for sbase?
[2013-05-31 10:23] Evan Gates evan.ga...@gmail.com * ugly POSIX style * backwards compatibility? I think it would be nice to have a simplest possible POSIX compliant sh. I'm not well versed in the options that already exist, is there a minimally compliant, smallest possible, POSIX sh? AFAIK, dash intents to provide that. meillo
Re: [dev] Is there any plan on a shell for sbase?
[2013-05-31 12:05] Fernando C.V. ferk...@gmail.com Probably I'm talking shit here... or maybe this is something you are considering with sbase already... but I kept thinking about this. 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, [...] Welcome to the Thompson shell! ;-) http://v6shell.org/ meillo
Re: [dev] lynx?
[2013-05-28 18:11] Thorsten Glaser t...@mirbsd.de markus schnalke dixit: you rather use w3m? Is there anyone on earth having figured out how to *use* that, as in navigate? Funny, navigation is the main reason I prefer w3m over lynx. :-) meillo
[dev] lynx?
Hoi, these days, lynx was often mentioned when a text browser was meant. Is there really someone (apart from mirabilos) who uses lynx? Don't you rather use w3m? I am just wondering ... meillo
Re: [dev] st: Large pile of code
[2013-04-24 17:14] random...@fastmail.us A) Why do min and max need to be macros at all? That's the point, IMO. All the problems are introduced by performance optimizations that might not even necessary. If you write it as a function you simply don't need to care for double-evaluation. It will just work as expected ... and in many cases the compiler will do the optimization for you. Show me the case that really needs a macro! meillo
Re: [dev] [dwm] usage, was dwm 6.0 - separate taglists for muli-monitor setup
[2013-04-23 20:34] Markus Teich markus.te...@stusta.mhn.de [0]: http://www.wongdev.com/blog/2013/01/24/dwm-tags-are-not-workspaces/ I like this text a lot. Please add it to the website. meillo
Re: [dev] [dwm] usage, was dwm 6.0 - separate taglists for muli-monitor setup
[2013-04-25 14:27] Markus Teich markus.te...@stusta.mhn.de I have just added the link to the Related discussion paragraph. Thanks. That was exactly what I wanted (and not wanted to do myself). meillo
Re: [dev] print utility
[2013-04-03 16:25] Sam Watkins s...@nipl.net
using awk this seems to work:
awk '{ gsub(A, B); print; }' A=$A B=$B
Still a bit long, but much better than I can manage in sed or perl. Not sure
if that is standard awk or not, there's also a -v option to set values.
Your version is the original one, newer implementations and POSIX use -v.
(However the last example on the POSIX page misses the -v.)
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/awk.html
Btw, as you wanted it short:
awk '{gsub(A,B)}1' A=$A B=$B
meillo
Re: [dev] print utility
[2013-04-02 15:36] Sam Watkins s...@nipl.net I reckon by far the most common thing people do with sed is to replace one (sort of) string with another. But even this core sed business is ridiculous with sed. e.g. A=/usr/bin B=/bin sed 's/$A/$B/' in out # won't work Changing delimiters doesn't help for the general case. I would have to escape any input string before sed can handle it, which is more difficult than writing a better substitute process. sed is over-complex and so it's stupid even at its simplest core business. I would like rather: sub $A $B in out etc. More binaries perhaps, but at least they are sane. Funny to see this proposal. Never heard of gres(1), huh? [0][1] It was a ripped-out-of-ed tool like grep(1). The name stands for ``g/re/s///'' as grep stands for ``g/re/p''. It did exactly what you want sub(1) to do. Still at Bell Labs times gres died out when sed(1) became available. ;-) Seemingly, those that shaped Unix and its philosophy had no objections to its death. I can't recall from mind where I've read this story, possible in ``Software Tools'' or in ``The UNIX Programming Environment''. meillo [0] http://www.mkssoftware.com/docs/man1/gres.1.asp [1] http://docstore.mik.ua/orelly/unix/sedawk/ch03_02.htm#AUTOID-2409
Re: [dev] print utility
[2013-04-02 15:23] Sam Watkins s...@nipl.net I suggest to extend your program so it can also print a range of lines (and thus subsume the functions of 'head' and 'tail' while doing more and yet staying fairly focused). You could perhaps use negative numbers to count back from the final line. It should be able to cut off 6 lines from the end of a file, or print from lines 10 through to the 2nd-last line. Please don't write this tool as it is already available: ed(1): echo '1,$-6p' | ed - $1 echo '10,$--p' | ed - $1 Better learn about software leverage! meillo
Re: [dev] [slcon] Call for Papers 2013
[2013-03-17 16:47] Anselm R Garbe garb...@gmail.com I will record videos of all talks, however they won't be available as live streams, but published at the end of each conference day. Great! meillo
Re: [dev] Find window with dmenu
[2013-02-12 14:27] Truls Becken truls.bec...@gmail.com On 2013-02-12, at 13:22, Chris Down wrote: Considering he's already doing rudimentary filtering through in *addition* to sed calls, awk is more generalisable choice to the problem set. Alternatively, you could say that sed is the more generalisable choice since grep is pretty much a subset of sed. I disagree because grep (with -E or as egrep) does support Extended Regular Expressions, which sed does not. The following is NOT portable: sed -E 's/\s\+// ; /(vim|surf):/d' http://pubs.opengroup.org/onlinepubs/9699919799/utilities/sed.html If you want sed with Extended Regular Expressions, take awk. :-) meillo
Re: [dev] FTP script: how to store password?
[2013-02-09 22:32] Sam Watkins s...@nipl.net On Sat, Feb 09, 2013 at 12:20:58PM +0100, Hugues Moretto-Viry wrote: Hi guys, I'm writing a little FTP client in pure shell + curl for my personal needs. Anyway, I need to store my passwords so I chose SQlite, because I don't want to put them in a regular file or in the script. Unfortunately, I think this is not really perfect. Do you know how to store my passwords outside the script (maybe hashed), in the suckless way? I would store them in one file per server, with key=value pairs, so can just 'source' the right file. e.g. filename: ftphosts/nipl.net content: host=nipl.net user=sam pass=whatever can have other optional keys such as 'port', and such. If you want a single file, you could use TSV or other tabular format, keep them sorted, and a binary search tool such as 'look' to find the right line: ai.ki sam something nipl.net sam whatever but I'd prefer the separate files. This looks much like a reinvention of netrc. Netrc is already there and widespread. Also, users know that it contains sensible data. The things not so perfect of netrc are minor compared to that. meillo
Re: [dev] Suckless generic diagram creation software?
[2013-02-06 16:18] Jacob Todd jaketodd...@gmail.com Troff and pic. ... to draw diagrams manually; graphviz for automatic layouting of graphs. meillo
Re: [dev] snotes v0.9 - a simple notes system
[2013-02-05 00:54] v4hn m...@v4hn.de
On Mon, Feb 04, 2013 at 10:09:25PM +0100, markus schnalke wrote:
[2013-02-04 20:57] v4hn m...@v4hn.de
On Mon, Feb 04, 2013 at 11:46:51PM +0800, Chris Down wrote:
SNOTES_EDITOR=${VISUAL:+xterm -e $VISUAL}
: ${SNOTES_EDITOR:=${EDITOR:-vim}}
That would make the config do more than it is supposed to.
I agree that it makes sense to respect $VISUAL though.
I now changed the line to
SNOTES_EDITOR=${VISUAL:-xterm -e vi}
to meet that requirement.
On my system VISUAL is set to `vi', which is a common situation.
Your code assumes that VISUAL contains a graphical editor. Thus
the setup breaks for me AFAICS.
I see. Thanks for note. I've changed it to the following now,
which should work for all reasonable setups.
If this doesn't work for someone, honestly, I couldn't care less.
It's a default, not the final truth.
SNOTES_EDITOR=${EDITOR:+xterm -e $EDITOR}
SNOTES_EDITOR=${SNOTES_EDITOR:-xterm -e vi}
Sorry, but you've missed the point. This setup does not solve
the issue at all.
meillo
Re: [dev] snotes v0.9 - a simple notes system
[2013-02-04 17:09] Charlie Kester corky1...@comcast.net On 02/04/2013 13:09, markus schnalke wrote: On my system VISUAL is set to `vi', which is a common situation. Your code assumes that VISUAL contains a graphical editor. I'm not sure, but I think the semantics when this variable first began to be used was to distinguish a full-screen editor like vi (or emacs) from a line editor like ed. That's correct. The naming of the variables and editors is not by accident: VISUAL -- vi (which is short for `visual') EDITOR -- ed (which is short for `editor') ;-) meillo
Re: [dev] snotes v0.9 - a simple notes system
[2013-02-05 13:16] v4hn m...@v4hn.de
On Tue, Feb 05, 2013 at 12:10:12PM +0100, markus schnalke wrote:
[2013-02-05 00:54] v4hn m...@v4hn.de
I see. Thanks for note. I've changed it to the following now,
which should work for all reasonable setups.
If this doesn't work for someone, honestly, I couldn't care less.
It's a default, not the final truth.
SNOTES_EDITOR=${EDITOR:+xterm -e $EDITOR}
SNOTES_EDITOR=${SNOTES_EDITOR:-xterm -e vi}
Sorry, but you've missed the point. This setup does not solve
the issue at all.
Sorry for using too rough words -- I've misread `:+' for `:-'.
Missing the point(VISUAL) was the idea. Quoting from Wikibooks[0]:
Generally you will want to set it [VISUAL] to the same value as the EDITOR
variable. Originally EDITOR would have be set to ed (a line-based editor)
and VISUAL would've been set to vi (a screen-based editor). These days,
you're unlikely to ever find yourself using a teletype as your terminal,
so there is no need to choose different editors for the two.
I agree on the quoted statement but not on your conclusion. Not setting
different editors into the variables is different from evaluating only
one of the two variables. As it is hardly necessary to set the variables
differently, users might set only one of them (likely visual as they use
visual editors). This is safe if programs follow the common practice of
evaluating in the order VISUAL - EDITOR - vi.
ok, so either I'll keep the above two lines or I'll move the logic
to the initialization to retain a clean config file without sequential
logic:
SNOTES_EDITOR=${VISUAL:-${EDITOR:-vi}}
SNOTES_EDITOR=xterm -e $SNOTES_EDITOR
cat $HOME/.snotes/config EOF
SNOTES_EDITOR=$SNOTES_EDITOR
[...]
You may choose.
What kind of choice is that? I argue about sane solutions and you
want me to choose between two bad ones.
Let my suggest a solution: Put the first two lines of your second
option in place of your first option and thus use:
SNOTES_EDITOR=${VISUAL:-${EDITOR:-vi}}
SNOTES_EDITOR=xterm -e $SNOTES_EDITOR
Or even shorter:
SNOTES_EDITOR=xterm -e ${VISUAL:-${EDITOR:-vi}}
Or if you like to be able to override the xterm spawning, use:
SNOTES_EDITOR=${SNOTES_EDITOR:-xterm -e ${VISUAL:-${EDITOR:-vi}}}
The first two of my suggestions are very much ideoms, whereas
both of your suggestions would produce unexpected behavior for
me.
meillo
Re: [dev] snotes v0.9 - a simple notes system
[2013-02-05 15:22] v4hn m...@v4hn.de
On Tue, Feb 05, 2013 at 02:18:18PM +0100, markus schnalke wrote:
[2013-02-05 13:16] v4hn m...@v4hn.de
SNOTES_EDITOR=${VISUAL:-${EDITOR:-vi}}
SNOTES_EDITOR=xterm -e $SNOTES_EDITOR
cat $HOME/.snotes/config EOF
SNOTES_EDITOR=$SNOTES_EDITOR
[...]
You may choose.
The first two of my suggestions are very much ideoms, whereas
both of your suggestions would produce unexpected behavior for me.
I honestly don't see any unexpected behaviour here.
I'd expect that changing VISUAL would change the default editor
in applications at startup time not at installation time.
Let my suggest a solution: [...]
SNOTES_EDITOR=xterm -e ${VISUAL:-${EDITOR:-vi}}
Fine with me, I just pushed this. Thank you for your criticism.
Great! Thanks for the discussion. :-)
meillo
Re: [dev] Suckless graphs
btw: [2013-02-04 12:22] Kai Hendry hen...@iki.fi That graphing script could be as simple as calling GNUplot, ``Despite gnuplot's name, it is not part of or related to the GNU Project, nor does it use the GNU General Public License, [...]'' http://en.wikipedia.org/wiki/Gnuplot meillo
Re: [dev] snotes v0.9 - a simple notes system
[2013-02-04 22:54] Chris Down ch...@chrisdown.name
Something like this should work:
SNOTES_EDITOR=${VISUAL:-$EDITOR}
Better:
SNOTES_EDITOR=${VISUAL:-${EDITOR:-vi}}
meillo
Re: [dev] snotes v0.9 - a simple notes system
[2013-02-04 20:57] v4hn m...@v4hn.de
On Mon, Feb 04, 2013 at 11:46:51PM +0800, Chris Down wrote:
SNOTES_EDITOR=${VISUAL:+xterm -e $VISUAL}
: ${SNOTES_EDITOR:=${EDITOR:-vim}}
That would make the config do more than it is supposed to.
I agree that it makes sense to respect $VISUAL though.
I now changed the line to
SNOTES_EDITOR=${VISUAL:-xterm -e vi}
to meet that requirement.
On my system VISUAL is set to `vi', which is a common situation.
Your code assumes that VISUAL contains a graphical editor. Thus
the setup breaks for me AFAICS.
I suggest you split the task:
1) evaluate the preferred editor.
2) launch it with xterm.
If someone sets VISUAL to a graphical editor, the terminal window
is superfluous but would do no harm.
meillo
ls -s vs. du (was: Re: [dev] [st] font fallback)
[2013-01-05 18:55] Christoph Lohmann 2...@r-36.net % ls -hs st-0.3/st 126K st I wondered why 20h did not use `du -h st-0.3/st' instead. Then I wondered why ls(1) has `-s' at all. Even in 1st Edition Unix, ls(1) has `-s' although du(1) is available. http://man.cat-v.org/unix-1st/1/ls http://man.cat-v.org/unix-1st/1/du Does someone of you have more information on this? meillo
Re: [dev] [suckless] Migration to git
[2012-11-27 12:03] chris hall followingthep...@gmail.com On Tue, Nov 27, 2012 at 8:50 AM, markus schnalke mei...@marmaro.de wrote: [2012-11-26 16:47] Roberto E. Vargas Caballero k...@shike2.com - History rewriting: git rebase or git filter-branch (btw: That's the worst feature a version control system can offer.) I disagree, IMO this is one of the most useful features of a vcs. This isn't usually rewriting history on a global scale (that is possible, but usually very dangerous) but instead only altering my local and unpushed commits. (Sounds a bit like hard links to directories ...) I use this for 2 different workflows: In one I have a WIP commit that I add to every time I am closer, and then break this up before pushing. The other I instead make a commit every time I get a step closer, and then squash them into logical commits before pushing. This gives me version control within an individual feature, although I guess you could achieve the same thing with branches and manually cping files around. I find a vcs constraining if it doesn't allow me the use of these workflows, YMMV History rewriting is no necessity for these workflows. Cloning of the repo (which replaces branching) allows you to do the same. You are always able to clone any arbitrary revision. You guys just fear cloning a repo ... (It is only a performance issue if your project comprises hundreds of thousand lines of code and a huge number of changesets, which we surely don't have.) It's the ingenuity of Unix to have just one kind of fork(). Why can't we map this concept to DVCS and have just one kind of cloning? meillo
Re: [dev] [suckless] Migration to git
[2012-11-26 16:47] Roberto E. Vargas Caballero k...@shike2.com [...] but if you want some reasons I am going to give you some of then: - History rewriting: git rebase or git filter-branch (btw: That's the worst feature a version control system can offer.) - Mail workflow support: git am, git format-patch or git email. - Incremental commits: git add -i, git checkout -f. - A diary of tip references: git reflog (this features saved my life a lot of times). - Temporal changes: git stash. - Be scriptable: git has a low-level set of commands that allow build any operation you need using a shell script : git commit-tree, git cat-file, git ls-tree ... There are others reasons, like for example the speed changing between branches, but they are not important in suckless projects. Why do people, even on this list, argue with the presence of features? You should argue with the *absence* of features! If, for instance, branches are not important to suckless projects, we should be looking for a VCS *without* branch support. (Actually, DVCSs don't need branch support at all as branching is part of the nature of distributed version control, in cloning the repo. Why would one want a second type of branching built in if this function is already available for free?) meillo
Re: [dev] Troff for typsetting e-mails
[2012-10-28 06:22] Christoph Lohmann 2...@r-36.net as the subject says, I’m thinking of typesetting my e‐mail in troff. Anyone here has done something similar? I have not done it before but as I like troff much I've thought about doing so. Eventually, I have decided against it because I found the complexity of the implementation and the email source text not worth the result. What do you gain? 1) Text adjusted at both margins. 2) References at the end of the paragraph or at the end of the message. 3) Lists, blockquotes, etc. The adjusting (1) would be appealing but I don't see much value in it as I seldom write really long messages that would profit from it. Well, for German text automatic hyphenation could improve the line- breaking. Yet, I don't see enough improvement here. References at the end (2) would be really cool but managing them manually is not much overhead in my case. Finally, automatic management of lists and the like (3) is nothing I would profit much from. The main disadvantage of troff postprocessing is the problem to send verbatim text, e.g. source code. Lines starting with dot or single- quote might not be a problem but backslashes are. There is no such thing as a true verbatim environment as in TeX. Either you need to handle the backslashes manually or you have to remap the backslash character and enter ugly corners of troff. I've chosen the latter option for my master's thesis. See the VS and VE macros in [0]. [0] http://hg.marmaro.de/docs/master/file/49d3aa0d128a/style Further more, you need to handle quoted text in replies. This is a short explanation of my POV on the topic. I am very interested in the topic. Please keep me updated on your further thoughts and actions. meillo
Re: [dev] [ii] exposed password on process monitoring
[2012-06-16 17:00] Nico Golde n...@ngolde.de Thanks for reminding me. ii tip contains a change now so that -k specifies an environment variable containing the password and not the password directly. AFAIR the environment can be displayed, too. I think it was `ps e'. Hence the fix is no fix. meillo
Re: [dev] [ii] exposed password on process monitoring
[2012-06-16 16:33] Connor Lane Smith c...@lubutu.com More déjà vu. I apologize for having posted without having read the thread. meillo
Re: [dev] unsubscribe
[2012-06-13 10:21] pancake panc...@youterm.com You have been successfully unsubscribed from this mailing list. s/successfully/un/ In expectation of success, readers would hardly have noticed the two additional letters that make all the difference. meillo
Re: [dev] awful surf screenshot
[2012-03-26 14:02] hiro 23h...@googlemail.com http://surf.suckless.org/screenshots/surf-20091028.jpg That's really not a good example to promote surf. All the fonts are small distorted or at least unreadable. I agree. Maybe we just talked about different things. I don't care for promoting surf. I only care for having the code available and maybe a web address as an entry point. It needs not to be on the main suckless page. meillo P.S. Just noticed, that the suckless.org website design has changed. It looks appealing. Good work!
Re: [dev] Suckless ML archiver?
[2012-03-17 16:06] Scott Lawrence byt...@gmail.com On Sat, 17 Mar 2012, Anselm R Garbe wrote: On 17 March 2012 20:56, Scott Lawrence byt...@gmail.com wrote: On Sat, 17 Mar 2012, Anselm R Garbe wrote: The mlmmj output format is a directory consisting of files (1-n) where each contains a single message in mbox format. The number (1-n) is incremented for each message. For instance the dev@suckless.org mailing list directory contains 11359 message files as of now. You could extend your archiver to work on such a directory structure. Once done, I would give it a go on the dev@suckless.org messages. A single message in mbox format? Or a single message in RFC5322 format (as typically found in mboxes)? Or single message in not-quite-standard format (such as used by pipermail behind the scenes)? Sorry for the confusion, it is rfc5322 format. That means, if you add a `.mh_sequences' file, then you have an MH mail folder -- great. Oh, if it's just rfc5322, then a simple 'cat' won't do (slark expects an actual mbox ATM). If you have nmh installed, then you can use packf(1) to generate an mbox, even to stdout (packf -file /dev/stdout | ...) AFAIK the differences between an mbox containing one message and a plain RFC822 message (MH mail store format) are the `From ' line (line number 1) and that each subsequenc line starting with ``From '' will be prefixed with `'. Awk will convert the format easily for you. meillo
Re: [dev] Adventures with static linking
[2012-02-14 21:55] Bjartur Thorlacius svartma...@gmail.com Thanks for a great reading. :) Full Ack. meillo
Re: [dev] mail flame war (was: interested in issue tracker dev)
[2012-01-14 11:54] hiro 23h...@googlemail.com mail sucks ... the start of a flame! *yay* Please define what you mean with ``mail''. meillo
Re: [dev] interested in issue tracker dev
[2012-01-13 15:27] Paul Onyschuk bl...@bojary.koba.pl - treat first message in mbox as meta: modify and store common informations (priority, short description, category of issue and so on) there No, put meta information in the header, where it belongs to. anno(1) from MH does it for you. Any newer message might change these attributes. Well, you might want to update these attributes in the first message, to have the latest state there, but in its header. Also, the change history would still be available. I don't know how debbugs stores the meta data, but their change history is great. Be sure to play with it. meillo
Re: [dev] interested in issue tracker dev
[2012-01-13 17:28] Paul Onyschuk bl...@bojary.koba.pl On Fri, 13 Jan 2012 15:48:43 +0100 markus schnalke wrote: Mbox formats are human readable, and file per issues makes it accessible. Throwing everything into one file (like mbox mail archive) or splitting everything into zillon files (file per message like maildir) requires additional techniques/tools just to find interesting issue. As you put all mails to one issue into one mbox file, you can put mails into one mail folder as well. There's no difference there. History of issues in many cases is just garbage. What I need is status of issue and responses to specific issue. Git/Mercurial or any other version control system can provide history if you really need that. Almost every open source projects nowadays gives read access to source code repository, so what is the point of writing custom log format? No custom log format, you just add some mail header lines to a new message on receiving, that's all. At least to me, that appears to be natural. This way you can also track interesting issues without subscribing to mailing list or using web interface. I haven't said anything about mailing lists or web interfaces. But well, you surely want a web interface (at least read-only) and you probably want be able to subscribe to issues. The mail interface really is the important part, as Anselm already said. When you want control it by email, then consider building it upon email. Right now best interfaces for issue trackers are search engines (e.g. Google site:adress_of_bug_tracker interesting issue) and mail archives (Gmane and so on) in my opinion. Unless you want to make changes ... meillo
Re: [dev] interested in issue tracker dev
[2012-01-12 19:06] Anselm R Garbe garb...@gmail.com On 12 January 2012 18:34, aecepo...@gmail.com wrote: I might be interested in trying to help write one such suckless issue tracker as requested on the webpage. I just want to ask; What set of features are a must for you? Oh what a relief someone wants to volunteer on this idea. One of the most important things of such a tracker is decent mail integration in my opinion (as most trackers that have evolved in the OSS space recently suck very much when it comes to mail integration). What about debbugs? Haven't set it up yet, but used it within Debian and like its user (mail) interface. Apart from that, you might want to consider building the issue tracker on top of MH. meillo
Re: [dev] what's your opinion on Go
[2011-12-13 08:12] Michael P. Soulier msoul...@digitaltorque.ca [...] but if I had to pick one language to use for everything, it would be C. You better not pick any single language to use for everything. meillo
Re: [dev] DWM vs XFCE4 Memory Usage
[2011-12-04 21:35] Roger rogerx@gmail.com Checking memory usage between XFCE4 and DWM, I find XFCE4 uses only ~30MB more then DWM. 100MB - DWM + Xorg 130MB - XFCE4 I'm a bit confused: Doesn't XFCE set on top of Xorg? Could someone please explain. meillo
Re: [dev] [dmenu] Keyboard Bindings
[2011-11-21 10:12] Rob robpill...@gmail.com On 21 November 2011 09:15, Yoshi Rokuko yo...@rokuko.net wrote: it seems that i cannot communicate my point - why are vi-styled-key- binding-styled-interfaces so popular? It's not vi-style, it's Unix. If you come from a Windows background, you'll be used to Ctrl+Backspace to delete a word, or Shift+Home, Backspace to delete a line. Unix has C-W and C-U, it's just muscle memory. Uriel created a page once: http://unix-kb.cat-v.org/ meillo
Re: [dev] xv6
[2011-11-09 14:52] Kurt H Maier karmaf...@gmail.com This is five years old, and has been discussed on this list at least once in the past year. How about having all mail to the list going through a program to check if there are large similarities to old messages in the list archive. If so, the message would be sent back, together with links to possibly similar messages. The user could post his message anyways, but it would require more effort. That's in contrast to the current scheme, where doing the archive search takes additional effort. ... just a thought. ;-) meillo
Re: [dev] [dwm] 2000 SLOC
[2011-10-31 10:11] Anselm R Garbe garb...@gmail.com On 31 October 2011 10:01, Martin Kopta mar...@kopta.eu wrote: Are there any explicit rules which project must follow in order to be part of suckless? What is the line in here? I'm working on such guidelines. The main aspects are: I wonder why we actually do need such guidelines. We don't have masses of projects to filter. We can simply continue including what we (i.e. eventually Anselm) consider worthwhile and remove what we consider not suiting. That makes everthing easier and also we keep our flexibility. (As we agree that wmii should go, just remove it. Its fans had long enough time to move the contents.) Generally, I think, that one success factor in the (early) development of dwm had been that Anselm just did what he thought was good for himself. This can be done similarily for suckless.org. Anselm has shown that he goes for rough consensus. Instead of adding manifests, we better have real content and let that speak. 1. Relevance/Elitism: the project must be relevant in the context of suckless.org's target audience, it must target expert users/developers/administrators and _not_ typical end users. Why? Are there too many projects in which only few people are interested? 3. Quality: the project must aim to be a quality finished product once exceeding the 1.0 version number and be maintained afterwards. Someone already pointed it out. It actually were suckless projects that did intentionally not care about the meaning of version numbers. And about quality: Who of us mainly cares about quality? We care about hackable code! That's important. Unmaintained projects will be removed after a grace period of one year. Rules, rules, rules ... 5. Exclusivity: the project must be unique, i.e. it should not solve a problem that is solved by another suckless.org project. Why not? I suggest to drop the idea of having such a set of rules. We have the expression of our code and we have a common sense within the suckless community. What else is the Unix philosophy? meillo
Re: [dev] List of tools for a CLI environment
[2011-10-27 09:05] Bjartur Thorlacius svartma...@gmail.com Directory names are a sequence of arbitrary nonzero bytes. Parsing a concatenation of arbitrary strings sucks. Directories can only be separated by zero bytes. That's actually a bug in Unix, discovered too late. meillo
Re: [dev] Some questions about st and a patch
[2011-10-19 21:36] Andrew Hills hills...@gmail.com On Wed, Oct 19, 2011 at 9:20 PM, Stephen Paul Weber singpol...@singpolyma.net wrote: Or are you complaining about filesize? Are you on dialup? No, just complaining that it's hard to find the content in your message when the majority of my mail reader's window is full of PGP signature instead of words. Just that I frequently see way worse messages in this respect on this list. meillo
Re: [dev] [dwm] adding docking support
[2011-10-16 17:54] Anselm R Garbe garb...@gmail.com Do we really agree that touch interfaces do suck less? No. meillo
Re: [dev] [dmenu] dmenu_run improvements
[2011-07-24 14:09] Connor Lane Smith c...@lubutu.com On 24 July 2011 06:34, Dave Reisner d...@falconindy.com wrote: if [ $path -nt $CACHE ]; then 'test -nt' is non-portable. I think you've just discovered why we use the 'ls -dt' hack. The right time to add a comment, so we won't need to rediscover it again. meillo
Re: [dev] dmenu-4.4
On 20 July 2011 11:06, Nick suckless-...@njw.me.uk wrote: But just downloading the key from a keyserver, even if it isn't trusted by your web of trust, is better than e.g. just distributing a hash, [...] The concept of PGP trust lies in the Web-of-Trust, nowhere else. If you don't find a trust-path from you to the signing key, then the signature does only provide the information of a checksum hash. meillo
Re: [dev] [dwm] titlenormcolor patch
[2011-07-13 14:47] ml+suckl...@wzff.de Attached is a really important diff against tip I hope to get into 6.0. It might need additional testing, but otherwise works fine for me. Thanks in advance for the next 5 years! diff -r 4548c824adac dwm.c --- a/dwm.c Sun Jul 10 21:25:23 2011 +0100 +++ b/dwm.c Wed Jul 13 14:44:09 2011 +0200 @@ -2062,6 +2062,7 @@ checkotherwm(); setup(); scan(); + puts(Hello World!); run(); cleanup(); XCloseDisplay(dpy); YMMD! Thanks. meillo
Re: [dev] Experimental editor
[2011-06-17 16:24] Martin Kühl martin.ku...@gmail.com Consider ex mode. How do you edit text in it? You don't have normal mode to help you, it only operates on real buffers, and you certainly don't have ex mode available. If ex mode were just a command buffer, you could use every piece of functionality your editor provided, maybe even open another command buffer operating on the current one. Or simply, as Connor put it, all we're doing is editing text. Thanks for the explanation. Now I understand this point, and I agree here. meillo
Re: [dev] Experimental editor
[2011-06-15 08:12] Peter John Hartman peterjohnhart...@gmail.com Why would you want several editors? For the same reason we want Unix's manifold toolchain and for the same reason we want several programming languages: Because ``One fits all'' is an illusion. The problem with vi and mutt is that they have all these keybindings; hence you can on occasion find yourself in some crazy dark key combination that you didn't mean to be in. Hit Escape and you'll be at a defined place. :-) (btw: I talk about vi, not about mutt.) meillo
Re: [dev] Experimental editor
[2011-06-15 14:47] Connor Lane Smith c...@lubutu.com On 15 June 2011 12:26, markus schnalke mei...@marmaro.de wrote: What's the difference between a mode and a ``quasimode''? What's the difference between shift and caps lock? I disagree with this analogy. Shift is no quasimode. In vi, you enter insert mode, which you consider a real mode, with `i' and leave it with Escape. Likewise you enter ex mode (i.e. last-line mode), which you consider a quasimode, with `:' and leave it with Enter. It surely isn't a mode you stay long in, but there is no reason why it shouldn't be seen as a real mode. You understand my point of view? I want there to be just a collection of buffers, and typing into command buffer is what gives you `command mode', sam style. We always use the same keys, because all we're doing is editing text, so it becomes muscle memory. Now draw the analogy between selecting one or the other buffer with with mouse to hitting some mode switching key. For me that's the same. You do want modes ... you simply don't want to call them ``modes''. :-) This. I want keys to always mean the same thing. I'd say that the meaning of `f' isn't the same as the meaning of `f' if you hold Ctrl at the same time. Where's the difference if you alter the meaning of a key with a modifier key or with a mode? Okay, the former modification drops as soon as you release the key. Too often they don't, and you end up not knowing what on Earth is happening. With this approach, all you need to keep in mind is where your cursor is. Maybe you haven't used vi as it was meant to be used: You're always in normal mode (hence the name). Switching to other modes is only a temporary thing. If you wanna know where you are: Hit Escape! meillo
Re: [dev] Experimental editor
[2011-06-17 09:54] David Tweed david.tw...@gmail.com
On Fri, Jun 17, 2011 at 9:51 AM, David Tweed david.tw...@gmail.com wrote:
On Fri, Jun 17, 2011 at 9:46 AM, Nicolai Waniek roc...@rochus.net wrote:
On 06/17/2011 10:37 AM, markus schnalke wrote:
For the same reason we want Unix's manifold toolchain and for the same
reason we want several programming languages: Because ``One fits all''
is an illusion.
Then try to figure out some basic tools that you can glue together to
form a fully functional editor.
'Reinventing' an editor for every purpose and most probably copying some
things on source level from one editor to the next is ridiculous.
Isn't vi a good example for how not to reinvent everything? It wraps
around ex. (Some say ``Vi is actually one mode of editing within the
editor ex.'')
But actually, I think you misunderstood my words. I don't think one
should do the *same* again and again but rather put small specialized
parts together. If you used ed or ex you quickly notice that they are
great for editing on line basis but you'll suffer when editing within
a line. You likely tend to rewrite the whole line anew instead of
editing it. Vi (i.e. the normal mode) improves here. On line basis you
might still want to use ex ... although many don't.
Even more annoying is that the way that the lack of an OS-level editor
component means that there's a tendency for any application that wants
to provide a writing/editing capability to write their own, often
poor, editing code.
You point to a different problem: Application programmers don't honor
common practice in Unix.
To clarify, I by OS-level component I mean at the this is THE
component applications use when the want editing, but which would be
changeable by the user.
Actually there is such thing: ${VISUAL-${EDITOR-vi}}
I entirely agree with that one interface fits all
users is a problem, but I'd like a system where there was one
interface for editing in all circumstances for this user.
From application's view: See above.
Else: Ed is the standard text editor!
meillo
Re: [dev] Experimental editor
[2011-06-12 18:55] Martin Kühl martin.ku...@gmail.com [...] command-quasimode [...] [...] mostly modeless. [2011-06-12 22:38] Connor Lane Smith c...@lubutu.com For substitution I'm tempted to just add a keybind to switch to and from the command pane, which appears at the bottom of the view (`Quake-like', as Paul says). That means we can do this just with a raw command, like vi does with `:'. So that's pretty much modeless, then. What's the difference between a mode and a ``quasimode''? Almost none! It appears as if you just *want* modes. ;-) I have followed this editor discussion, only reading. Still I wonder why you try so much to stay modeless. Modes are a real advantage because each mode offers a separate editor. Take vi: You can edit in normal mode (= the actual vi mode) or in ex mode or in insert mode (e.g. with ^W, ^U). You have the choice which editor (mode) you use for some editing task. Ed has modes, too: Command and insert mode. Surely, the problems are knowing in which mode you're in and switching modes. But in return, each mode lets you re-use your keyboard keys (the optimum) and for each mode you can design a new editor that's best suited for the kind of editing this mode is intended to do. Am I missing some big disadvantages of modes? I simply don't understand your strong dislike. meillo
Re: [dev] dwm
[2011-05-07 20:39] m1...@web.de @Anselm i get tired from this..i just switched my wm..have fun with dwm ;) You did right. Use the window manager that matches your needs best. meillo
[dev] [slock] fixing the annoying combination with PAM
Hoi, at my university PAM is used for user login. They have slock installed because they have the suckless-tools package (Ubuntu) installed. If I run slock , X gets locked like it should. Unfortunately I'm not able to unlock it again because slock checks against /etc/passwd which does not contain an entry for my account. This leaves me stuck in an dead end. This is annoying. Of course, I could simply not use slock, but you know how things happen from time to time ... your habits take over. ;-) Hence I though that slock could check for an passwd entry before it locks. Thus it can prevent locking the screen when you won't be able to unlock it afterwards. Here is a patch against current tip which implements this check. I'm no expert in this topic, I just hacked it to work for me. meillo diff -r 4d3769ac5d02 slock.c --- a/slock.c Thu Nov 26 12:53:26 2009 + +++ b/slock.c Tue Apr 19 18:50:59 2011 +0200 @@ -228,6 +228,10 @@ else if(argc != 1) usage(); + if(!getpwuid(getuid())) + die(no passwd entry for you); + #ifndef HAVE_BSD_AUTH pws = get_password(); #endif
Re: [dev] dmenu patch to return all matching items (for a new dmenu-powered music player interface)
[2010-11-11 12:47] Dieter Plaetinck die...@plaetinck.be On Thu, 11 Nov 2010 12:36:23 +0100 sta...@cs.tu-berlin.de wrote: * Anselm R Garbe garb...@gmail.com [2010-11-11 12:19]: On 11 November 2010 06:25, Dan Brown danbr...@gmail.com wrote: As part of a project to create a simple and fast music player interface, I patched dmenu to allow it to return all matching items instead of just the one at the cursor. dmenu is the browsing This patch looks kinda useful to me and I'll think about probably supporting this in mainstream dmenu. Can be very useful bound to some modkey + enter you mean you want to choose between return current result vs return all current matches at run-time? What's a use case for that? I think this should be configured with a commandline argument, because the script that calls dmenu needs to know in advance what kind of output it will get anyway and it depends on what task the script will do. Or am I missing something? Note that the user might not be able to know in which mode dmenu acts at run-time. The mode should be made visible then. (I don't say that this is the right way to go, though.) meillo
Re: [dev] dmenu patch to return all matching items (for a new dmenu-powered music player interface)
[2010-11-11 14:36] Dieter Plaetinck die...@plaetinck.be On Thu, 11 Nov 2010 14:12:59 +0100 markus schnalke mei...@marmaro.de wrote: Note that the user might not be able to know in which mode dmenu acts at run-time. why wouldn't he? if a dmenu appears on a users' screen, it appears because the user configured/installed a script/keybinding/tool that spawns the dmenu. Isn't know your own system a fair assumption? People may have different scripts launch dmenus. One will have to give them different colors to divide them apart. If dmenu would be a tool that is usually invoked directly on the command line, then I would agree with you. Because this is not the case I do not. Think about vi behaving differently whether invoked from crontab or visudo or hg ci. I would consider this bad. In any way, wasn't dmenu designed to behave the same everywhere? Such as `i' in vi should mean ``insert'' on every system. If on any system I use dmenu pops up, I'd like to know what it does when I hit Enter. If in filter mode, all entries on the right side would be highlighted, then I am pleased. The clear rule would be: Each highlighted entry gets printed. Think this is how is should be. meillo
Re: [dev] dmenu patch to return all matching items (for a new dmenu-powered music player interface)
[2010-11-11 14:08] Connor Lane Smith c...@lubutu.com On 11 November 2010 14:02, Connor Lane Smith c...@lubutu.com wrote: I do agree there should be some sort of indication like this, but I don't think it's that easy. Right now all I can think of is changing the prompt, like dwm does when its behaviour changes with the layout symbols. I'd also like to point out that dmenu has had the '-i' flag for a long time, which makes dmenu match items case insensitively. Although the difference is fairly subtle, it certainly is a mode. In contrast to the filter mode, with caseless matching you would *see* that it behaves differently. And you see which item will get printed. This is the reason I suggest, that in filter mode you should also *see* which items will get printed. In filter mode the highlighting in the list has no more meaning (if I understood correctly). IMO the highlighting should keep its meaning, being: Each highlighted item will be printed. meillo
Re: [dev] curses samterm
[2010-08-03 16:30] Joe joebsulli...@gmail.com [08/03/10] @11:28AM PDT, mei...@marmaro.de wrote: [2010-08-03 10:14] Joe joebsulli...@gmail.com NAME ed - text editor SYNOPSIS ed [-] [-sx] [-p string] [file] It should be: ed [-] [file] I concur. fwd: sj...@apple.com. My only other choice is 9 man ed: SYNOPSIS ed [ - ] [ -o ] [ file ] or Google: ed [-] [-Gs] [-p string] [file] ed [ - ] [ -x ] [ name ] ed [-] [-Esx] [-p string] [file] ed [-s | -] [-p string] [-x] [-C] [file] You see, the dash is the only options provided by all implementations, except First Editon. meillo
Re: [dev] curses samterm
[2010-08-03 10:14] Joe joebsulli...@gmail.com ED(1)ED(1) NAME ed - text editor SYNOPSIS ed [-] [-sx] [-p string] [file] It should be: ed [-] [file] meillo
Re: [dev] unsubscribe
Each time such a mail reaches the list, I exactly know what will go on afterwards. ;-) Don't we have a law for this yet? meillo
Re: [dev] Presentation slides software
[2010-06-29 12:34] Uriel ur...@berlinblue.org I'm looking for a minimally sane way to generate presentation slides, ideally using something similar to markdown and capable of generating decent-looking html (and hopefully) pdf. I know about magicpoint, and I normally use the troff slides macros: http://repo.cat-v.org/troff-slider/ I use a modified version of your slides macros for some time now and am very pleased with them. I generate PS and display with gv. I still haven't managed to cut the PDF pages in length (haven't tried much). Some sources from me are available at: http://marmaro.de/docs/chaosseminar/unix-phil/ You are probably at the same point. But the generated HTML is rather messy, and fixing htmlroff is too much work. I can't help here because I don't generate HTML from it. btw: Do you include bitmap pictures into your slides? If so, how? I read that Heirloom troff has some features therefore, but I think they are Heirloom extensions. meillo
Re: [dev] ji - ii-like jabber client
[2010-06-24 13:10] Ramil Farkhshatov ra...@gmx.co.uk I decided to share a simple jabber client with ii interface. It supports normal convercations and multi-user conferences. Requires iksemel and gnutls (optional). Can be taken here: git clone http://iris-comp.ru/public/git/ji.git (I know about bitlbee, but didn't like it for some reason). Do you know about jj too? http://23.fi/jj/ Haven't used it myself though. meillo
Re: [dev] Convert Suckless Projects Documentation to a More Simple Language
[2010-06-16 16:06] Matthew Bauer mjbaue...@gmail.com sarcasm=1 Please stop it. Thanks. meillo
Re: [dev] [dvtm] Fibonacci layout patch
[2010-06-01 13:34] Mate Nagy mn...@port70.net On Tue, Jun 01, 2010 at 01:27:07PM +0200, Mate Nagy wrote: Using the vim splits may be cheating, but it sure is convenient. sorry for self-reply: I thought that maybe for maximum punishment, the fibonacci layout could support nmaster. (Also note that this is a 2560x1600 setup, that's why so much division (and nmaster) makes sense.) Thanks for your self-reply, I just wanted to ask what screen resolution you have. meillo
Re: [dev] Is there a reason to use install(1)?
[2010-05-29 18:15] Kris Maglione maglion...@gmail.com On Sat, May 29, 2010 at 11:56:26PM +0200, markus schnalke wrote: [2010-05-29 23:46] Moritz Wilhelmy c...@wzff.de Very often I see makefile use install(1) when cp, mkdir, chmod, and Co. would be equally compact. Consider install -D -m755 -u foo -g bar foo.sh $DESTDIR/usr/bin vs. mkdir -p $DESTDIR/usr/bin cp foo.sh $DESTDIR/usr/bin chmod 755 $DESTDIR/usr/bin/foo.sh chown foo:bar $DESTDIR/usr/bin/foo.sh and tell me about equally compact again... I know about such cases, but this is not the common case, at least as far as I've seen it. You mean, install is just meant as a wrapper around the standard tools to express the actions in a more compact way. (btw: It's a shame that install isn't a shell script then.) But it is the common case. At the very least copying and setting the permissions is the common case, mkdir is very common, and the chown comes about often enough. When you have to install a half dozen different files, it adds up. And it's definitely nearly universally available (except on Plan 9) despite not being defined by POSIX, but you're right about the incompatibilities-though they don't really matter if you don't try anything fancy. Thanks for the explanations. meillo
Re: [dev] Is there a reason to use install(1)?
[2010-05-30 00:29] Moritz Wilhelmy c...@wzff.de You mean, install is just meant as a wrapper around the standard tools to express the actions in a more compact way. (btw: It's a shame that install isn't a shell script then.) Well. why isn't man(1) a shell-script? It used to be. (And it should still be.) And what about the dozens of other tools which could be trivially implemented in sh? They aren't implemented in sh because many people care about other things. Gancarz probably should have wrote his book earlier. He includes an excellent chapter on writing as much as possible in sh. But, how did you feel when you, for the first time, heard Gancarz advising you to do so? Haven't you wanted to argue on this case first? some loop over the directories in $MANPATH to look for the manpage, nroff -man $f | $PAGER Even the BSDs have man as a binary program. BSDs tend to optimize for performance. Maybe they even were the first to introduce man as a binary program, but this is just a guess. meillo
Re: [dev] Is there a reason to use install(1)?
[2010-05-29 23:37] Ethan Grammatikidis eeke...@fastmail.fm This didn't seem to reach the list the first time, resending to check if it's a glitch. The mail already reached the list the first time. See: http://lists.suckless.org/dev/1005/4394.html meillo
[dev] Is there a reason to use install(1)?
Very often I see makefile use install(1) when cp, mkdir, chmod, and Co. would be equally compact. Is there any reason why someone should use install(1) instead of the standard Unix tools? Install(1) isn't available everywhere and AFAIR there are incompatible versions, too. There are several reasons not to use it, but are there ones that encourage using it? I know, we don't use it, but there might be advantages of it, though. These I would like to know. meillo
Re: [dev] Is there a reason to use install(1)?
[2010-05-29 23:46] Moritz Wilhelmy c...@wzff.de Very often I see makefile use install(1) when cp, mkdir, chmod, and Co. would be equally compact. Consider install -D -m755 -u foo -g bar foo.sh $DESTDIR/usr/bin vs. mkdir -p $DESTDIR/usr/bin cp foo.sh $DESTDIR/usr/bin chmod 755 $DESTDIR/usr/bin/foo.sh chown foo:bar $DESTDIR/usr/bin/foo.sh and tell me about equally compact again... I know about such cases, but this is not the common case, at least as far as I've seen it. You mean, install is just meant as a wrapper around the standard tools to express the actions in a more compact way. (btw: It's a shame that install isn't a shell script then.) meillo
Re: [dev] vimium extension for chromium
[2010-05-19 08:58] Niki Yoshiuchi aplu...@gmail.com On Wed, May 19, 2010 at 8:02 AM, Marvin Vek l...@onedot.nl wrote: On Wed, May 19, 2010 at 12:07:31PM +0200, markus schnalke wrote: Vimium and surf are very different; I see hardly any similarity. With s/surf/vimperator/ I can agree. Vimperator had version 0.4 released 30th of April 2007. First Surf commit i see was 11 months ago. I'd say the Surf people are cloning Vimperator. I think he meant that vimium was copying vimperator, as s// typically overwrites the former with the latter. Correct. meillo
[dev] [OT] Preferred way of branching in hg
Hoi, I have a project that is kept in a mercurial repo. Now I plan to branch a development version off. This means, I (1) want to go on fixing bugs in the stable version, and (2) want to start redesigning parts of the code base in a development branch. I want to branch as the development version might break or remove functionality which should be kept alive in the stable version. Steve Losh discussed the available approaches to branching on http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial From my current point of view, branching by cloning apprears to be preferrable. What are your opinions? meillo
Re: [dev] [surf] A debian package?
[2010-05-06 22:58] julien.steinhau...@orange.fr On Thu, May 06, 2010 at 08:59:54AM +0200, Troels Henriksen wrote: When is a Debian package of surf useful? For demo usage i guess, as for the dwm package. Ever heard of apt-get source foo ? You get the debianized sources this way. You can costumize them and rebuild a customized package that you install. Even if binary packages would be hardly useful, a Debian package provides debianized sources too. meillo
Re: [dev] Anyone have the traditional vi working on the xterm?
[2010-04-17 14:34] pmarin pacog...@gmail.com
I fixed the problem. The preprocesor definitions in the setsize
function (ex_tty.c) are hilarious.
I wrote a setsize function that works only with TIOCGWINSZ.
void
setsize(void)
{
...
}
#ifdef stuff is harmful.
Could you please explain what exactly the problem was.
Because I have ex-vi ``Version 4.0 (gritter) 3/25/05'' here and it
resizes without problem in xterm. Now I wonder what the differences to
your installation are.
meillo
Re: [dev] sed 10q or sed 11q
[2010-04-12 13:30] Szabolcs Nagy nszabo...@gmail.com On 4/12/10, Uriel lost.gob...@gmail.com wrote: What is your question? he just pointed out that 'sed 11q' incorrectly listed as an alternative to 'head' on cat-v (the correct alternative would be 'sed 10q') Correct. Thanks to all who replied. Now I understand, why one might want to use 11q instead of 10q. but it's a minor detail.. Nonetheless I think it should be changed to 10q on the harmful website, because that's the correct replacement. But, I agree that it is only a detail, actually. meillo
[dev] sed 10q or sed 11q
We don't need head(1) because we have sed(1). But do we get the first ten lines with sed 10q or with sed 11q ? I am a bit confused, currently. All sed implementation I had access to printed 10 lines with 10q. It were from: - GNU - Heirloom (sv3, s42, posix, posix2001) - SunOS (/usr/bin/sed, /usr/ucb/sed, /usr/xpg4/bin/sed) - 9base The man page of 9base's sed even says: ``sed 10q file -- Print the first 10 lines of the file.'' The Unix Programming Environment also writes: ``So it's easy to write a sed program that will print the first three (say) lines of its input, then quit: sed 3q.'' (page 110) Now I actually must assume, Uriel might be wrong. *eek* See http://harmful.cat-v.org/software/ But is this possible? Or does it Plan9 different and 9base didn't keep the semantics? Can someone please check Plan9's sed. meillo
Re: [dev][surf]
[2010-04-07 18:22] Bjartur Thorlacius svartma...@gmail.com The problem is that surf is both a HTTP-client (a downloader) and a HTML-renderer. When you only want to download HTML-files from HTTP and render instantly, this isn't a problem. But when you only want to use the downloader; things get harder and you'll have to use some weird tricks. If surf could be reduced to something like: GET $URI | html2text | more like I used myself, but the problem is that we need to enable link-following (which is the core feature of a web browser). GET $URI | html2markdown | markshow # could use rST This though needs reparsing of markdown which doesn't make sense on second thought. see `getter $IRI` # or see $(getter) where getter downloads the resource which the IRI which $IRI references references and returns a reference (filename) to the downloaded file and the media-type thereof (the referenced file ;). Preferably one would make a pager which supports links (think `more` with numbered links). Hubbub could be used to parse and sanitize the HTML and convert it to a simple (to reparse) clean format possibly containing some style information. If this format might turn out to be (X)HTML (isn't HTML-parsing faster in existing browsers because of optimizations?) Hubbub could be linked directly to the pager. Making a simple renderer, based on e.g. Dillo or WebCore/WebKit, which accepts a HTML-file would might be easier though. Any volunteers? The idea is nice, but this approach will hardly work with today's broken web. The web technology originally allowed such approaches, but now it is so heavily abused, that web browsers must suck. meillo
Re: [dev] Re: stali and OpenBSD userland etc.
[2010-04-10 17:12] finkler fink...@officinamentis.org On 04/10/10 16:14, Kurt H Maier wrote: On Sat, Apr 10, 2010 at 7:13 AM, finkler fink...@officinamentis.org wrote: And this is what is missing in OBSD: chown having a hard time believing this I was kind of surprised myself, but I simply can't find it in their CVS tree [1]. Maybe I have overlooked something? 1: http://www.openbsd.org/cgi-bin/cvsweb/src/ Chown is an additional name for chmod; so is chgrp. See Makefile in: http://www.openbsd.org/cgi-bin/cvsweb/src/bin/chmod/ meillo
[dev] OT: perpendicular universe
SCNR to write this mail. Origin: A perpendicular universe. Have you read Uncyclopedia's article about it? http://uncyclopedia.wikia.com/wiki/Perpendicular_Universe It made my day! :-) meillo
Re: [dev] [surf] Dependency on modifier keys
[2010-02-23 14:19] Sean Whitton s...@silentflame.com On Tue, Feb 23, 2010 at 01:57:17PM +0100, markus schnalke wrote: I used surf for several weeks last year. I had the same problem, so I hacked a mode interface like vi has. It is just a quick hack, it is outdated, and I don't use it anymore, but maybe it helps. Thanks for that. I've cleaned up the patch to be sure it works with 0.3, and I've removed all the other things - anyone who is interested will find it attached. Thanks for cleaning it up. :-) meillo
Re: [dev] [surf] Dependency on modifier keys
[2010-02-23 14:38] Sean Whitton s...@silentflame.com
On Tue, Feb 23, 2010 at 02:19:10PM +, Sean Whitton wrote:
Thanks for that. I've cleaned up the patch to be sure it works with
0.3, and I've removed all the other things - anyone who is interested
will find it attached.
This patch has broken my zoom and scrolling keys; now j and k just zoom,
and nothing scrolls.
This might be caused by your settings in config.h . Of course one
needs to adjust the keymappings too.
I attach my config.h to show a possible key setup. Be aware it is for
an outdated version of surf.
meillo
/* modifier 0 means no modifier */
static char *useragent = Mozilla/5.0 (X11; U; Linux; en-us) AppleWebKit/531.2+ (KHTML, like Gecko, surf-VERSION) Safari/531.2+;
static char *progress = #00;
static char *progress_trust = #00FF00;
static char *stylefile = .surf/style.css;
static char *scriptfile = .surf/script.js;
static char *cookiefile = .surf/cookies.txt;
static char *dldir = .surf/dl;
static time_t sessiontime = 3600;
char* cmd_seturi[] = { /bin/sh, -c,
xprop -id $1 -f $0 8s -set $0 `echo -n \\`xprop -id $1
| awk '/^_SURF_URI/{print substr($NF, 2, length($NF)-2)}'\\`
| dmenu -l 2 || exit 0`,
_SURF_URI, winid, NULL
};
#define SETPROP(p) { .v = (char *[]){ /bin/sh, -c, \
xprop -id $1 -f $0 8s -set $0 `echo -n \\`xprop -id $1 \
| awk '/^_SURF_URI/{print substr($NF, 2, length($NF)-2)}'\\` \
| dmenu -l 2 || exit 0`, \
p, winid, NULL } }
#define MODKEY GDK_CONTROL_MASK
static Key keys[] = {
/* modifier keyval functionarg Focus */
{ 0, GDK_o, spawn, SETPROP(_SURF_URI) },
/*{ 0, GDK_O, newwindow, { .v = NULL } },*/
{ 0, GDK_O, newwindow, { 0 } },
{ 0, GDK_Escape, stop, { 0 } },
{ 0, GDK_i, insert, { .v = NULL } },
{ 0, GDK_s, stop, { 0 } },
{ 0, GDK_R, reload, { .b = TRUE } },
{ 0, GDK_r, reload, { .b = FALSE } },
{ 0, GDK_p, clipboard, { .b = TRUE } },
{ 0, GDK_y, clipboard, { .b = FALSE } },
{ 0, GDK_minus, zoom, { .i = -1 } },
{ 0, GDK_plus, zoom, { .i = +1 } },
{ 0, GDK_0, zoom, { .i = 0 } },
{ 0, GDK_f, navigate, { .i = +1 } },
{ 0, GDK_b, navigate, { .i = -1 } },
{ 0, GDK_j, scroll, { .i = +1 } },
{ 0, GDK_k, scroll, { .i = -1 } },
{ 0, GDK_G, scroll, { .i = +1 } },
{ 0, GDK_g, scroll, { .i = -1 } },
{ 0, GDK_space, scroll, { .i = +100 } },
{ 0, GDK_slash, spawn, SETPROP(_SURF_FIND) },
{ 0, GDK_n, find, { .b = TRUE } },
{ 0, GDK_N, find, { .b = FALSE } },
};
static Item items[] = {
{ Back, navigate, { .i = -1 } },
{ New Window, newwindow, { .v = NULL } },
};
/*
{ Reload, reload,{ .b = FALSE } },
{ Stop, stop, { 0 } },
{ Forward,navigate, { .i = +1 } },
{ Copy URI, clipboard, { .b = FALSE } },
{ Paste URI, clipboard, { .b = TRUE } },
*/
Re: [dev] [surf] Dependency on modifier keys
[2010-02-23 23:06] Sean Whitton s...@silentflame.com It seems that with this patch you can no longer differentiate between Mod-Shift-j and j - or even Mod-j. Certainly not in the way I was doing it. I've moved things around to get it to work but this may be a problem with the patch. That is likely true. I did not use modification keys, except of shift which is handled (by gtk?) internally. Actually, this hack had the purpose *to get rid of* modification keys. ;-) meillo
Re: [dev] [ot] nmh mime pgp
[2010-02-18 16:03] Yoshi Rokuko yoshi.rok...@yokuts.org some time ago there was a discussion about suckless MUAs and some mentioned nmh, i like nmh so far. but i must be able to read encrypted mail and i found some stuff for nmh like rbmhshow, but rbmhshow-0.4.2 does not work out of the box for me. so before i take a look into it, i wanted to ask what you guys use if you use nmh. I use nmh. But I do not encrypt. For the rare cases when I receive an encrypted mail though, I decrypt with `gpg -d'. You might want to search in the nmh-workers mailing list archive for helpful information. There could be some. Or contact the author of rbmhshow. meillo
Re: [dev] [dwm] sdl12 / dwm 5.6 /5.7.2 ioquake3 problems
[2010-02-01 09:58] Nicolai Waniek roc...@rochus.net Oh and what he might mean with outline moving: just drawing the outline of a window that is to be moved, looking as if you only move around its border to the window's future position and not actually moving the window until you have decided where to place it. Smooth moving of clients affects only floating mode. Floating mode is mainly a compatibility feature for broken software, and most dwm users will seldom move a client with the mouse in floating mode. As implementing a ``outline moving'' feature adds complexity to dwm, and there is nearly no gain from it, it will hardly appear in dwm. meillo
Re: [dev] [OFFTOPIC] Recommended meta-build system
[2010-02-01 13:06] Anselm R Garbe ans...@garbe.us On 1 February 2010 12:52, jonathan.sl...@talktalk.net wrote: This is my PC and I decide what colours are used. To be fair Uriel isn't completely wrong. In an ideal world everyone would just use the software as is and not waste time on fiddling around with colors and such. But obviously a lot of people like customizing things/making them different to the default. I'm not sure what the reason is [...] Reasons to change the colors are that this may improve your productivity or comfort. The point it, that colors are nearly completely unrelated to the functionality of the program. They are only cosmetic, and thus everthing related to them should not add complexity in any way. I'd adjust the colors on my computer though, but by editing the code directly. But tagging rules are an example of custumization of dwm, that does not directly changes it's functions, but how it operates in the specific environment. This is similar to mailcap, termcap and the like. In my eyes, this is where ``configuration'' is important. (In contrast to colors, which are only cosmetic, and layouting algorithms which are basic functionality and thus should be changed in the main source directly, if at all.) meillo
Re: [dev] saving program options
[2010-01-25 02:10] anonymous aim0s...@lavabit.com TAOUP also recommends small programs that do just one thing. If you have so many options that you need a huge structure to store them, that might be a sign that your program is overly complex. Consider factoring it into a set of smaller cooperating processes. It is not too big, but there are more than 7 options anyway. What about troff, for example? It is not very small and has more than 7 options. Mind the difference between accidental complexity and essential complexity. (see ``No Silver Bullet'' by Brooks [0]) [0] http://en.wikipedia.org/wiki/No_Silver_Bullet Troff's complexity is mostly essential. (In fact, it is one of the best examples of how to avoid complexity, IMO.) I don't know about your program. If the structures are ``huge'', then you likely chose bad data structures. If they are large and the problem is essentially complex, it might be okay. If the data structures are huge, but the program(s) small, then you might want to use global variables. The advice is easy: Organize your code in a way to make it as simple, clear, and general as possible. IMO, you may use global variables, gotos, and other ``bad stuff'' without shame, *if* you have good reasons for them. Or better: You *should* use this stuff if they help you to make the code more simple. meillo
[dev] gsoc 2010
Are there plans to apply for Google Summer of Code, this year? I ask because I want to apply as student. meillo
Re: [dev] [SLOCK] is not safe
[2010-01-19 12:11] Premysl Hruby dfe...@gmail.com Problem here is not using exec startx or startx exit, not using or not using exec in xinitrc/xsession! I needed some time to get to the sense of the sentence, but now I reached it ... and yes, it's a nice play on words. Thanks, YMMD. meillo
Re: [dev] [DWM] suggestion for dwm
[2010-01-03 13:51] Peter John Hartman peterjohnhart...@gmail.com On Sun, 3 Jan 2010, anonymous wrote: More probabily status bar will be fully removed from dwm then something will be added to it. I agree w/r/t removing the status feature in dwm. (What does ``w/r/t'' mean?) anonymous did not say that he wants the status bar to be removed. If it isn't a trayer, then what is its purpose? The status bar shows the tags, the title of the client, and a user defined text. The first two things are its main purpose. If you want additional functionality, then use additional programs. If you dislike using one tool for one job, then our community is surely not where you belong to. meillo
Re: [dev] slock with non-system auth
[2009-12-19 21:37] pancake panc...@youterm.com I have done two patches for slock. The first simplifying the use of cpp and the other adding user defined password. The password should probably not be a clear text string inside the binary file, as one can easily read it with `strings slock'. Is there a secure hash function in standard C? I think not. Linking some external library for this, seems to be overkill. 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. meillo
Re: [dev] slock with non-system auth
[2009-12-20 12:03] Moritz Wilhelmy c...@wzff.de 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. meillo
Re: [dev] Full quotes below
[2009-12-16 18:11] Jessta jes...@gmail.com 2009/12/12 markus schnalke mei...@marmaro.de: Please refrain from adding full quotes a the end of your reply, it's such a pain to read. Your war will never be won until there is a tool that enforces it and then people will complain about the tool. Seems you are right. :-( The irony is, that reading this mailing list became a pain when I started using a sane mail client, the one that conforms best to the Unix Philosophy: nmh. meillo
Re: [dev] switch your MUA (was: Full quotes below)
[2009-12-16 13:01] Antoni Grzymala ant...@chopin.edu.pl markus schnalke dixit (2009-12-16, 12:29): You will certainly want to configure nmh extensively to make it fit your needs. It's a bit like dwm where almost everyone has his patches. That's for sure. Seems like I'll have to stick to mutt for the time being, though I've briefly looked at some other solutions like sup [1] and notmuch [2] (I quite the sense of humour around the second project). Still, they're not quite ready to replace the comfortable workflow I have with mutt. Are the programs not ready or are you not ready to do the step? IMO you're habits should not keep you from doing the right thing. If you feel that you really should change something, then do it! Don't use your old setup anymore (you may keep it working as fallback, but better do not). When you are confronted with the new system, then you'll become used to it quickly. meillo
Re: [dev] [dmenu] pasting bug
We could first try sselp and if it not exists run xclip. This should be possible with two exec calls after each other: execlp(sselp, ...); execlp(xclip, ...); Then the second will only be executed when the first fails. meillo
Re: [dev] [dwm] [patch] ALTRU switching tags with LRU
[2009-12-02 13:02] =?ISO-8859-1?Q?M=2E_Huil=E9n_Abed_Moure?= mariahui...@sherekan.com.ar This is a patch [...] Please use diff -u ... next time. meillo
Re: [dev] [surf] editing textboxes with external command
[2009-11-19 18:57] Moritz Wilhelmy c...@wzff.de [...] editing text boxes within an external editor. You took the words right out of my mouth. meillo
Re: [dev] [surf] bug in url changing
[2009-11-17 00:10] Tadeusz =?utf-8?B?U2/Fm25pZXJ6?= tadzi...@gmail.com There is this small bug, not sure if it isn't some dmenu limitation. E.g. when we are on suckless.org/manifest, and then we try to change the uri to suckless.org, surf still puts us to manifest site. No idea how to fix this though. I stumpled across this too. You have to hit Shift-Enter if you want to take exactly the input text. Enter takes the selected item in the list. I thought about how to change the behavior in a nice way, but none came to my mind. meillo
Re: [dev] [OT]: Go programming language
[2009-11-15 16:42] Anselm R Garbe ans...@garbe.us By far the best go-nuts mail I've seen so far was ken's response to the billion dollar mistake yesterday. Can you provide a link please. meillo
Re: [dev] wmii can save settings on close, can't it ?
[2009-11-13 20:00] Yannic Haupenthal m...@thedarkwebsite.de /dev/null Smells like bashism. Use /dev/null 21 instead. meillo
Re: [dev] [OT]: Go programming language
[2009-11-12 02:49] Aled Gest himse...@gmail.com 2009/11/11 Antoni Grzymala ant...@chopin.edu.pl: Looks like you didn't give more than half a minute's time, to see what Lisp's syntax (or rather the lack of it) is actually about. Your hopes are vain. It doesn't take long to judge clarity. Remember: ``Unix is simple. It just takes a genius to understand its simplicity.'' (dmr) As far as I can tell, Lisp's primary features are that everything is a list and that logic/arithmetic is specified in polish notation. Isn't that great? It's like ``everything's a file''. TCL has a similar concept with lists but in my mind has a nicer syntax. You mean: It has a not so strange/different syntax. To be fair I never said there is no cleaner syntax than C, what I said was It's the cleanest and most logical syntax I've come across so far., and I stand by that. I replied: ``Then you never tried Lisp!'' Maybe I should have said: ``Then you never understood Lisp'', which is true. My motivation to post in this thread was to point you to a language that will enhance your view in this discussion. meillo
