Missing Token

MacOS path_helper not so helpful

Tue, 15 May 2018 00:48:23 -0600

Do you use shell-based version managers like nvm, pyenv, or rbenv, in combination with tmux on macOS? If so, you may be in for a surprise. Outside of tmux and screen, version managers will work fine, but inside the session, system or Homebrew installed tools will be used instead. What’s going on here?

Path Helper

MacOS has a utility called path_helper that initializes the PATH environment variable by reading paths from /etc/paths and then any file under /etc/paths.d. The path helper utility doesn’t technically set the PATH, but will output the shell commands to set it accordingly. It is eval‘d by the first file sourced on a login shell for sh, bash, and zsh:

# Code snippet found in /etc/profile and /etc/zprofile
if [ -x /usr/libexec/path_helper ]; then
    eval `/usr/libexec/path_helper -s`
fi

Path Helper and Existing PATH

If you already have a PATH variable set when invoking path_helper, such as when you start a new tmux session, path_helper will ‘intelligently’ create a new PATH by merging the loaded paths with existing PATH and removing duplicates. The problem is, while path_helper deduplicates paths, it doesn’t preserve order. If you have a custom path or paths prepended to the default list in your ~/.bashrc or ~/.zshrc and invoke the path helper, your custom path(s) will now be at the end of the PATH variable. This effectively disables all your version managers by prioritizing system binaries over them.

Solution

Luckily there is a setting in tmux to tell it to avoid creating a login shell when starting a new session. This avoids sourcing /etc/[z]profile, and path_helper does not get invoked. Simply add this setting to your tmux.conf and you should be good to go:

# Don't create login shells
set -g default-command "${SHELL}"

If having tmux create login shells is somehow a requirement for you, your only other choice is to create or edit the first user controlled file that gets sourced in a login shell, either ~/.bash_profile or ~/.zprofile, and add some code to fix your PATH variable by comparing the existing PATH against the paths generated when running path_helper in a clean environment and then rebuilding the PATH variable with user-defined paths prepended to the system-defined paths:

reorganize_login_subshell_path() {
    # save path as old_path
    local old_path="$PATH"
    # run path_helper against an empty PATH
    PATH=''
    eval `/usr/libexec/path_helper -s`
    # At this point the PATH contains only system-wide paths.

    # If paths are the same this is not a subshell or no user-defined paths are
    # set. In other words, the PATH is correct and there is no work to be done.
    if [ "$old_path" = "$PATH" ]; then
        return
    fi
    # Use parameter substitution to subtract system-wide paths from old_path,
    # leaving only user-defined paths. "${var#Pattern}" means "Remove from $var
    # the shortest part of $Pattern that matches the front end of $var."
    local user_defined_paths="${old_path#$PATH:}"

    # Rebuild PATH with user-defined paths prepended to system-wide paths.
    PATH="$user_defined_paths:$PATH"
}

if [ -x /usr/libexec/path_helper ]; then
    reorganize_login_subshell_path
fi
# remove path reorganization function to avoid cluttering environment
unset -f reorganize_login_subshell_path

The latter approach here is not recommended as it attempts to solve the problem of PATH munging with more PATH munging, making it all the more difficult to reason about the state of your shell environment.

The Why of "Wat" [Ruby edition]

Thu, 13 Nov 2014 23:48:23 -0700

In his wonderfully sarcastic lightning talk, Wat, Gary Bernhardt explores the dark side of Ruby and Javascript with examples that seem to defy logic. When I first saw Wat, I immediately wanted to know more. How do these strange behaviors come about? Is it an interpreter error, designed into the language, or something else entirely? If the behavior is intentional, what is the reasoning behind it? I decided to take the plunge and find out for myself.

Let’s talk about Ruby

Undefined variable self assignment

a     # => NameError: undefined local variable or method `a' for main:Object
b     # => NameError: undefined local variable or method `b' for main:Object
a = b # => NameError: undefined local variable or method `b' for main:Object
a = a # => nil

Why would Ruby transform an undefined variable to nil in self assignment? Let’s first breakdown a typical variable assignment in Ruby:

foo = 4

Ruby initializes foo to nil.
Ruby evaluates the expression on the right-hand side. In this case the result is simply 4.
Ruby assigns the result of the right-hand side evaluation (4) to foo.

And now the same breakdown of a self assignment:

foo = foo

Ruby initializes foo to nil.
Ruby evaluates the expression on the right-hand side. To do this, Ruby looks up the value of foo, which by this point is nil.
Ruby assigns the result of the right-hand side evaluation (nil) to foo.

The key point here is that Ruby will always initialize the variable on the left-hand side before evaluating the expression on the right-hand side. This guarantees that any undefined variables on the left-hand side will be defined by the time the right-hand side is evaluated.

We now know how Ruby allows for self assignment of an undefined variable, but that still leaves why. One reason this seemingly odd behavior exists is to accommodate a somewhat common idiom – conditional setting of variables:

class TaskList
  def tasks
    @tasks = @tasks || []
  end
end

(Note that the above is usually written @tasks ||= [], though the two aren’t equivalent¹.)

If @tasks is undefined, and Ruby doesn’t initialize @tasks before evaluating the right-hand side of the assignment, this idiom would not work as intended.

Ruby and bare words

ruby has no bare words # => NameError: undefined local variable or method `words'

def method_missing( *args ); args.join(" "); end

ruby has bare words # => "ruby has bare words"

This one is nothing more than an interesting application of language features, some more well known than others. The first and probably best known feature is that parenthesis are optional in Ruby method calls. Because of this, Ruby interprets ruby has no bare words as if we wrote ruby( has( no( bare( words ) ) ). Second, when making a method call, Ruby searches the current scope for a matching method definition. If it cannot find one, it passes the method name in question to method_missing². You can define your own method_missing to provide extra runtime functionality. In this case, our method_missing takes the passed in method name (plus zero or more other arguments) and returns a string of all those arguments joined together. Let’s break up the example to illustrate how the string is built:

# Starting with the innermost method call
method_missing( "words" ) # => "words"
method_missing( "bare", "words" ) # => "bare words"
method_missing( "has", "bare words" ) # => "has bare words"
method_missing( "ruby", "has bare words" ) # => "ruby has bare words"

Ruby behaves this way because part of its core functionality has been broken, making the why pretty pointless here. Note that in Ruby 1.9.3+, arguments are passed to method_missing as symbols instead of strings, which causes infinite recursion. This is because Array#join attempts to convert the symbols to string objects by calling to_str, and since no to_str method is defined for the Symbol class, the method call gets passed to – you guessed it – method_missing.

Let’s talk about Javascript

As it turns out, the Javascript portion of wat has already been covered by Adam Iley’s well written blog post. I discovered this post while researching my own, and was surprised to find it had not only already been written, but with an identical title! Thanks Adam!