26 May
2007
26 May
'07
7:38 p.m.
I've got a few nested (via CALL) batch files that create different
files via the > and >> redirection operators under MS-DOS 7.01.
Everything seems to work fine until I've created more than the number
of files on my CONFIG.SYS FILES= statement--whereupon I get a "File
creation error" message and DOS hangs, necessitating a reboot.
It seems as if COMMAND.COM is keeping open any file created within a
batch script by redirection. Is this really so--or is it the case
that DOS isn't closing each batch file invoked with a CALL statement?
Assuming that this is a real stinker of a DOS bug, how does one get
around it?
Cheers,
Chuck
27 May
27 May
1:32 a.m.
Chuck Guzis wrote:
I've got a few nested (via CALL) batch files that
create different
files via the > and >> redirection operators under MS-DOS 7.01.
Everything seems to work fine until I've created more than the number
of files on my CONFIG.SYS FILES= statement--whereupon I get a "File
creation error" message and DOS hangs, necessitating a reboot.
It seems as if COMMAND.COM is keeping open any file created within a
batch script by redirection. Is this really so--or is it the case
that DOS isn't closing each batch file invoked with a CALL statement?
In my experience, DOS keeps all files open until the original parent
batch file finishes execution.
Assuming that this is a real stinker of a DOS bug, how
does one get
around it?
1. Increase FILES= (what is it set to now?)
2. Chain if at all possible (it sounds like you're going past DOS's
nominal level of recursion)
--
Jim Leonard (trixter at oldskool.org) http://www.oldskool.org/
Help our electronic games project: http://www.mobygames.com/
Or check out some trippy MindCandy at http://www.mindcandydvd.com/
A child borne of the home computer wars: http://trixter.wordpress.com/
1:03 p.m.
On 27 May 2007 at 0:32, Jim Leonard wrote:
1. Increase FILES= (what is it set to now?)
2. Chain if at all possible (it sounds like you're going past DOS's
nominal level of recursion)
That's what I thought. FILES=500 isn't an option with DOS, I think.
I wonder if doing something like:
job-step-1>TEMP
job-step-2>>TEMP
REN TEMP TARGET-FILE-1
job-step-3>TEMP
job-step-4>>TEMP
REN TEMP TARGET-FILE-2
...
In other words, use the same file name over and over again as the
redirection target, but rename it to the real target after it's been
created.
I suppose that I'll just code the whole thing in CENVID if that
doesn't work.
Cheers,
Chuck
1:49 p.m.
Chuck Guzis wrote:
On 27 May 2007 at 0:32, Jim Leonard wrote:
I wonder if a rename forces the batch interpreter to close any reference to
the source file anyway?
Are you stuck using MSDOS? e.g. 4DOS has a much better batch interpreter from
what I remember and might not be crippled in the same way.
1. Increase FILES= (what is it set to now?)
2. Chain if at all possible (it sounds like you're going past DOS's
nominal level of recursion)
That's what I thought. FILES=500 isn't an option with DOS, I think.
I wonder if doing something like:
job-step-1>TEMP
job-step-2>>TEMP
REN TEMP TARGET-FILE-1
2:24 p.m.
On 27 May 2007 at 12:49, Jules Richardson wrote:
I wonder if a rename forces the batch interpreter to
close any reference to
the source file anyway?
That's my hope, but there's no guarantee of that. COMMAND.COM could
just keep opening new handles leaving the old ones open.
Are you stuck using MSDOS? e.g. 4DOS has a much better
batch interpreter from
what I remember and might not be crippled in the same way.
I'm using DOS 7.01 (or something like it that hosts Win98, but I'm
not running Windows) and using DOSLFN to support long file names.
Does 4DOS support long file name references?
I'd like to see a COMMAND.COM with lfn support and some of the handy
batch extensions of Win2K, such as nested FORs.
Cheers,
Chuck
3:29 p.m.
Chuck Guzis wrote:
I'm using DOS 7.01 (or something like it that
hosts Win98, but I'm
not running Windows) and using DOSLFN to support long file names.
Does 4DOS support long file name references?
Yes, it would seem that it does - from the install readme for v7.50:
When installing 4DOS under Windows 95/98 we recommend that you do NOT
use a "long" directory name. If you do, you will have to know and use
the equivalent short name to load 4DOS in CONFIG.SYS; it's easier to
simply use a short name from the beginning. (This is not a 4DOS
limitation. It's because DOS, which starts before Windows 95/98 and
loads the primary command processor, cannot handle long file names.
While 4DOS fully supports long file names, to make DOS work well it
is best to install 4DOS in a directory with a short name.)
Grab a copy from http://www.jpsoft.com/ftp/free/4dos750.exe
Or if you're feeling insane, grab the source from http://www.4dos.hit.bg and
build it yourself :-)
I'd like to see a COMMAND.COM with lfn support and
some of the handy
batch extensions of Win2K, such as nested FORs.
I believe that the 4DOS batch extensions were about as powerful as it ever got
for MS platforms (short of switching to something like Perl). It always amazed
me at just how limited the standard MSDOS / NT shell batch language was, but
then I got spoiled by UNIX platforms...
cheers
Jules
4:58 p.m.
On 27 May 2007 at 14:29, Jules Richardson wrote:
Grab a copy from
http://www.jpsoft.com/ftp/free/4dos750.exe
Or if you're feeling insane, grab the source from http://www.4dos.hit.bg and
build it yourself :-)
Thanks, I may do that. My recollection from using 4DOS in the
"olden" (DOS 4.01) times was that there was a considerable number of
incompatibilities with programs expecting COMMAND.COM. Maybe it's
time to revisit it.
I believe that the 4DOS batch extensions were about as
powerful as it ever got
for MS platforms (short of switching to something like Perl). It always amazed
me at just how limited the standard MSDOS / NT shell batch language was, but
then I got spoiled by UNIX platforms...
I've considered using a version of bash for MS-DOS, but there are
enough differences (such as the interpretation of command lines with
wildcards) that it'd throw a monkey wrench into anything expecting
COMMAND.COM rules.
For doing strange things, I can recommend CENVID and (for Win32)
CENWIN. Essentially an interpreted C dialect tied into the
DOS/Windows environment. I believe it's in the SIMTEL library--but
no source code.
Cheers,
Chuck
cheers
Jules
6262
days inactive
6263
days old
6 comments
3 participants
participants (3)
-
cclist＠sydex.com -
julesrichardsonuk＠yahoo.co.uk -
trixter＠oldskool.org