Some years ago I wrote emenu. A dmenu like tool for command line. It supports various input methods and its about 250 loc.
http://hg.youterm.com/menush/file/b25e917ad97a/eread.c
On 01/09/2011, at 23:07, Bjartur Thorlacius <svartman95_AT_gmail.com> wrote:
> Þann fim 1.sep 2011 20:05, skrifaði Rafa Garcia Gallego:
>> On Thu, Sep 1, 2011 at 7:46 PM, Bjartur Thorlacius<svartman95_AT_gmail.com> wrote:
>>> Why not write the UI to tty directly? Or do you suppose redirecting stderr
>>> to null to get rid of the UI is worth supporting?
>>>
>>
>> Actually I might as well had done this. However, I had nothing to
>> write to stderr anyways and it seems cleaner this way: the file
>> descriptor is open and points to the tty, so why not use it?. Bonus
>> feature: you may redirect it to another tty for -say- debugging.
>>
> Debugging is more than a good enough use case for me. :)
>
>> Anyways, I doubt anyone redirects stderr to /dev/null by default,
>> much less for an interactive program. You could (maybe should)
>> redirect stderr in the command you use to feed slmenu its options
>> (unlike say for dmenu, which usually just pollutes your
>> .xsession-errors a bit). Either way, slmenu does not print its UI
>> until it's finished reading stdin, same as dmenu.
> I was thinking more of the lines of users redirecting stderr either to log files or a separate terminal.
> The former might be reasonable in scripts, even ones prompting users, if they call overly verbose commands. Suckless shan't cater to such insanities. In the latter case, writing to stderr might in fact be desired. But ultimately, both are probably rare.
>
Received on Fri Sep 02 2011 - 01:22:38 CEST
This archive was generated by hypermail 2.2.0 : Fri Sep 02 2011 - 01:24:03 CEST