shebang should be '/usr/bin/env ruby'

OK, what exactly ist the "design decision" that has to be discussed? I would say something like:

sed -ri s#!/usr/bin/ruby#!/usr/bin/env ruby# 

will do the trick. Done!

It might be the case that 'env' itself is in another path. That is a problem, yes. Does the comunity know about such systems? I guess those which have env somehere else that /usr/bin are very rarely used and quite old systems.

The design decision is Luke's - he has the strongest understanding of his client base. I don't have any fundamental issues with the change but it's Luke's call.

I'm fine with this change.

I was going to make this change but it looks like someone's already done it. The only #!/usr/bin/ruby I have found is in:

bin/pi
bin/ralsh
lib/puppet/dsl.rb
spec/unit/file_serving/configuration.rb
spec/unit/file_serving/configuration/parser.rb
spec/unit/indirector/checksum/file.rb
spec/unit/indirector/direct_file_server.rb
spec/unit/indirector/facts/facter.rb
spec/unit/indirector/file.rb
spec/unit/indirector/file_server.rb
spec/unit/parser/ast/node.rb
spec/unit/ral/provider/mount/parsed.rb
spec/unit/ral/type/mount.rb
test/lib/stubba.rb

I went ahead and changed those and made it available as commit 6b674b8ba5ca560841d8c5c04dd44768ad7a5c92 of branch fix-1148 in my repository, if anyone wants it. Punting back to luke otherwise.

Pushed as [9d30b26]. I had to cherry-pick the commit, because I'd given plathrop bad directions on how to rebase.

Okay - discovered a flaw with this idea - I knew I had seen an issue. Using the env ruby as the shebang breaks init scripts.

* Tue Aug 1 2006 David Lutterkort <dlutter@redhat.com> - 0.18.4-2 - Use /usr/bin/ruby directly instead of /usr/bin/env ruby in

executables. Otherwise, initscripts break since pidof can't find the right process

Thoughts on how to address this?

It might be time for puppet to look into a build-system that detects where the system ruby is installed and then does the appropriate substitutions during the build process?

On another note, the file puppet/external/nagios.rb has:

#!/usr/local/bin/ruby

which is different from all the rest, and is even more non-standard. Can this one be changed as well?

hacim - fixed those non-standards in commit [e621985d24fbd417690f763276d7d895c0640042] in branch 0.24.x

Replying to jamtur01:

Okay - discovered a flaw with this idea - I knew I had seen an issue. Using the env ruby as the shebang breaks init scripts. * Tue Aug 1 2006 David Lutterkort <dlutter@redhat.com> - 0.18.4-2 - Use /usr/bin/ruby directly instead of /usr/bin/env ruby in executables. Otherwise, initscripts break since pidof can't find the right process Thoughts on how to address this?

Use pgrep instead of pidof in the Red Hat initscripts. The shebang shouldn't be modified just because one platform's initscripts use a nonportable method to determine what processes may be running. That said, I would expect the initscripts written for a sysv implementation (ie, Red Hat) to readily work on any sysv platform for portability and code reuse reasons.

$ ps awux | grep puppet
puppet    5327  2.7  1.8  91076 77032 ?        Ssl  02:00  20:29 /usr/bin/ruby /usr/sbin/puppetmasterd --manifest=/var/lib/puppet/master/manifests/site.pp --logdest=/var/log/puppet/
502      13578  0.0  0.0   3896   660 pts/1    S+   14:25   0:00 grep puppet
root     31219  0.4  1.1  62640 48408 ?        Ss   Mar30  25:58 /usr/bin/ruby /usr/sbin/puppetd --logdest=syslog
$ sudo pidof ruby
31219 5327
$ pgrep puppetmasterd
5327
$ pgrep puppetd
31219

If the system doesn't have pgrep, use ps and awk.

$ ps awux | awk '/bin\/puppetmaster/ {print $2}'
5327
$ ps awux | awk '/bin\/puppetd/ {print $2}'
31219

Or similar.

Actually looking at the init scripts for Red Hat I don't quite see how the PID file is used at all and pidof seems not to be used either. So maybe not a problem - though I suspect some work is needed on the Red Hat init scripts.

The problem report mystifies me too. Why would using env break pidof? All env is doing is manipulating the environment (if there are any changes) and then execing its argument.

Where are we in this ticket? Is this actually a problem?

And I'm pretty sure that the install.rb script actually replaces all of the installed shebang lines with a shebang listing the literal ruby binary, so it doesn't actually matter. This is easy enough to test:

$ DESTDIR=/tmp/puppetinstall ./install.rb
...lots of output...
$ head -1 /tmp/puppetinstall/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/puppet
#!/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/ruby
$

Yes, the ruby install on OS X is strange, but that's neither here nor there: The shebangs shouldn't actually show up in real life.

Given that, I'm going to assume this ticket is fixed. If you're not using install.rb to get your file list, then you've got to support the system yourself.

Of course 'install.rb' does replace shebangs, BUT: What if someone does not install from source, but uses packages? Then, the packager's environment ist used, which is not the right one in our case (we have /opt/local/bin/ruby (darwinports)).

saying things like:

If you're not using install.rb to get your file list, then you've got to support the system yourself.

is pretty adacious (IMHO) in the context of puppet, which is supposed to work on many (if not all) unix-like systems. Mac OS X is one of those, anyway, I have a workaround: - Install puppet from packages - have puppet itself replace the shebang afterwards I regard this a hack....

Replying to do:

Of course 'install.rb' does replace shebangs, BUT: What if someone does not install from source, but uses packages? Then, the packager's environment ist used, which is not the right one in our case (we have /opt/local/bin/ruby (darwinports)). saying things like: {{{ If you're not using install.rb to get your file list, then you've got to support the system yourself. }}} is pretty adacious (IMHO) in the context of puppet, which is supposed to work on many (if not all) unix-like systems. Mac OS X is one of those, anyway, I have a workaround: - Install puppet from packages - have puppet itself replace the shebang afterwards I regard this a hack....

Puppet is not in the business of package management. If there's a problem with what your packaging system is doing to Puppet to make it into a package, it should be addressed with the package maintainer, not here.

plathrop hit the nail on the head -- if your package is not using install.rb, then it should provide equivalent functionality.