File.expand_path(__FILE__)

[John Platte]

what's wrong with solving it by planning for it?

Only that it requires setting up infrastructure simply to get a
reliable answer to a question about Ruby's environment. I expect such
in other languages; in Ruby it seems really out of place (to me).

Thanks for your code snippet.

 

[Simon Strandgaard]

Yeah, I think it is used quite frequently. Darn. The only ad hoc
sulution to this that occurs to me is to override __FILE__#== and $0#== to
repair this. Now this starts getting ugly... Simon?

Agree, the line 'if __FILE__ == $0' is indeed ugly

There is 4 things wrong with it:

A) $0 is a global variable, with a very short name,
not selfexplaining.

B) people sometimes write to $0, when they want to tell
ps or top, what the process are currently doing.
this is fragile, I have been hit by it one time.

C) __FILE__ and $0 is relative paths.
this is fragile, I have been hit by it more than one time.

D) making the comparison, seems kludgy.

I remember it took me forever to figure these things out.


I think its time to rethink __FILE__ and get rid of $0.

 

[Simon Strandgaard]

what's wrong with this, i do it in all my programs:

require 'pathname'

class Main
...
FILE = Pathname.new(__FILE__).realpath.to_s
...
end

what's wrong with solving it by planning for it?

I don't intend to be non-friendly, but if you do so in all your Main classes,
then it looks like kludge to me. You wouldn't have to make such work-arounds
if __FILE__ were with an absolute path.

I don't know if all this rethinking __FILE__/$0 makes sense..

 

[Robert Klemme]

Agree, the line 'if __FILE__ == $0' is indeed ugly

There is 4 things wrong with it:

A) $0 is a global variable, with a very short name,
not selfexplaining.

.... but known from the earlies shell scripts.

B) people sometimes write to $0, when they want to tell
ps or top, what the process are currently doing.
this is fragile, I have been hit by it one time.
Yep.

C) __FILE__ and $0 is relative paths.
this is fragile, I have been hit by it more than one time.

They are not always relative, it depends on the invocation.

D) making the comparison, seems kludgy.

Well, sort of.

I remember it took me forever to figure these things out.


I think its time to rethink __FILE__ and get rid of $0.

I certainly disagree here: $0 never changes automatically during the
lifetime of a script while __FILE__ reflects the current file. That's an
important distinction in the light of require and load. Just imagine a
help module that automatically prints invocation hints...

Regards

robert

 

[Ara.T.Howard]

I don't intend to be non-friendly, but if you do so in all your Main
classes, then it looks like kludge to me. You wouldn't have to make such
work-arounds if __FILE__ were with an absolute path.

i have to disagree - the reason i do it is that i drive alot of external
programs which dump their output in the cwd, therefore i end up doing a lot of
Dir.chdir's (see my dirstack package on RAA)... i have several main templates
and a code generator which uses these templates to spit out a main program of
several common flavors. one of things i find useful is knowing the absolute
path of the invoked program file because i'm __planning__ on doing a lot of
chdirs... some of my other templates do not include this. by your logic my
option parsing would be a kludge since it always has a '--help' and '--log'
option and there should be a way to avoid such duplicate effort... then again
perhaps you are correct, witness perl's pod2usage. code generators are a nice
way to get somewhere fast though...

I don't know if all this rethinking __FILE__/$0 makes sense..

i think it makes perfect sense to have

__FILE__ => absolute path of script file
__PROGRAM__ => absolute path of called program
__RUBY__ => absolute path of ruby interp running called program
__DIR__ => absolute directory of file (can use for relative requires)

it's always easy get a relative path from an absolute one, but not the other
way!

cheers.

-a
--
===============================================================================
| EMAIL :: Ara [dot] T [dot] Howard [at] noaa [dot] gov
| PHONE :: 303.497.6469
| ADDRESS :: E/GC2 325 Broadway, Boulder, CO 80305-3328
| URL :: http://www.ngdc.noaa.gov/stp/
| TRY :: for l in ruby perl;do $l -e "print \"\x3a\x2d\x29\x0a\"";done
===============================================================================

 

[John Platte]

i think it makes perfect sense to have

__FILE__ => absolute path of script file
__PROGRAM__ => absolute path of called program
__RUBY__ => absolute path of ruby interp running called program
__DIR__ => absolute directory of file (can use for relative
requires)

it's always easy get a relative path from an absolute one, but not the
other
way!

Then $0 would need to be absolute too.

So the question is, would, could switching the default $0 setting and
__FILE__ to absolute paths break existing programs?

Are there Windows considerations that could cause problems? Cygwin?
MinGW?

I'm considering writing up an RCR, but before I put Matz and myself
through all that, I want to make sure we're not wasting time.

 

[Ara.T.Howard]

Then $0 would need to be absolute too.

snoopy vars are on the way out - that's what __PROGRAM__ is (in theory)...

So the question is, would, could switching the default $0 setting and
__FILE__ to absolute paths break existing programs?

perhaps it should then be:

$SCRIPT_FILE => absolute path of script file
$PROGRAM_NAME => absolute path of called program
$RUBY => absolute path of ruby interp running called program
$BASE_DIR => absolute directory of file (can use for relative


or (__VAR__ - take your pick)

and this breaks no current code (probably).

now that i think about it, if you are putting an RCR together it might make
sense to create a namespace for the notion of 'stuff specific to this instance
of ruby' and put all this stuff in there. something like

require 'rbconfig'
require 'pathname'

module Runtime
SCRIPT_FILE = Pathname.new(__FILE__).realpath.to_s
PROGRAM_NAME = Pathname.new($0).realpath.to_s
RUBY = File.join Config::CONFIG['bindir'], Config::CONFIG['RUBY_INSTALL_NAME']
BASE_DIR = File.dirname SCRIPT_FILE
end

or perhaps implement the namespace as in

ENV['RUBY_SCRIPT_FILE'] = Pathname.new(__FILE__).realpath.to_s

who knows...

all i'm saying is, if a namespace was inforced we could put all sorts of
useful stuff in there w/o breaking old code.

Are there Windows considerations that could cause problems? Cygwin?
MinGW?

I'm considering writing up an RCR, but before I put Matz and myself
through all that, I want to make sure we're not wasting time.

-a
--
===============================================================================
| EMAIL :: Ara [dot] T [dot] Howard [at] noaa [dot] gov
| PHONE :: 303.497.6469
| ADDRESS :: E/GC2 325 Broadway, Boulder, CO 80305-3328
| URL :: http://www.ngdc.noaa.gov/stp/
| TRY :: for l in ruby perl;do $l -e "print \"\x3a\x2d\x29\x0a\"";done
===============================================================================

 

[Simon Strandgaard]

i think it makes perfect sense to have

__FILE__ => absolute path of script file
__PROGRAM__ => absolute path of called program
__RUBY__ => absolute path of ruby interp running called program
__DIR__ => absolute directory of file (can use for relative requires)

it's always easy get a relative path from an absolute one, but not the other
way!

This was what I wanted to express, though I could not write it in such a striking
sentence

I don't know what is right nor wrong...

Maybe make __FILE__ a class with a one useful method, #standalone?
So that instead of 'if $0 == __FILE__' you can type 'if __FILE__.standalone?'

Maybe make a System class, containing a $0 replacement?

What does other languages do ?

 

[Simon Strandgaard]

I certainly disagree here: $0 never changes automatically during the
lifetime of a script while __FILE__ reflects the current file. That's an
important distinction in the light of require and load. Just imagine a
help module that automatically prints invocation hints...

You are right.. I were to quick to rid of $0.. of cause some kind of
replacement are needed.

$0 is a mixup to me, it mixes
A) invocation path.
B) program name, which ps/top can use.

Two different things to me.
But I have no ideas to what an eventual replacement could be like.


BTW: I have submitted an RCR about the __FILE__ problem.
http://rcrchive.net/rcr/RCR/RCR250

 

[Robert Klemme]

requires)

__DIR__ is superfluous if __FILE__ is absolute alreay. File.dirname(
__FILE__ ) will do the job.

And I'd choose different names. The __FILE__ and __LINE__ are there
because of CPP, there's no need to use these kind of names for new
semantics.

This was what I wanted to express, though I could not write it in such a striking
sentence

I don't think that statement is true. For both approaches (rel path ->
abs path and abs path -> rel path) you need an additional piece of
information, an additional path to relate to. That said, both (the
relative path and the absolute path) lack information, which makes it
equally difficult to do the transformation (or let's say impossible
without this additional information).

I don't know what is right nor wrong...

Maybe make __FILE__ a class with a one useful method, #standalone?
So that instead of 'if $0 == __FILE__' you can type 'if

__FILE__.standalone?'

I don't have statistics but this may brake too much code.

Maybe make a System class, containing a $0 replacement?

I like the idea. Maybe call it Runtime. This could even be facilitated
in creating nested but independent interpreters etc.:

Runtime.current.interpreter
=> /usr/bin/ruby

Runtime.current.gc
=> 1023 (collected instances)

Runtime.current.used_mem
=> 12828379478

Runtime.new( "my_script.rb", "--verbose", "foo" )
=> Runtime

Regards

robert