I had a little time yesterday afternoon at lunch and last night while watching MNF to work on a few things I’ve had on the back burner. In a nutshell, I’ve wanted to further tie things together in screen with some kind of menuing. GNU screen allows users to set up keybindings to launch new apps in addition to using an escape sequence (ctrl-a : [command]) to launch things.
I wanted to go a step further because I wanted “dynamic” menus that can be easily edited and customized as well as menus that are more oriented towards data than applications. The former is easy enough: just implement a script and modify it as needed. The latter can be as simple or complex as desired. I’m practical, so I went the simple route.
Let me qualify this by saying I know it’s not fancy, it lacks eye candy, and that there are plenty of ways to skin this cat. I’ll also admit my primary impetus for this was a desire to get my streaming audio (pls files) in a list from which I could choose for streaming (and streamripping) without typing “mplayer -playlist path/to/streams/type[tab]” etc. — not the highest priority in my life, but something I’ve wanted for a while. I didn’t want to bother with setting up databases, I didn’t want some WHILE bullshit polling the system to scan for any new files to add to the database, and I wanted to stick with shell scripts without getting into window dressing like dialog. Just get a quick list of what’s available when I select a menu entry and play it in a new screen pseudo-terminal. Easy, no nonsense, little drain on system resources, fast, efficient. In other words, screw amarok and whatever is gnome’s bloat-du-jour.
I wrote a main menu for screen that solves the first issue. I can fill it to my heart’s content with custom commands (it’s sparse now) and use it to call other menus (as I’ve done temporarily until I finish my multimedia script which is now in separate pieces). Note that this was written ksh-specific and may need adjustments in bash or other shells.
#!/bin/sh # lucky13linux.wordpress.com - Mon Oct 6 21:36:57 CDT 2008 # menu for running apps in screen # also calls other scripts from $HOME/bin print 'select application to open ' PS3='app: ' select application in \ 'snownews' \ 'gmail' \ 'mc' \ 'aim' \ 'pork' \ 'epic4' \ 'calcurse' \ 'podcasts' \ 'streams' \ 'playlists' do case $REPLY in 1 ) RUN_THIS="snownews -u" ;; 2 ) RUN_THIS="elinks https://gmail.com" ;; 3 ) RUN_THIS="mc" ;; 4 ) RUN_THIS="naim" ;; 5 ) RUN_THIS="pork" ;; 6 ) RUN_THIS="epic" ;; 7 ) RUN_THIS="calcurse" ;; 8 ) RUN_THIS="$HOME/bin/mypodcasts.sh" ;; 9 ) RUN_THIS="$HOME/bin/myplaylists.sh" ;; 10 ) RUN_THIS="$HOME/bin/mym3u.sh" ;; esac if [[ -n $application ]]; then screen -t $application $RUN_THIS break fi else print "invalid response... try again" done
This gives me my basic menu and frees keybindings in my .screenrc (which has gotten a little meiotic lately and difficult to remember sometimes without hitting “ctrl-a ?” for help; or typing “alias” periodically to remember all my little shortcuts). The menu is bound to one of the keybindings freed up (ctrl-a e) so it can be launched at will, and it terminates when the new terminal opens with the selection (which means I don’t have a ton of stuff to close and check and everything). The launched instances also tidy themselves up when finished, making “window” management in screen more automatic. In short, it acts a little bit more like a window manager than a terminal multiplexer. Kind of.
My original goal of being able to reduce work/typing to play audio was benefited by my organization of directories, but it’s flexible enough that it can be adapted to less organized files. I try to keep files of the same type in one nested directory. So, as you can see in the next script, my audio is all in one directory and broken down according to podcasts, streams, and songs by genre and artist. Well, you can’t see all that in this particular script. What you can see is that I just had to define one directory and search it for the relevant files. That allows SELECT to format the results in columns of the individual stream files rather than in one column with full paths, allowing more to show up on one page. If you only have a few files, no problem. I have over 40 (and I haven’t copied over the other ones from my other hard drive or backups yet).
#!/bin/sh # lucky13linux.wordpress.com - Mon Oct 6 13:30:46 CDT 2008 # this script is ksh-oriented but may work for other shells # and can be linked to a keybinding in screen to open a menu. STREAMDIR="$HOME/audio/streams/" print 'Select stream to play: ' PS3='stream? ' select STREAMFILE in $(ls $STREAMDIR | grep -i pls | sort); do if [[ -n $STREAMFILE ]]; then mplayer -playlist $STREAMDIR$STREAMFILE break else print '*** invalid, try again...' fi done
Note that I don’t open this one in yet another screen pseudo-terminal but leave it in the one in which it opens. I initially did but some things open too fast or too slow and the screen numbering order would get wonky.
As I wrote above, I’m probably going to aggregate my multimedia scripts into one script at some point. I wanted to see how many keybindings I would need to do each thing separately. Answer: way too many.
NOTE: This post may be edited for formatting later. I’ll also try to add some screenshots to it later today.
EDITED – Thu Oct 16 2008: corrected part of the if loop in the script for the screenmenu above. I now have more entries in mine and have added additional menus for various things to further customize my system. Additionally, I’ve rebound the w key in screen (ctrl-a w) to open the navigable list of terminals in screen (which is bound by default to ctrl-a “). This still allows for use of ctrl-a-ctrl-w for the same thing the default binding of ctrl-a-w does while making it a little easier to navigate through terminals.
made with: VIM - Vi IMproved 7.2 (2008 Aug 9, compiled Oct 5 2008 12:03:46) and the vimpress plugin OpenBSD 4.3 GENERIC#0 i386