1. File handling
- Posted by Daniel Berstein <daber at PAIR.COM> Jun 06, 1998
- 532 views
- 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
- Posted by Hawke <mdeland at NWINFO.NET> Jun 06, 1998
- 478 views
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
- 493 views
- 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
- Posted by Daniel Berstein <daber at PAIR.COM> Jun 07, 1998
- 492 views
-----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
- Posted by Daniel Berstein <daber at PAIR.COM> Jun 07, 1998
- 489 views
-----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
- Posted by Andy Kurnia <akur at DELOS.COM> Jun 07, 1998
- 509 views
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
- Posted by Einar Mogen <nord.staernes at ROLLAG.MAIL.TELIA.COM> Jun 07, 1998
- 495 views
>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
- Posted by Daniel Berstein <daber at PAIR.COM> Jun 07, 1998
- 490 views
-----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
- Posted by Irv <irv at ELLIJAY.COM> Jun 07, 1998
- 489 views
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
- Posted by Irv <irv at ELLIJAY.COM> Jun 07, 1998
- 490 views
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
- Posted by Terry Constant <constant at FLASH.NET> Jun 07, 1998
- 487 views
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
- Posted by mountains at MINDSPRING.COM Jun 07, 1998
- 484 views
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
- Posted by Irv <irv at ELLIJAY.COM> Jun 07, 1998
- 521 views
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
- Posted by Terry Constant <constant at FLASH.NET> Jun 07, 1998
- 527 views
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