Re: [dev] [dmenu] dmenu_run in C

From: Anselm R Garbe <garbeam_AT_gmail.com>
Date: Tue, 16 Dec 2014 12:41:35 +0100

On 15 December 2014 at 16:42, Nick <suckless-dev_AT_njw.me.uk> wrote:
> Quoth Calvin Morrison:
>> On 14 December 2014 at 11:44, M Farkas-Dyck <strake888_AT_gmail.com> wrote:
>> > On 14/12/2014, Jonny Langley <jonny_AT_kingslea.school.nz> wrote:
>> >> It adds just under 100 LOC, but means the shell scripts
>> >> dmenu_{run,path} are unneeded.
>> >
>> > ; wc -l dmenu_^(run path)
>> > 2 dmenu_run
>> > 13 dmenu_path
>> > 15 total
>>
>> how many lines of code is an interpreter though?
>>
>> then again, is there any Unix or Unix like system without a shell?
>
> Don't forget that we get to remove stest too:
> ; wc -l stest.[1c]*
> 87 stest.1
> 84 stest.c
> 171 total
>
> And do you remember the reason for stest? Because unix tools and
> shells have a habit of being ever so slightly incompatible.
>
> So I support the idea of just doing this in C.

You have to apply the Unix philosophy to each of such concerns first.
The dmenu_path shell script is packaged with dmenu because it provides
a simple demo for similar but potentially custom dmenu input
generators. The script itself is a good example of the Unix principle
in action, whereas the C version of it applies it only to some extent
(it is KISS though and does only one dmenu_path task -- perhaps it
does it well).

Of course packaging stest with dmenu is only an intermediate excuse
until sbase becomes the official suckless util set. Then we can base
our scripts on sbase instead.

In summary, I'd suggest to rename the C version of the dmenu_path into
scanpath or similar to avoid the name clash. Then we can package it
with dmenu and amend dmenu_run to use scanpath instead, but keeping
dmenu_path in. In several months we can delete stest and rely on
sbase.

_AT_sbase developers:
For sbase I would suggest to have some 9 command-like derivative that
works in systems (and one can rely on) that feature a non-sbase util
set by default, but to make it easy to always use the sbase version
instead. In p9p one can use '9 test' for example to ensure the p9p
version of test. Having something like 's test' to ensure the sbase
version would be cool. What do you guys think?

Best regards,
Anselm
Received on Tue Dec 16 2014 - 12:41:35 CET