From: Stu <stu@...>
Date: 2013-01-02T17:00:25+09:00
Subject: Re: using shebang with rvm?

Wes ~

That is what I was saying. Also this is correct if you deviate from
any posix syntax or use a third party language. So env would also be
used for bash or zsh where bashisms( i.e. shell extension) are used
but not ash.

example to use bash it's the same semantically for portability if one
requires bash or zsh specific syntax:

#!/usr/bin/env ksh
#!/usr/bin/env bash
#!/usr/bin/env zsh
#!/usr/bin/env fish


All bourne derived shells( i.e. not csh) are backward compatible with
posix sh which is a small mixture of original bourne syntax and korn
syntax.

The only time you would ever want to use a direct path is with a posix
sh script as so:

#!/bin/sh

or csh ... but don't use csh =)

#!/bin/csh -f

If your really curious on the spec you can be read here:
http://rubyprogrammer.net/~stu/posix/

You can set your path inside your interactive rc file with the $PATH
variable. It's delimited with a colon and is a first positive match
wins hash. If your writing a script that depends on knowing where your
binaries are you can use a variable to hold the direct path to the
executable or set the path variable directly inside the script.

Trivial example of embedded ruby embedded inside shell:

#!/bin/sh
r=/path/to/mri/ruby20
$r <<EOF
puts "Hello, world!"
RbConfig::CONFIG.each_pair { |k,v| puts k+':<=>:'+v }
s=RbConfig::CONFIG.values.grep /bin\/*sh/
puts <<EOR
Bye bye your current shell is #{s}
Your ruby is ${r}
EOR
EOF

Set the execute bit and run it through a pipe to less or tail -2 for
example. Have another ruby. Wanna glue one to the other? Create
benchmark results? Just some ideas. Maybe not the most practical
examples but provide you some insight on what may be useful with a
couple lines of shell code.

Bash is an okay shell for beginners. Consider zsh for interactive use
as it has a nice flow to development once you begin to customize it. I
have ash on FreeBSD which is very fast for shell scripts as it's <70kb
binary in contrast to bash being over a meg. I don't believe they
ported Almquist's shell to OSX. Maybe homebrew has it (sometimes under
the name dash in the gnu distros so I'm unsure what got ported on osx
as it's a mashup of FreeBSD kernel with BSD, next and gnu userland)...

My main toolset preference tends to be sh for system level automata,
primarily because that is my background... consider scripting a
network where ruby may or may not be present machine to machine , ruby
for larger stack oriented projects where oops, arrays may be needed,
zsh, vi, irb for my preferred development stack.

I also use rvm which is one of the few bash specific scripts, actually
I would call rvm a framework utility at this point, which it is obvious where
posix was considered but the need for the automation on directory
switching with rvmrc for developers whom needed various sandboxing
with minimal setup usurped avoiding the extended syntax of bash. The
need for arrays also is where bash becomes the dependency.

Take a look at Wayne's code. You will see some of the best shell code
by someone who takes such things seriously by studying rvm.

Other projects of the same vein such as chruby or rbenv make no effort
for portability outside of forcing user to install bash or run a
computer only capable of supporting homebrew .

I do find it ironic how the author of rbenv promoted it initially with
sort of a dunning kruger style marketing his way was the "one true
way" when it's far from a minimalist's alternative to rvm while
deviating from posix for no reason other than it's obvious the rbenv
developer is not a system administrator and knows of nothing other
than how to provide FUD with ad hominem bullet points like his lamers
statement that rvm is dangerous and error-prone. I guess this sort of
thing is how people get themselves noticed when either vying for some
corporate employment contract or simply to gain some sort of
superficial notoriety.

On a simpler level consider command env to work like how you
understand how the ruby interpreter yields results from it's block
iterators. /usr/bin/env ruby basically has ruby as an argument to the
command env which locates ruby in the path hash and yields the result
which in this case is the path located to the shell which instructs
the kernel to create a memory overlay to load ruby after env evaluates
the ruby location; From there ruby will be executed in place in order
to evaluate any of the code after which in turn yields each token to
the executable. The env will work with any command hashed from the
$PATH global environment variable.

Happy Hacking.

~Stu

On Tue, Jan 1, 2013 at 9:44 PM, Wesley Rishel <lists@ruby-forum.com> wrote:
> Stu wrote in post #1090776:
>> It's primarily for portability. Using env more or less defeats
>> portability issues as every box could have ruby installed somewhere
>> else.
>>
>> ...
>
> Thanks, Stu, the entire note was very helpful.
>
> I am not sure if you are suggesting that I should also be able to have a
> non-absolute path to env command.
>
> Using bash on OS 10.8 I find that a she-bang for Ruby just doesn't work
> unless it points to some absolute path.
>
> The most portable I can make a file is to say
>
>          #! /usr/bin/env ruby
>
> Anyway, that approach meets my needs.
>
> Regards,
>
> Wes
> ____
>
> "With consistency a great soul has simply nothing to do. Speak what you
> think today in hard words and tomorrow speak what tomorrow thinks in
> hard words again, though it contradict everything you said today. "
>
>                            Ralph Waldo Emerson
>
> ____
>
>
> --
> Posted via http://www.ruby-forum.com/.