pwd() reflects the actual directory and not symbolic link

Previous Topic Next Topic
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

pwd() reflects the actual directory and not symbolic link

Daniel Sebald
I've noticed for years that whenever a directory is specified in Octave,
be it in the File Browser directory showing the files, or be it messages
that dbFUNC displays about the current line position, etc. that it is
always the real directory.  I never thought much about it, but I'm now
wondering why not make an attempt to reflect the "working directory"
that the user launches from or selects in the navigating file dialogs?
 From the user's perspective, I'm thinking s/he'd like to see the "link"
version of the directories.

To illustrate, here's a simple example.

@linux ~ $ mkdir realdir
@linux ~ $ ln -s realdir linkdir
@linux ~ $ cd linkdir
@linux ~/linkdir $ pwd
@linux ~/linkdir $ readlink -f .
@linux ~/linkdir $ /usr/local/src/octave/build1/run-octave --gui&

In the above, I showed how system commands can give both the linked
version of the path and the real path.  If there were script files in
this directory, readlink -f would accept "filename.m".

After having launched Octave above, first notice that the directory of
the "File Browser" display "realdir" rather than "linkdir".  I launched
from "linkdir".  Second, note the following:

 >> pwd
ans = /home/djs/realdir
 >> system pwd
ans = 0

Any thoughts?  Is it even possible to reconstruct the link path from
within the C++ program?