[Date Prev][Date Next][Subject Prev][Subject Next][
Date Index][
Subject Index]
Re: U2 Query: file locations
- Subject: Re: U2 Query: file locations
- From: "Robert Holmgren" holmgren@xxxxxxxx
- Date: Tue, 29 Nov 2005 01:56:25 -0500
** Reply to message from David Auerbach on Mon, 28
Nov 2005 16:56:16 -0500
> Sooooo, 44+3=44+1+1+1+1
> You can all wake up now, I'm done.
Right. Thanks, David. Good one!
But he's right, of course, even though he's looking for a new job. Bonne
chance, David! We don't do any real recursion, at least not in XPL -- the
language isn't built for it, it requires far too much memory anyway, and takes
much (or somewhat) longer than an iterative procedure (even though the code can
be extremely concise, because all you need is a base procedure and a statement
of what to do with what David calls successors). But it's easy to think of a
loop as something that recurs, so... sloppy language and imprecise thinking
being endemic everywhere, it's common to call that recursion. For example,
here's a very practical iterative procedure that actually can perform a useful
service:
Find Files wherever they may be on the drive, and display their attribute status
I've deliberately slowed this down with PAUSE commands, so you can see what is
happening; normally you'd hide as much of this output as possible. It is
*crucial*, if you are testing this under NT, to replace the "kmd.exe" with
"cmd.exe". AND you want to pare down the list of C D E ... drives to what you
actually have available (i.e. , "va/nv $HD"). Lastly, this is *one
long line*, so remove any carriage return(s) at line ends introduced by your
Emailer. File it as TEST.BAT or something, then run it at DOS:
for %%a in (KMD.EXE LIST.COM U2UTL9x.BAT ZIP.EXE UNICOWS.dll) do kmd.exe /c for
%%b in (C D E F G H I J K L M N O P Q R S T U V W X Y Z) do kmd.exe /c for %%c
in (DIR/S/B ATTRIB/S PAUSE) do %%c %%b:\%%a
These are nested FOR...IN...DO commands, to three levels. The first level
lists a group of files to be found, one after the other. The second level
establishes the drives to be searched. In other words, it will search for the
first file KMD.EXE on all drives, one after the other. Then it will search for
the second file LIST.COM on all drives, one after the other... The actual
commands executed for *each* file on *each* drive are "DIR /includeSubdirs
/Bare_listing", then "ATTRIBute /includeSubdirs", then PAUSE -- *one after the
other*.
Now, the example I gave yesterday is not recursion either. That is very far
removed. That is simply a case of creating an agent in a program, then
executing the agent (as a child of the program a.k.a. parent), then deleting
the agent. We do that all the time in U2 -- it's fundamental. Here's a
concrete example, which brings us back to the "portable XyWrite" concept:
How do you deal *portably* with the PP: table that normally resides,
hard-coded, in DFL? The table that enumerates your printers, and enables you
to issue SETP commands. The answer is, you generate a fresh, machine-specific
copy of it each time you run STARTUP.INT, then you run it, then you delete it.
Remember that DFL is actually a PRiNter file -- no kidding. See that ";PR;" up
top, on line one? It's a PRiNter file. You *could* merge the entirety of DFL
into your "real" PRiNter file, and you'd be fine. They divorce DFL from PRN
for two reasons: 1) PRN would get too big (tops out at 64K), and 2) there's no
reason to repeat what applies to all PRNs if you have more than one PRN. So
DFL is separate.
OK, this is what we do. We locate all the PRNs that we might use in the same
dir as Editor. Then we run this:
>JM 2.GetPathQ2 +"\HPLJ-3.PRN \\PSMAINE\P1
3 "++"\HPLJ2FAX.PRN HP LaserJet Series II for Fax
1 "++"\TYF.PRN TYF to a foreign printer (IMage printing)
1 "++"\HPLJ-4.PRN \\PSNYC\P1
1 "++"\POSTGHST.PRN PostScript Ghostscript
1 "++"\STRIP.PRN Strip formatting
1 "++"\XYWBMAIL.PRN Strip formatting
1 "++"\HPL3ANSI.PRN ANSIfied LJ3
1 "++"\GENERIC.PRN Do nothing
">+"\SETP.PRN">BX sa %01,Q2 )>BX waitQ2 JM
2.AwaitFileQ2 BX load Q2 BX waitQ2 BX ernv Q2 BX waitQ2 BX setp 5Q2
BX waitQ2 ...
(Real code appears below.) We're creating, in Save/Get 01, a mini-PRiNter file
to be called SETP.PRN. It contains the PP: table and nothing else. The
D:\PATH specs are generated on-the-fly for each PRN. Save/Get 01 is written to
disk, LOADed, and then deleted (ERNV). Then we set POSTGHST.PRN as our default
printer (SETP 5). Finito. (BTW, if you want to use the HP LaserJet PRNs
listed above, how do you deal with the PR=d:\path\LJ4.BIN spec (or whatever) in
PRN? You use the RPLFIL command, to replace the filespec variable. Another
brief XPL routine.)
I should get paid for this...
XPLeNCODE v2.0
b-gin [UNTITLED]
>JM 2.GetPathQ2 +"
\LJ3.BIN,3P;*"+"; Doesn't work if not *in* PRN file![cr|lf]PP
:9[cr|lf]1{tab}"++"\HPLJ-3.PRN{tab}\\PSMAINE\P1[cr|lf]3
{tab}"++"\HPLJ2FAX.PRN{tab}HP LaserJet Series II for Fa
x[cr|lf]1{tab}"++"\TYF.PRN{tab}TYF to a foreign printer
(IMage printing)[cr|lf]1{tab}"++"\HPLJ-4.PRN{tab}\\PSN
YC\P1[cr|lf]1{tab}"++"\POSTGHST.PRN{tab}PostScript Ghos
tscript[cr|lf]1{tab}"++"\STRIP.PRN{tab}Strip formatting
[cr|lf]1{tab}"++"\XYWBMAIL.PRN{tab}Strip formatting[cr|
lf]1{tab}"++"\HPL3ANSI.PRN{tab}ANSIfied LJ3[cr|lf]1{tab
}"++"\GENERIC.PRN{tab}Do nothing[cr|lf]">+"
\SETP.PRN">BX sa %01,Q2 )>BX waitQ2 JM 2.Aw
aitFileQ2 BX load Q2 BX waitQ2 BX ernv Q2 BX wait
Q2 BX setp 5Q2 BX waitQ2 ...
-nd
XPLeNCODE
-----------------------------
Robert Holmgren
holmgren@xxxxxxxx
-----------------------------