RE: [expath] Re: Finalizing the File Module

What about System.getProperty("user.dir")? I thought that was how you got
the cwd of the Java process?
On 24 Mar 2014 22:43, "David Lee" <dlee@calldei.com> wrote:

>  I would advise against anything relying heavily on the concept of "the
> current directory".
>
> This is a concept that is simply not reliably portable.  As tantalizing as
> it is to believe in "cwd" its a fantasy of epic proportions to bet on it.
>
>
>
> Reasons:
>
> Some operating systems simply do not have the concept at all - it simply
> doesnt exist.
>
> In systems where "cwd" is a OS feature not all portions of a program have
> the same concept,
>
> for example in windows and unix the "cwd" is a process-wide setting.
>  Thats simply not convenient for many uses such as multi-tenancy and
> multi-threaded applications ... so the concept is often virtualized to
> support those applications.  The problem is the virtualization is not
> always complete - because to virtualize the CWD usually implies that
> different components can independently set it ... yet this is not
> universally supported.   Even in OS's where the "cwd" is well defined (at a
> process level) its amazing and surprising to discover that many libraries
> will actually change it on you without your knowledge - sometimes in a
> thread-unsafe way.   A common (legacy) method of deterring the absolute
> path of the current directory on unix is to keep doing a chdir("..") and
> storing the inodes of "." until you cant anymore then unwind the stack.
>   Try opening a file in a different thread via "." while this happens ...
> :)
>
>  ( just a FYI on unix/linux the cwd is not stored as a path its an inode
> and may have multiple equivalent paths).
>
>
>
> Java implementations, for example, recognize that modifying the CWD is not
> supportable so simply don't expose any method at all to change it.  In fact
> the Java JRE doesnt directly support the concept of a CWD at all ... but
> that doesn't stop people from pretending (such as trying to get the
> absolute path of ".")   In xmlsh I attempt to support changing the cwd on a
> per-shell (which may or may not be a separate thread).  This largely but
> not entirely works.  It all depends on what API you use ... because I cant
> set the "real" CWD its virtualized ..  and only if you go through codepaths
> that know about this will it work.
>
>
>
> All in all ... if you want a reliable and portable file path handling I
> suggest you never use the current directory explicitly but rather force all
> file references to be resolved against an absolute path ... that is
> generally a supportable feature.  You can set this path in various places
> in your module and "call it" the "current directory" but you need to be
> very careful of all the places you make assumptions about resolving paths
> ... do they take the system CWD (if such a thing exists? ) do they take
> your set CWD ? at what snapshot in "time" ? can different modules have
> different settings for the cwd ? Is it part of a pushed/popped environment
> or globally set ? What scope ?
>
> Its very compelling to pretend that the problem is easy ... but its not.
>
>
>
> -David
>
>
>
>
>
>
>
>
>
>
>
>
>
> Hi Christian,
>
> I find both functions useful, especially current-dir(). It stands to
> reason that an XQuery application may be very interested in the current
> directory, in order to be able to resolve relative paths against the
> current dir. It should also be noted that file:list resolves relative paths
> against the current dir, so that subsequent use of the listed file names as
> URI argument in doc() simply MUST explicitly resolve against the current
> directory, as the implicit resolving performed by doc() is against the base
> URI of the query, which means the documents are not found (unless the query
> is contained by the current directory).
>
> Also noteworthy is that retrieval of the current directoy via file:parent
> requires a different argument than '.', as using '.' yields the parent
> directory of the current directory, rather than the current directory. This
> in turn means that retrieval of the current directory via file:parent
> requires the use of some arbitrary (and possibly fake) file name as
> argument, like so
>
>    file:parent('dummy')
>
> It is very desirable that retrieval of the current directory can be
> achieved in a straightforward way, rather than the "tricky" way via
> file:parent.
>
> Kind regards,
> Hans-Jürgen
>
>
>  --
> You received this message because you are subscribed to the Google Groups
> "EXPath" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to expath+unsubscribe@googlegroups.com.
> To post to this group, send email to expath@googlegroups.com.
> Visit this group at http://groups.google.com/group/expath.
> For more options, visit https://groups.google.com/d/optout.
>