Dmenu and scripts

[statmonkey]

I have been playing around with dmenu (you know reading the arch forums, stealing the stuff and then with half and idea of what I am doing trying to run things and having them explode).  Specifically I am wondering how you can get dmenu to call a script that runs in a terminal from a hot key call.  Like this SUP+S pulls up dmenu and then somescript is selected then ... crickets.  Shouldn't I be able to get the script to run or do I have to do all this in the terminal?  Very late at night for me so if this is stupid don't hammer me but did I miss in the configuration somewhere or am I off on the concept of dmenu completely?

[PackRat]

create a script that runs the terminal and then calls the script you want to run:

simple example -

Code: [Select]

#!/bin/sh
uxterm -e <kick-ass-script>
key bind the new script.

[dizzie]

I have ~/bin in my $PATH, and my script have the +x bit set (chmod +x script.sh), so yeah do as said above "terminal-of-choice -e script.sh"

[PackRat]

Found this -

Code: [Select]

#!/bin/sh
cachedir=${XDG_CACHE_HOME:-"$HOME/.cache"}
if [ -d "$cachedir" ]; then
cache=$cachedir/dmenu_run
else
cache=$HOME/.dmenu_cache # if no xdg dir, fall back to dotfile in ~
fi
APP=$(
IFS=:
if stest -dqr -n "$cache" $PATH; then
stest -flx $PATH | sort -u | tee "$cache" | dmenu "$@"
else
dmenu "$@" < "$cache"
fi
)

grep -q -w "$APP" ~/.dmenu_term && urxvtc -e $APP || echo $APP | ${SHELL:-"/bin/sh"} &
it's a replacement script for dmenu_run that will launch terminal apps that are listed in the $HOME/.dmenu_term file.

original link at arch forums - https://bbs.archlinux.org/viewtopic.php?pid=1088164#p1088164

You can replace urxvtc with your terminal of choice, and change location/name of .dmenu_term if you prefer; edit script accordingly. The .dmenu_term file is just a plain text list of apps that run in a terminal - I tested it with htop, works fine. It accepts all the dmenu customizations so you can change the colors, font etc ...

[statmonkey]

Dizzie sorry, my post was a little confusing but PackRat somehow managed to interpret my gibberish. 

PackRat, yes that is exactly what i was after.  The problem (for me) was that when I was reading that thread I was so giddy about some of the other crazy arse stuff that I saw you could do with dmenu I skipped that post and went straight to TOYS!!!! I found it again last night and was planning on trying it today but ... thanks to your kindness I don't have to wade through all that it's right here   I love Vsido. 

Thank you both for the help.

[statmonkey]

I am double posting here so shoot me 

In following that thread (from PackRat) I have an issue on my box (at least).  The changes to dmenu_run include a call to stest.  Which from what I can find is not on my box.  In the posts I have read it is a standard part of dmenu.  Can anyone out there confirm for me that they have or don't have /usr/bin/stest ?  According to what I have read it is a replacement for dmenu_path

dmenu_path was removed in favor of stest,

that seems to be just the arch repo/fork apt says I have the latest suckless tools.

Anyone else seen this or have a solution? 

[VastOne]

That full discussion was.... (on Arch Wiki)

dmenu_path was removed in favor of stest, which is included into dmenu_run

I do not run dmenu so I am as dumb as a rock, but what is dmenu_run?  A part of suckless_tools?

[statmonkey]

dmenu is pretty awesome.  Dmenu run is basically the config script for dmenu.  As PackRat posted below a pretty good example.  It is installed as part of suckless_tools and on the Vsido version it is:

Code: [Select]

#!/bin/sh
exe=`dmenu_path | dmenu ${1+"$@"}` && exec $exeAs shown above it uses dmenu_path which is an executable.  There is no stest in our version from what I can tell but I can't find much out about our version or what the differences are and not sure why we are getting dmenu_path versus the stest version.  I am guessing that there has been a fork or two somewhere between the arch version and this one. I have coded up something to work around this and sort of do what I want but now curious as to what the differences are and why.  A quick check of dmenu 4.5 from the suckless site shows stest in the archive but it's not on my box and apt says dmenu is up to date.  So I am guessing I would have to uninstall dmenu and build the latest version.

[VastOne]

Thanks for the explanation statmonkey, appreciate it

Let me know if you building from scratch does solve it... I will do the same on the next release if it does in fact do what you all want

[PackRat]

If you uninstall and then build dmenu from source, dmenu, dmenu_run, and stest will be installed to /usr/local/bin by default.

It also appears that the vertical patch referred to in the arch forum is now included, but not the x,y,z coordinate configurations they are posting.

@vastone - if you will continue to include i3 with VSIDO, I recommend that dmenu be added; it's the common/standard method of generating a menu for tiling or minimal window managers.

It's actually a very powerful/flexible piece of software - custom menus that include scripts can be piped to dmenu; I've seem some pretty clever menus generated by power users.

[VastOne]

^ Thanks PackRat, consider it done

[VastOne]

@ PackRat and statmonkey,

Is there a default config for dmenu that is good enough or can either of you supply a good setup for the default?

[statmonkey]

PackRat may disagree but the basic install is a good place to start and probably good enough.  The thing is there is just sooo much you can do as PackRat mentioned I have also seen some incredibly clever stuff.  For example there are menu's and scripts for mpd that make plait and things like that unneeded.  Even with the dmenu basic (without stest) you can call scripts that will work either in console or as needed.  All dmenu_run does is set the environment (simple way to put it) and then call dmenu as is.  As I am learning you can set all sorts of cache, history, terminal, menu, document, etc files that will give you scripts of all sorts. .eg.

Code: [Select]

#!/bin/bash

if [[ -f $HOME/.config/dmenurc ]]; then
  . $HOME/.config/dmenurc
else
  DMENU="dmenu -i"
fi

ARTIST=$( mpc ls | $DMENU )

if [[ $ARTIST == "" ]]; then
  exit 1
else
  ALBUM=$( echo -e "Play All\n$( mpc ls "$ARTIST" )" | $DMENU )

  if [[ $ALBUM == "" ]]; then
    exit 1
  else
    mpc clear
    if [[ $ALBUM == "Play All" ]]; then
      mpc add "$ARTIST"
    else
      mpc add "$ALBUM"
    fi
    mpc play
  fi
fi

exit 0will basically call a dmenu with all your artists listed out and you can play all or selected, etc. This is just one small example.

[VastOne]

Thanks statmonkey... Did you get the latest compiled and did it solve the stest issue?

[PackRat]

Okay, some whacked behavior on my end so hope this doesn't end up posted 3-4 times -

Yes, the default behavior is good; dmenu sources the system $PATH and then narrows the list as you type - so typing "g..c..o.." will allow you to select gcolor2 from the list with arrow keys. As long as you can type the first couple letters of the app, you're good (screenshot)



As far as I know, dmenu still only sources the system $PATH, not the $PATH variable in the user's .bashrc so to make your custom $PATH available to dmenu, it will need to be added to the system $PATH. I have -

Code: [Select]

export PATH=$PATH:~/bin:~/conky
in my ~/.fluxbox/startup and other wm startup scripts. It works, but may be obsolete.

If you're a script-kiddie of sorts, then dmenu becomes a really powerful tool. Menus for whatever you do - i.e. music, movies, coding, internet - can be created and menu(s) piped to dmenu with key bindings.