1. Include File Relative Paths
- Posted by c.k.lester <euphoric at cklester.com> Mar 06, 2007
- 560 views
- Last edited Mar 07, 2007
What do you suggest to combat this issue...? I'm including a file that is in a subdirectory. I would like to keep the relative file path references in the include file to accommodate updates, etc. For example: include system/myfile.e myfile.e contains o = open_file("txt/afile.txt") The file path system/txt/afile.txt is perfectly valid, but open_file() fails to find it. This is because Euphoria doesn't look relative to where the include file is located. Is there a fix for this? or what is a reasonable workaround? Thanks.
2. Re: Include File Relative Paths
- Posted by don cole <doncole at pacbell.net> Mar 06, 2007
- 535 views
- Last edited Mar 07, 2007
c.k.lester wrote: > > What do you suggest to combat this issue...? > > I'm including a file that is in a subdirectory. I would like to keep the > relative file path references in the include file to accommodate updates, etc. > > For example: > > include system/myfile.e > > myfile.e contains > > o = open_file("txt/afile.txt") > > The file path system/txt/afile.txt is perfectly valid, but open_file() fails > to find it. This is because Euphoria doesn't look relative to where the > include file is located. > > Is there a fix for this? or what is a reasonable workaround? > > Thanks. Hello c.k.lester , I had this problen with some bmp files. My work around:
global function wCheckFile(sequence file_path) integer fn VOID = setSearchPaths(file_path) fn = w32FileOpen(file_path, "r") -- looks in the search paths if fn=-1 then VOID = message_box( file_path, "Can't Find File", MB_ICONHAND+ MB_TASKMODAL ) return 0 end if return 1 end function wCheckFile(current_dir()&"\\txt\\afile.txt")--I notice you didn't have 2 back slashes here. o = open_file(current_dir()"\\txt\\afile.txt")--again you need another back slash
If the file isn't there then the message box will tell you where it should be. Don Cole
3. Re: Include File Relative Paths
- Posted by c.k.lester <euphoric at cklester.com> Mar 06, 2007
- 528 views
- Last edited Mar 07, 2007
don cole wrote: > c.k.lester wrote: > > I'm including a file that is in a subdirectory. I would like to keep the > > relative file path references in the include file to accommodate updates, > > etc. > > Is there a fix for this? or what is a reasonable workaround? > I had this problen with some bmp files. My work around: > global function wCheckFile(sequence file_path) ... > end function > wCheckFile(current_dir()&"\\txt\\afile.txt")--I notice you didn't have 2 back > slashes here. I use forward slashes because they work on both Windows and Linux and because I don't have to escape it. "txt/myfile.e" is the same as "txt\\myfile.e" Thanks, Don. I'll try your current_dir() solution tomorrow and see if that works.
4. Re: Include File Relative Paths
- Posted by Derek Parnell <ddparnell at bigpond.com> Mar 06, 2007
- 524 views
- Last edited Mar 07, 2007
c.k.lester wrote: > > What do you suggest to combat this issue...? > > I'm including a file that is in a subdirectory. I would like to keep the > relative file path references in the include file to accommodate updates, etc. > > For example: > > include system/myfile.e > > myfile.e contains > > o = open_file("txt/afile.txt") > > The file path system/txt/afile.txt is perfectly valid, but open_file() fails > to find it. This is because Euphoria doesn't look relative to where the > include file is located. > > Is there a fix for this? or what is a reasonable workaround? You will have to run some code in the include file to find itself. That is, you will have to look for "system/myfile.e" in the command_line()[1] directory, then in the directories mentioned in $EUINC symbol, and finally in the $EUDIR/include directory. -- Derek Parnell Melbourne, Australia Skype name: derek.j.parnell
5. Re: Include File Relative Paths
- Posted by c.k.lester <euphoric at cklester.com> Mar 06, 2007
- 528 views
- Last edited Mar 07, 2007
c.k.lester wrote: > don cole wrote: > > global function wCheckFile(sequence file_path) > ... > > end function > > wCheckFile(current_dir()&"\\txt\\afile.txt")--I notice you didn't have 2 > > back > slashes here.</font></i> > I'll try your current_dir() solution tomorrow and see if that works. Okay, I just tried it. Didn't work. The current_dir() is still the base directory and doesn't pick up the fact that the calling file is in a subdirectory... :/
6. Re: Include File Relative Paths
- Posted by c.k.lester <euphoric at cklester.com> Mar 07, 2007
- 562 views
Derek Parnell wrote: > c.k.lester wrote: > > I'm including a file that is in a subdirectory. I would like to keep the > > relative file path references in the include file to accommodate updates, > > etc. > > Is there a fix for this? or what is a reasonable workaround? > You will have to run some code in the include file to find itself. That is, > you > will have to look for "system/myfile.e" in the command_line()[1] directory, > then > in the directories mentioned in $EUINC symbol, and finally in the > $EUDIR/include > directory. Hey, Derek, I figure you or Matt (or any of the leet Euphoria programmers out there!) could resolve this with a little bit o' code in the interpreter, couldn't you? :) How much would it take to put this in Euphoria: that it also checks the containing directory of the included file? Why wouldn't that be seen as a good thing? Rob? I can tell you why it's necessary: CGI programming. Also, usability (and ease-of-use), and development simplicity. Unless there's a better way. But I don't see it, and I checked the forums and saw Derek's suggestion for using the ^ symbol to indicate an include file is to be found relative to the including file's home directory. But that wouldn't affect using open() from an included file that's in a subdirectory, would it? Anyway, to whomever: make it so. Pretty please. :)
7. Re: Include File Relative Paths
- Posted by Robert Craig <rds at RapidEuphoria.com> Mar 07, 2007
- 527 views
c.k.lester wrote: > > Derek Parnell wrote: > > c.k.lester wrote: > > > I'm including a file that is in a subdirectory. I would like to keep the > > > relative file path references in the include file to accommodate updates, > > > etc. > > > Is there a fix for this? or what is a reasonable workaround? > > You will have to run some code in the include file to find itself. That is, > > you > > will have to look for "system/myfile.e" in the command_line()[1] directory, > > then > > in the directories mentioned in $EUINC symbol, and finally in the > > $EUDIR/include > > directory. > > Hey, Derek, I figure you or Matt (or any of the leet Euphoria programmers out > there!) could resolve this with a little bit o' code in the interpreter, > couldn't you? :) > > How much would it take to put this in Euphoria: that it also checks the > containing directory of the included file? Why wouldn't that be seen as a > good thing? Rob? I thought Chris Bensler was working on this. He had my blessing to make some changes in the front end for this. Regards, Rob Craig Rapid Deployment Software http://www.RapidEuphoria.com
8. Re: Include File Relative Paths
- Posted by don cole <doncole at pacbell.net> Mar 07, 2007
- 538 views
c.k.lester wrote: > > c.k.lester wrote: > > don cole wrote: > > > global function wCheckFile(sequence file_path) > > ... > > > end function > > > wCheckFile(current_dir()&"\\txt\\afile.txt")--I notice you didn't have 2 > > > back > > slashes here.</font></i> > > I'll try your current_dir() solution tomorrow and see if that works. > > Okay, I just tried it. Didn't work. The current_dir() is still the base > directory and doesn't pick up the fact that the calling file is in a > subdirectory... :/ Okay why can't you just drag and drop afile.txt to your base directory? Or locate with walk_dir()? I'm not sure what you're trying to do here but it seems to me you're trying to make something simple difficult. Don Cole
9. Re: Include File Relative Paths
- Posted by don cole <doncole at pacbell.net> Mar 07, 2007
- 533 views
c.k.lester wrote: > > > For example: > > include system/myfile.e > > c.k., I may not be the brightest bulb in the chandelier. I can see putting an include file the INCLUDE directory. Or putting an include file in the EU directory. But why would you want to put an include file in the system direcory? Don Cole
10. Re: Include File Relative Paths
- Posted by c.k.lester <euphoric at cklester.com> Mar 07, 2007
- 546 views
don cole wrote: > c.k.lester wrote: > > For example: > > include system/myfile.e > I may not be the brightest bulb in the chandelier. I can see putting an > include > file the INCLUDE directory. Or putting an include file in the EU directory. > But why would you want to put an include file in the system direcory? hehe. That doesn't actually refer to the Windows/System folder... Here's my setup (+ is directory, - is file) (example not real!): bbcmf <-- (base directory) - index.esp - plugins.e <-- this handles adding the plugins in the plugins dir + system - one.e - two.e - plugins.e <-- this handles base functionality for plugins -- and exposes a plugins API + plugins + plugin1 + res - plugin1.css - plugin1.js - plugin1.e In index.esp, I include plugins.e, which includes plugins/plugin1/plugin1.e, which has a command like import_script( "res/plugin1.js" ) I want that import_script() to recognize a relative location, because someone else might have their plugins directory labeled modules or something else. I don't want to have to use import_script( "plugins/plugin1/res/plugin1.js" ) (as is required now). It's duplicitous and if the directory structure changes, I'm screwed. And, again, if somebody else wants to use the plugin, they would have to make changes to the include file. That's a no-no. The point is to have modular code that can be used or removed easily. For one plug-in file, that's obviously not a big deal. But for 5-10, over the population of hundreds of programmers, that's a lot of wasted time and energy. This hasn't been the best example, but if you search the forum you'll see the discussions that have occurred because of it.
11. Re: Include File Relative Paths
- Posted by Matt Lewis <matthewwalkerlewis at gmail.com> Mar 07, 2007
- 541 views
c.k.lester wrote: > > Hey, Derek, I figure you or Matt (or any of the leet Euphoria programmers out > there!) could resolve this with a little bit o' code in the interpreter, > couldn't you? :) > > How much would it take to put this in Euphoria: that it also checks the > containing directory of the included file? Why wouldn't that be seen as a > good thing? Rob? > I believe the relevant code is path_open() in scanner.e. CK, I nominate you to take a swing at it :) Once you get it working, send it to me, and I'll commit it for you. It's pretty straight forward: <euforum> function path_open() -- open an include file (new_include_name) according to the include path rules integer absolute, try sequence full_path object inc_path sequence errbuff absolute = FALSE -- skip whitespace not necessary - String Token does it -- check for leading backslash absolute = find(new_include_name[1], SLASH_CHARS) or (not ELINUX and find(':', new_include_name)) if absolute then -- open new_include_name exactly as it is try = open(new_include_name, "r") if try = -1 then errbuff = sprintf("can't open %s", new_include_name) CompileErr(errbuff) end if return try end if -- relative path name - first try main_path full_path = main_path & new_include_name try = open(full_path, "r") if try = -1 then -- Search directories listed on EUINC environment var inc_path = getenv("EUINC") if sequence(inc_path) and length(inc_path) > 0 then inc_path = append(inc_path, PATH_SEPARATOR) full_path = "" for p = 1 to length(inc_path) do if inc_path[p] = PATH_SEPARATOR then -- end of a directory. -- remove any trailing blanks and SLASH in directory while length(full_path) and find(full_path[$], " \t" & SLASH_CHARS) do full_path = full_path[1..$-1] end while if length(full_path) then full_path = full_path & SLASH & new_include_name try = open(full_path, "r") if try != -1 then exit end if full_path = "" end if else -- don't store leading blanks in directory if length(full_path) or (inc_path[p] != ' ' and inc_path[p] != '\t') then full_path &= inc_path[p] end if end if end for inc_path = inc_path[1..$-1] end if end if if try = -1 then -- Finally, try EUDIR\INCLUDE full_path = eudir & SLASH & "include" & SLASH & new_include_name try = open(full_path, "r") end if if try != -1 then -- successful new_include_name = full_path return try end if if length(main_path) = 0 then main_path = "." end if if find(main_path[$], SLASH_CHARS) then main_path = main_path[1..$-1] -- looks better end if if atom(inc_path) then errbuff = sprintf("can't find %s in %s\nor in %s%sinclude", {new_include_name, main_path, eudir, SLASH}) else errbuff = sprintf("can't find %s in %s\nor in %s\nor in %s%sinclude", {new_include_name, main_path, inc_path, eudir, SLASH}) end if CompileErr(errbuff) end function </euforum>
12. Re: Include File Relative Paths
- Posted by c.k.lester <euphoric at cklester.com> Mar 07, 2007
- 529 views
Matt Lewis wrote: > c.k.lester wrote: > > How much would it take to put this in Euphoria: that it also checks the > > containing directory of the included file? Why wouldn't that be seen as a > > good thing? Rob? > I believe the relevant code is path_open() in scanner.e. CK, I nominate > you to take a swing at it :) Well, thankfully, you're not on the nominating committee! :P > Once you get it working, send it to me, and I'll commit it for you. Okay, so where is scanner.e? I don't even have a compiler installed on my PC, which I assume I'd need if working on the interpreter, right? What will I need to install in order to really work on this? If there's a page of instructions somewhere, lemme know. :) (Chris Bensler? You got it working, yet?)
13. Re: Include File Relative Paths
- Posted by Matt Lewis <matthewwalkerlewis at gmail.com> Mar 07, 2007
- 524 views
c.k.lester wrote: > > Matt Lewis wrote: > > c.k.lester wrote: > > > How much would it take to put this in Euphoria: that it also checks the > > > containing directory of the included file? Why wouldn't that be seen as a > > > good thing? Rob? > > I believe the relevant code is path_open() in scanner.e. CK, I nominate > > you to take a swing at it :) > > Well, thankfully, you're not on the nominating committee! :P > > > Once you get it working, send it to me, and I'll commit it for you. > > Okay, so where is scanner.e? I don't even have a compiler installed on my > PC, which I assume I'd need if working on the interpreter, right? What will > I need to install in order to really work on this? If there's a page of > instructions somewhere, lemme know. :) > This is all front end stuff, so you can use the euphoria backend to test. You probably already have the source on your machine, if you installed a 3.x release. You could even work on it with the ooeu source, since I haven't changed that part of the code. Matt
14. Re: Include File Relative Paths
- Posted by c.k.lester <euphoric at cklester.com> Mar 07, 2007
- 536 views
Matt Lewis wrote: > > I believe the relevant code is path_open() in scanner.e. CK, I nominate > you to take a swing at it :) Once you get it working, send it to me, and > I'll commit it for you. okay, here's the required changes: add this function:
function get_file_path(sequence s) -- return a directory path from a file path for t=length(s) to 1 by -1 do if find(s[t],SLASH_CHARS) then return s[1..t] end if end for -- if no slashes were found then can't assume it's a directory return ".\"" end function
Then, in path_open(), make this change: ...
if absolute then -- open new_include_name exactly as it is try = open(new_include_name, "r") if try = -1 then errbuff = sprintf("can't open %s", new_include_name) CompileErr(errbuff) end if return try end if ---------------------------------------------------------------------------- ---------------------------------------------------------------------------- -- THIS IS THE NEW AND REVISED CODE FOR USING RELATIVE INCLUDE FILE PATHS... -- first try path from current file path currdir = get_file_path( file_name[current_file_no] ) full_path = currdir & new_include_name try = open(full_path, "r") if try = -1 then -- relative path name - first try main_path full_path = main_path & new_include_name try = open(full_path, "r") end if -- END OF NEW AND REVISED CODE FOR USING RELATIVE INCLUDE FILE PATHS ---------------------------------------------------------------------------- ---------------------------------------------------------------------------- if try = -1 then -- Search directories listed on EUINC environment var inc_path = getenv("EUINC")
... Hopefully it's clear where to insert new code and modify old code. Now relative includes work. Now to get open() to work relatively... Where's that?
15. Re: Include File Relative Paths
- Posted by c.k.lester <euphoric at cklester.com> Mar 07, 2007
- 532 views
c.k.lester wrote: > > add this function: add it just before path_open() :) > }}} <eucode> > function get_file_path(sequence s) > -- return a directory path from a file path > for t=length(s) to 1 by -1 do > if find(s[t],SLASH_CHARS) then > return s[1..t] > end if > end for > -- if no slashes were found then can't assume it's a directory > return ".\"" that should probably be return "." & SLASH
16. Re: Include File Relative Paths
- Posted by c.k.lester <euphoric at cklester.com> Mar 07, 2007
- 541 views
c.k.lester wrote: > Forgot to mention the need for a new variable in path_open() sequence currdir (whew!)
17. Re: Include File Relative Paths
- Posted by Pete Lomax <petelomax at blueyonder.co.uk> Mar 07, 2007
- 533 views
c.k.lester wrote: > > What do you suggest to combat this issue...? > > I'm including a file that is in a subdirectory. I would like to keep the > relative file path references in the include file to accommodate updates > > For example: > > include system/myfile.e > > myfile.e contains > > o = open_file("txt/afile.txt") > > The file path system/txt/afile.txt is perfectly valid, but open_file() > fails to find it. This is because Euphoria doesn't look relative to where > the include file is located. > > Is there a fix for this? or what is a reasonable workaround? > First a half-silly question: where is open_file() defined? See also the separate comment to Rob/Chris that I am about to make. I really think you want to manage this properly/manually, eg:
global ciDir -- current include directory ciDir="" ... ciDir="system/" -- or &="system/" include system/myfile.e ciDir="" -- or ciDir[1..length(ciDir)-7] -- myfile.e contains: constant myiDir=ciDir -- save my include dir ... o = open(myiDir&"txt/afile.txt")
At least keeping mods to ciDir next to the include statements makes future maintainenance relatively painless. Regards, Pete
18. Re: Include File Relative Paths
- Posted by Pete Lomax <petelomax at blueyonder.co.uk> Mar 07, 2007
- 523 views
Robert Craig wrote: > I thought Chris Bensler was working on this. > He had my blessing to make some changes in > the front end for this. Alarm bells a-ringing! Does this mean that db_open/create/compress, read/save_bitmap, etc will start to mess about in C:\Euphoria\include ?? Does not sound like a good idea to me, Pete
19. Re: Include File Relative Paths
- Posted by c.k.lester <euphoric at cklester.com> Mar 07, 2007
- 536 views
Pete Lomax wrote: > c.k.lester wrote: > > I'm including a file that is in a subdirectory. I would like to keep the > > relative file path references in the include file to accommodate updates > > include system/myfile.e > > myfile.e contains > > o = open_file("txt/afile.txt") > > The file path system/txt/afile.txt is perfectly valid, but open_file() > > fails to find it. This is because Euphoria doesn't look relative to where > > the include file is located. > First a half-silly question: where is open_file() defined? It's irrelevant in this example. I could have just used open(file,mode) in the sample code up there. The problem is, the open() is getting called from a file that's in a subdirectory of the directory containing the base program file. If you'll check out my fix for relative include files, you'll see the solution. I just don't know how to apply it to open() in the interpreter. > I really think you want to manage this properly/manually, eg: > > }}} <eucode> > global ciDir -- current include directory > ciDir="" I don't think a variable in the global namespace is proper in this case (or ever, really) when all I'm trying to do is open a file relative to the calling file. The fix for relative include paths was easy. It allows you to do this: -- base program file c:\htdocs\my_prog.exw include mydir/one.e -- c:\htdocs\mydir\one.e include two.e -- c:\htdocs\mydir\two.e include nextdir/three.e -- c:\htdocs\mydir\nextdir\three.e puts(1,"I'm included!") Run this with the current interpreter and you get a "can't find file..." error. Run it with the relative include file code and it works fine. Why would one want to do that? Portability! Maintainability! When somebody takes my c:\htdocs\plugins\superPlugin code directory and puts it into their program's directory (which might be z:\net\htdocs\release\, they can simply include the include file and it will all work... no include path modifications required. That's how it should be.
20. Re: Include File Relative Paths
- Posted by Robert Craig <rds at RapidEuphoria.com> Mar 07, 2007
- 522 views
- Last edited Mar 08, 2007
Pete Lomax wrote: > Robert Craig wrote: > > I thought Chris Bensler was working on this. > > He had my blessing to make some changes in > > the front end for this. > > Alarm bells a-ringing! > Does this mean that db_open/create/compress, read/save_bitmap, etc will start > to mess about in C:\Euphoria\include ?? No. Definitely not. Chris Bensler proposed a change to the search path for opening *include files* at compile-time (i.e. path_open() in scanner.e). I said I agreed in principle with this change, and gave him the go ahead to discuss it here and test it. I think his change would satisfy C.K. and some other people. Chris then raised a bunch of other controversial ideas that were never resolved, and lately he seems to have disappeared without checking in any source code changes. I'm not sure if or when he is going to get back to this. The Euphoria open() built-in routine is implemented by the C routine EOpen() in be_runtime.c It is *not* going to change. It passes a file name or path string to the O/S which opens it. The O/S, of course, makes use of the O/S's idea of the "current working directory" when opening relative paths. Regards, Rob Craig Rapid Deployment Software http://www.RapidEuphoria.com
21. Re: Include File Relative Paths
- Posted by c.k.lester <euphoric at cklester.com> Mar 07, 2007
- 524 views
- Last edited Mar 08, 2007
Robert Craig wrote: > Pete Lomax wrote: > > Does this mean that db_open/create/compress, read/save_bitmap, etc will > > start > > to mess about in C:\Euphoria\include ?? > No. Definitely not. > > Chris Bensler proposed a change to the search path for > opening *include files* at compile-time (i.e. path_open() in scanner.e). I have made the required changes so include can work with relative paths. I don't think anything will break. It simply adds another place to check for include files... namely, from the calling file's directory. Rob, have you seen that modification? Doesn't it work satisfactorily? > The Euphoria open() built-in routine is implemented > by the C routine EOpen() in be_runtime.c > It is *not* going to change. It passes a file name or path string to > the O/S which opens it. The O/S, of course, makes use of the O/S's idea > of the "current working directory" when opening relative paths. What needs to change for this to work: -- c:\htdocs\my_prog.e include mydir/inc1.e -- c:\htdocs\mydir/inc1.e if sequence(dir("res/myfile.txt")) then fn = open("res/myfile.txt","r") else puts(1,"Doesn't work.") end if -- c:\htdocs\mydir\res\myfile.txt setting1=c:\ setting2=Craig setting3=Robert Something needs to change so that open() and dir() both understand that if it doesn't find "res/myfile.txt" in some default location, it is to look for it starting with the calling file's directory. Relative file locations = good If this is not going to be changed, I can work around it. I just haven't seen a downside to this, yet. Anybody want to suggest some?
22. Re: Include File Relative Paths
- Posted by Jason Gade <jaygade at yahoo.com> Mar 07, 2007
- 528 views
- Last edited Mar 08, 2007
c.k.lester wrote: > What needs to change for this to work: > > -- c:\htdocs\my_prog.e > include mydir/inc1.e > > -- c:\htdocs\mydir/inc1.e > if sequence(dir("res/myfile.txt")) then > fn = open("res/myfile.txt","r") > else > puts(1,"Doesn't work.") > end if > > -- c:\htdocs\mydir\res\myfile.txt > setting1=c:\ > setting2=Craig > setting3=Robert > > Something needs to change so that open() and dir() both understand that > if it doesn't find "res/myfile.txt" in some default location, it is to > look for it starting with the calling file's directory. > > Relative file locations = good > > If this is not going to be changed, I can work around it. I just haven't > seen a downside to this, yet. Anybody want to suggest some? I was thinking about this and I think it's a bad idea for open(). It's a good idea for include though. When you include a file, then as far as that file is concerned it is part of the main app and runs from the same directory. What am I missing? -- "Any programming problem can be solved by adding a level of indirection." --anonymous "Any performance problem can be solved by removing a level of indirection." --M. Haertel "Premature optimization is the root of all evil in programming." --C.A.R. Hoare j.
23. Re: Include File Relative Paths
- Posted by Jason Gade <jaygade at yahoo.com> Mar 07, 2007
- 564 views
- Last edited Mar 08, 2007
Especially if you think you're building a library of functions to be used and the library doesn't know if it resides in $EUINC or in myapp/some/deeply/nested/directory. -- "Any programming problem can be solved by adding a level of indirection." --anonymous "Any performance problem can be solved by removing a level of indirection." --M. Haertel "Premature optimization is the root of all evil in programming." --C.A.R. Hoare j.
24. Re: Include File Relative Paths
- Posted by Pete Lomax <petelomax at blueyonder.co.uk> Mar 08, 2007
- 537 views
c.k.lester wrote: > > Pete Lomax wrote: > > I really think you want to manage this properly/manually, eg: > > > > }}} <eucode> > > global ciDir -- current include directory > > ciDir="" > > I don't think a variable in the global namespace is proper in this case > (or ever, really) when all I'm trying to do is open a file relative to > the calling file. You seem to miss the point that you cannot and must not change open(). You will break thousands of existing programs (including Edita!). However I suppose you could do this: 1) extend the enhancements to path_open so that the new currdir variable is always left with whatever path actually succeeded. 2) add a new builtin open_relative(name,mode) which is just like open except that it emits tmp=currdir&name open(tmp,mode). <snip> > Why would one want to do that? Portability! Maintainability! I know! I have had relative includes working myself nearly a year now. Very nice they are too. (Just a shame the rest of my language isn't finished.) > When somebody takes my c:\htdocs\plugins\superPlugin code directory and puts > it into their program's directory (which might be z:\net\htdocs\release\, > they can simply include the include file and it will all work... no include > path modifications required. That's how it should be. Wait a minute here. So you are saying that they can dump it in \release, or \release\superPlugin, or \release\junk and it has to work in all cases?? Otherwise why not just use a "superPlugin" constant?? Or are you saying you have a component and you don't want to tell it what it is part of? Why not? Confused now, Pete
25. Re: Include File Relative Paths
- Posted by c.k.lester <euphoric at cklester.com> Mar 08, 2007
- 546 views
Pete Lomax wrote: > c.k.lester wrote: > > I don't think a variable in the global namespace is proper in this case > > (or ever, really) when all I'm trying to do is open a file relative to > > the calling file. > You seem to miss the point that you cannot and must not change open(). > You will break thousands of existing programs (including Edita!). How will it break it if all it does it look one more place for a file it is trying to open, which would have crashed in the past? > However I suppose you could do this: > 1) extend the enhancements to path_open so that the new currdir variable is > always left with whatever path actually succeeded. > 2) add a new builtin open_relative(name,mode) which is just like open except > that > it emits tmp=currdir&name open(tmp,mode). I suspect #2 would suffice. It would be the enhanced open(), which I would then use all the time. Why not? :) > > When somebody takes my c:\htdocs\plugins\superPlugin code directory and puts > > it into their program's directory (which might be z:\net\htdocs\release\, > > they can simply include the include file and it will all work... no include > > path modifications required. That's how it should be. > > Wait a minute here. So you are saying that they can dump it in \release, or > \release\superPlugin, or \release\junk and it has to work in all cases?? Yes, which isn't that amazing. It happens in PHP all the time. I'm sure other languages handle it just fine. > Otherwise why not just use a "superPlugin" constant?? I've resorted to a plugins constant for now. > Or are you saying you > have a component and you don't want to tell it what it is part of? Why not? The plugins basically add things to the entire setup with code like add_script("text/javascript", "plugins/jquery/res/jquery-latest.js" ) which, with relative open(), would be add_script("text/javascript", "res/jquery-latest.js" ) meaning that 'plugins' and 'jquery' can be user definable without any user modification to the plugin code. But now I'm doing this (lame): add_script("text/javascript", PLUGINS_DIR & "jquery/res/jquery-latest.js" ) which is still not optimal because the file resides in jquery, yet it has to specify itself. LAME! I just like flexibility (and portability) (and modularity), to an extreme. :)
26. Re: Include File Relative Paths
- Posted by Pete Lomax <petelomax at blueyonder.co.uk> Mar 11, 2007
- 559 views
c.k.lester wrote: > How will it break it if all it does it look one more place for a file it is > trying to open, which would have crashed in the past? OK, that was not clear at all. If you want *retry* logic, then wot Derek said at the get-go is the best. I've been talking about "one-shot" opens. While such may or may not be a problem for many standard calls to open(), without any hesitation it would clearly be a "very bad thing"™ for say the open in db_create(). Already exists? No problem. Let me create another one somewhere else. You would be alone in thinking that is a good idea (I hope). > > > However I suppose you could do this: > > 1) extend the enhancements to path_open so that the new currdir variable is > > always left with whatever path actually succeeded. > > 2) add a new builtin open_relative(name,mode) which is just like open except > > that > > it emits tmp=currdir&name open(tmp,mode). > > I suspect #2 would suffice. What? Are you on (and not taking) some medication I should know about? Why o why would you want to implement part 2 only, with a variable which may or may not contain the desired directory??!! > > Wait a minute here. So you are saying that they can dump it in \release, > > or \release\superPlugin, or \release\junk and it works in all cases?? > > Yes, which isn't that amazing. As I now realise, "retry" logic. > It happens in PHP all the time. > I'm sure other languages handle it just fine. I'm sure Eu handles it just fine, if you code it. Regards, Pete
27. Re: Include File Relative Paths
- Posted by Pete Lomax <petelomax at blueyonder.co.uk> Mar 11, 2007
- 547 views
I wrote: > > c.k.lester wrote: > > I suspect #2 would suffice. > What? <snip> Actually, ignore that whole idea anyway, since it has no retry logic. Pete