1. exu and ex.err
Here's a thought for the group to discuss...
On the 'nix platform, there may be times when a particular user has read
only access to a particular folder, which means if anything goes wrong,
exu will not have the rights to create an ex.err in the current directory.
This is an especially big pain in the neck when writing CGI programs, since
NO ex.err file can EVER be written (unless I allow world-writable access to
my cgi-bin!) What does everybody think about creating a euphoria/errors/
directory where error files are written as PROGRAM_NAME.err? Then this
folder could be given world-writable (but NOT readable) rights, and there's
no problem, right?
Has anyone else run into this kind of problem, or am I the only one?...
Brian Jackson
bjackson at 2fargon.hypermart.net
2. Re: exu and ex.err
Brian:
It seems to me that you should not be writing any ex.err file.
Your CGI program should have been fully tested before going on line.
If it crashes because of not having the rights to write the ex.err file.
Don't forget you can still print a crash message.
You may be able in linux to redirect the ex.err output to the screen
instead of the file via a pipe or redirection.
The best way to protect your security take system offline, change
the rights, debug the problem, then change the rights
and go back online.
Bernie
3. Re: exu and ex.err
Brian Jackson wrote:
> What does everybody think about creating a
> euphoria/errors/directory where error files
> are written as PROGRAM_NAME.err?
From what I've read and experienced myself, *nix permissions are one of the
biggest irritations when moving over from DOS. I don't know that there's a
need for a new directory, though. How about putting it in /bin?
-- David Cuny
4. Re: exu and ex.err
Brian Jackson writes:
> On the 'nix platform, there may be times when a
> particular user has read only access to a particular folder,
> which means if anything goes wrong, exu will not have the
> rights to create an ex.err in the current directory.
A while back I considered adding a crash_file("...")
library routine that would let you specify the relative or
absolute path name of the error file (normally "./ex.err").
I guess I'll go ahead with that for the Linux alpha release.
You'll be able to write the error file anywhere you like.
Maybe "" will mean "no error file".
Currently, exu should notice that it can't open ex.err, and should
issue a brief message to standard error.
Regards,
Rob Craig
Rapid Deployment Software
http://members.aol.com/FilesEu/
5. Re: exu and ex.err
forgive the late answer (I was on holidays). just one point:
for no error file, use /dev/null ...
Riwal Raude
rauder at thmulti.com
> -----Original Message-----
> From: Robert Craig [SMTP:rds at ATTCANADA.NET]
> Sent: Friday, August 06, 1999 10:11 PM
> Subject: Re: exu and ex.err
>
> Brian Jackson writes:
> > On the 'nix platform, there may be times when a
> > particular user has read only access to a particular folder,
> > which means if anything goes wrong, exu will not have the
> > rights to create an ex.err in the current directory.
>
> A while back I considered adding a crash_file("...")
> library routine that would let you specify the relative or
> absolute path name of the error file (normally "./ex.err").
> I guess I'll go ahead with that for the Linux alpha release.
> You'll be able to write the error file anywhere you like.
> Maybe "" will mean "no error file".
>
> Currently, exu should notice that it can't open ex.err, and should
> issue a brief message to standard error.
>
> Regards,
> Rob Craig
> Rapid Deployment Software
> http://members.aol.com/FilesEu/
6. Re: exu and ex.err
Riwal Raude writes:
> forgive the late answer (I was on holidays). just one point:
> for no error file, use /dev/null ...
When Euphoria detects an error in your program
it normally writes a message on the screen
(i.e. to standard error), and it also writes an
"ex.err" file in the current directory.
With the new crash_file(filename) routine on Linux
(coming soon to DOS and Windows) you can
replace "ex.err" by a file of your own choosing,
anywhere on the machine. You can even write the
ex.err information to "/dev/null" on Linux, or "NUL"
on DOS/Windows. In this case the ex.err information
will be discarded, but you'll still get a message on the
screen (or standard error).
As a special case, if you say: crash_file("")
nothing will go to either ex.err *or* the screen.
Public Domain users will always get the >300 message
if their program exceeds 300 statements. Executables
bound by registered users are not affected by the 300 limit.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
7. Re: exu and ex.err
Rob:
While you are adding changes for crash message features would you
please add the following feature.
Add a magic number to the abort. abort(magic number) so that
when the abort contains the magic number and is executed that you
process it the same way as you process a run-time error.
That is dump all the data to a ex.err file and display the crash
message.
I have been using this method to debug my code by using abort(1/0)
executing this causes a divide by zero error and dumps the error
file and displays the crash message. ( This works OK but the error
file says divide by zero error ) The only thing to add would be
needed is to detect the magic number and taking the same action
as a divide error and changing the error message to "Debug Dump".
Bernie
