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 <svartma...@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<svartma...@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. >
