I like to know if there's anything that I may have missed in this implementation. The method tries to provide the absolute path of the binary or script which is likely to execute based on the provided path. I carefully based it from how cmd.exe chooses the file to execute. It intends to be platform-independent but so far it's only tested with an NT-based Windows and Linux. I don't plan to support legacy Windows or DOS that may not have PATHEXT just in case Ruby supports them.You may also wonder why some declarations happen within a condition line but I find it hard seeing anything in the code like test flags that run even when they are not necessary so please just avoid talking about it or anything that's only about coding style or philosophy. Some may argue that it's not Ruby-like but it's simply functionally wrong or programmatically wrong to me. I also avoid significant redundant queries. Despite this I still balance efficiency and readability. I'm also strict to uniformity in coding style. Ruby may be an expressive language as some may say but I believe it's not restricted from showing correct logic structure and choosing not to compromise it for the sake of readability is an option.module Bin  def self.which(cmd)    exts = (pathext = ENV['PATHEXT']) ? \        pathext.split(';').select{ |e| e[0] == '.' } : []    if (cmd[File::SEPARATOR] or (File::ALT_SEPARATOR and cmd[File::ALT_SEPARATOR])) \    or (paths = ENV['PATH']).nil? \    or (paths = paths.split(File::PATH_SEPARATOR).select{ |e| File.directory?(e) }).empty?      if not exts.empty?        return File.absolute_path(cmd) \            if not (ext = File.extname(cmd)).empty? \            and exts.any?{ |e| e.casecmp(ext) } \            and File.file? cmd and File.executable? cmd        exts.each do |ext|          exe = #{cmd}#{ext}          return File.absolute_path(exe) if File.file? exe and File.executable? exe        end      elsif File.file? cmd and File.executable? cmd        return File.absolute_path(cmd)      end    elsif not exts.empty?      has_valid_ext = (not (ext = File.extname(cmd)).empty? and exts.any?{ |e| e.casecmp(ext) })      paths.unshift('.').each do |path|        if has_valid_ext \        and File.file? (exe = File.join(path, #{cmd})) \        and File.executable? exe          return File.absolute_path(exe)        end        exts.each do |ext|          exe = File.join(path, #{cmd}#{ext})          return File.absolute_path(exe) if File.file? exe and File.executable? exe        end      end    else      paths.each do |path|        exe = File.join(path, cmd)        return File.absolute_path(exe) if File.file? exe and File.executable? exe      end    end    nil  endend
A platform-independent implementation of which in Ruby
ruby;file system;portability
I see at least two issues, aside from the atrocious code style:String#casecmp returns an integer, much like strcasecmp does in C. But in Ruby, everything other than false and nil is truthy.  So if a PATHEXT environment variable is present and has at least one extension, and cmd has an extension, has_valid_ext will always be true -- regardless of whether cmd's extension is valid.  The only thing keeping it from affecting results is the low chance of, say, whatever.zip being both executable and in the search path.Windows and Linux differ in how they handle the current directory when searching.  Windows checks it first before resorting to a path search, and Linux won't check it at all unless the path either includes it, or is empty.  If $PATH were set to blah, for example, Linux wouldn't even bother looking at ..Since you eliminate invalid directories before checking for emptiness, though, you don't catch the case where the path contains only inaccessible locations -- so you end up checking the CWD, making the result in Linux potentially different from what which would report.  Not sure how significant it is, since it's rather uncommon to have such a broken PATH variable...but it doesn't help.Aside from that, there's a difference between multi-platform and platform-independent.  This code can pretty much be considered the former (once it's fixed), but by definition is not the latter.  Anything that depends solely on system environment variables, has made assumptions about the platform that might not hold true.For example, you assume that if PATHEXT exists, that (1) it has a certain significance, and (2) it is case insensitive.  You assume that iff there is a list of directories to search for files in, it will always be called PATH.  Without knowing what OS you're running in, neither assumption can be supported; at best, they're educated guesses.