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?
create a script that runs the terminal and then calls the script you want to run:
simple example -
#!/bin/sh
uxterm -e <kick-ass-script>
key bind the new script.
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"
Found this -
#!/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 ...
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.
I am double posting here so shoot me 8)
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
Quotedmenu_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?
That full discussion was.... (on Arch Wiki)
Quotedmenu_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?
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:
#!/bin/sh
exe=`dmenu_path | dmenu ${1+"$@"}` && exec $exe
As 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.
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
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.
^ Thanks PackRat, consider it done
@ 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?
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.
#!/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 0
will basically call a dmenu with all your artists listed out and you can play all or selected, etc. This is just one small example.
Thanks statmonkey... Did you get the latest compiled and did it solve the stest issue?
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)
(http://en.zimagez.com/miniature/october13817050971366x768.jpg) (http://en.zimagez.com/zimage/october13817050971366x768.php)
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 -
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.
Since I posted in the wrong thread will update this and say this issue is solved. I was easily able to compile dmenu and it did in fact solve all the problems I was having. The debian version that is in the repo's is very old and moving to dmenu 4.5 was discussed but never seems to have happened. This means that the dmenu in the repo's is built on the old structure. Not a deal killer but a lot of the goodies are unavailable as PackRat has mentioned. The new version allows more flexibility for calls and patches. Thanks for all the help, sorry I was a little slow on the uptick.
@statmonkey, thanks for that update
I would like you to do something for me and at the same time show the power of a package on VSIDO that not many users know about...
First, is this package you build called dmenu? If that is the case simply run this from terminal
sudo dpkg-repack dmenu
This will package the exact build you just made into a debian deb file... please upload that file to me somewhere and I can use it as the source for the new ISO's and will not have to build it myself
Oh wow that is cool! I'll do this now and let you know. Ha Ha Ha -- well that turned into an extremely interesting little project. The long and short of it is that I can use your neat little tool now to get a dmenu deb but in order to do that I had to build from scratch a dmenu.deb. Perhaps I didn't but it was the only way I could get dmenu installed on my box so apt would see it as part of the apt system. You see I had just done a quick and dirty make clean install and then done my adjusting from there. So when I ran dpkg-repack dmenu the system said "whachyou talkin bout Willis" I know nothing of this dmenu.
dmenu would not build as a deb easily because ..... it doesn't come that way. Or at least I could not find it. So after about 100 ways that did not work I found http://stackoverflow.com/questions/8003739/is-there-a-way-to-automatically-determine-dependencies-when-setting-up-a-dpkg-co (http://stackoverflow.com/questions/8003739/is-there-a-way-to-automatically-determine-dependencies-when-setting-up-a-dpkg-co) in which the answers lay. Outstanding stuff by that guy.
Anyway it created an opportunity. I disliked the way my install was and this allowed me to build it to install dmenu and stest to where I want and I can easily add packages and scripts to the install (now that I know what I am doing) as anyone sees fit to suggest. e.g. I built it so dmenu and stest go into /usr/bin and dmenu_run which is what matters goes into /usr/local/sbin but that is essentially trivial to adjust at this point. I also was able to create and use any dmenu_run of my choice (although I used the one from the Arch Forum for this build). VastOne can't thank you enough for sending me on this little errand. I learned a lot (mostly more about how little I really know) but good stuff.
In the end I did use your tool but after I had already done the install and had a deb. I am attaching the one built with repack named dmenu_4.5.2_amd64.deb. It is version .2 and my initial build from source is dmenu-4.5.1.deb just to keep them straight.
Finally if anyone has read this far and is interested. If there are dmenu tweaks that you would like to have in the Vsido version you can either pass them along to me :) then I can have them or follow the instructions on the link and build your own. Fun stuff!
PS - I haven't tested the repack on my system due to time constraints, the original version kept the proper ownerships of files etc. Both should work the same though I would expect. One more thing you might want to put a hold on dmenu so it doesn't get updated by Sid and you lose you settings.
Wow... excellent perseverance statmonkey! Well done, and I am sure you have learned a few more things!
Thank you for the time and effort in sorting this out... this is the type of help I am always looking for and makes me very proud that users are willing to invest the time and effort that will help every one.
Great job! 8)
Sorry for the long delay, I have a major tournament this weekend and I am spending as much time as I can to practice for it... I will install this tonight and if all testing goes well I may release the ISO later tonight or tomorrow sometime
No worries. I haven't seen any issues but let me know. Really no thanks nec. I enjoyed it, really enjoyed it. Now that I know this pretty well I am trying to resist the temptation to start forking every debian app with a bugaboo that drives me nuts (like mpd and the root crap it does) :'(
I have been buried the last few days as well but do want to research the dmenu add ons and see if there is anything useful. The xft stuff for example might be worth having in as standard. I am using fluxbox but there might be things the other wm's use that could/should be here.
Slight issue - not sure why yet but it seems that dmenu-run needs help when called from a key combo. It has to do with interactive/non-interactive shell but I thought stest would cover that. Starting to wonder if I need to include dmenu-path in the install to make this a little more flexible. It seems wasteful but ... another method would be to call dmenu_run the first time from the cli, this would initialize the dmenu_cache according to .profile and .bashrc but that requires user knowledge that should be avoidable. Sorry, guess I am thinking out loud here.
Sorry for the double post.
I just noticed that when I did a fresh install it is still installing the sucklesstools version of dmenu and not the individual deb version. This means that dmenu_run is the older version and doesn't install stest. In order for dmenu with stest allowing all the latest features to work you will need to remove sucklesstools using apt then install the dmenu deb from this thread. If you want the other suckless tools they will have to be installed individually. I am working on rebuilding a package that will give you all the latest suckless tools and dmenu4.5+ in one go. I am a little busy at the moment but hope to get it done in the next day or so. I'll then pass that along as a more proper fix. So now I will add a sorry that I missed that when I passed this upstream. In my defense I was so giddy at resolve dmenu and getting that together I completely forgot the part about sucklesstools and the debian sid repo's impact on this.
No worries statmonkey, this is all a never ending process...
That is what makes it so much fun! ???
Thanks VastOne, sending you a pm on this
VastOne asked me to summarize what is different about the latest Dmenu and Suckless-Tools I put together for Vsido and I suppose summarize why it was done. The Debian version of Suckless-Tools 39.1 remains behind the actual dmenu in both structure and options. So, I built a new dmenu and repackaged suckless-tools essentially giving Vsido our own custom version. In the latest version 39.1.1 the following has been done:
- Replaced dmenu 4.4.1 with dmenu 4.5, this version uses stest and is much faster and more efficient.
The Debian dev has moved dmenu and dmenu_run to a different folder, I moved them back to /usr/local/bin for consistency with where suckless-tools originally put them.
Added xft support so that you can use xft fonts
Removed dmenu_path since it is no longer used
Added dmenu_select which is a nice user script that allows you to run scripts/etc from dmenu in a terminal and remembers what programs you did this with
The only local adjustments that might be needed would be to add a full path to the dmenu_run script. I find it useful because I use my download folder and a project folder for testing and add those paths. The other thing is to put suckless-tools on hold to keep this from being over written. I will add a write up on at least part of how I did this and maybe each of the three major parts to it, someone might find this interesting. I don't use i3 and know that you guys use dmenu a lot. If anyone has anything they would like to see included in this package in the future let me know I would be happy to include it.
^ Very nice statmonkey...
I have added your deb to your message...
I really appreciate this work and your commitment to seeing it through, well done! :)
This is like my own private thread :D
Anyway, the maintainer and I have been exchanging emails and he will be releasing a new version of dmenu soon that will incorporate most if not all of the changes I suggested so it looks like my developer days are over. LOL. Anyway for consistency purposes he won't be including the two scripts that I did and I am attaching them here if anyone wants them.
dmenuselect allows you to open apps or scripts in terminal and remembers what you chose last time
todo adds a nice vertical todo list with the ability to remove what you accomplished. I find both pretty useful.
^ This is your personal ChangeLog.... :P
Well done getting your work to the developer and convincing him it is needed...
Thanks for this statmonkey!
I appreciate your thanks but let's not over state my role in this. I learned a lot that's a fact and I think the maintainer was headed there anyway I just pushed him a tad. The important thing is we all get a better dmenu out of the deal and perhaps gained the knowledge that despite my rudimentary skills anyone can contribute. Actually that is more of a reminder to me than anything else and I really need to share more than I have been. Also reminding you VastOne that had you not given me the initial push here I wouldn't have done a thing.
Sorry, I have been out of the loop for a while with some project work. I had this path issue resolved in my last build of dmenu so not sure what version you were running PackRat but I will take a look at it. The default dmenu and suckless tools I built should source the path from the $USER .bashrc. That being said I saw that Vasudev (the dev for dmenu) released a new version moving dmenu to the /usr/bin location and including dmenu-path in the build with stest. I am not sure at the moment what the reason for this is but will contact him and ask. I will also play a little. I don't think it will work that way (dmenu should only call one or the other not both), but theoretically if both stest an dmenu-path are called you should be able to adjust the sourcing in dmenu-path. Anyway, if you do an update and were using to Vsido dmenu you hot/keys etc will probably not work and there may be other consequences.
I saw that update from the dev come in today...
Hopefully your schedule lets you back to some normalcy!
Cheers!
From what I can see the latest Debian version does the following differently than the Vsido version:
Moves dmenu from /usr/local/bin to /usr/bin (which seems trivial at most)
Excludes xft from the dmenu itself and offers it as part of an alternative dmenu that needs to be called separately (so if you want the xft features you have to call that version explicitly - not sure why this was done, perhaps there are some consequences I am unaware of with the xft diffs) and then adds them in using a post install script versus having them just built in.
Vsido version included the scripts dmenuselect and todo which allowed user to run and dmenu to remember console apps and to create todo lists in a drop down menu (these are nice features but not critical)
Does not include man pages for dmenu, etc which our Vsido version did
The actual package has the control and Debian documentation in the wrong place (trivial)
Summary - Overall it's the same core dmenu with some of the functionality we had removed, some we had made optional and the files moved around. That said it will work and should provide the same basic functionality with a few variations. For my purposes though I will be making a 64bit version of the Vsido version. I want xft in the build, the xtra scripts, etc. I am not sure whether anyone else uses the Vsido version I made but will upload it if there is interest. Here is a download link to the latest Vsido_sucklesstools https://sourceforge.net/projects/sucklesstoolsvsido/files/ (https://sourceforge.net/projects/sucklesstoolsvsido/files/)
PackRat - regarding the path issues you had. Again not sure what version you are running but both the Vsido version and the newest version use the same basic calls. Dmenu_run if called sources either the files $HOME/.cache or $HOME/.dmenu_cache if they exist and if they don't exist it builds them using stest (a little exe that verifies that they are executable, etc.) which sources $PATH (or the environment path from the shell). If your dmenu is not including all in your $PATH I would recommend the following (assuming you have the latest dmenu installed):
check to see whether you have $HOME/.cache or $HOME/.dmenu_cache and then look at which ever one exists in a text editor.
if you don't see all the files you would expect (for example you see it hasn't sourced the full paths from your .bashrc then rename that file to say .filename.bak)
run echo $PATH to make sure you shell path is what you think it is and once you are satisfied
run dmenu_run to generate a new dmenu_cache or .cache depending on your XDG config. This should repopulate the file correctly and all your scripts, etc that are part of your path should be there. You know more than I do so I am pretty sure that if you don't get the proper results you can open dmenu_run and see what it is trying to do and figure out where the problem is but I doubt there will be any. It's a pretty simple script.
I will build dmenu_40.2 in the next day or so. Once again if there is anything anyone believes should be there that isn't let me know and I can add it. If you have a killer dmenu script that you think we could all benefit from pm me with it and I will add it in. I am always willing to steal from any of you. Of course if you think I am all wet then you can post that in a pm as well :)
Attaching suckless-tools_40-2 for anyone who wants it.