Re: [dev] app locations?

[Dimitris Papastamos]

On Mon, Oct 17, 2016 at 10:01:12AM -0400, stephen Turner wrote:
> So i have determined the locations of most of sbase and ubase using
> the linux FHS [0]. I have a few that needs categories for the legacy
> style linux and was hoping someone would have a few pointers. I
> offered my thoughts based on the FHS description of the directories,
> correct me if I'm wrong. Thanks for any help or pointers.
> 
> /usr/sbin/
> fallocate
> lastlog
> fsfreeze
> vtallow
> respawn
> swaplabel
> unshare
> 
> /usr/bin
> truncate
> sponge
> 
> 
> [0] http://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html

everything in /bin

Re: [dev] Allow secure access to Web site suckless.org

[Dimitris Papastamos]

On Wed, Aug 03, 2016 at 01:20:32PM +0200, FRIGN wrote:
> On Wed, 3 Aug 2016 13:10:06 +0200
> hiro <23h...@gmail.com> wrote:
> 
> > are you claiming Let's Encrypt is trustworthy?!
> 
> However, to add to my previous point, I like the automated process for
> Let's Encrypt, and it adds more trust than just connecting over HTTP.
> 
> The 100% ideal way would be to do onion stuff, but how many people are
> really using Tor to browse the web? Let alone to download tarballs and
> stuff. For the majority, an "inferior" solution which can be
> troublesome in some cases but still provides another layer of security
> is in my opinion favorable. Dimitris already set up Let's Encrypt on
> 2f30.org, maybe he can help set things up for suckless.org. :)

I did set it up for the first few months but then was too lazy to
renew it.

Re: [dev] [noice] with musl

[Dimitris Papastamos]

On Mon, Jul 18, 2016 at 02:09:02PM +0300, Cág wrote:
> > did you try recompiling with "-fPIC"?
> 
> I am not sure where to put it, so I did it like this
> 
> make CC="gcc -fPIC"
> 
> and it gave the same error.

Try to do a make clean first and then simply make.

Re: [dev] [noice] with musl

[Dimitris Papastamos]

On Mon, Jul 18, 2016 at 02:09:02PM +0300, Cág wrote:
> > did you try recompiling with "-fPIC"?
> 
> I am not sure where to put it, so I did it like this
> 
> make CC="gcc -fPIC"
> 
> and it gave the same error.

noice does not build any shared libraries.  A friend of mine
tried to build it on alpine i686 and it worked.

There's also a port for it:
http://git.alpinelinux.org/cgit/aports/tree/testing/noice

Maybe use abuild to build the port and see what kind of flags are
passed to the compiler and linker.

Re: [dev] [smdev] hotplugging

[Dimitris Papastamos]

On Sat, Jun 25, 2016 at 11:25:50PM +0300, Cág wrote:
> Hi lads,
> 
> Could ye please point me to the right solution? I'm trying to
> replace udev with
> smdev. Typing smdev returns me
> "Environment not set up correctly for hotplugging".

Try echo `which smdev` > /proc/sys/kernel/hotplug
and then run smdev -s.

Re: [dev] [lnanosmtp]

[Dimitris Papastamos]

On Thu, Jun 09, 2016 at 03:41:22PM +0200, FRIGN wrote:
> This is so full of bullshit. There's no reason e.g. not to make it
> compilable on the BSD's. The Linux syscall-interface is also prone
> to changes.

If the Linux syscall interface changes in a non backwards-compat manner
then it is consider a bug.  This is unlike to what happens in the BSD
world.

Regardless though, not using libc for such a project is just stubborn
and inflexible.

Re: [dev] [slock] [PATCH] Ctrl-u now resets the input

[Dimitris Papastamos]

On Wed, Jun 08, 2016 at 09:55:38AM +0200, Anselm R Garbe wrote:
> Hi Troy,
> 
> I'm not sure if this feature is really required. Typing a wrong
> password can be corrected on second attempt anyways.
> 
> What is the opinion of other users to this change?

I don't think it is necessary for slock.  I am used to typing
C-u in login(1) because some annoying implementations will delay
further input on an incorrect attempt for a few seconds.

Most of the time I know I've made an error when typing the password
before I type return.

Re: [dev] [dwm] under NetBSD

[Dimitris Papastamos]

On Tue, May 03, 2016 at 03:52:50PM +0300, Mitt Green wrote:
> Hi,
> 
> I adjusted paths in config.mk:
> X11INC = /usr/X11R7/include
> X11LIB = /usr/X11R7/lib
> FREETYPEINC = ${X11INC}/freetype2‎
> 
> It compiles successfully, but startx/xinitrc
> show me X for a second and then it goes
> back to tty.
> 
> Typing dwm from tty gives
> 'Shared object "libX11.so.7" not found'
> 
> libX11.so.7 is in /usr/X11R7/lib (result of find).
> NetBSD is similar to OpenBSD, I believe, at least
> in this case.
> 
> Any help will be highly appreciated.
> 
> P.S. X works fine, I've tried Openbox.
> 
> / Mitt

http://www.netbsd.org/docs/elf.html#elf-rpath

Re: [dev] a few questions about watch in ubase

[Dimitris Papastamos]

On Thu, Apr 21, 2016 at 02:04:43PM -0400, Greg Reagle wrote:
> Please excuse me if these questions are rudimentary.  I am using Debian
> Stable.
> 
> Why is watch linked with the crypt library?
>   cc -s -o watch watch.o libutil.a -lcrypt
> It does not seem to need it.

watch does not use anything from libcrypt but other tools in ubase do.
It is just a convenience to be able to specify the libs once and not per
tool.

> watch uses "\x1b[2J\x1b[H" to clear the screen, which are the two control
> codes Erase Screen and Cursor Home.  These seem to be ANSI escape control
> codes.
> 
> Is it appropriate to use ANSI escape codes in the program rather than using
> something like tput or terminfo, or to just execute the "clear" command?
> Are the escape codes portable?

They are portable for ansi terminals.

Re: [dev] [lnanohttp] nanonimal http server for linux

[Dimitris Papastamos]

On Thu, Apr 21, 2016 at 01:18:12AM +1100, Sylvain BERTRAND wrote:
> On Wed, Apr 20, 2016 at 03:09:20PM +0100, Dimitris Papastamos wrote:
> > On Thu, Apr 21, 2016 at 12:22:42AM +1100, Sylvain BERTRAND wrote:
> > > On Wed, Apr 20, 2016 at 09:39:43AM +0100, Dimitris Papastamos wrote:
> > > > On Wed, Apr 20, 2016 at 07:05:09PM +1100, Sylvain BERTRAND wrote:
> > > > > quark pulls the posix libc. lnanohttp has 0 deps: this is straight 
> > > > > linux
> > > > > syscalls programming, there are no libc syscall wrappers.
> > > > 
> > > > What's wrong with libc?
> > > 
> > > Overkill, don't need it. 
> > > 
> > 
> > You should have revived kHTTPd[0] instead.
> > 
> > [0] http://www.fenrus.demon.nl/
> 
> Mine is user space. This one is kernel space.

You don't understand humour.

Re: [dev] [lnanohttp] nanonimal http server for linux

[Dimitris Papastamos]

On Wed, Apr 20, 2016 at 07:05:09PM +1100, Sylvain BERTRAND wrote:
> quark pulls the posix libc. lnanohttp has 0 deps: this is straight linux
> syscalls programming, there are no libc syscall wrappers.

What's wrong with libc?

Re: [dev] [ANNOUNCE] flao: simple FLAC audio player

[Dimitris Papastamos]

On Sat, Apr 16, 2016 at 04:39:22PM -0400, Wolfgang Corcoran-Mathe wrote:
> Hi all,
> 
> I have been working on a CLI player for FLAC[0] audio files intended
> as a replacement for the old and crufty flac123[1].  It is about 230
> SLOC and includes the minimum amount of FLAC insanity necessary to
> play music.
> 
> 
> ## Repo
> 
> git://git.sigwinch.xyz/flao.git

Nice!  Consider adding -I/usr/local/include and -L/usr/local/lib to
INCS and LIBS respectively.  This allows it to compile on BSD as well.

Re: [dev] [dwm] bad line in config.mk?

[Dimitris Papastamos]

On Sat, Apr 09, 2016 at 12:13:44AM +0545, Neeraj Adhikari wrote:
> Hi,
> 
> I downloaded the dwm-6.1 tarball and tried to compile but it failed
> with the error message that ft2build.h was not found. When I looked at
> config.mk, The line below immediately below "# OpenBSD (uncomment)"
> that changes the include path for freetype2 was not commented by
> default, causing the build to break. Commented that line, and dwm
> compilled fine. Can this be called a bug?

It was an oversight when the tarball was created.  We cannot go back
in time and fix this.

It is already fixed in HEAD.

Re: [dev] [dmenu] versioning and patching

[Dimitris Papastamos]

On Mon, Mar 14, 2016 at 07:25:22PM -0700, Eric Pruitt wrote:
> On Mon, Mar 14, 2016 at 08:12:17PM -0600, Anthony J. Bentley wrote:
> > Boruch Baum writes:
> > > 1] I want to request that dmenu produce 'correct' output for its
> > > --version command. Currently, the ouput is identical to --help ouput and
> > > gives no version information at all.
> >
> > --help and --version give the same output because they're both
> > invalid options.
> 
> With the possible exception of ubase, do any of the suckless projects
> support (GNU?) long options? A lot of suckless projects aim to be
> portable and use a modified version of plan9's arg.h to parse arguments
> which means there's no support for long options.

ubase doesn't support long options.

Re: [dev] Re: [sbase] [PATCH] sort: Fix -u option

[Dimitris Papastamos]

On Sat, Mar 12, 2016 at 03:48:13PM -0800, Michael Forney wrote:
> On Sat, Mar 12, 2016 at 11:46:31AM -0800, Michael Forney wrote:
> > In eb9bda878736344d1bef06d42e57e96de542a663, a bug was introduced in the
> > handling of -1 return values from getline. Since the type of the len
> > field in struct line is unsigned, the break condition was never true.
> > This caused sort -u to never succeed.
> 
> This should be "sort -c" (here and in subject).
> 
> Please amend before committing.

Thanks, applied!

Re: [dev] [bug][dwm] Fullscreen youtube after tag switch in 6.1

[Dimitris Papastamos]

On Sun, Mar 06, 2016 at 01:18:57PM -0300, Carlos Pita wrote:
> > Flash is very much a technical problem. Binary blob, catastrophic
> > security record, X11 support is a giant hack (render a window on top of
> > the page), absolutely non-portable outside of a few common
> > OS+architecture combinations, want me to go on?
> 
> I don't care about flash at all. I just reported a problem I found.

The bug report sucked.  There is no indication this is a bug in dwm.

Re: [dev] [sbase][bug] cat -u is not unbuffered

[Dimitris Papastamos]

On Tue, Mar 01, 2016 at 12:23:52AM -0600, Ryan Wilson wrote:
> So I was studying sbase and found a bug in cat. POSIX says that cat -u should 
> "Write bytes from the input file to the standard output without delay as each 
> is read." But if you try feeding cat input slowly you can see this is not the 
> case:
> 
> # Feed one byte per second to cat:
> $ yes | pv -q -L1 | ./cat -u
> 
> 
> It should print one byte per second, but instead it hangs. Running it under 
> ltrace -S reveals the problem:
> 
> __libc_start_main(0x804877a, 2, 0xbff42644, 0x8048c10 
> setbuf(0xb7728d40, 0)= 
> 
> fread(0xbff4054c, 1, 8192, 0xb7728580 
> SYS_read(8192, "y", 3076835683)  = 1
> SYS_read(4096, "\n", 3076835683) = 1
> SYS_read(4096, "y", 3076835683)  = 1
> SYS_read(4096, "\n", 3076835683) = 1
> SYS_read(4096, "y", 3076835683)  = 1
> SYS_read(4096, "\n", 3076835683) = 1
> 
> cat disabled stdio buffering for stdout, but that is not sufficient. Input is 
> still buffered because fread blocks until it can fill the entire 8192 byte 
> buffer. Note that setbuf(stdin, NULL) is no fix either, because fread still 
> wants to fill the entire buffer you give it.
> 
> The fix is to either:
> 
> * Do a getchar/putchar loop and copy one byte at a time. Sucks, but that's 
> the only way to not block on reads with stdio. That's how cat originally did 
> it in Unix v7, and that's how the BSDs still do it for certain options.
> * Do a read(2)/write(2) loop. That's what concat() did until commit c0d36e00, 
> but the problem is other things use concat() and its not safe for them to mix 
> raw IO with stdio IO.
> 
> Thoughts?

Thanks for the report, this has been fixed on HEAD.

Re: [dev] suckless shared tools

[Dimitris Papastamos]

On Sat, Feb 27, 2016 at 03:56:25PM -0300, Marc Collin wrote:
> Hello,
> A few days ago arg.h was update on sbase to fix an out-of bounds error.
> After that the same error was fixed (some sooner some later) on lots
> of other projects that also have arg.h like ubase, slock, dmenu, st,
> and others. And many tools that use arg.h are still not fixed. Isn't
> this bad for maintenance? Couldn't projects import arg.h and similar
> tools from another repository and then only 1 place have to be fixed
> to everyone benefit? Or a script that can be run to automatically sync
> all arg.h on git.suckless.org with the master version?
> Thanks.

Send patches.

Re: [dev] [sbase][PATCH] Add factor(1)

[Dimitris Papastamos]

On Fri, Feb 26, 2016 at 12:48:09PM +0100, Jens Staal wrote:
> On 2016 M02 26, Fri 09:11:20 CET Mattias Andrée wrote:
> > I'm actually using factor. And it is in base systems, so
> > I think it should be included, but I will be simplifying
> > it.
> 
> What about including it in ubase instead?

That would be misleading.

Re: [dev] [sbase][PATCH] Add factor(1)

[Dimitris Papastamos]

On Fri, Feb 26, 2016 at 12:45:27PM +0100, Mattias Andrée wrote:
> On Fri, 26 Feb 2016 11:39:07 +
> Dimitris Papastamos <s...@2f30.org> wrote:
> 
> > On Fri, Feb 26, 2016 at 12:33:37PM +0100, Mattias Andrée
> > wrote:
> > > On Fri, 26 Feb 2016 11:31:31 +
> > > Dimitris Papastamos <s...@2f30.org> wrote:
> > >   
> > > > On Fri, Feb 26, 2016 at 12:28:32PM +0100, Mattias
> > > > Andrée wrote:  
> > > > > On Fri, 26 Feb 2016 11:26:15 +
> > > > > Dimitris Papastamos <s...@2f30.org> wrote:
> > > > > 
> > > > > > On Fri, Feb 26, 2016 at 12:19:32PM +0100, Mattias
> > > > > > Andrée wrote:
> > > > > > > On Fri, 26 Feb 2016 10:07:31 +
> > > > > > > Dimitris Papastamos <s...@2f30.org> wrote:
> > > > > > >   
> > > > > > > > On Fri, Feb 26, 2016 at 09:47:14AM +0100,
> > > > > > > > Mattias Andrée wrote:  
> > > > > > > > > On Fri, 26 Feb 2016 09:43:02 +0100
> > > > > > > > > FRIGN <d...@frign.de> wrote:
> > > > > > > > > 
> > > > > > > > > > On Fri, 26 Feb 2016 09:37:12 +0100
> > > > > > > > > > Mattias Andrée <maand...@kth.se> wrote:
> > > > > > > > > > 
> > > > > > > > > > Hey Mattias,
> > > > > > > > > > 
> > > > > > > > > > > Mostly random things, but regularly
> > > > > > > > > > > when I correct maths tests.  
> > > > > > > > > > 
> > > > > > > > > > do the primes you ask your students to
> > > > > > > > > > study fit in 64 bits?
> > > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > Yes. But sometimes the primes I factor do
> > > > > > > > > not.
> > > > > > > > 
> > > > > > > > Write a dc(1) script!  
> > > > > > 
> > > > > > man dc
> > > > > > 
> > > > > 
> > > > > I know, but why?
> > > > 
> > > > Because it can already handle arbitrary precision
> > > > arithmetic.
> > > >   
> > > 
> > > I'm lost. Do you think factor(1) shall be implemented
> > > as a dc(1) script in sbase?  
> > 
> > No, as I already mentioned earlier, I don't want factor(1)
> > in sbase at this point in time.  We can revisit this when
> > we have a dc implementation.
> > 
> > This was just a suggestion at an alternative way of
> > implementing factor by just relying on existing POSIX
> > utilities and without having to implement your own bignum
> > code.
> > 
> 
> How are you going to implement dc without writing your
> own bignum code? Either, we use an existing bignum, write
> our own, or do not implement either of factor(1), dc(1),
> and bc(1). And if we are not going to implement them, then
> GNU factor will do.
> 

dc is a general purpose language, factor isn't.  If you want to focus
on something more meaningful for sbase, consider writing a small
bignum library that can be used with the future sbase dc.  We can then
decide if factor should be implemented on top of dc or using this
bignum library.

In any case, dc is a needed utility for sbase, factor isn't so I can
provide no promises on factor inclusion.

Re: [dev] [sbase][PATCH] Add factor(1)

[Dimitris Papastamos]

On Fri, Feb 26, 2016 at 12:33:37PM +0100, Mattias Andrée wrote:
> On Fri, 26 Feb 2016 11:31:31 +
> Dimitris Papastamos <s...@2f30.org> wrote:
> 
> > On Fri, Feb 26, 2016 at 12:28:32PM +0100, Mattias Andrée
> > wrote:
> > > On Fri, 26 Feb 2016 11:26:15 +
> > > Dimitris Papastamos <s...@2f30.org> wrote:
> > >   
> > > > On Fri, Feb 26, 2016 at 12:19:32PM +0100, Mattias
> > > > Andrée wrote:  
> > > > > On Fri, 26 Feb 2016 10:07:31 +
> > > > > Dimitris Papastamos <s...@2f30.org> wrote:
> > > > > 
> > > > > > On Fri, Feb 26, 2016 at 09:47:14AM +0100, Mattias
> > > > > > Andrée wrote:
> > > > > > > On Fri, 26 Feb 2016 09:43:02 +0100
> > > > > > > FRIGN <d...@frign.de> wrote:
> > > > > > >   
> > > > > > > > On Fri, 26 Feb 2016 09:37:12 +0100
> > > > > > > > Mattias Andrée <maand...@kth.se> wrote:
> > > > > > > > 
> > > > > > > > Hey Mattias,
> > > > > > > >   
> > > > > > > > > Mostly random things, but regularly when I
> > > > > > > > > correct maths tests.
> > > > > > > > 
> > > > > > > > do the primes you ask your students to study
> > > > > > > > fit in 64 bits?
> > > > > > > >   
> > > > > > > 
> > > > > > > Yes. But sometimes the primes I factor do
> > > > > > > not.  
> > > > > > 
> > > > > > Write a dc(1) script!
> > > > 
> > > > man dc
> > > >   
> > > 
> > > I know, but why?  
> > 
> > Because it can already handle arbitrary precision
> > arithmetic.
> > 
> 
> I'm lost. Do you think factor(1) shall be implemented as a
> dc(1) script in sbase?

No, as I already mentioned earlier, I don't want factor(1)
in sbase at this point in time.  We can revisit this when we have
a dc implementation.

This was just a suggestion at an alternative way of implementing
factor by just relying on existing POSIX utilities and without having
to implement your own bignum code.

Re: [dev] [sbase][PATCH] Add factor(1)

[Dimitris Papastamos]

On Fri, Feb 26, 2016 at 12:28:32PM +0100, Mattias Andrée wrote:
> On Fri, 26 Feb 2016 11:26:15 +
> Dimitris Papastamos <s...@2f30.org> wrote:
> 
> > On Fri, Feb 26, 2016 at 12:19:32PM +0100, Mattias Andrée
> > wrote:
> > > On Fri, 26 Feb 2016 10:07:31 +
> > > Dimitris Papastamos <s...@2f30.org> wrote:
> > >   
> > > > On Fri, Feb 26, 2016 at 09:47:14AM +0100, Mattias
> > > > Andrée wrote:  
> > > > > On Fri, 26 Feb 2016 09:43:02 +0100
> > > > > FRIGN <d...@frign.de> wrote:
> > > > > 
> > > > > > On Fri, 26 Feb 2016 09:37:12 +0100
> > > > > > Mattias Andrée <maand...@kth.se> wrote:
> > > > > > 
> > > > > > Hey Mattias,
> > > > > > 
> > > > > > > Mostly random things, but regularly when I
> > > > > > > correct maths tests.  
> > > > > > 
> > > > > > do the primes you ask your students to study fit
> > > > > > in 64 bits?
> > > > > > 
> > > > > 
> > > > > Yes. But sometimes the primes I factor do not.
> > > > 
> > > > Write a dc(1) script!  
> > 
> > man dc
> > 
> 
> I know, but why?

Because it can already handle arbitrary precision arithmetic.

Re: [dev] [sbase][PATCH] Add factor(1)

[Dimitris Papastamos]

On Fri, Feb 26, 2016 at 12:19:32PM +0100, Mattias Andrée wrote:
> On Fri, 26 Feb 2016 10:07:31 +
> Dimitris Papastamos <s...@2f30.org> wrote:
> 
> > On Fri, Feb 26, 2016 at 09:47:14AM +0100, Mattias Andrée
> > wrote:
> > > On Fri, 26 Feb 2016 09:43:02 +0100
> > > FRIGN <d...@frign.de> wrote:
> > >   
> > > > On Fri, 26 Feb 2016 09:37:12 +0100
> > > > Mattias Andrée <maand...@kth.se> wrote:
> > > > 
> > > > Hey Mattias,
> > > >   
> > > > > Mostly random things, but regularly when I correct
> > > > > maths tests.
> > > > 
> > > > do the primes you ask your students to study fit in 64
> > > > bits?
> > > >   
> > > 
> > > Yes. But sometimes the primes I factor do not.  
> > 
> > Write a dc(1) script!

man dc

Re: [dev] [sbase][PATCH] Add factor(1)

[Dimitris Papastamos]

On Fri, Feb 26, 2016 at 09:47:14AM +0100, Mattias Andrée wrote:
> On Fri, 26 Feb 2016 09:43:02 +0100
> FRIGN  wrote:
> 
> > On Fri, 26 Feb 2016 09:37:12 +0100
> > Mattias Andrée  wrote:
> > 
> > Hey Mattias,
> > 
> > > Mostly random things, but regularly when I correct maths
> > > tests.  
> > 
> > do the primes you ask your students to study fit in 64
> > bits?
> > 
> 
> Yes. But sometimes the primes I factor do not.

Write a dc(1) script!

Re: [dev] [sbase][PATCH] Add factor(1)

[Dimitris Papastamos]

We don't need a factor implementation in sbase.  In the future, if you
are unsure on whether a particular tool is needed or to avoid duplicated
effort in case someone else is working on it, ask on the mailing list
first.

Re: [dev] [sbase][RFC] patch: whitespace patches

[Dimitris Papastamos]

On Thu, Feb 25, 2016 at 02:42:42PM +0100, Mattias Andrée wrote:
> On Thu, 25 Feb 2016 14:11:05 +0100
> FRIGN  wrote:
> 
> > On Thu, 25 Feb 2016 13:39:30 +0100
> > Mattias Andrée  wrote:
> > 
> > Hey Matthias,
> > 
> > > I think the documentation should be clear that it
> > > only to be relied upon if whitespace changes do
> > > not have any affects. Perhaps it should not allow
> > > introducing whitespace where there was none,
> > > 
> > >-helloworld
> > >+hello world
> > > 
> > > or removing all whitespace
> > > 
> > >-hello  world !
> > >+helloworld !
> > > 
> > > to protect against changes in strings. This however
> > > does would mean that
> > > 
> > >-a=b*c
> > >+a = b * c
> > > 
> > > would not be allowed either.  
> > 
> > this is insane. Just read the fucking patches and stop
> > handholding the users.
> > 
> > Cheers
> > 
> > FRIGN
> > 
> 
> Whitespace patches can be large. This is to help ensure
> that the user does not miss something in the patch that
> changes the behaviour of the program. Like someone trying
> to sneak in a backdoor or otherwise weaken security.
> Of course the user will be reading the patch to make
> sure that the patch fixes the whitespace correctly.
> 
> So it is not about handholding, but rather a security
> feature.

Currently, the easy way to do that is to build with and without
the patch and run sha1 on the resulting binaries.

Re: [dev] [sbase][RFC] patch: whitespace patches

[Dimitris Papastamos]

On Thu, Feb 25, 2016 at 02:11:05PM +0100, FRIGN wrote:
> On Thu, 25 Feb 2016 13:39:30 +0100
> Mattias Andrée  wrote:
> 
> Hey Matthias,
> 
> > I think the documentation should be clear that it
> > only to be relied upon if whitespace changes do
> > not have any affects. Perhaps it should not allow
> > introducing whitespace where there was none,
> > 
> >-helloworld
> >+hello world
> > 
> > or removing all whitespace
> > 
> >-hello  world !
> >+helloworld !
> > 
> > to protect against changes in strings. This however
> > does would mean that
> > 
> >-a=b*c
> >+a = b * c
> > 
> > would not be allowed either.
> 
> this is insane. Just read the fucking patches and stop
> handholding the users.

I don't see how this has to do with handholding users.

Re: [dev] [sbase][RFC] patch: whitespace patches

[Dimitris Papastamos]

On Wed, Feb 24, 2016 at 08:54:13PM +0100, Mattias Andrée wrote:
> Hi!
> 
> I'm working on implementing patch(1). I'm thinking about
> introducing an extension to the standard: -w. When this
> flag is used, patch will verify that the patchfile only
> changes whitespace in the file.
> 
> So I have 2 question.
> 
> 1) Do you think this should be a flag or a separate tool?

Sounds like it could be a flag.
> 
> 2) Should it be able to do a dry run, would be another flag
>that can be used independently of -w?

Yes it would be nice to support a dry run flag regardless of
whether -w is specified or not.

Re: [dev] [sbase][PATCH 2/2] add sha512-224sum (SHA512/224) and sha512-256sum (SHA512/256)

[Dimitris Papastamos]

Thanks for the patches!

I've applied the first.  This one causes a compilation issue with the sbase-box
target because of the '-' in the source file name.  Can you have a look?

Re: [dev] [sbase] missing tool - awk

[Dimitris Papastamos]

On Fri, Feb 19, 2016 at 08:48:51PM -0200, Alba Pompeo wrote:
> Hello.
> I notice awk is in the sbase TODO.
> Why not just import Kernighan's awk[0]? He created the language after
> all. And the program isn't legacy code (last update was on 2012). So
> all looks fine.
> Want to hear what you think.
> Ciao
> [0] http://www.cs.princeton.edu/~bwk/btl.mirror/
> 

I don't want to import an awk implementation.

If you already use sbase on a system and you want awk, you can just
build Kernighan's awk and use it.

I don't see why we need to import it.

Re: [dev] [sbase][PATCH] Add tsort(1)

[Dimitris Papastamos]

On Wed, Feb 17, 2016 at 01:17:33AM +0100, Mattias Andrée wrote:
> Signed-off-by: Mattias Andrée 
> ---
>  Makefile |   1 +
>  README   |   1 +
>  tsort.1  |  72 +
>  tsort.c  | 218 
> +++
>  4 files changed, 292 insertions(+)
>  create mode 100644 tsort.1
>  create mode 100644 tsort.c

Thanks for your work.  I've applied the patch!

Re: [dev] [ANNOUNCE] slock-1.3

[Dimitris Papastamos]

On Mon, Feb 15, 2016 at 11:40:07AM +0100, FRIGN wrote:
> On Mon, 15 Feb 2016 10:55:45 +0100
> Markus Teich  wrote:
> 
> Hey Markus,
> 
> > This is an interesting idea. I would not use it for mainline (users don't 
> > want
> > to change their password in many places), but you can push a patch to the 
> > wiki.
> 
> Dimitris talked about a "third" way to handle passwords on a system, and we
> discussed plans on porting ubase to this new "platform", however, I forgot
> how it was called.
> It could be a way to simplify the slock code though, from what I remember.

http://www.openwall.com/tcb/

this is however outside the control of slock, there is no porting that
needs to be done for ubase to take advantage of this.

this is a system issue, assuming the system is configured to use tcb
and the libc supports it then all programs get it for free.

Re: [dev] [sbase][PATCH] ls: only display directory headers when more than one directory is specified

[Dimitris Papastamos]

Thanks! I've applied the patch.

Re: [dev] [sbase][PATCH] install

[Dimitris Papastamos]

On Thu, Feb 11, 2016 at 12:06:14PM +0100, Mattias Andrée wrote:
> diff --git a/Makefile b/Makefile
> index 1c09cac..b34800d 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -103,6 +103,7 @@ BIN =\
>   getconf\
>   grep\
>   head\
> + install.out\
>   join\
>   hostname\
>   kill\
> @@ -177,6 +178,9 @@ $(OBJ): $(HDR) config.mk
>  .o:
>   $(CC) $(LDFLAGS) -o $@ $< $(LIB)
>  
> +install.out: install.o
> + $(CC) $(LDFLAGS) -o $@ $^ $(LIB)
> +
>  .c.o:
>   $(CC) $(CFLAGS) $(CPPFLAGS) -o $@ -c $<
>  
> @@ -196,13 +200,14 @@ confstr_l.h limits_l.h sysconf_l.h pathconf_l.h: 
> getconf.sh
>  install: all
>   mkdir -p $(DESTDIR)$(PREFIX)/bin
>   cp -f $(BIN) $(DESTDIR)$(PREFIX)/bin
> - cd $(DESTDIR)$(PREFIX)/bin && ln -f test [ && chmod 755 $(BIN)
> + mv -f $(DESTDIR)$(PREFIX)/bin/install.out 
> $(DESTDIR)$(PREFIX)/bin/install
> + cd $(DESTDIR)$(PREFIX)/bin && ln -f test [ && chmod 755 $(BIN:.out=)
>   mkdir -p $(DESTDIR)$(MANPREFIX)/man1
>   for m in $(MAN); do sed "s/^\.Os sbase/.Os sbase $(VERSION)/g" < "$$m" 
> > $(DESTDIR)$(MANPREFIX)/man1/"$$m"; done
>   cd $(DESTDIR)$(MANPREFIX)/man1 && chmod 644 $(MAN)
>  
>  uninstall:
> - cd $(DESTDIR)$(PREFIX)/bin && rm -f $(BIN)
> + cd $(DESTDIR)$(PREFIX)/bin && rm -f $(BIN:.out=)
>   cd $(DESTDIR)$(MANPREFIX)/man1 && rm -f $(MAN)

I tried applying this series but found some problems with the Makefile.

a) you will have to update the sbase-box target, make sbase-box doesn't
   currently work.

b) sbase typically builds with OpenBSD make (and others) as well but
   not with this patch.  make install.out on OpenBSD throws:

   make: don't know how to make install.out.c (prerequisite of: install.out.o)

Re: [dev] [sbase][PATCH] Makefile: uninstall [ command in the uninstall rule

[Dimitris Papastamos]

On Fri, Feb 12, 2016 at 09:45:03AM +0100, Mattias Andrée wrote:
> Signed-off-by: Mattias Andrée 
> ---
>  Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Makefile b/Makefile
> index 1c09cac..1742992 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -202,7 +202,7 @@ install: all
>   cd $(DESTDIR)$(MANPREFIX)/man1 && chmod 644 $(MAN)
>  
>  uninstall:
> - cd $(DESTDIR)$(PREFIX)/bin && rm -f $(BIN)
> + cd $(DESTDIR)$(PREFIX)/bin && rm -f $(BIN) [
>   cd $(DESTDIR)$(MANPREFIX)/man1 && rm -f $(MAN)

Applied!

Re: [dev] [sbase][PATCH] install

[Dimitris Papastamos]

Looks good, thanks!  Some minor comments below.

On Thu, Feb 11, 2016 at 12:06:14PM +0100, Mattias Andrée wrote:
> New command. Includes the flags:
> 
> -s strip binary
> -d create directory
> -D create missing directories
> -t DIR target directory
> -m MODEpermission bits
> -o USERset owner
> -g GROUP   set group
> 
> Installed files are copied, and default mode is 755.
> 
> Signed-off-by: Mattias Andrée 
> ---
>  LICENSE   |   1 +
>  Makefile  |   9 ++-
>  README|   1 +
>  TODO  |   1 -
>  install.c | 259 
> ++
>  5 files changed, 268 insertions(+), 3 deletions(-)
>  create mode 100644 install.c

Missing manpage.

> + install.out\

What is this .out?

> +static void
> +make_dir(char *dir, int was_missing)
> +{
> + if (!mkdir(dir, was_missing ? 0755 : mode)) {
> + if (!was_missing && (lchown(dir, owner, group) < 0))
> + eprintf("lchmod %s:", dir);
> + } else if (errno != EEXIST) {
> + eprintf("mkdir %s:", dir);
> + }
> +}
> +
> +static void
> +make_dirs(char *dir, int was_missing)
> +{
> + char *p;
> + for (p = strchr(dir + (dir[0] == '/'), '/'); p; p = strchr(p + 1, '/')) 
> {
> + *p = '\0';
> + make_dir(dir, was_missing);
> + *p = '/';
> + }
> + make_dir(dir, was_missing);
> +}

Can we use mkdirp() from libutil?

> +static void
> +strip(const char *filename)
> +{
> + pid_t pid = fork();
> + switch (pid)
> + {

Style fix.

> + case -1:
> + perror("fork");
> + exit(EXIT_FAILURE);

Just use eprintf().  We don't use EXIT_* in sbase.

> + if (mflag) {
> + mode = parsemode(mflag, mode, 0);
> + if (mode < 0)
> + return EXIT_FAILURE;

Ditto.

Re: [dev] [sbase][PATCH v2] pathchk

[Dimitris Papastamos]

On Wed, Feb 03, 2016 at 08:12:26PM +0100, Mattias Andrée wrote:
> New command, including man page.
> UTF-8 compatible and should be POSIX-compliant.

Applied, thanks!

Re: [dev] [sbase] install

[Dimitris Papastamos]

On Wed, Feb 03, 2016 at 08:10:50PM +0100, Mattias Andrée wrote:
> I don't really see the point of including install,
> but I assumed there would have been some consensus
> on what to features to include.
> None of implementations have the same flag set, and
> some have incompatible flag sets; and it does not
> bring any feature that the other utilities do not
> offer (some implementations have backup flags, but
> so does some cp implementations.)
> 
> FreeBSD and GNU have some files in common are
> commonly used. I assumes these would be useful
> to make most makefiles working without modifying
> them:
> 
>   -d (mkdir -p)
>   -g GID (select group)
>   -o UID (select owner)
>   -m MODE (select mode)
>   -s (strip)
> 
> (-g and -o are not too commonly used.)
> 
> GNU install also has
> 
>   -D (create missing directories)
>   -t DIR (copy all files into DIR)
> 
> which are used in makefiles from time to time.
> 
> Would anyone object if I implemented install
> with these and only these flags?

One can replace install with the following sequence of commands.

rm
mkdir
cp
chmod
chown

etc.

It is used widely enough in make targets that it is worth having
as a standalone command in sbase.

I think -d, -g, -o, -m, -s, -D and -t should be enough for an
initial implementation.

Re: [dev] [sbase][PATCH] install

[Dimitris Papastamos]

On Thu, Feb 11, 2016 at 01:57:00PM +0100, Mattias Andrée wrote:
> It cannot be `install` because it conflicts with
> install rule. So I decided to append .out (like in a.out)
> to make it work.

Duh, of course.

> > > +static void
> > > +make_dir(char *dir, int was_missing)
> > > +{
> > > + if (!mkdir(dir, was_missing ? 0755 : mode)) {
> > > + if (!was_missing && (lchown(dir,
> > > owner, group) < 0))
> > > + eprintf("lchmod %s:", dir);
> > > + } else if (errno != EEXIST) {
> > > + eprintf("mkdir %s:", dir);
> > > + }
> > > +}
> > > +
> > > +static void
> > > +make_dirs(char *dir, int was_missing)
> > > +{
> > > + char *p;
> > > + for (p = strchr(dir + (dir[0] == '/'), '/');
> > > p; p = strchr(p + 1, '/')) {
> > > + *p = '\0';
> > > + make_dir(dir, was_missing);
> > > + *p = '/';
> > > + }
> > > + make_dir(dir, was_missing);
> > > +}  
> > 
> > Can we use mkdirp() from libutil?
> 
> mkdirp has to be change to allow custom
> mode, but it also has to be change to
> optioanlly do lchown. I though this was
> better because other utilities will probably
> not need this.

Makes sense to keep it as is then.

Re: [dev] fsbm (1) version 1.1 released

[Dimitris Papastamos]

On Thu, Feb 11, 2016 at 03:48:34PM -0200, Alba Pompeo wrote:
> Both are very cool!
> A nitpick is that Dimitri's version uses the nonstandard header sys/sysctl.h.
> This prevents compilation on musl.

Hm yes, it is only meant to work on OpenBSD.  The sample() function is totally 
non-portable.
(It might also work on NetBSD).

Re: [dev] fsbm (1) version 1.1 released

[Dimitris Papastamos]

On Thu, Feb 11, 2016 at 12:55:34PM -0500, Calvin Morrison wrote:
> On 11 February 2016 at 12:53, Alba Pompeo <albapom...@gmail.com> wrote:
> > It's not supposed to be used on Linux on the first place - right.
> > My bad for missing this information.
> >
> >
> > On Thu, Feb 11, 2016 at 3:51 PM, Dimitris Papastamos <s...@2f30.org> wrote:
> >> On Thu, Feb 11, 2016 at 03:48:34PM -0200, Alba Pompeo wrote:
> >>> Both are very cool!
> >>> A nitpick is that Dimitri's version uses the nonstandard header 
> >>> sys/sysctl.h.
> >>> This prevents compilation on musl.
> >>
> >> Hm yes, it is only meant to work on OpenBSD.  The sample() function is 
> >> totally non-portable.
> >> (It might also work on NetBSD).
> >>
> >
> 
> I also cannot guarantee cross platform compatibility, as it depends on
> /proc/net/dev. I am unsure of which systems support this.

Only Linux.

Re: [dev] fsbm (1) version 1.1 released

[Dimitris Papastamos]

On Thu, Feb 11, 2016 at 11:01:35AM -0500, Calvin Morrison wrote:
> Hi,
> 
> I had time to commit my last changes into fsbm [0], the minimal
> bandwidth meter. Notably the two features added are below:
> 
> -r flag now accepted to show raw byte or bit counts, rather than
> squashing into Kb/s  Mb/s etc.
> -i flag now accepted to show a single interface that is requested
> 
> For now the -i flag only will operate on one interface, so it could be
> improved by handing multiple interfaces, but I don't really see a use
> case for it.
> 
> [0] https://github.com/mutantturkey/fsbm

Cool!  I made a similar tool some time ago, so I cleaned it up and put
it on git.

http://git.2f30.org/sbm/files.html

Re: [dev] tag new slock release?

[Dimitris Papastamos]

On Wed, Feb 10, 2016 at 04:46:01PM +0100, Markus Teich wrote:
> Heyho,
> 
> I propose to tag a new v1.3 release for slock. I have no open patches or bug
> reports on my list and my attention was brought to it a few times already. A
> major thing noted by most people was the fix for resizing the cover window on
> xrandr resize events (f5ef1b8), which can be considered a security issue. A 
> new
> release would make packaging easier for the distributions.

Sounds good to me.

Re: [dev] [PATCH] Change an eprintf to a die to stop child from running its own slideshow

[Dimitris Papastamos]

On Thu, Jan 14, 2016 at 09:02:43PM +1300, David Phillips wrote:
> The child thread was created because execlp will not return if successful.
> The eprintf was placed after the call to execlp to catch any error, but the
> child continued to return a (closed) fds[0], resulting in a second slideshow
> being run by the child.
> 
> This commit fixes the issue by killing the child.
> ---
>  sent.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/sent.c b/sent.c
> index fc5e389..88abe90 100644
> --- a/sent.c
> +++ b/sent.c
> @@ -153,7 +153,7 @@ filter(int fd, const char *cmd)
>   close(fds[0]);
>   close(fds[1]);
>   execlp(cmd, cmd, (char *)0);
> - eprintf("execlp %s:", cmd);
> + die("execlp %s:", cmd);

Good catch.  eprintf() is totally misnamed here.  In general eprintf()
is not expected to return but this version actually does not exit.

Re: [dev] [PATCH] Change an eprintf to a die to stop child from running its own slideshow

[Dimitris Papastamos]

On Thu, Jan 14, 2016 at 11:21:00AM +0100, Kamil Cholewiński wrote:
> > It depends on your background.  eprintf() and weprintf() were written by
> > Rob Pike and Kernighan and used in the book "The Practice of Programming".
> 
> I see... Principle of least surprise, except it's me who should never be
> surprised. I guess the rest of us get surprised only once.

The e prefix indicates error.  This I think is more clear than the BSD approach
of using the x prefix.

wprintf() is taken so it had to be weprintf().

Re: [dev] [PATCH] Change an eprintf to a die to stop child from running its own slideshow

[Dimitris Papastamos]

On Thu, Jan 14, 2016 at 09:02:43PM +1300, David Phillips wrote:
> The child thread was created because execlp will not return if successful.
> The eprintf was placed after the call to execlp to catch any error, but the
> child continued to return a (closed) fds[0], resulting in a second slideshow
> being run by the child.
> 
> This commit fixes the issue by killing the child.
> ---
>  sent.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/sent.c b/sent.c
> index fc5e389..88abe90 100644
> --- a/sent.c
> +++ b/sent.c
> @@ -153,7 +153,7 @@ filter(int fd, const char *cmd)
>   close(fds[0]);
>   close(fds[1]);
>   execlp(cmd, cmd, (char *)0);
> - eprintf("execlp %s:", cmd);
> + die("execlp %s:", cmd);
>   }
>   close(fds[1]);
>   return fds[0];
> -- 
> 2.6.2
> 

I should mention there are many more places in the code where this
issue happens.

On BSD there is err() and warn() which makes it very clear which one
is fatal.

One approach is to keep die() and rename eprintf() to something more
appropriate.

Otherwise we can use the approach in sbase which is to have eprintf()
be equivalent to die() and weprintf() for just the warning version.

Re: [dev] lock (1) - where does it go?

[Dimitris Papastamos]

On Tue, Jan 12, 2016 at 09:35:59AM -0500, Calvin Morrison wrote:
> sorry to revive an old topic -
> 
> I'd like to have this in with other utils, because i find it useful in
> my day to day work. I do not care about the licensing, feel free to
> use whatever license is appropriate.MIT/X I think is what is used
> around here.
> 
>  Would someone be willing to commit this into u/sbase for me?

There is already flock(1) in sbase if that's what you mean.

Re: [dev] lock (1) - where does it go?

[Dimitris Papastamos]

On Tue, Jan 12, 2016 at 11:28:42AM -0500, Calvin Morrison wrote:
> > Care to clarify the limitations of flock?
> 
> Extensive discussion took place here:
> http://lists.suckless.org/dev/1404/20719.html

Yes I saw the thread.  What is the problem with the current flock
implementation?

I understand flock is not standardized but every system I know of
implements it.

Re: [dev] lock (1) - where does it go?

[Dimitris Papastamos]

On Tue, Jan 12, 2016 at 11:24:09AM -0500, Calvin Morrison wrote:
> On 12 January 2016 at 10:27, Dimitris Papastamos <s...@2f30.org> wrote:
> > On Tue, Jan 12, 2016 at 09:35:59AM -0500, Calvin Morrison wrote:
> >> sorry to revive an old topic -
> >>
> >> I'd like to have this in with other utils, because i find it useful in
> >> my day to day work. I do not care about the licensing, feel free to
> >> use whatever license is appropriate.MIT/X I think is what is used
> >> around here.
> >>
> >>  Would someone be willing to commit this into u/sbase for me?
> >
> > There is already flock(1) in sbase if that's what you mean.
> >
> 
> No sorry, flock is a different program that the wraps flock().
> Somewhat evil and not going to necessarily work on all use cases. This
> was discussed length in a previous thread. This program uses
> directories which are helpfully atomic, to 'lock' a program from
> running until it's removed.

Care to clarify the limitations of flock?

Re: [dev] lock (1) - where does it go?

[Dimitris Papastamos]

On Tue, Jan 12, 2016 at 12:00:57PM -0500, Calvin Morrison wrote:
> On 12 January 2016 at 11:39, Dimitris Papastamos <s...@2f30.org> wrote:
> > On Tue, Jan 12, 2016 at 11:28:42AM -0500, Calvin Morrison wrote:
> >> > Care to clarify the limitations of flock?
> >>
> >> Extensive discussion took place here:
> >> http://lists.suckless.org/dev/1404/20719.html
> >
> > Yes I saw the thread.  What is the problem with the current flock
> > implementation?
> >
> > I understand flock is not standardized but every system I know of
> > implements it.
> >
> 
> https://en.wikipedia.org/wiki/File_locking#Problems

And mkdir() is atomic on NFS? :P

Please explain what problem you are trying to solve that flock(1)
does not satisfy.

Re: [dev][ubase][PATCH] fix several problems in dd

[Dimitris Papastamos]

On Fri, Jan 01, 2016 at 12:52:31PM +0100, FRIGN wrote:
> On Fri, 01 Jan 2016 11:21:05 +0100
> isabella parakiss  wrote:
> 
> Hey Isabella,
> 
> > i've been told on #2f30 that my opinion is void until i submit meaningful
> > patches.  this is a rant^Wbreakdown and fix of a random tool in ubase
> 
> I'll look deeper into this later, but I want to note here that back in the
> day, dd was imported into ubase from some foreign repo for some performance
> tweaks. I was sure back then when Dimitris told me, that this is going to
> bite us.

Well yes, importing code that is not thoroughly understood has the
potential to cause problems later on.  However, this version of dd was
stripped down quite a bit from the upstream one.

At the end of the day, a bug is a bug irrespective of how it was introduced.

I will have a look at the patch tomorrow.

Re: [dev] Fmask [c posix]

[Dimitris Papastamos]

On Wed, Dec 30, 2015 at 12:49:59AM -0200, Marc Collin wrote:
> Hello suckless.
> 
> I came across something really interesting.
> http://bbs.progrider.org/prog/read/1399107986
> What do you guys think?

Why do you think it is interesting?

Re: [dev] libutil/eprintf clarification patch (to the Evil_Bob's request)

[Dimitris Papastamos]

On Mon, Dec 21, 2015 at 10:49:58AM +0100, Markus Teich wrote:
> FRIGN wrote:
> > I thought about this tonight and came to the conclusion that this "hack"
> > doesn't introduce too many problems.
> 
> Heyho FRIGN,
> 
> what do you think about making `usage(int status, char *shortargs)` an
> eprintf-like function in eprintf.c? This might clear things up for everyone.

Stop the madness!

Re: [dev] C package manager-ish

[Dimitris Papastamos]

On Tue, Dec 15, 2015 at 12:20:52PM +0200, Adrian Grigore wrote:
> Hey guys,
> 
> I wanted to know what's your general opinion on https://github.com/clibs/clib.
> 
> Disclaimer: I'm not a C programmer, but planning to learn.

Well, package managers suck.

Re: [dev] c++ compiler that rocks

[Dimitris Papastamos]

>  GCC C compiler is a virus, Then you are saying there is no
> alternative if I want a c or c++ compiler. ?
> 
> Or is suckless planning to develop a new C compiler?

http://git.suckless.org/scc/

Re: [dev] dwm: drw_draw does too much

[Dimitris Papastamos]

On Fri, Nov 27, 2015 at 12:18:44PM -0700, David Kennedy wrote:
> This part of the drawbar function is really confusing:
> 
>   if (m == selmon) { /* status is only drawn on selected monitor */       
>            
>   w = TEXTW(stext);
>   x = m->ww - w;
>   if (x < xx) {
>   x = xx;
>   w = m->ww - xx;
>   }
>   drw_text(drw, x, 0, w, bh, stext, 0);
>   } else
>   x = m->ww;
> 
> Why is it confusing? Because TEXTW is just an alias for drw_text:
> 
>   #define TEXTW(X)(drw_text(drw, 0, 0, 0, 0, (X)) + 
> drw->fonts[0]->h)
> 
> In other words, before calling drw_text (which needs to know the width of the 
> thing to be drawn) on line 739, we call drw_text with no parameters on line 
> 733 to get the width of the thing to be drawn.
> 
> I think it would be better if another function was defined to get the width, 
> and drw_text only had to draw the text. Then w could be a required parameter.
> 
> Then again, drw_font_getexts_width already exists and could be used for this 
> purpose. But it overlaps the functionality provided by drw_font_getexts. 
> Maybe drw_font_getexts should be used wherever pixel dimensions are required.
> 
> Thoughts? Should I just submit a patch?   
>   

A discussion should always start with a patch.

Re: [dev] [sbase] Portability

[Dimitris Papastamos]

On Thu, Nov 26, 2015 at 01:52:23AM -0500, Random832 wrote:
> I downloaded and built sbase for my OSX system to test the cal program,
> and noticed (and fixed locally) several issues.
> 
> Before posting any patches, I wanted to ask - philosophically speaking,
> how much effort should sbase put towards supporting systems that don't
> support the latest-and-greatest POSIX functions? Three functions were
> missing (utimensat, clock_gettime, and fmemopen), and fmemopen in
> particular required an extensive implementation, which I found online
> (https://github.com/NimbusKit/memorymapping) rather than writing myself.
> 
> Also, if these are added should they go in libutil or a new "libcompat"?

Yes this is kind of a known issue.  I would like to stick to the latest
interfaces.  Unless of course there is no reason and we do not benefit from
using those latest interfaces.

Sometimes we come across good interfaces that are not standardized.
We just put an implementation in libutil.  This is similar to how OpenBSD
handles the portable versions of the programs.

In regards to the functions you highlighted:

* utimensat is cool and I would like to keep it.  I had the same
problem on DragonFlyBSD.  I went ahead and implemented the utimensat()
syscall for it and send a patch.
* clock_gettime is quite useful and is known not to work on OSX.  I have
a patch[0] for another project to address this problem.
* fmemopen is rarely used but I think it simplifies the code in grep.

I am open to recommendations as long as we do not sacrifice anything from
using the latest interfaces.

Cheers,
Dimitris

[0] 
http://u.2f30.org/sin/patches/ratox/0001-Add-OSX-replacements-for-certain-functions.patch

Re: [dev] [sbase] Portability

[Dimitris Papastamos]

On Thu, Nov 26, 2015 at 01:52:23AM -0500, Random832 wrote:
> I downloaded and built sbase for my OSX system to test the cal program,
> and noticed (and fixed locally) several issues.
> 
> Before posting any patches, I wanted to ask - philosophically speaking,
> how much effort should sbase put towards supporting systems that don't
> support the latest-and-greatest POSIX functions? Three functions were
> missing (utimensat, clock_gettime, and fmemopen), and fmemopen in
> particular required an extensive implementation, which I found online
> (https://github.com/NimbusKit/memorymapping) rather than writing myself.
> 
> Also, if these are added should they go in libutil or a new "libcompat"?

If nothing else, we can put some of these patches on the wiki.  Given
that some interfaces might require OS specific glue code to function
on a particular OS, it would only make sense to support this with an
external patch.

sbase should only contain code that runs on POSIX systems (with some
minor exceptions) and fallback implementations for non-standardized
interfaces that can be implemented portably on top of POSIX interfaces.

Re: [dev] Re: [sbase] Portability

[Dimitris Papastamos]

On Thu, Nov 26, 2015 at 05:12:17AM -0500, Random832 wrote:
> Dimitris Papastamos <s...@2f30.org> writes:
> > sbase should only contain code that runs on POSIX systems (with some
> > minor exceptions) and fallback implementations for non-standardized
> > interfaces that can be implemented portably on top of POSIX interfaces.
> 
> So there's no place for fallback implementations _of_ POSIX interfaces
> on top of either older POSIX interfaces or non-standard ones?

I would like to avoid that for upstream.  If you do push the libcompat patchset
to the wiki, you can add fallback implementations as needed.

> Anyway, here's a patch for some data type issues that came up - more to
> do with compiling with all warnings, though the fact that clock_t is
> unsigned on OSX helped catch one of them.

Applied with some modifications.  Thanks!

Re: [dev] [noice] [PATCH] Support commands specified by environment variables

[Dimitris Papastamos]

On Thu, Nov 26, 2015 at 01:59:32PM +0100, Martin Kühl wrote:
> Not sure where else to post this, so...
> 
> Specifying commands by name in config.h means that
> every time one switches ones editor (for example),
> one has to modify every config.h file referencing that editor
> and then recompile every corresponding program.
> 
> This change adds a string `env` for specifying an environment
> variable to `struct key` and uses it to optionally specify the
> command to run on SEL_{RUN,RUNARG}.
> The `run` string is used as a fallback when the environment variable
> has not been specified or is not set.
> It also updates `config.def.h` to demonstrate this new capability.

Applied, cheers!

Re: [dev] Announcement: Backporting the fun into C

[Dimitris Papastamos]

On Sun, Nov 22, 2015 at 11:21:13AM +0100, Martti Kühne wrote:
> My experience with suckless software has shown me pretty clearly that
> the tradeoffs in code quality around here are not really acceptable
> for code that I wanted both to release or work on myself, and let's
> face it, it doesn't help to just pretend these issues don't exist.
> That also means, no, I won't cut corners like to leave the releasing
> of resources and file descriptors to the operating system or use die()
> in what is supposed to be library code where error handling must
> clearly be up to the caller. Other people should actually be able to
> write programs with it, too, as that's a legitimate aspect of the term
> library.

I don't know what you are on about, but suckless hasn't really developed
any libraries.  The only "library" is libutf which allows the caller to
handle errors just fine.

The other are bits and pieces shared between suckless projects but they
are not libraries.  They are merely util functions.

Learn to do the minimum work necessary to get the job done.

Re: [dev] Re: [sbase] cal doesn't highlight current day

[Dimitris Papastamos]

On Fri, Nov 20, 2015 at 06:53:53PM +, Connor Lane Smith wrote:
> On 20 November 2015 at 18:40, Connor Lane Smith  wrote:
> > I've attached a patch. It's not too bad, although it does have ugly
> > escape codes. But I don't actually mind either way.
> 
> Slightly uglier bugfix.

I've applied the patch, thanks!

Re: [dev] [slcon2] Videos are now online!

[Dimitris Papastamos]

On Wed, Nov 18, 2015 at 10:52:19AM -0500, Greg Reagle wrote:
> On 11/13/2015 02:30 PM, FRIGN wrote:
> > videos of the slcon2 talks are now online[0] in the webm format.
> > 
> > [0]: http://suckless.org/conference/
> 
> Great, thanks.  Is there any code for "Simple Jabber - Divide And Conquer 
> XMPP, Jan Klemkow"?

https://github.com/younix/sj

Re: [dev] a suckless hex editor

[Dimitris Papastamos]

On Fri, Nov 13, 2015 at 02:52:17PM -0500, Greg Reagle wrote:
> Okay then.  It no longer depends on xxd.  It depends on od for the hex dump
> (works with both GNU od and sbase od) and echo, awk, tr, cut for the reverse
> hex dump.

> #!/bin/sh
> [ -z "$1" -o -z "$2" ] && { echo "$0 infile outfile"; exit 1; }
> [ -z "$EDITOR" ] && { echo "\$EDITOR must be defined"; exit 1; }
> 
> tmpfile=$(mktemp) || exit 1
> infile="$1"
> outfile="$2"
> 
> od -Ax -tx1 "$infile" | head -n -1 > $tmpfile
> $EDITOR "$tmpfile"
> /bin/echo -ne $(tr -s ' ' < "$tmpfile" | cut -d' ' -f2-17 | awk '{for (i=1; 
> i<=NF; i++) printf "\\x%s", $i}') > $outfile
> rm "$tmpfile"

echo -e is evil, use printf(1)

Re: [dev] [sent] 0.1 release

[Dimitris Papastamos]

On Thu, Nov 12, 2015 at 01:20:57PM +0100, Markus Teich wrote:
> Heyho,
> 
> I am happy to announce the version 0.1 release of sent, a suckless 
> presentation
> tool. Yesterday I finished the multiline support and now sent is not anymore
> only useful for takahashi style presentations. The next big step for the 0.2
> release is to migrate from png to farbfeld.
> 
> http://tools.suckless.org/sent
> http://git.suckless.org/sent
> http://dl.suckless.org/tools/sent-0.1.tar.gz

Nice!  You might also want to update the news page on the site.

Re: [dev] sbase: od: bug report

[Dimitris Papastamos]

Hint: Print out the values of skip and addr in the od() function.

Re: [dev] sbase: od: bug report

[Dimitris Papastamos]

On Mon, Oct 26, 2015 at 05:26:21PM +0100, FRIGN wrote:
> On Mon, 26 Oct 2015 11:00:54 -0400
> Greg Reagle  wrote:
> 
> Hey Greg,
> 
> > Since there is no accompanying patch/fix, I am using dev rather than 
> > hackers.
> 
> thank you very much for this bug report! I still think this should be
> on hackers@ though.
> 
> > Command od doesn't seem to like multiple file arguments.  See attached.
> 
> Looking into the issue, I found the following problem roughly at the
> same time Dimitris did:
> 
> while (skip - addr) {
> 
> Normally, skip is 0, and on the first file, addr is 0 as well, so the
> overflow issue was masked.
> However, when od() was called with a second file, addr was > 0 and it
> would enter the loop, resulting in all sorts of strangeness.

To elaborate a bit at this point, the negative value (skip - addr) is
interpreted as a large unsigned value.  The kernel will try to do a 
copy_to_user()
with a very large length field.  It will fault at some point because
user memory is either not mapped or writeable and return -EFAULT
through the read syscall.

Quick way to find this is to use strace(1) and see which syscall fails.

Re: [dev] dmenu segfaults when pressing control+enter without a selection

[Dimitris Papastamos]

On Thu, Oct 15, 2015 at 08:26:58PM -0400, Matthew of Boswell wrote:
> On Thu, 15 Oct 2015 18:08:20 -0400
> Matthew of Boswell  wrote:
> 
> > Fix attached.
> 
> Nevermind... I didn't know that dmenu was on git.suckless.org...
> There's no reference to its git repository on the main suckless.org
> website. Looks like this segfault was fixed last year on the master
> branch...
> 
> By the way... shouldn't there be a newer release of dmenu? Most distros
> don't package the git version.

Just install manually.

Re: [dev] Stali RC

[Dimitris Papastamos]

On Mon, Oct 05, 2015 at 11:02:13AM +0200, Roberto E. Vargas Caballero wrote:
> > 
> > > - am I correct in thinking that we install manual pages, but currently no 
> > > 'man' program to read them?
> > 
> > I'd propose using the OpenBSD man tools.
> > 
> 
> I propose to use neatroff, that is a new implementation from scratch of
> the full troff toolchain. I know that the main use of troff today is
> man pages, and it can be solved using OpenBSD mandoc, but I feel that
> a unix alike system without full support for troff is not unix alike.
> 
> 
> https://github.com/litcave/neatroff
> https://lists.gnu.org/archive/html/groff/2013-07/msg1.html
> http://litcave.rudi.ir/neatroff.pdf

neatroff looks really nice and well done.  I am all for it.

Re: [dev] Stali RC

[Dimitris Papastamos]

On Fri, Oct 02, 2015 at 02:21:57PM +, Richard wrote:
> Actually, having set my expectations very low, I am finding that it works 
> surprisingly well. Having played and poked around in the OS for a few hours 
> this has lead to yet more questions:
> 
> - do we install a pager? I've look in bin for more/less/pg etc. Are there any 
> plans for a pager? I looked in the TODO documents for both sbase and ubase 
> but did not notice any.

Yes there are plans for a pager.  The heirloom project has a pg
implementation I think.

> - am I correct in thinking that we install manual pages, but currently no 
> 'man' program to read them?

I'd propose using the OpenBSD man tools.

> - looking further ahead; has there been any thoughts towards a 
> staticallylinked/musl-based X11 server? Is it feasible to simply take the 
> xorg sources and compile those with static linking or does that not work (or 
> would it be philosophically incompatible)? suckless obviously has some useful 
> tools like 'st' and 'dmenu' ready to go once X11 is available. I ask because 
> the finest browser ever written is obviously 'surf', but worryingly surf 
> depends on webkitgtk; which depends on gtk; which in turn might lead back to 
> glibc,glib etc.

There are ugly workarounds.  I will try to dig out some logs from #suckless
explaining the core concepts.

> - what's the relationship between 'stali' and the 'morpheus' project which I 
> stumbled accross over at 2f30? Has one replaced the other? Are they 
> developing in parallel?

Morpheus was an experimental distro I started along with some friends
to see if we can realize the stali idea.  We made some mistakes along
the way however.  We'll try to correct these in stali.

> This is a fun distribution - thanks for writing it, R.

It is not ready yet!

Re: [dev] Stali RC

[Dimitris Papastamos]

On Sun, Oct 04, 2015 at 01:00:36PM -0300, Marc Collin wrote:
> On Thu, Sep 24, 2015 at 11:29 PM, Pickfire  wrote:
> > Is there a package manager for suckless [...] ?
> 
> 
> 
> Well maybe you could use apk[1]?
> Looks suckless to me.

There are no plans to have a package manager.

Re: [dev] sbase: is od needed?

[Dimitris Papastamos]

On Mon, Sep 28, 2015 at 12:51:19PM -0400, Greg Reagle wrote:
> Howdy.  Would it be useful for me to write od?  Has anyone else worked on
> it?

Yes it is in the TODO, send a patch to hackers@ when you have something to show.

There was an implementation of a subset of od done in the past but it
was never merged because it needed reworking.  IIRC, it was not posted on
the ml so don't bother looking.

Cheers,
Dimitris

Re: [dev] Stali RC

[Dimitris Papastamos]

On Fri, Sep 25, 2015 at 08:45:05AM +, Richard wrote:
> Ah, great thanks. So I was half right: if you follow the instructions on
> 
> http://sta.li/installation
> 
> 
> git clone http://git.sta.li/rootfs-x86_64
> 
> you will end up with no /etc directory. But the directory is still needed in 
> this distro.
> 
> Confusion solved, thanks, R.

As it stands, there is a lot of work to be done on stali.  Do not
expect it to just work.  If you want to help, then send some patches
to hackers@ for consideration.

Re: [dev] [slock] chown to root:root on install?

[Dimitris Papastamos]

On Tue, Sep 08, 2015 at 02:30:39PM +0100, Nick wrote:
> Separately to this, slock seems to exit (without prompt) after about 
> 0.3s after I run it, unless I move the mouse or hit the keyboard 
> directly after starting it. Has anyone else seen this? I could look 
> into it more, but wonder if I am perhaps being stupid?

Please provide a backtrace.

Re: [dev] [slock] chown to root:root on install?

[Dimitris Papastamos]

On Tue, Sep 08, 2015 at 02:44:26PM +0100, Nick wrote:
> Quoth Dimitris Papastamos:
> > On Tue, Sep 08, 2015 at 02:30:39PM +0100, Nick wrote:
> > > Separately to this, slock seems to exit (without prompt) after about 
> > > 0.3s after I run it, unless I move the mouse or hit the keyboard 
> > > directly after starting it. Has anyone else seen this? I could look 
> > > into it more, but wonder if I am perhaps being stupid?
> > 
> > Please provide a backtrace.
> 
> I looked into it a bit more, and it turns out it is exiting with 
> status 1; I double-checked and indeed it is returning from the 
> "nothing to protect" condition.

I am not sure why, can you try to increase the timeout in the two
loops that grab the pointer/keyboard inside lockscreen()?

I suspect len is 0 and lock is set to NULL.

Re: [dev] Torified surf is unstable

[Dimitris Papastamos]

On Tue, Aug 18, 2015 at 12:41:51PM +0200, GhostAV wrote:
 On Tue, Aug 18, 2015 at 11:28:36AM +0100, Dimitris Papastamos wrote:
  On Tue, Aug 18, 2015 at 12:23:12PM +0200, Gabriel Pérez-Cerezo wrote:
   At Tue, 18 Aug 2015 11:15:59 +0100,
   Dimitris Papastamos wrote:
 The command prints
 [Aug  18  11:55:55]  WARNING  torsocks[14305]:  [syscall]  Unsupported
 syscall number 240.  Denying the call (in tsocks_syscall() at 
 syscall.c:165)
 to STDOUT.

What syscall is it?
   I don't know.  I tried man syscall  and man syscalls but  none of them
   contain a list of syscalls by number. How do I look it up?
  
  Numbers are different per architecture.  For i686 I guess the right
  place to look is here[0].
  
  Futexes are not directly used by surf but indirectly by libc.  I don't
  think there is much we can do here, this seems like an issue on the torsocks
  side.  By denying the system call, perhaps something is left uninitialized
  and then crashes.
  
  [0] http://lxr.free-electrons.com/source/arch/x86/syscalls/syscall_32.tbl
 Best place to look for the according syscall for your architecture and
 current version is in /usr/include/asm/unistd{,_32,_64}.h depending
 wether you have an 32 or 64 bit system.

Yes those are autogenerated from the above .tbl I believe.

Re: [dev] Torified surf is unstable

[Dimitris Papastamos]

On Tue, Aug 18, 2015 at 12:23:12PM +0200, Gabriel Pérez-Cerezo wrote:
 At Tue, 18 Aug 2015 11:15:59 +0100,
 Dimitris Papastamos wrote:
   The command prints
   [Aug  18  11:55:55]  WARNING  torsocks[14305]:  [syscall]  Unsupported
   syscall number 240.  Denying the call (in tsocks_syscall() at 
   syscall.c:165)
   to STDOUT.
  
  What syscall is it?
 I don't know.  I tried man syscall  and man syscalls but  none of them
 contain a list of syscalls by number. How do I look it up?

Numbers are different per architecture.  For i686 I guess the right
place to look is here[0].

Futexes are not directly used by surf but indirectly by libc.  I don't
think there is much we can do here, this seems like an issue on the torsocks
side.  By denying the system call, perhaps something is left uninitialized
and then crashes.

[0] http://lxr.free-electrons.com/source/arch/x86/syscalls/syscall_32.tbl

Re: [dev] Torified surf is unstable

[Dimitris Papastamos]

On Tue, Aug 18, 2015 at 12:00:40PM +0200, Gabriel Pérez-Cerezo wrote:
 Hello,
 
 I run surf  through tor using 'torify  surf'. If I don't  add the '-i'
 option, it segfaults  when searching on Duckduckgo. Even if  I add the
 '-i' flag, it crashes after some time with messages like
 *** Error in `surf': free(): invalid pointer: 0x095ca248 ***
 or a  segmentation fault  and often  reaches 100%  CPU usage.  Can you
 replicate this situation?
 
 The command prints
 [Aug  18  11:55:55]  WARNING  torsocks[14305]:  [syscall]  Unsupported
 syscall number 240.  Denying the call (in tsocks_syscall() at syscall.c:165)
 to STDOUT.

Looking at the torsocks code, it seems they do handle futexes[0].  Can
you try a newer version of torsocks or directly from git?

[0] https://gitweb.torproject.org/torsocks.git/tree/src/lib/syscall.c#n428

Re: [dev] [st] Compilation error after commit dc33d1d

[Dimitris Papastamos]

On Tue, Aug 18, 2015 at 08:28:41PM +0800, Pickfire wrote:
 st build options:
 CFLAGS   = -g -std=c99 -pedantic -Wall -Wvariadic-macros -Os -I.
 -I/usr/include -I/usr/X11R6/include -I/usr/include/freetype2
 -I/usr/include/libpng16 -I/usr/include/harfbuzz -I/usr/include/freetype2
 -I/usr/include/libpng16 -I/usr/include/harfbuzz
 -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/harfbuzz
 -DVERSION=0.6 -D_XOPEN_SOURCE=600
 LDFLAGS  = -g -L/usr/lib -lc -L/usr/X11R6/lib -lm -lrt -lX11 -lutil
 -lXext -lXft -lfontconfig -lfreetype  -lfreetype
 CC   = cc
 CC st.c
 st.c: In function ‘xinit’:
 st.c:3487:37: error: ‘mouseshape’ undeclared (first use in this
 function)
  cursor = XCreateFontCursor(xw.dpy, mouseshape);
 ^
 st.c:3487:37: note: each undeclared identifier is reported only once for
 each function it appears in
 st.c:3490:45: error: ‘mousefg’ undeclared (first use in this function)
  if (XParseColor(xw.dpy, xw.cmap, colorname[mousefg], xmousefg) == 0)
 {
 ^
 st.c:3496:45: error: ‘mousebg’ undeclared (first use in this function)
  if (XParseColor(xw.dpy, xw.cmap, colorname[mousebg], xmousebg) == 0)
 {
 ^
 Makefile:21: recipe for target 'st.o' failed
 make: *** [st.o] Error 1

Your config.h is old.

Re: [dev] [dvtm] create in $CWD not working

[Dimitris Papastamos]

On Wed, Jul 15, 2015 at 01:11:22PM -0400, Ross Mohn wrote:
 That highlights my frustration with the new definitions for the mailing
 lists. I am a hacker/developer and really only ask a question when I
 need a little help hacking on the code. As you can see, my question led
 me to submit the patched solution in the same email thread. The changed
 definitions keep the development out of the endless support threads on
 dev@ and development more enjoyable. My question was a development
 question, not a support question, and therefore was more appropriately
 discussed on hackers@. Why support is discussed on dev[elopment] and
 not on a new support@ list is still beyond me, but I'll get over it as
 soon as Marc shows up on hackers@. :-)

Discussions on hackers@ always start with a patch.  Your first email had
no patch attached.

Renaming dev@ to misc@ or support@ is not practical due to the number of
people subscribed on the dev@ list.

Re: [dev] [st][PATCH] Preserve pixelsize fractions in font defaultsize.

[Dimitris Papastamos]

On Fri, Jun 12, 2015 at 01:22:08PM -0700, Matthew Wesley wrote:
 On Fri, Jun 12, 2015 at 1:00 PM, FRIGN d...@frign.de wrote:
  we had this discussion before and the reasons have already been told.
  Adding a company to a license is a risk we won't take.
  We prefer to deny these patches in favor of staying away from possible
  risks of this nature, so please either commit this patch as a legal
  person (not entity per se) or let it go.
 
 Unfortunately, I'm restricted by Google policies, so I'm going to just
 let it go. Quentin's patch from May precedes and supersets mine,
 however, and extends the floating point conversion to a few places I
 didn't bother with. You may want to accept his patch instead.

Can you not get an exemption from your employer so you can freely contribute
to this project under your own name?

Re: [dev] [sbase] [PATCH 1/3] mv, cp: Preserve nanosecond timestamps

[Dimitris Papastamos]

This had been on my radar for some time, thanks for working
on this.

Applied all three patches.

Re: [dev] [sbase] [PATCH 1--2] ls: fix -S and -q

[Dimitris Papastamos]

On Fri, May 15, 2015 at 12:29:48AM +0200, Alexandre Niveau wrote:
 Greetings,
 
 I found some bugs in ls.
 
 1. option -S does not work on its own:
 
 $ echo aa a; echo b b; echo 
 $ ls -S
 a
 b
 c
 
 First attached patch fixes this.

Applied the first patch, will review the second patch in the weekend.

Re: [dev] [PATCH] [slock] rework setting window color

[Dimitris Papastamos]

On Fri, May 08, 2015 at 06:13:21PM +0200, Markus Teich wrote:
 + color = len ? INPUT : (failure || failonclear ? FAILED 
 : INIT);

I would split this condition out.  Looks good for the rest.

Re: [dev] [sbase] [PATCH] join: fix typo

[Dimitris Papastamos]

On Sat, May 09, 2015 at 01:01:30PM -0400, Wolfgang Corcoran-Mathe wrote:
 ---
  join.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/join.c b/join.c
 index 2522404..58f0f88 100644
 --- a/join.c
 +++ b/join.c
 @@ -292,7 +292,7 @@ initspan(struct span *sp)
  {
   sp-nl = 0;
   sp-maxl = INIT;
 - sp-lines = ereallocarray(NULL, INIT, sizeof(struct line *));;
 + sp-lines = ereallocarray(NULL, INIT, sizeof(struct line *));
  }
  
  static void
 -- 

Applied, thanks!

Re: [dev] [sbase] [PATCH 1/2] ln: only check existence of src/to for hardlinks

[Dimitris Papastamos]

Applied both, thanks :)

Re: [dev] sple - A simple PDF links/emails extracotr.

[Dimitris Papastamos]

On Thu, May 07, 2015 at 11:58:14AM -0400, Jason Woofenden wrote:
 On 2015-05-07 05:07PM, Jochen Sprickerhof wrote:
  * Jason Woofenden ja...@jasonwoof.com [2015-05-07 10:09]:
 pdftohtml -stdout foo.pdf | sed -ne 's/href=\([^]\+\)/\n\1\n/g' -e 
   's/\(^[^\n]*\n\|\(\n\)\)\([^\n]*\)\n[^\n]*/\2\3/gp'
  
  I would use grep ;). Using my urlselct from [1] I would write:
  
  pdftotext foo.pdf - | urlselect
  
  Cheers Jochen
  
  [1] http://lists.suckless.org/dev/1504/26641.html
 
 Ooh, grep -o is great!

It is also a non-standard extension.

Re: [dev] [sbase] [PATCH] join manpage: Fix spelling

[Dimitris Papastamos]

Thanks, applied both patches.

Re: [dev] Miscellaneous sbase issues

[Dimitris Papastamos]

On Mon, Apr 27, 2015 at 08:12:42PM +0100, Nick wrote:
 One thing the patch doesn't cover is an archive using a symlink to 
 somewhere like ../../ and then putting a file in symlink/newfile 
 (hence sending it to ../../newfile). I only thought of that when 
 reading the bsdtar manpage[0].
 
 I'm not sure what the best behaviour is in that case. Some options:
 
 1) If a symlink creates a path ascending further up the directory 
 tree (towards /) than the current directory, replace all symlinks in 
 the path with directories and extract there.
 
 2) Remove the symlink and replace it with a real directory before 
 extracting the file into it (this is the behaviour of bsdtar with 
 the -U option)
 
 3) Refuse to create any file following a symlink (this is the 
 default behaviour of bsdtar)
 
 4) Issue a warning if writing a file, but follow the symlink as 
 instructed
 
 If you're curious about how bsdtar does it, look at check_symlinks() 
 in libarchive/archive_write_disk_posix.c, but note the comment at 
 the top of the function - TODO: Make this work.
 
 I have a slight preference for option 1, but it doesn't feel 
 particularly clean. Anyone else have better ideas? I know it's 
 annoying, but I don't think ignore it is good enough, as it would 
 be far too easy to create a tarball that blatted any file the user 
 had access to using this method (and using -t to check paths 
 wouldn't help, as the ../ is in the symlink target). I'm attaching a 
 tarball that demonstrates the problem, in case I haven't explained 
 it well enough. If you used $HOME/bin/, and unpacked the tarball in 
 $HOME/tmp, it will create a file in $HOME/bin/myscript.
 
 Nick
 
 0. 
 https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/bsdtar.1.html

I am not sure what the proper approach is.  Option 3) sounds pretty
safe as a starting point.

Any ideas?

Re: [dev] Miscellaneous sbase issues

[Dimitris Papastamos]

On Sun, Apr 26, 2015 at 06:24:18PM -0700, Michael Forney wrote:
 tar
 ---
 Since fb1595a69c091a6f6a9303b1fab19360b876d114, tar calls remove(3) on
 directories before extracting them. I'm not sure that it is reasonable
 for tar to do this because users may want to re-extract archives, or
 extract archives on top a directory structure that already exists.
 Additionally, it is fairly common to find tar archives containing the
 . directory (possibly with a trailing '/'), which were constructed
 using tar -cf foo.tar ..

Yeah that makes sense I suppose.  Some things that need to be done
for tar:

- Investigate aforementioned remove vs unlink issue.
- When we tar a file, we need to ensure to use both name/prefix if the
filename is more than 100 chars.
- Strip leading / from filenames and dangerous things like ../../ etc.

 cat, tee
 
 These utilities read from stdin using fread(3) into a buffer of size
 BUFSIZ. However, fread will read until it fills up the entire buffer (or
 hits EOF) before returning, causing noticeable delay when the input
 comes from other programs or scripts.
 
 To demonstrate this problem, compare the output of these commands:
 
   for i in $(seq 500) ; do printf 0123456789abcdef ; sleep 0.005 ; done
   for i in $(seq 500) ; do printf 0123456789abcdef ; sleep 0.005 ; done | cat
   for i in $(seq 500) ; do printf 0123456789abcdef ; sleep 0.005 ; done | tee
 
 I considered fixing this by making the concat function take an fd
 instead and make a single call to read(2), but this causes problems for
 sponge, which uses a FILE * obtained from tmpfile(3) as both output and
 input for concat. We could also use mkstemp(3) to return a file
 descriptor, and use a FILE * from fdopen for writing, and the file
 descriptor for reading, but this seems unclean to me.

We should avoid mixing file stream I/O and raw I/O.
Check out '2.5.1 Interaction of File Descriptors and Standard I/O Streams'.

 Another option would be to use fgetc and fputc for the concat
 implementation, and let libc take care of the buffering. I'm not sure if
 this has any performance implications.

Sounds about right.

Re: [dev] [sbase] [PATCH] tr: Fix -c option when translating

[Dimitris Papastamos]

Applied, thanks!

Re: [dev] books that rock

[Dimitris Papastamos]

 - KR
 - The practice of programming
 - The dragon book
 - The standard C library. P.J. Plauger
 - Lions book
 - The desing of the unix operating system. J. Bach
 - The art of unix programming
 - Let's build a compiler (this is a articles serie, but
   there is a compiler version)
 - Linkers and Loaders , published by Morgan-Kaufman
 -  Termcap  terminfo

the design and implementation of the 4.4 BSD operating system

Re: [dev] dmenu history

[Dimitris Papastamos]

On Thu, Apr 23, 2015 at 04:39:26PM +0100, maeve.ul...@openmailbox.org wrote:
 http://tools.suckless.org/dmenu/patches/dmenu-tip-history.diff via
 http://tools.suckless.org/dmenu/patches/history
 
 does not work with
 
 http://ftp.de.debian.org/debian/pool/main/s/suckless-tools/suckless-tools_40.orig-dmenu.tar.gz
 via https://packages.debian.org/jessie/suckless-tools

Use upstream dmenu, port the patches if they do not already work and
submit them to the wiki.

Packaging suckless software is useless.

Re: [dev] [sbase] [join] RFC

[Dimitris Papastamos]

On Sun, Apr 19, 2015 at 12:28:05PM -0400, Wolfgang Corcoran-Mathe wrote:
 I've added a manpage and applied all of FRIGN and Hiltjo's style
 changes.

Thanks, applied!

Re: [dev] [sbase] [join] RFC

[Dimitris Papastamos]

On Thu, Apr 16, 2015 at 06:20:40PM -0400, Wolfgang Corcoran-Mathe wrote:
 Hello,
 
 I have made an attempt at join(1). I hope it is worth a look.
 
 See NOTES for some points on which this implementation differs from
 other joins. The handling of -a | -v when used with -o is an issue.

Excellent work!

Please provide a manpage and document any implementation details there.
Also fix any outstanding style issues as mentioned by others and we can
merge this.

Re: [dev] [st] [PATCH 4/3] tresize: remove unnecessary if

[Dimitris Papastamos]

See attached patch.
From f6c18450a99875647d85f633fef00e72a0c1577b Mon Sep 17 00:00:00 2001
From: sin s...@2f30.org
Date: Wed, 15 Apr 2015 09:43:06 +0100
Subject: [PATCH] Fix memmove() invocation with src/dst being NULL

This fixes a segmentation fault on some systems.
---
 st.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/st.c b/st.c
index b1d3791..bb8c365 100644
--- a/st.c
+++ b/st.c
@@ -2788,8 +2788,11 @@ tresize(int col, int row) {
free(term.line[i]);
free(term.alt[i]);
}
-   memmove(term.line, term.line + i, row * sizeof(Line));
-   memmove(term.alt, term.alt + i, row * sizeof(Line));
+   /* ensure that both src and dst are not NULL */
+   if (i  0) {
+   memmove(term.line, term.line + i, row * sizeof(Line));
+   memmove(term.alt, term.alt + i, row * sizeof(Line));
+   }
for(i += row; i  term.row; i++) {
free(term.line[i]);
free(term.alt[i]);
-- 
1.8.4

Re: [dev] [st] [PATCH 4/3] tresize: remove unnecessary if

[Dimitris Papastamos]

On Tue, Apr 14, 2015 at 04:33:56PM +0100, Connor Lane Smith wrote:
 On 14 April 2015 at 13:50, Dimitris Papastamos s...@2f30.org wrote:
  dst and src are required to be valid objects even if n is 0, otherwise
  this is undefined behaviour.
 
 I looked this up in C11. Seems to be the case:
 
  7.24.2.1.2. The memcpy function copies n characters from the object
  pointed to by s2 into the object pointed to by s1.
 
  6.2.6.1.2. Except for bit-fields, objects are composed of contiguous
  sequences of one or more bytes, ...
 
  124) ... there are no pointers to or arrays of bit-field objects.
 
 An object pointed to by s1 or s2 is guaranteed to be at least 1 byte
 long, so memcpy is free to dereference the first byte of either,
 whether or not n  0.
 
 I think it's a mistake that a libc actually go ahead and do this, but
 the C standard suggests that it is permitted, so we should certainly
 do the check.

Yup, well it happens only with the optimized version of memmove() in OpenBSD.
Not sure if this was intended or not.  In any case, it is valid for libc
to assume that src/dst is at least 1 byte long even if n is 0 as you say.

Re: [dev] [st] [PATCH 4/3] tresize: remove unnecessary if

[Dimitris Papastamos]

On Tue, Apr 14, 2015 at 01:43:56PM +0200, Silvan Jegen wrote:
 On Tue, Apr 14, 2015 at 12:55 PM, Gregor Best g...@ring0.de wrote:
  The cause seems to be that for bot `term.line` and `term.alt` are NULL
  at this point. While this does mean that even with a `len` parameter of
  0, the `dst` pointer gets touched, I don't think it's ever right to call
  either `memcpy` or `memmove` with a NULL destination pointer.
 
 I just tested glibc's memmove. The results are:
 
 dst == NULL, n  0: segfault
 src == NULL, n  0: segfault
 
 if dst or src are NULL and n is 0 there is no segfault. Fascinating.

dst and src are required to be valid objects even if n is 0, otherwise
this is undefined behaviour.

The fact that it doesn't crash on this implementation doesn't mean
anything.

Re: [dev] [PATCH] Added dvtm and abduco to rocks.md on website

[Dimitris Papastamos]

On Mon, Apr 06, 2015 at 10:43:16AM -0400, Greg Reagle wrote:
 I am including the patch as an attachment so webmail doesn't mess up the
 formatting.

Push this directly to the wiki repo.

Re: [dev] [rocks] Alpine Linux

[Dimitris Papastamos]

On Mon, Apr 06, 2015 at 06:18:37PM +0200, Vampyrah Broadcasting wrote:
 Hello everybody,
 
 Recently, I found the Alpine Linux distro. I think this fits into the
 rocks page, since it uses musl libc, BusyBox and OpenRC. Sounds cool,
 doesn't it? Especially since almost all distros are using systemd
 right now...

Yes, it is quite nice, sabotage[0] is nice too.

[0] https://github.com/sabotage-linux/sabotage