scary cool bash scripting inside a Makefile

Makefiles are both scary and wonderful. When both these adjectives are involved, it often makes for interesting hacking. This is likely the reason I use bash.

In any case, I digress, back to real work. I use Makefiles as a general purpose tool to launch any of a number of shell scripts which I use to maintain my code, and instead of actually having external shell scripts, I just build any necessary bash right into the Makefile.

One benefit of all this is that when you type “Make <target>”, the <target> can actually autocomplete which makes your shell experience that much more friendly.

In any case, let me show you the code in question. Please note the double $$ for shell execution and for variable referencing. The calls to rsync and sort make me pleased.

rsync -avz --include=*$(EXT) --exclude='*' --delete dist/ $(WWW)
# empty the file
echo -n '' > $(METADATA)
cd $(WWW);
for i in *$(EXT); do
b=$$(basename $$i $(EXT));
V=$$(echo -n $$(basename "`echo -n "$$b" | rev`"
"`echo -n "$(NAME)-" | rev`") | rev);
echo $(NAME) $$V $$i >> $(METADATA);
done;
sort -V -k 2 -o $(METADATA) $(METADATA) # sort by version key


The full Makefile can be found inside of the bash-tutor tarball.

reading obscure documentation

Sometimes the interfaces you need just aren’t well documented, but thanks to the internets, some websearches, and a useful dictionary, you can often decipher random web documentation jargon to help you produce useful code.

sorting out the confusion

if i’ve been silent as of late, it’s because i’ve been furiously coding away. i’ve got what i think are some elegant implementations cooking, and with any luck my extra work will pay off in hours and days and months of time saved down the road. i’ve got a few interesting (interesting with respect to your average rating of the blog posts on this site) posts cooking in my mind, and hopefully they’ll appear shortly!

in other news, i’d like to reference an already pretty well referenced, but probably less read link, explaining the confusion you’ve no doubt once had to suffer through (or still do)

hth: http://gstreamer.freedesktop.org/documentation/splitup.html

multi monitors and how it should all work (long babble)

at work i use two screens for my day to day workflow. i find it’s much more efficient for doing work, like coding. i’ll often have at least one terminal open, a full screen text editor, and usually a number of references, such as the dbus specification open in a web browser.

i recently just realized that one of the reasons multiple monitors are so useful to me, isn’t because of the increased screen real estate (although that certaintly is an important factor) but because of how the window manager deals with the windows. for example, when i click maximize, the chosen window expands to fill that monitors capacity, and not the entire set of monitors. it would be nice for this type of behaviour to be configurable somewhere for people with ultra large screens, who want to manage their windows better. the closest i’ve found is: winwrangler which i’ve started using at home where i only have one screen. it works sort of along those lines, however i still want more. multiple “workspaces” are essential. no matter how many screens i have, i’ll always need a few workspaces to be able to flip between email and coding– there is no sense in mixing it all together.

the cheeses (“the cheddar”, aka the suggestions i want to make in this babble):

• as i change workspaces both/(all) screens change along with me. adding multiple monitors, essentially extends the size of the workspace. let us call this “mode 1“.

• an alternate behaviour could be to allow “x” independent workspaces on monitor 1, and “y” independent workspaces on monitor 2, and so on… i read somewhere that someone accomplished this with two different x sessions somehow; the problem was that you couldn’t drag windows from one to the other. if someone was able to solve that problem and that type of usability was possible, then we could call this “mode 2“

• even more exciting would be to have a workspace on each monitor sharing a common set of workspaces. for example workspace “c” could be displayed on monitor 1, and workspace “e” could be displayed on monitor 2. you could switch each independently, and in the special case that both monitors were displaying the same workspace, then you would be getting an almost “clone”. the one exception to this being a true clone is that when using multiple monitors, you usually have a static per-monitor panel layout which doesn’t change as you switch workspaces. that functionality is good. all this would be called “mode 3“

• for completeness sake, a *true* clone of one screen to another is a possibility, and should be called “mode 0“.

the complicated point to this discussion is doing what any good mathematician, computer scientist, or ropes-technician (because of the knot tying) would do, and that is to extend the idea of our our modes to the more general case where we can mix and match them for N screens. (to take it a step further would be to let any physical screen be split into M virtual screens, and then use those to solve the above problem!)

think of combining two screens in mode 1, which together are in mode 2 with a second screen, which all together could be in mode 3 with an auxiliary monitor. you’ve got a big mess, and maybe it would be nice to dump this whole setup to your clone output in mode 0 to the projector. now i’m pretty sure that nobody would want that particular setup, but there should be some sensible way to choose what setup you do want, and to configure it appropriately.

i’ve heard that xmonad can apparently do something like mode 3. it makes me want to switch to using that. mode 1 is currently what i’m using. mode 2 could probably be emulated in a window manager which supports mode 3, by confining monitor 1 to only allow even numbered workspaces, and monitor 2 to only allow odd numbered workspaces (mod N if you have N monitors), and mode 0 already exists and is nice for presentations.

i think there are two important things to get right:

1) have a way to create “virtual screens” – it would be nice to be able to benefit from multiple screen logic, without physically buying 8 screens. also this would be indispensible for testing.
2) have a beautifully designed tool for managing the configuration, which obviously uses a well thought out configuration file format.

i would love to hear your thoughts, and if anyone knows of projects with great goals like these, please let me know.

ps: compiz has a “multi output mode” but i’m not sure exactly what it does and if it helps with any of this.

first babble

hello! this blog is intended to be a place where ramblings and discoveries, by and for systems administrators and programmers can be posted and seen by many to ultimately help in the dissemination of useful findings that we wish we had been able to have read here earlier.

if that didn’t make too much sense, perhaps i could rephrase it.