OpenEuphoria

2. Re: close(writefile)

• Posted by DerekParnell (admin) Dec 20, 2012
• 1206 views

No. This is due to a technical issue in that a routine cannot permanently change the value held in any argument passed to it. The scope of a parameter is limited to the routine, so any changes the routine makes to a parameter will not remain after the routine returns.

If you are using version 4 or above, as a work around, you could create your own close function, for example ...

function close(integer handle) 
     -- Avoid closing STDIN, STDOUT, STDERR, and already closed files. 
    if handle > 2 then 
        eu:close(handle) -- Call the built-in close function 
        return -1 
    end if 
    return handle 
end function 
 
integer fh 
 
   fh = open("someFile") 
   ? fh --> 3 or some other value 
   fh = close(fh) 
   ? fh --> -1 

It might be possible to change the built-in close routine into a function that returns -1 when it successfully closes a file, but we'd have to think that through a bit more for ramifications to existing code.

4. Re: close(writefile)

• Posted by jimcbrown (admin) Dec 20, 2012
• 1205 views

That's a good point. However, 0 is a valid file handle and normally represents stdin.

In the nix world, you can actually close stdin and later reuse the zeroth file handle when opening up a new file (for reading or writing, or both).

Maybe it should return -2, or 0.1 ?

6. Re: close(writefile)

• Posted by useless_ Dec 20, 2012
• 1200 views

Can you write to stdin? If variable_name "writefile" is set to stdin, it's still not an open write_file, and i must open() (assign a valid write file handle) to it. The code i'd write to test it being zero isn't broken by nix saying it's pointed to stdin, it still tells me it's not an open writing file.

useless

8. Re: close(writefile)

• Posted by DerekParnell (admin) Dec 20, 2012
• 1167 views

Actually, -1 is -1. Whether you wish your application to interpret it as a error code or not is at your discretion. I just used -1 to indicate a non-valid file handle value. I could have used a different value but it doesn't matter which at this point in the discussion, so long as it can never be a valid file handle.

We probably should have a function that takes a file handle and returns the current 'state' of the handle. Eg ... closed, open for read/write/append, etc ... and maybe a few other things about it.

10. Re: close(writefile)

• Posted by mattlewis (admin) Dec 21, 2012
• 1138 views

I don't think that's a good solution. It might be better to add some functions to be able to query the back end as to the status of a particular file handle.

In the mean time, you could write some simple wrappers around open and close that keep track of which file handles are being used.

Matt

12. Re: close(writefile)

• Posted by jimcbrown (admin) Dec 22, 2012
• 1121 views

integer fn = open(this) 
close(fn) 
integer fn2 = open(that) 

Both fn and fn2 can be used for reading and/or writing to, so I don't see a problem with that - both have the same integer and represent the same open file.

The only obvious thing I see here would be mistaken identity - one assumes fn points to this even though fn really is pointing to that. (This is not unique to Euphoria though but applies to any program in any language that uses file descriptors (fds).)

I suppose it wouldn't be too much trouble to add another function that can attempt to return a filename for a given file descriptor (when applicable of course), but at this point you might be better off not using file handles at all, instead using read_file() and write_file() or read_lines() and write_lines(), and simply always passing the filename in as a string.

14. Re: close(writefile)

• Posted by jimcbrown (admin) Dec 22, 2012
• 1135 views

I feel this would be too much trouble - what happens if two different filenames end up with the same hash? At the very least, I'd want to see a working implementation.

I'm inclined to agree with you here.

I confess that I'm not a fan of Euphoria tasks. When I need something like it, I prefer to use fork().

Again, I'm inclined to agree with you here (that task ids probably should be recycled, unless someone can think of a compelling reason why they shouldn't be).

16. Re: close(writefile)

• Posted by jimcbrown (admin) Dec 22, 2012
• 1085 views

That seems even more problematic. Again, I'd want to see a working implementation.

I see no benefit to this as opposed to just passing the filename as a string everytime.

Fair enough. You were just brainstorming, but you don't necessarily advocate or support this idea. Maybe someone else will pick up on it and like it, and write the implementation for it.

Until then, I'm with you - not a fan of hashes (at least not for this particular usage of hashes anyways).