Qrix braucht -P (und noch mehr?)

[Klaus Lehmann]

On Thu, 08 Feb 2001 10:21:52 +0100, Allers Heinrich wrote:

guten tag herr allers
danke für die ausführliche antwort.

leider habe ich etwas vergessen zu erwähnen, ich hätte
ihnen in ihrer argumentation einige mühen ersparen können.
sorry vielmals.


kl>> kl>index -f70 -ddaten\kat -ekat/daten -n0 -m0 -h0
kl>> kl>zu geben, wenn das Ganze auf K:\BIBL\ALLEGRO
kl>> stattfindet.
kl>
kl>Nein, das ist keine feine Art des Aufrufes, denn es
setzt voraus, daß
kl>entweder ein DOS-Pfad ins Allegro-Programmverzeichnis
gelegt worden ist,
kl>oder daß das Aufruf- und Arbeitsverzeichnis mit dem
kl>Allegro-Programmverzeichnis identisch ist.
genau. so sehe ich das auch. aber h. fischers methode
funktioniert ja.


kl>
kl>Für Experten sollte eigentlich die Sache so aussehen:
Aufrufverzeichnis,
kl>Programmverzeichnis und Datenbankverzeichnis sind
grundsätzlich drei
kl>verschiedene, an beliebigen Stellen im Netz liegende
Verzeichnisse.

!!und da war mein versäumnis!!

ich denke und arbeite (teilweise? weniger!) noch in alten
allegro-dos-zeiten. da war und konnte aufrufverzeichnis
gleich dem arbeitsverzeichnis sein. (=immer in netzwelten
gedacht.)
da gabs die guten alten batschies, temporäre files wurde
beim indexieren ins datenverz. geschrieben, und beim
batchgesteuerten index da auch gelöscht. proto? tauchte
auch im datenverz auf (DAS fande ich IMMER sehr
interessant! es bedurfte keines parameters dafür.
index/qrix muss es irgendwie gemerkt haben, das es nur
leserechte im arbeitsverz gibt, hat sich also in datenverz
hinübergerettet. klug(vor)gedacht von den herren
programmierern (gabs da auch damen?). lob, lob.... ;-)

aber zu zeiten von win32-modulen. tja. seufz.
da gebe ich ihnen 100% recht.
aller(s)dings spare ich mir da die trennung: 
1. aufruf GLEICH programm-verz.
/liegt lokal! auf festplatte
/hier hat der win9x/winnt-user die vollen rechte

2. datenverz. liegt im netzwerk
/hier kann man mit nt-mitteln (etwas problematischer wohl
mit win9x!?) den bereich des servers sicher machen:
volle rechte für die mitarbeiter, leserechte für den
opac-user
/das ist jetzt ganz platt formuliert, muss und kann man
noch besser machen/


das problem für den admin liegt offen und klar:
-das netzlaufwerk ist einfach zu supporten. files
raufkopiert. sauber.

-aber die lokalen directories! da muss man sich dan
gedanken machen, wie man automatische file-update-routinen
herstellt, die auch dann lokal greifen. es geht, ja es
geht. ich hab mir da was gebaut. dank dos-batch-befehlen
(was machen 'wir' bloss unter win2000???? da soll es keine
commando-shell geben. ist dieser alptraum korrekt??? ;-)
hmmmm?!


--(dumm) gefragt: sind denn wirklich 3 unterschiedliche
verzeichnisse notwendig?
--wennich zwei davon lokal habe? (=aufruf und programm) ?
--das dritte ist das datenverz. und liegt auf dem netz. ok.



--oder funktioniert es denn bei ihnen so:
--UND das wäre in der tat genial!!!!
-einmal aufrufverz lokal (da ist WAS drinn?) nur ein
lnk-datei? oder eine batch?
-zweitens programmverz auf dem netz (readonly)
-drittens datenverz. auf dem netz (write/create/delete usw
usw)

WENN die konstruktion SO funktioniert, wäre sie phänomenal!

sie würde VIEL support-arbeit ersparen. (ich wette, h.
fischer liest jetzt auch SEHR aufmerksam mit?! ;-) und
nicht nur er, da gibts noch ein paar kollegen, die mir
einfallen....  willkommen im club, ist man versucht zu
sagen ;-)


ach, wäre das schön. nur einzweidrei (mehr nicht!) files
lokal. die user könnten keinen unfug machen. der rest auf
dem server. megagut!
wenn ich viel zeit habe, mache ich mich mal ran.
(klar ist, daß die schriftenfonts nach \winnt\system32 o.ä.
gehören (win9x analog); dareum geht es mir nicht. IHR wisst
alle, wie schwer es ist, 500 files in dem lokalen
programmverz auf dem neusten stand zu halten???!!!)






weiter..
kl>Andere Alternative, wenn Sie mit Indexparameterdatei kat
arbeiten:
kl>set -p=<Programmlaufwerk>:\<Programmverzeichnis>
kl>set -d=<Datenbanklaufwerk>:\<Datenbankverzeichnis>
kl>%-p%\index -f70 -d%-d%\kat -ekat/%-d% -n0 -m0 -h0
kl>> kl>Also: Die Neuindexierung braucht unter DOS alle
Pfade.
kl>Ja, aber übergeben über Umgebungsvariable. (Und einen
ins
kl>Programmverzeichnis führenden DOS-Pfad schon garnicht!).
kl>> Sonst hat man einen
kl>> kl>Sack voll I-Zwischendateien und eine alte ADX.
jepp. siehe oben.



kl>> 1. hier verzichte ich auf die pfadangabe (z.B.
kl>> k:\index.exe) , da ich den aufruf immer aus dem
kl>> allegro-programmverzeichnis mache,
kl>
kl>Das wundert mich, daß gerade Sie als Systemverwalter das
Aufrufverzeichnis
kl>mit dem Programmverzeichnis zusammenfallen lassen.  :-))
siehe oben. das war mein versäumnis! ;-)
die indexierung der datenbankdateien, die ja im
netzwerklaufwerk liegen, lasse ich (batschgesteuert logo)
in einem temporären netzwerklaufwerk indexieren, von dort
werden sie ins ursprüngliche netzdatenlaufwerk verlagert.
das läuft recht gut. 's sinds sogar einige
erkenungsschritte eingebaut, in der geprüft wird, ob die
datenbnak in benutzung ist oder nicht. uswusw.


kl>> dazu kommt noch, dass ich absolute 'hygiene' bei der
kl>> unterscheidung von datenbankpfad zu programmpfad
betreibe:
kl>> bedeutet: im datenbankpfad befinden sich nur
kl>> stl,tbl,adx,ald,api,apt UND MEHR NICHT!
kl>> die apr,cfg,aim und alles andere gedöns befindet sich
im
kl>> programm(ier)pfad!
kl>Nach Ihrem Konzept liegen somit im Programmverzeichnis
auch alle temporären
kl>Dateien, das Gedöns halt. Das braucht nicht zu sein,
.... aber ich will mich
kl>jetzt nicht wiederholen!
jepp. siehe oben.


kl>> hmmm3, möchte so gerne aufräumen, mittlerweile besteht
kl>> c:\allegro aus über 500 files.
kl>
kl>Na und? Wichtig ist doch, daß man weiß, was
dahintersteckt, daß sie sich via
kl>Namen und/oder Dateityp klassifizieren lassen, und da
kann man Allegro doch
kl>eigentlich nicht vorwerfen, daß es das nicht
ermöglicht!?
kl>> und es wird unübersichtlich.
kl>Liegt's wieder nur am Werkzeug? Bei mir ist's optimal
übersichtlich: Ich
kl>nehme mein ztree und sage 'f *.flx' und sehe fein
aufgelistet alle Flexe,
kl>die neusten obenan; und danach sage ich 'f *.ap?' und
sehe alle
kl>Umschlüsselungs- und Exportparameterdateien, usw.
;-) grinsebacke....
nein, nein. 'wir' haben doch alle unsere lieblings-prima
werkzeuge, sie das ztree, andere den original-NC, dens ja
auch für win32(95/98/NT)+os2 gibt (OBWOHL er da ganz schön
schwerfällig ist!!!! ;-(((
'ne prima alternative ist DN (Dos Navigator). russische
quellen auf anfrage! ;-)
DN ist plattformübergreifend! (dos-os2[wichtig! ;-)]win9x,
winnt vermutlich auch win2k)
DN ist freeware!!!!
nebenbei: der MC (Midnight Commander, ein nc-clone aus der
unix(linux) welt) ist zwar auch für os2 portiert worden,
auch für DOS? WIN9X= WiNNT?; er ist auf alle fälle sehr(?)
schwierig zu installieren (ich komme dmait nicht klar! ;-);
und benötigt wohl irgendwelche X-Bibliotheken (?)



ganz gespannt
viele grüße
Ihr
k.l.

-
                                                                   
 Klaus Lehmann                              Adresse:               
 Admin Novell-Servers (Berlin-Kreuzberg)    Hundekehlestr. 18      
 und allegro-C-Dienstleistungen.            D-14199 Berlin         
 -Datenbankbereinigungen, safer shells      phone: 49-30-8950 3156 
 -Fehlerindices, Fremddatenimport/Export    mobil: 49-0171-9537843 
 -Novell Netware, WindowsNT-Server uvm.     phon2: 49-30-29049 123 
  eMail: klehmann at arco-online.de            fax:   49-30-29049 128