1. File handling
- Posted by Daniel Berstein <daber at PAIR.COM>
Jun 06, 1998
-
Last edited Jun 07, 1998
Has anyone done routines for deleting, renaming, copying, moving, and
creating temporary files?
I'd never realized Euphoria didn't bring this ?!
Rob, why don't you include these standard C functions on next release
(there're at io.h, stdio.h, dir.h):
access chmod chsize lock
unlock mktemp remove rename
mkdir rmdir
2. Re: File handling
Daniel Berstein wrote:
>
> Has anyone done routines for deleting, renaming, copying, moving, and
> creating temporary files?
>
> I'd never realized Euphoria didn't bring this ?!
>
> Rob, why don't you include these standard C functions on next release
> (there're at io.h, stdio.h, dir.h):
>
> access chmod chsize lock
> unlock mktemp remove rename
> mkdir rmdir
did you take a look at the system command? you get access to all of
DOS's
functions that way...also, unless i miss my guess, those commands above
are a variant of some sort of UNIX...no? if so, then (to my knowledge)
Euphoria doesn't support UNIX variants yet...
hope this helps (HTH-- my contribution to the initial clutter for this
week :) )
--mike
3. Re: File handling
- Posted by mountains at MINDSPRING.COM
Jun 06, 1998
-
Last edited Jun 07, 1998
At 08:05 PM 6/6/98 -0300, you wrote:
>Has anyone done routines for deleting, renaming, copying, moving, and
>creating temporary files?
>
>I'd never realized Euphoria didn't bring this ?!
>
>Rob, why don't you include these standard C functions on next release
>(there're at io.h, stdio.h, dir.h):
>
> access chmod chsize lock
> unlock mktemp remove rename
> mkdir rmdir
>
How about system(delete, rename, mkdir, rmdir, attrib)?
The file/record lockings are available via an interrupt,
so a Euphoria include file could be written to call
the interrupt, if there was any interest. How many people are
runnng Euphoria on shared data?
Irv
4. Re: File handling
-----Original Message-----
De: mountains at MINDSPRING.COM <mountains at MINDSPRING.COM>
Para: EUPHORIA at cwisserver1.mcs.muohio.edu
<EUPHORIA at cwisserver1.mcs.muohio.edu>
Fecha: domingo 7 de junio de 1998 0:23
Asunto: Re: File handling
>The file/record lockings are available via an interrupt,
>so a Euphoria include file could be written to call
>the interrupt, if there was any interest. How many people are
>runnng Euphoria on shared data?
I don't need currently file locking... but who know in the near future? It's
easy to implement... so why don't put it? That means: Rob you have homework.
Regards,
Daniel Berstein
daber at pair.com
5. Re: File handling
-----Original Message-----
De: Hawke <mdeland at NWINFO.NET>
Para: EUPHORIA at cwisserver1.mcs.muohio.edu
<EUPHORIA at cwisserver1.mcs.muohio.edu>
Fecha: sábado 6 de junio de 1998 23:23
Asunto: Re: File handling
>Daniel Berstein wrote:
>>
>> Has anyone done routines for deleting, renaming, copying, moving, and
>> creating temporary files?
>>
>> I'd never realized Euphoria didn't bring this ?!
>>
>> Rob, why don't you include these standard C functions on next release
>> (there're at io.h, stdio.h, dir.h):
>>
>> access chmod chsize lock
>> unlock mktemp remove rename
>> mkdir rmdir
>
>
>
>did you take a look at the system command? you get access to all of
>DOS's
>functions that way...also, unless i miss my guess, those commands above
>are a variant of some sort of UNIX...no? if so, then (to my knowledge)
>Euphoria doesn't support UNIX variants yet...
>
>hope this helps (HTH-- my contribution to the initial clutter for this
>week :) )
>--mike
I know we can use system(), but that's a shell call... not a native code.
The point is that it's really easy for Rob to include them in Euphoria.
Besides, if you're using a GUI a system() call will flicker the screen.
Regards,
Daniel Berstein
daber at pair.com
6. Re: File handling
Daniel Berstein:
> access chmod chsize lock
> unlock mktemp remove rename
> mkdir rmdir
GREAT! I vote for this 
Irv Mullins:
>How about system(delete, rename, mkdir, rmdir, attrib)?
They need command.com AND they will cause screen flicker under exw.
The last one ALSO needs attrib.exe.
What if attrib.exe has a virus?
>The file/record lockings are available via an interrupt,
>so a Euphoria include file could be written to call
>the interrupt, if there was any interest. How many people are
>runnng Euphoria on shared data?
How many people are running a share-aware program on non-shared data?
How many people are not using the lock/unlock mechanism of C?
How many people omit SHARED or LOCK ... when OPENing a file in BASIC?
What I am saying is, that it's better to have something even if most of us
don't use it, than not to have something someone is going to use!
Euphoria is (almost) a complete language, which is why I like it. Why force
programmers to manually code lock() in Assembly? Or, use system() to call
system commands? 
For example, there is someone in this list [me ] who almost never uses
graphics_mode() but is glad it exists when it is needed... who would want
to do system("mode co80", 2); everytime?
Why is there puts() if you can code system("echo " & seq, 2);? (To redirect
output to file you use system("echo " & seq & " >file", 2);)
Why is there printf() if you can code system("echo " & sprintf(fmtstr,
seq), 2);?
Ah, a few new procedures/functions (on file handling) will NOT hurt anyone
7. Re: File handling
>Besides, if you're using a GUI a system() call will flicker the screen.
When you call system, one of the parameters passed is a flag telling whether
you want screen output or not. So the screenflicker can be avoided. (am I
right?)
Einar
8. Re: File handling
-----Original Message-----
De: Einar Mogen <nord.staernes at ROLLAG.MAIL.TELIA.COM>
Para: EUPHORIA at cwisserver1.mcs.muohio.edu
<EUPHORIA at cwisserver1.mcs.muohio.edu>
Fecha: domingo 7 de junio de 1998 5:40
Asunto: Re: File handling
>>Besides, if you're using a GUI a system() call will flicker the screen.
>
>When you call system, one of the parameters passed is a flag telling
whether
>you want screen output or not. So the screenflicker can be avoided. (am I
>right?)
No. The parameter is to tell the function if the system has to change video
mode before returning control to the program. If you're program runs on text
mode you can tell system you don't need a video change... else you need
it ---> flicker :(
I'm sure that Rob can hardcode these functions into Euphoria. In the
meantime I coded some Euphoria functions that use int 21 to do the job (no
lock/unlock). I just sent them to Rob.... grab them soon from RDS's site.
Regards,
Daniel Berstein
daber at pair.com
9. Re: File handling
At 03:13 PM 6/7/98 +0700, Andy Kurnia wrote:
>
>What I am saying is, that it's better to have something even if most of us
>don't use it, than not to have something someone is going to use!
>
One word: C
Irv
10. Re: File handling
At 04:53 AM 6/7/98 -0300, Daniel wrote:
>-
>De: Einar Mogen <nord.staernes at ROLLAG.MAIL.TELIA.COM>
>>>Besides, if you're using a GUI a system() call will flicker the screen.
>>
>>When you call system, one of the parameters passed is a flag telling
>whether
>>you want screen output or not. So the screenflicker can be avoided. (am I
>>right?)
>
>No. The parameter is to tell the function if the system has to change video
>mode before returning control to the program. If you're program runs on text
>mode you can tell system you don't need a video change... else you need
>it ---> flicker :(
>
I am puzzled. I just added a command to one of the buttons in
my GUI database to delete a file: system("delete test.xxx",2)
When I click that button, the file gets deleted, and there is
no flicker or other problem. More surprising, if the file is not found, a
neat "file not found" appears at the top of the screen without changing from
mode 256, and you continue on without trouble.
Ok, the truth is I have been secretly deleting your files at
random every time you play my concentration game...didn't notice,
did you?
Bwahahaha!!!
Irv
11. Re: File handling
mountains at MINDSPRING.COM wrote:
>
> At 08:05 PM 6/6/98 -0300, you wrote:
> >Has anyone done routines for deleting, renaming, copying, moving, and
> >creating temporary files?
> >
> How about system(delete, rename, mkdir, rmdir, attrib)?
>
The main problem with system() is the lack of error reporting if one of
the commands fail for some reason. I have written two special routines
that use system() and the special features of 4Dos to capture stderr
output, exit code of internal commands, and exit code of external
commands. But these routines are kludges. If there were a system type
function that could capture and return such information, it would be a
step forward.
One possible example, using 4Dos.com:
sequence errinfo
errinfo = systemcap("Rename MyFile ThisFile",?)
errinfo would contain {atom, atom, sequence}
that is, {External exit code, internal exit code, sequence containing
stderr}
Its been so long since I worked with Command.com, I can't remember if
there is a way to get exit code info on internal commands. If not there
would only be one atom.
In any case, the return sequence would have information about success or
failure that could be analyzed.
--
Terry Constant
constant at flash.net
12. Re: File handling
At 06:44 AM 6/7/98 -0500, Terry Constant wrote:
>Its been so long since I worked with Command.com, I can't remember if
>there is a way to get exit code info on internal commands. If not there
>would only be one atom.
>
There must be a way. Batch files can branch based on errorlevel.
Also there is interrupt 4Dh that reads the errorlevel returned
on a program exit (I think. Anybody want to wade thru the dos-ref
and find out for sure?)
>In any case, the return sequence would have information about success or
>failure that could be analyzed.
>
Someone made a suggestion to Rob that system() be made a function,
rather than a procedure, for exactly that purpose. I hope he
sees fit to change it.
Irv
13. Re: File handling
At 08:05 AM 6/7/98 -0400, you wrote:
>At 06:44 AM 6/7/98 -0500, Terry Constant wrote:
>
>>Its been so long since I worked with Command.com, I can't remember if
>>there is a way to get exit code info on internal commands. If not there
>>would only be one atom.
>>
>There must be a way. Batch files can branch based on errorlevel.
>Also there is interrupt 4Dh that reads the errorlevel returned
>on a program exit (I think. Anybody want to wade thru the dos-ref
>and find out for sure?)
>
>>In any case, the return sequence would have information about success or
>>failure that could be analyzed.
>>
>Someone made a suggestion to Rob that system() be made a function,
>rather than a procedure, for exactly that purpose. I hope he
>sees fit to change it.
>
I tried the interrupt routine below, but it doesn't work.
Why? My guess is because the errorlevel code is destroyed
by the first call to errorlevel.
Perhaps system() is using (therefore destroying) it before
returning? Only Rob can tell us.
On the other hand, maybe something is wrong with my interrupt
routine. I don't know much about writing these.
include machine.e
sequence reg_list -- list of register values
function ErrorLevel()
reg_list = repeat(0, 10)
reg_list[REG_AX] = #4D00 -- function: get ERRORLEVEL
reg_list = dos_interrupt(#21, reg_list) -- Call DOS interrupt #21
return reg_list
end function
? ErrorLevel()
system("del test.xxx",2)
? ErrorLevel() -- prints same as above, regardless of whether
-- the system call fails or succeeds.
Irv
ref:Programmer's Technical Reference for MSDOS and the IBM PC
Chap.4
Function 4Dh Get Return Code of a Subprocess (WAIT)
Get return from functions 31h and 4Dh (ERRORLEVEL)
entry AH 4Dh
return AH circumstance which caused termination
00h normal termination
01h control-break or control-C
02h critical device error
03h terminate and stay resident (function 31h)
AL exit code of subprogram (functions 31h or 4Ch)
note 1) The exit code is only returned once (the first time).
2) This call is explicitly supported in the OS/2 1.x DOS
Compatibility Box.
3) Many programmers have wondered where DOS stores this
information, so they might access it multiple times or set it
directly. This is a version-dependent area that changes with
every release of DOS.
14. Re: File handling
Irv wrote:
>
> I tried the interrupt routine below, but it doesn't work.
> Why? My guess is because the errorlevel code is destroyed
> by the first call to errorlevel.
> Perhaps system() is using (therefore destroying) it before
> returning? Only Rob can tell us.
> On the other hand, maybe something is wrong with my interrupt
> routine. I don't know much about writing these.
>
> include machine.e
> sequence reg_list -- list of register values
>
> function ErrorLevel()
> reg_list = repeat(0, 10)
> reg_list[REG_AX] = #4D00 -- function: get ERRORLEVEL
>
> reg_list = dos_interrupt(#21, reg_list) -- Call DOS interrupt #21
> return reg_list
> end function
>
> ? ErrorLevel()
> system("del test.xxx",2)
> ? ErrorLevel() -- prints same as above, regardless of whether
> -- the system call fails or succeeds.
>
Irv,
Its been awhile since I worked with this stuff. But my first response to
your "Why?" it doesn't work is that your first call to ErrorLevel() is
to the shell (of Command.com) that the Euphoria program is in. The
system() loads another shell, so any error codes generated by programs
in that shell go there. By the time you get to your second call to
ErrorLevel(), the shell is gone in which the error codes were generated
and your second call is merely reading the same shell as the first call,
that is the same info.
--
Terry Constant
constant at flash.net
