gvim $PATH Malarkey

Posted on

What's the problem then?

I've had some funny issues with PATH in gvim and in turn was giving me a bit of gyp running plugins that called external programs (see the excellent Syntastic, ghcmod, a slew of other useful things but most importantly :make)

Sometimes it'd work and sometimes it wouldn't which isn't very computery. I ended up wasting a bit of time on it and this is what I found:

  • It all depends on how gvim is launched
    • If I launched gvim from the command line everything would be fine
    • If I launched from gmrun it wouldn't be fine
    • Or via a shortcut key I'd configured in XMonad
  • In all circumstances running the :!echo $PATH returned the correct values
  • When it wasn't working echoing gvim's path (:echo $PATH {dropping the !}) return a different value

Weird. It's like gvim had two different paths

Do What?

Running a shell command from the ex prompt (:!echo $PATH) spins up an interactive shell which reads .bashrc just fine and returns the correct PATH from the interactive shell's environment.

The ex command :echo $PATH (again no !) shows gvim's environment inherited from whatever process launched it. Plugins spawning processes use this PATH.

If I launch from the terminal gvim inherits the correct path because .bashrc is read which isn't the case for gmrun, XMonad etc.

And you can fix that?

Yes! Set the path you want for all programs in your ~/.login file and this will be inherited by everything.

This is pretty well documented shell behavior, why so tricky?

Well yeah it is. I read this detailing bash startup files pretty early on which put me on the right path (Ha!) but I still ended up wasting load of time for a number of reasons.

The main trap I fell into was not realizing you have to logout and login again for any changes in .profile to take effect which totally makes sense if you think about it for a couple of seconds.

Also I used terminal Vim a lot (works fine) and sometimes launch gvim from a terminal prompt (also works fine) which made testing tricky until I realized some basic home truths about *nix environments are inherited.

And that sent me down the rabbit hole for longer that it should which is why I'm making a not for myself here :D

aapt not Working on 64 bit Ubuntu

Posted on

fig(i) I was quite literally tearing my hair out! Clip art. Man I love clipart. One day an artist of great talent will reappropriate this under appreciated ouevre and elevate it to high art treading the same path as Warhol and Litchenstein. Fast forward 100 years and it'll be out with formaldahyde drenched sharks and in with gigantic canvas' of Clippy

Handy hints for Android development!

On a 64 bit install I couldn't get my project building, it came up with a cryptic message that aapt would was missing. It's a packaging tool and it was an executable that was exactly in the place it was supposed to be. Oddly enough it didn't run from the command line either and with an arcane message of FILE NOT FOUND.

The problem?

The Anroid build tools I'd installed are 32 bit versions. They won't work without 32 bit installs of glibc and libc++

It was a bit of a pain figuring out that was the problem but once I had it was easily fixed. Tada!

    sudo apt-get install lib32stdc++6 lib32z1

Shell programming: Iterate through the results of find

Posted on

Iterate through the results of find without messing around with IFS

For my own reference really.

find $in_dir -type f -name "*.cpp" -print0 | while read -d $'\0' file
do
    @echo "$file"
done

Not done much in the way of shell programming before, I'd usually use something like Ruby for this kind of thing. Unfortunately I'm becoming increasingly intolerant of boot up time cost for tiny shell scripts so I'm having a dabble with something quicker.

Initial impressions are it's quite antiquated; overly fussy syntax and doing . That aside though it's also plenty powerful and with a bit of effort you can do most things and yep, it's very quick.