OpenEuphoria

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.

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.

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... :/

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

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

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>

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

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

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

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.

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?

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.

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. :)

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