View Issue Details

IDProjectCategoryView StatusLast Update
0000246LDMudEfunspublic2004-11-26 22:56
ReporterlarsAssigned To 
PrioritynormalSeverityfeatureReproducibilityN/A
Status newResolutionopen 
Summary0000246: Filepath resolution support
DescriptionShort: Efun to resolve paths
From: Lars Duening <lars@bearnip.com>
Date: Tue, 22 May 2001 23:46:39 -0600
Type: Feature
State: New

Following up to all the resolve_path mails - I'll write something on the
catch_output and reload_object tomorrow (and apologies to Dale who now gets
to read this all again):

Dale Perkins wrote on Saturday, May 19 2001, 14:08:04:

>> - The relative path requires an anchor to be relative to. By default this
>> could be the current object, but the wizard should be able to specify
>> otherwise. A possible efun signature would therefore be
>>
>> string resolve_path ( string pathname
>> , string|object anchor = this_object())
>
>How about calling query_path() in the object passed to the efun, if that
>fails then you use the objects base directory.

Hmm, I don't really like adding hard coded lfun names to the driver - but
there might be a different way of getting the same result:

   string resolve_path ( string pathname
                       , string|object|closure anchor)

If the anchor is a string, it is the anchor path.
If the anchor is an object, it's object_name is the anchor path.
If the anchor is a closure, it is called and the resulting string is the
anchor path.

Your idea could then be implemented with the call

    resolve_path(path, (: this_object()->query_path() :) )

or easier

    resolve_path(path, this_object()->query_path() );

> string dir_of(object ob){
> return "/" + implode(explode(file_name(ob), "/")[0..<2], "/");
> }

This would be a equivalent to the dirname and basename unix commands. Are
they needed often?

>> - The ~ notation for home directories needs to be understood, and in
>> extension any shortcut notation (Nightfall for example uses + for
>> domains and & for projects). The solution I see here is to introduce
>> a new master apply which is called for any path which begins with
>> a special character other than '/' and '.'.

I thought about this, and I think that a resolve_path() efun does not need to
expand the shortcuts - it just needs to recognize them. The actual expansion
can be done in valid_read()/valid_write(), where it happens nowadays anyway.

Acius wrote:

>I have written a fair amount of MS-DOS, Windows, and Linux code, and
>they all have very similar systems for handling relative paths. Namely,
>each object/process has its own "current directory" and paths in all
>file commands are evaluated relative to it. If embedding this in the
>lib, I would actually change the handling of relative paths in all
>file-access commands. That would let me do things like:
>
>read_bytes("mydata", 100);
>
>... or ...
>
>save_object("myself");

I think the problem here is that there is no widely accepted notion of what
the 'current directory' for an object is, so we'd end up with a boondoggle of
hooks. In other words: this kind of functionality belongs into simul_efuns
and/or valid_read() and valid_write().

> Admittedly, the system I've described above doesn't need a new efun at
> all, just a few extra calls to master.c. And in fact, this entire system
> could be implemented with existing MUDlib code using valid_read and
> valid_write mechanisms... (although I think the point was making it
> consistent, not just making it possible)

The original point was to make one of the central pieces of path resolution
more efficient :-)

--
Lars Duening; lars@bearnip.com
PGP Key: http://www.bearnip.com/lars/pgp-lars.asc
------------------------------------------------------------------------------
Freaky writes:

Generell wuerde ich mir so eine Funktion im Driver auch wuenschen, da
ich dann nicht immer so auf einen korrekten Filenamen achten muesste
(z.B. kein .. oder /./ oder // im Pfad usw.)

Wir haben fuer diesen Zweck folgende simul-efuns:
abs_path und file_path

Und Funktionen 'add_path' und 'query_current_path' im Pla
Wildcard-Aufloesung.
------------------------------------------------------------------------------
Date: Thu, 24 May 2001 13:21:17 -0400
From: Matthew Julius <julius.2@wright.edu>

Lars Duening wrote:

[snip]

> string resolve_path ( string pathname
> , string|object|closure anchor)
>
> If the anchor is a string, it is the anchor path.
> If the anchor is an object, it's object_name is the anchor path.
> If the anchor is a closure, it is called and the resulting string is the
> anchor path.

[snip]


I'm not a big fan of this resolve_path() business. Relative paths vary
widely from game to game and the only consistent relative symbols used
across the board are "." and "..". I don't see an efun making them
that much more efficient. The LPC overhead in converting a relative path
to absolute is miniscule compared to the amount of work that you're
probably doing anyway (file manipulation, ls, etc.) so I don't see this
efun being used for efficiency concerns. I think it would only be useful
for convenience, but it's not particularly convenient for anyone who
already has a simul efun that does this (and probably does a whole lot
more, at that).

Additionally, there's going to be confusion with leading slashes and
other relative symbols. For example, what are the results of these calls
in compat mode (or native mode for that matter):

  resolve_path("dir/", "/secure")
    "dir/"
    "/dir/"
    "secure/dir/"
    "/secure/dir/"
  resolve_path("~wizard", "/secure")
    "/secure/~wizard"
    "secure/~wizard"
    "~wizard"
    "/~wizard"

So, at the very least, wouldn't we need a driver hook to define the
relative symbols ? What if somebody's mudlib allows a wizard to define
his or her own symbols ?

Also, most mudlibs will be doing processing after a call to resolve_path()
anyway, so this efun would be even less of a savings. It probably
wouldn't result in any savings at all, since all it will be doing is
converting "." and "..". The mudlib I use also allows "...", which causes
even more confusion. Is the "..." resolved at all, or do I end up
resolving it in a simul efun (in which case, I'd rather just do "." and
".." along with it).

I just don't see how this functionality is all that useful as an efun.

> >> - The ~ notation for home directories needs to be understood, and in
> >> extension any shortcut notation (Nightfall for example uses + for
> >> domains and & for projects). The solution I see here is to introduce
> >> a new master apply which is called for any path which begins with
> >> a special character other than '/' and '.'.
>
> I thought about this, and I think that a resolve_path() efun does not need to
> expand the shortcuts - it just needs to recognize them. The actual expansion
> can be done in valid_read()/valid_write(), where it happens nowadays anyway.

It definitely has to recognize the relative symbols. However, if it's
not expanding them also, what exactly is this efun going to be doing? And
whatever that is, why is it an efun and not 2 or 3 lines of LPC in a simul
efun?


> The original point was to make one of the central pieces of path resolution
> more efficient :-)

Hmm ...



--
Matthew Julius o_o
                                 ( _ )
julius.2@wright.edu ( | | )
TagsNo tags attached.
External Data (URL)

Activities

There are no notes attached to this issue.

Issue History

Date Modified Username Field Change
2004-11-26 22:56 lars New Issue