[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
pwd() reflects the actual directory and not symbolic link
From: |
Daniel J Sebald |
Subject: |
pwd() reflects the actual directory and not symbolic link |
Date: |
Sat, 7 Jul 2018 19:22:29 -0500 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 |
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
/home/djs/linkdir
@linux ~/linkdir $ readlink -f .
/home/djs/realdir
@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
/home/djs/linkdir
ans = 0
Any thoughts? Is it even possible to reconstruct the link path from
within the C++ program?
Dan
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- pwd() reflects the actual directory and not symbolic link,
Daniel J Sebald <=