File.expand_path(__FILE__)

Discussion in 'Ruby' started by John Platte, Apr 29, 2004.

  1. John Platte

    John Platte Guest

    I'm having a problem with File.expand_path(__FILE__) after a chdir.
    Looks like a bug in Ruby to me. If someone can tell me what I'm doing
    wrong, I'd be grateful.

    Here's the reduction:

    [ryan@kursk 15:26:38 ~]$ cat tmp/demo-problem.rb
    puts "starting working directory: " + Dir.getwd
    puts "expand_path: " + File.expand_path(__FILE__)
    puts "about to change to dirname of __FILE__: " + __FILE__
    Dir.chdir(File.dirname(__FILE__))
    puts "new working directory: " + Dir.getwd
    puts "expand_path: " + File.expand_path(__FILE__)

    [ryan@kursk 15:26:40 ~]$ cd tmp

    [ryan@kursk 15:26:44 ~/tmp]$ ruby demo-problem.rb
    starting working directory: /Users/ryan/tmp
    expand_path: /Users/ryan/tmp/demo-problem.rb
    about to change to dirname of __FILE__: demo-problem.rb
    new working directory: /Users/ryan/tmp
    expand_path: /Users/ryan/tmp/demo-problem.rb

    [ryan@kursk 15:26:45 ~/tmp]$ cd ..

    [ryan@kursk 15:26:50 ~]$ ruby tmp/demo-problem.rb
    starting working directory: /Users/ryan
    expand_path: /Users/ryan/tmp/demo-problem.rb
    about to change to dirname of __FILE__: tmp/demo-problem.rb
    new working directory: /Users/ryan/tmp
    expand_path: /Users/ryan/tmp/tmp/demo-problem.rb

    [ryan@kursk 15:26:56 ~]$

    --
    Ryan "John" Platte
    Custom services, NIKA Consulting
    http://nikaconsulting.com/
     
    John Platte, Apr 29, 2004
    #1
    1. Advertising

  2. On Fri, 30 Apr 2004 05:28:43 +0900
    John Platte <> wrote:

    > I'm having a problem with File.expand_path(__FILE__) after a chdir.
    > Looks like a bug in Ruby to me. If someone can tell me what I'm doing
    > wrong, I'd be grateful.
    >
    > Here's the reduction:
    >
    > [ryan@kursk 15:26:38 ~]$ cat tmp/demo-problem.rb
    > puts "starting working directory: " + Dir.getwd
    > puts "expand_path: " + File.expand_path(__FILE__)
    > puts "about to change to dirname of __FILE__: " + __FILE__
    > Dir.chdir(File.dirname(__FILE__))
    > puts "new working directory: " + Dir.getwd
    > puts "expand_path: " + File.expand_path(__FILE__)


    ^^^^^^^^
    BOOM

    I guess you assume that __FILE__ change when doing chdir.
    But it doesn't



    server> ruby a.rb
    "a.rb"
    "/tmp"
    "a.rb"
    "/"
    "a.rb"
    "/tmp"
    server> expand -t2 a.rb
    p __FILE__, Dir.pwd
    Dir.chdir("..") do
    p __FILE__, Dir.pwd
    end
    p __FILE__, Dir.pwd
    server>


    As you can see, filenames doesn't change during chdir.


    HTH,

    --
    Simon Strandgaard
     
    Simon Strandgaard, Apr 30, 2004
    #2
    1. Advertising

  3. John Platte

    Hal Fulton Guest

    Simon Strandgaard wrote:
    > On Fri, 30 Apr 2004 05:28:43 +0900
    > John Platte <> wrote:
    >
    >>I'm having a problem with File.expand_path(__FILE__) after a chdir.
    >>Looks like a bug in Ruby to me. If someone can tell me what I'm doing
    >>wrong, I'd be grateful.

    >
    > I guess you assume that __FILE__ change when doing chdir.
    > But it doesn't


    I think you've analyzed this incorrectly.

    The value of __FILE__ doesn't change, nor did he expect it to.
    But expand_path is giving him an erroneous result, is it not?

    "/Users/ryan/tmp/tmp/demo-problem.rb" -- there is no tmp/tmp
    directory if I understand correctly.

    It does look like a bug to me.


    Hal
     
    Hal Fulton, Apr 30, 2004
    #3
  4. Hal Fulton <> wrote:
    > Simon Strandgaard wrote:
    > > On Fri, 30 Apr 2004 05:28:43 +0900
    > > John Platte <> wrote:
    > >
    > >>I'm having a problem with File.expand_path(__FILE__) after a chdir.
    > >>Looks like a bug in Ruby to me. If someone can tell me what I'm doing
    > >>wrong, I'd be grateful.

    > >
    > > I guess you assume that __FILE__ change when doing chdir.
    > > But it doesn't

    >
    > I think you've analyzed this incorrectly.
    >
    > The value of __FILE__ doesn't change, nor did he expect it to.
    > But expand_path is giving him an erroneous result, is it not?
    >
    > "/Users/ryan/tmp/tmp/demo-problem.rb" -- there is no tmp/tmp
    > directory if I understand correctly.
    >
    > It does look like a bug to me.


    No bug.


    At the last line "File.expand_path(__FILE__)" is being invoked.
    Currend dir = "/Users/ryan/tmp/"
    File name = "tmp/demo-problem.rb"

    When these are being concatenated it outputs
    absolut path = "/Users/ryan/tmp/tmp/demo-problem.rb"


    concat is working ok.

    --
    Simon Strandgaard
     
    Simon Strandgaard, Apr 30, 2004
    #4
  5. John Platte

    Hal Fulton Guest

    Simon Strandgaard wrote:
    > No bug.
    >
    >
    > At the last line "File.expand_path(__FILE__)" is being invoked.
    > Currend dir = "/Users/ryan/tmp/"
    > File name = "tmp/demo-problem.rb"
    >
    > When these are being concatenated it outputs
    > absolut path = "/Users/ryan/tmp/tmp/demo-problem.rb"
    >
    >
    > concat is working ok.


    expand_path doesn't simply concatenate. If it did, we could
    simply do dir + name.

    Taking a valid relative pathname and returning an invalid
    absolute pathname is not useful, certainly not a feature.

    If not a bug, at least an anomaly.


    Hal
     
    Hal Fulton, Apr 30, 2004
    #5
  6. Hal Fulton <> wrote:
    > Simon Strandgaard wrote:
    > > No bug.
    > >
    > >
    > > At the last line "File.expand_path(__FILE__)" is being invoked.
    > > Currend dir = "/Users/ryan/tmp/"
    > > File name = "tmp/demo-problem.rb"
    > >
    > > When these are being concatenated it outputs
    > > absolut path = "/Users/ryan/tmp/tmp/demo-problem.rb"
    > >
    > >
    > > concat is working ok.

    >
    > expand_path doesn't simply concatenate. If it did, we could
    > simply do dir + name.



    server> ruby -e 'p File.expand_path("a/b")'
    "/tmp/a/b"
    server> ls a
    ls: a: No such file or directory
    server>



    > Taking a valid relative pathname and returning an invalid
    > absolute pathname is not useful, certainly not a feature.
    >
    > If not a bug, at least an anomaly.


    I think concat are the desired behavier of expand_path.
    For instance if you want to create a directory, you first
    have to make the path, before you make it. I don't have
    better evidence.

    --
    Simon Strandgaard
     
    Simon Strandgaard, Apr 30, 2004
    #6
  7. John Platte

    Hal Fulton Guest

    Simon Strandgaard wrote:
    > I think concat are the desired behavier of expand_path.
    > For instance if you want to create a directory, you first
    > have to make the path, before you make it. I don't have
    > better evidence.


    I see your point, and I don't have a counterexample.

    And I guess there is a problem with what the OP wanted --
    if the original name is relative to the original current
    directory, then the interpreter would have to keep track
    of where we were relative to our original dir.

    It is doable, but is it worth it? And is there a real
    purpose to expand_path besides tilde substitution and
    simple concatenation?

    Matz??


    Hal
     
    Hal Fulton, Apr 30, 2004
    #7
  8. Hal Fulton <> wrote:
    > Simon Strandgaard wrote:
    > > I think concat are the desired behavier of expand_path.
    > > For instance if you want to create a directory, you first
    > > have to make the path, before you make it. I don't have
    > > better evidence.

    >
    > I see your point, and I don't have a counterexample.
    >
    > And I guess there is a problem with what the OP wanted --
    > if the original name is relative to the original current
    > directory, then the interpreter would have to keep track
    > of where we were relative to our original dir.
    >
    > It is doable, but is it worth it? And is there a real
    > purpose to expand_path besides tilde substitution and
    > simple concatenation?



    Maybe extend __FILE__ with a #absolute method,
    in order to make __FILE__ immune against chdir ?

    --
    Simon Strandgaard
     
    Simon Strandgaard, Apr 30, 2004
    #8
  9. On Fri, Apr 30, 2004 at 09:23:53AM +0900, Hal Fulton wrote:
    > And I guess there is a problem with what the OP wanted --
    > if the original name is relative to the original current
    > directory, then the interpreter would have to keep track
    > of where we were relative to our original dir.
    >
    > It is doable, but is it worth it? And is there a real
    > purpose to expand_path besides tilde substitution and
    > simple concatenation?


    It does more than simple concatenation + ~ subst., it concatenates &
    normalizes:

    Dir.pwd
    # =>"/tmp"
    File.expand_path "../bin/sh"
    # =>"/bin/sh"
    # not => "/tmp/../bin/sh"

    --
    Running Debian GNU/Linux Sid (unstable)
    batsman dot geo at yahoo dot com

    "You, sir, are nothing but a pathetically lame salesdroid!
    I fart in your general direction!"
    -- Randseed on #Linux
     
    Mauricio Fernández, Apr 30, 2004
    #9
  10. "Simon Strandgaard" <> schrieb im Newsbeitrag
    news:...
    > Hal Fulton <> wrote:
    > > Simon Strandgaard wrote:
    > > > I think concat are the desired behavier of expand_path.
    > > > For instance if you want to create a directory, you first
    > > > have to make the path, before you make it. I don't have
    > > > better evidence.

    > >
    > > I see your point, and I don't have a counterexample.
    > >
    > > And I guess there is a problem with what the OP wanted --
    > > if the original name is relative to the original current
    > > directory, then the interpreter would have to keep track
    > > of where we were relative to our original dir.
    > >
    > > It is doable, but is it worth it? And is there a real
    > > purpose to expand_path besides tilde substitution and
    > > simple concatenation?

    >
    >
    > Maybe extend __FILE__ with a #absolute method,
    > in order to make __FILE__ immune against chdir ?


    This is easily fixed:

    09:58:20 [ruby]: /cygdrive/c/temp/ruby/pfile.rb
    ["/cygdrive/c/temp/ruby/pfile.rb", "/cygdrive/c/temp/ruby/pfile.rb"]
    09:58:31 [ruby]: ./pfile.rb
    ["./pfile.rb", "/cygdrive/c/temp/ruby/pfile.rb"]
    09:58:38 [ruby]: ruby pfile.rb
    ["pfile.rb", "/cygdrive/c/temp/ruby/pfile.rb"]
    09:58:40 [ruby]: cat pfile.rb
    #!/usr/bin/ruby

    FILE = File.expand_path __FILE__

    p [__FILE__, FILE]

    Regards

    robert
     
    Robert Klemme, Apr 30, 2004
    #10
  11. "Robert Klemme" <> wrote:
    > "Simon Strandgaard" <> schrieb im Newsbeitrag
    > >
    > > Maybe extend __FILE__ with a #absolute method,
    > > in order to make __FILE__ immune against chdir ?

    >
    > This is easily fixed:
    >
    > FILE = File.expand_path __FILE__
    > p [__FILE__, FILE]


    Not if the person has done a chdir just before expand_path.
    I wonder why __FILE__ isn't an absolute path. Relative paths is
    just too fragile.


    Proposal: make __FILE__ an absolute path.
    That would make __FILE__ robust to Dir.chdir.


    Any thoughts on this proposal? fore or against

    --
    Simon
     
    Simon Strandgaard, Apr 30, 2004
    #11
  12. "Simon Strandgaard" <> schrieb im Newsbeitrag
    news:...
    > "Robert Klemme" <> wrote:
    > > "Simon Strandgaard" <> schrieb im Newsbeitrag
    > > >
    > > > Maybe extend __FILE__ with a #absolute method,
    > > > in order to make __FILE__ immune against chdir ?

    > >
    > > This is easily fixed:
    > >
    > > FILE = File.expand_path __FILE__
    > > p [__FILE__, FILE]

    >
    > Not if the person has done a chdir just before expand_path.


    Well, I should've written "first line in script".

    > I wonder why __FILE__ isn't an absolute path. Relative paths is
    > just too fragile.
    >
    >
    > Proposal: make __FILE__ an absolute path.
    > That would make __FILE__ robust to Dir.chdir.
    >
    >
    > Any thoughts on this proposal? fore or against


    Slightly against, because

    - it's easily fixed

    - you loose information: there might be situations where the script wants
    to know the exact path it was invoked with.

    - most of the time (when invoked from the shell via path expansion)
    scripts are invoked with an absolute path anyway.

    Kind regards

    robert
     
    Robert Klemme, Apr 30, 2004
    #12
  13. "Robert Klemme" <> wrote:
    > "Simon Strandgaard" <> schrieb im Newsbeitrag
    > news:...
    > > "Robert Klemme" <> wrote:
    > > > "Simon Strandgaard" <> schrieb im Newsbeitrag
    > > > >
    > > > > Maybe extend __FILE__ with a #absolute method,
    > > > > in order to make __FILE__ immune against chdir ?
    > > >
    > > > This is easily fixed:
    > > >
    > > > FILE = File.expand_path __FILE__
    > > > p [__FILE__, FILE]

    > >
    > > Not if the person has done a chdir just before expand_path.

    >
    > Well, I should've written "first line in script".


    ok ;-)


    > > I wonder why __FILE__ isn't an absolute path. Relative paths is
    > > just too fragile.
    > >
    > >
    > > Proposal: make __FILE__ an absolute path.
    > > That would make __FILE__ robust to Dir.chdir.
    > >
    > >
    > > Any thoughts on this proposal? fore or against

    >
    > Slightly against, because
    >
    > - it's easily fixed


    Agree.. however see below


    > - you loose information: there might be situations where the script wants
    > to know the exact path it was invoked with.


    I think its the wrong place to retrive this kind of information.
    Broken metaphor... I have used it myself, but without thinking about it.


    >
    > - most of the time (when invoked from the shell via path expansion)
    > scripts are invoked with an absolute path anyway.


    Please elaborate.. I don't understand.

    :)

    --
    Simon Strandgaard
     
    Simon Strandgaard, Apr 30, 2004
    #13
  14. "Simon Strandgaard" <> schrieb im Newsbeitrag
    news:...
    > "Robert Klemme" <> wrote:
    > > "Simon Strandgaard" <> schrieb im Newsbeitrag
    > > news:...
    > > > "Robert Klemme" <> wrote:
    > > > > "Simon Strandgaard" <> schrieb im Newsbeitrag
    > > > > >
    > > > > > Maybe extend __FILE__ with a #absolute method,
    > > > > > in order to make __FILE__ immune against chdir ?
    > > > >
    > > > > This is easily fixed:
    > > > >
    > > > > FILE = File.expand_path __FILE__
    > > > > p [__FILE__, FILE]
    > > >
    > > > Not if the person has done a chdir just before expand_path.

    > >
    > > Well, I should've written "first line in script".

    >
    > ok ;-)
    >
    >
    > > > I wonder why __FILE__ isn't an absolute path. Relative paths is
    > > > just too fragile.
    > > >
    > > >
    > > > Proposal: make __FILE__ an absolute path.
    > > > That would make __FILE__ robust to Dir.chdir.
    > > >
    > > >
    > > > Any thoughts on this proposal? fore or against

    > >
    > > Slightly against, because
    > >
    > > - it's easily fixed

    >
    > Agree.. however see below
    >
    >
    > > - you loose information: there might be situations where the script

    wants
    > > to know the exact path it was invoked with.

    >
    > I think its the wrong place to retrive this kind of information.
    > Broken metaphor... I have used it myself, but without thinking about it.


    Where would you expect it to reside? Maybe the best solution is

    $0 : path as used for invocation
    __FILE__: abs path to current file

    Then I agree. :) Any objections? Does this break existing code?

    > > - most of the time (when invoked from the shell via path expansion)
    > > scripts are invoked with an absolute path anyway.

    >
    > Please elaborate.. I don't understand.
    >
    > :)


    15:35:31 [ContentReporter_BRANCH]: PATH="${PATH}:/c/temp/ruby" bash -c
    'echo $PATH; dollar0.rb'
    <privacy>:/c/temp/ruby
    __FILE=/c/temp/ruby/dollar0.rb
    $0=/c/temp/ruby/dollar0.rb
    15:35:51 [ContentReporter_BRANCH]: cat /c/temp/ruby/dollar0.rb
    #!/usr/bin/ruby

    puts "__FILE=#{__FILE__}"
    puts "$0=#{$0}"

    The invocation (-c 'dollar0.rb') does not use a path but rather the shell
    finds the executable based on its $PATH.

    Regards

    robert
     
    Robert Klemme, Apr 30, 2004
    #14
  15. John Platte

    Kent Dahl Guest

    Robert Klemme wrote:
    > Where would you expect it to reside? Maybe the best solution is
    >
    > $0 : path as used for invocation
    > __FILE__: abs path to current file
    >
    > Then I agree. :) Any objections? Does this break existing code?


    Wouldn't this break the idiom of using

    if __FILE__ == $0 then
    #...
    end

    to make a file both require-able and executable?
    I know I use it frequently.

    --
    (\[ Kent Dahl ]/)_ _~_ _____[ http://www.pvv.org/~kentda/ ]_____/~
    ))\_student_/(( \__d L b__/ Master of Science in Technology )
    ( \__\_õ|õ_/__/ ) _) Industrial economics and technology management (
    \____/_ö_\____/ (____engineering.discipline_=_Computer::Technology___)
     
    Kent Dahl, Apr 30, 2004
    #15
  16. "Kent Dahl" <> schrieb im Newsbeitrag
    news:c6tmj9$58n$...
    > Robert Klemme wrote:
    > > Where would you expect it to reside? Maybe the best solution is
    > >
    > > $0 : path as used for invocation
    > > __FILE__: abs path to current file
    > >
    > > Then I agree. :) Any objections? Does this break existing code?

    >
    > Wouldn't this break the idiom of using
    >
    > if __FILE__ == $0 then
    > #...
    > end
    >
    > to make a file both require-able and executable?
    > I know I use it frequently.


    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?

    robert
     
    Robert Klemme, Apr 30, 2004
    #16
  17. John Platte

    John Platte Guest

    The OP yawns and wakes up to a big thread that has sprouted up where he
    posted his little codeling...

    On 2004 Apr 30, at 6:39, Robert Klemme wrote:

    >> I wonder why __FILE__ isn't an absolute path. Relative paths is
    >> just too fragile.
    >>
    >>
    >> Proposal: make __FILE__ an absolute path.
    >> That would make __FILE__ robust to Dir.chdir.
    >>
    >>
    >> Any thoughts on this proposal? fore or against


    That was my expectation. I really don't understand why __FILE__ would
    be relative. I did a lot of work in PHP before coming to Ruby, and PHP
    uses an absolute path in its __FILE__, which is a wonderful thing when
    trying to create programs that are robust against odd web server
    configurations.

    I see Perl uses relative paths for both __FILE__ and $0...and since a
    lot of Ruby scripts use "if __FILE__ == $0", those two should keep
    following the same policy. So I don't expect that behavior to change
    for my odd little case.

    Might there be another place to put this absolute path? (Or might one
    exist already?) PHP defines a global $SCRIPT_FILENAME...

    > Slightly against, because
    >
    > - it's easily fixed


    but obviously from the head-scratching on this thread, the current
    behavior at least threatens POLS.

    > - you loose information: there might be situations where the script
    > wants
    > to know the exact path it was invoked with.


    That seems like more of a special case to me than knowing exactly where
    we live in the filesystem, but I'll admit that if Ruby got this far
    with this behavior, maybe I'm not in the majority.

    > - most of the time (when invoked from the shell via path expansion)
    > scripts are invoked with an absolute path anyway.


    My situation: I was invoking a utility script from Vim's shell, and it
    had a bug that dumped output in the wrong directory. As I hacked a fix,
    somehow I wound up with code that triggered the unexpected behavior I
    posted about (I apologize for not pointing out which part was
    unexpected).

    Whatever the solution, I want it to be easy to get an authoritative
    absolute path for the current file from Ruby; I'd strongly prefer that
    it not be fragile to chdirs, since that's a side effect that reduces
    flexibility.

    Surely there's an existing solution to this within Ruby or Perl or some
    other language?

    Thanks to the other posters for the workaround(s) and explanation.

    --
    Ryan "John" Platte
    Custom services, NIKA Consulting
    http://nikaconsulting.com/
     
    John Platte, Apr 30, 2004
    #17
  18. "John Platte" <> schrieb im Newsbeitrag
    news:...
    > The OP yawns and wakes up to a big thread that has sprouted up where he
    > posted his little codeling...
    >
    > On 2004 Apr 30, at 6:39, Robert Klemme wrote:
    >
    > >> I wonder why __FILE__ isn't an absolute path. Relative paths is
    > >> just too fragile.
    > >>
    > >>
    > >> Proposal: make __FILE__ an absolute path.
    > >> That would make __FILE__ robust to Dir.chdir.
    > >>
    > >>
    > >> Any thoughts on this proposal? fore or against

    >
    > That was my expectation. I really don't understand why __FILE__ would
    > be relative. I did a lot of work in PHP before coming to Ruby, and PHP
    > uses an absolute path in its __FILE__, which is a wonderful thing when
    > trying to create programs that are robust against odd web server
    > configurations.
    >
    > I see Perl uses relative paths for both __FILE__ and $0...and since a
    > lot of Ruby scripts use "if __FILE__ == $0", those two should keep
    > following the same policy. So I don't expect that behavior to change
    > for my odd little case.


    .... or operators are overloaded to ensure proper behavior.

    > Might there be another place to put this absolute path? (Or might one
    > exist already?) PHP defines a global $SCRIPT_FILENAME...
    >
    > > Slightly against, because
    > >
    > > - it's easily fixed

    >
    > but obviously from the head-scratching on this thread, the current
    > behavior at least threatens POLS.
    >
    > > - you loose information: there might be situations where the script
    > > wants
    > > to know the exact path it was invoked with.

    >
    > That seems like more of a special case to me than knowing exactly where
    > we live in the filesystem, but I'll admit that if Ruby got this far
    > with this behavior, maybe I'm not in the majority.


    Both may be true. :)

    > > - most of the time (when invoked from the shell via path expansion)
    > > scripts are invoked with an absolute path anyway.

    >
    > My situation: I was invoking a utility script from Vim's shell, and it
    > had a bug that dumped output in the wrong directory. As I hacked a fix,
    > somehow I wound up with code that triggered the unexpected behavior I
    > posted about (I apologize for not pointing out which part was
    > unexpected).
    >
    > Whatever the solution, I want it to be easy to get an authoritative
    > absolute path for the current file from Ruby; I'd strongly prefer that
    > it not be fragile to chdirs, since that's a side effect that reduces
    > flexibility.
    >
    > Surely there's an existing solution to this within Ruby or Perl or some
    > other language?


    See my other post:

    # at the top of script
    FILE = File.expand_path( __FILE __ )

    > Thanks to the other posters for the workaround(s) and explanation.


    We love to bang our heads on simple looking but difficult to solve
    problems. :)

    robert
     
    Robert Klemme, Apr 30, 2004
    #18
  19. John Platte

    John Platte Guest

    On 2004 Apr 30, at 9:39, Robert Klemme wrote:

    >> I see Perl uses relative paths for both __FILE__ and $0...and since a
    >> lot of Ruby scripts use "if __FILE__ == $0", those two should keep
    >> following the same policy. So I don't expect that behavior to change
    >> for my odd little case.

    >
    > .... or operators are overloaded to ensure proper behavior.


    I can't imagine that would lead to increased predictability!

    On this topic, however, it'd be nice to have a method like
    this_file_invoked? that encapsulated the $0 == __FILE__ idiom.

    >> Surely there's an existing solution to this within Ruby or Perl or
    >> some
    >> other language?

    >
    > See my other post:
    >
    > # at the top of script
    > FILE = File.expand_path( __FILE __ )


    Yes, that snippet was a workaround I was thanking you for, but I don't
    consider it a solution to the problem:

    it seems we can't determine the absolute path of __FILE__ correctly
    after a chdir without having planned for that eventuality before the
    chdir.

    Can someone solve that one?

    --
    Ryan "John" Platte
    Custom services, NIKA Consulting
    http://nikaconsulting.com/
     
    John Platte, Apr 30, 2004
    #19
  20. John Platte

    Ara.T.Howard Guest

    On Fri, 30 Apr 2004, John Platte wrote:

    > On 2004 Apr 30, at 9:39, Robert Klemme wrote:
    >
    > >> I see Perl uses relative paths for both __FILE__ and $0...and since a
    > >> lot of Ruby scripts use "if __FILE__ == $0", those two should keep
    > >> following the same policy. So I don't expect that behavior to change
    > >> for my odd little case.

    > >
    > > .... or operators are overloaded to ensure proper behavior.

    >
    > I can't imagine that would lead to increased predictability!
    >
    > On this topic, however, it'd be nice to have a method like
    > this_file_invoked? that encapsulated the $0 == __FILE__ idiom.
    >
    > >> Surely there's an existing solution to this within Ruby or Perl or
    > >> some
    > >> other language?

    > >
    > > See my other post:
    > >
    > > # at the top of script
    > > FILE = File.expand_path( __FILE __ )

    >
    > Yes, that snippet was a workaround I was thanking you for, but I don't
    > consider it a solution to the problem:
    >
    > it seems we can't determine the absolute path of __FILE__ correctly
    > after a chdir without having planned for that eventuality before the
    > chdir.
    >
    > Can someone solve that one?


    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?

    -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
    ===============================================================================
     
    Ara.T.Howard, Apr 30, 2004
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. klenwell

    __file__ vs __FILE__

    klenwell, Nov 3, 2007, in forum: Python
    Replies:
    11
    Views:
    929
    Matimus
    Nov 5, 2007
  2. Alan Davies

    File.expand_path and ~ on windows

    Alan Davies, Sep 18, 2003, in forum: Ruby
    Replies:
    2
    Views:
    151
    Alan Davies
    Sep 22, 2003
  3. Erik Veenstra
    Replies:
    1
    Views:
    156
    Nobuyoshi Nakada
    Jun 3, 2008
  4. Fritz Anderson
    Replies:
    3
    Views:
    134
    Robert Dober
    Dec 9, 2008
  5. Alpha Blue
    Replies:
    25
    Views:
    286
    Robert Klemme
    Feb 5, 2010
Loading...

Share This Page