View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000246 | LDMud | Efuns | public | 2004-11-26 23:56 | 2004-11-26 23:56 |
| Reporter | Assigned To | ||||
| Priority | normal | Severity | feature | Reproducibility | N/A |
| Status | new | Resolution | open | ||
| Summary | 0000246: Filepath resolution support | ||||
| Description | Short: 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 ( | | ) | ||||
| Tags | No tags attached. | ||||
| External Data (URL) | |||||
