Svenska ElektronikForumet

sodjan skrev:Sedan tycker jag att "environment" är ett korkat begrepp, även de lokala
tillhör ju "environment"... "System", "global" eller något liknande vore bättre.

Jag håller med dig.. soppigt är vad det är. Hur är det på VMS och DCL, du som kör det lite mer dagligdags än jag. Jag har fått känslan av att det kan blir ganska soppigt där med.

I OpenVMS? Där är allt så klart mycket tydligare och "bättre"...
Kan väl ta det lite kort då...

Det som bäst motsvarar "environment variables" är det som kallas "logical names".
Ett logiskt namn är något som har ett namn och som innehåller en textsträng.
Strängen kan innehålla vad som helst, t.ex ett directory eller någon konfiguration.

Logiska namn ligger inte direkt i procesen utan i "Logical name tables".
Default, om man inte säger något annat, så ligger de i processens egen tabell som alltid
heter LNM$PROCESS_TABLE. "LNM$" prefixar allt som har har logiska namn att göra.
Detta motsvarar väl vanliga lokala symboler med "set myvar mytext". Dessa försvinner
så klart när processen försvinner. Substitution genom en inbyggd funktion i "shellet" eller anrop från (t.ex) C.
De kan även användas direkt eftersom shellet översätter logiska namn transparent.
Vid inloggning skapas även ett antal standard logiska namn liknande sysin, sysout : Kommandon tar logiska namn helt transparent, man behöver alltså inte
*veta* att det är ett logisk namn man använder och prefixa med "$"
eller liknande syntax. Om man vill ha logiskal namn som är synliga för hela systemet så lägger man
det i system tabellen, d.v.s ungefär motsvarande "environment variables". Det finns en definierad search-order som är process -> job -> group -> system.
Så ett process logiskt namn överrider ett system logiskt namn vilket framgår om
man översätter ett logiskt namn. Man kan så klart specifikt ange att man vill ha
just ett system logiskt namn (trnlnm = "Translate Logical Name") : För specifika applikationer kan man skapa egna tabeller för logiska namn. Man kan
antingen lägga till den nya tabellen till processens "search order" eller så specar
man tabellen direkt. Genom att lägga tabellen i SYSTEM_DIRECTORY så blir
den direkt permanent och synlig för hela systemet. Ja det är väl en introduktion i alla fall. Kollosalt flexibelt och användbart
vilket kanske märks bäst då man *använder* logiska namn, här handlade
det kanske mest om hur man skapar och underhåller dom. Det är tydligt,
konsistent och så klart väldokumenterat.

Kommandon tar logiska namn helt transparent, man behöver alltså inte
*veta* att det är ett logisk namn man använder och prefixa med "$"
eller liknande syntax.

Hur skiljer man då mellan logiska namn och ren text?

I bash kan jag göra Och får resultatet

Nu blir jag besviken på VMS.

Jag trodde att logicals åtminstone delvis fungerade som assigns på amigan, alltså att om de pekar på en diskplats så evalueras de normalt redan när de sätts och följer därmed med t.ex. eventuella ändringar av namn på kataloger på disk eller liknande.


Jag tycker för övrigt att hela idén med env-variabler eller motsvarande är rätt kass. Program bör istället använda konfigurationsfiler, och shellscript bör givetvis vara utformade som vilka andra program som helst med ett för skalet eget sätt att ha lokala variabler, och lagring i filer för globala variabler.

Att "filer skräpar ner disken" är bara trams som kommer från alla usla operativsystem som inte har ett vettigt tempfilsystem som tömmer innehållet vid avstängning/omboot (som t.ex. amigans ramdisk)...

Alltså inom en annan textsträng?
När det gäller enkla saker inom processer så kan man använda symboler,
det liknar också lokala variabler i Unix/Linux. Om man har ett logiskt namn så får man använda en funktion: Men visst, jag var inte helt tydlig. Att det är transparent gäller inte
i rena texter rakt av. Men däremot där t.ex ett "device" förväntas:

> Jag trodde att logicals åtminstone delvis fungerade som assigns på amigan, alltså att om de pekar
> på en diskplats så evalueras de normalt redan när de sätts...

Ja alltså, ett logiskt namn är bara "ett namn" = "en text".
Själva definitionen innebär ingen evaluering alls. Om man
vill "frysa" värdet så får man översätta och spara det.

> ...och följer därmed med t.ex. eventuella ändringar av namn på
> kataloger på disk eller liknande.

Hur "följder de med" om de "evalueras redan när de sätts" ??


Det man normalt gör är att definiera en "root" för en specifik applikation.
Ta t.ex Python installationen på mitt test system. Vid boot körs ett
startup script som körs från systemets gemensamma startup: Det är enda stället som disken där Python ligger är hårdkodad (LDA2:).
Det generella startup scriptet (som kommer med kittet och som
jag inte behöver ändra något i) definierar sedan en root för Python: och sedan så använder alla andra logiska namn denna root som "disk": Så om jag skulle flytta Python till en annan disk, så är det *ETT* ställe att
justera i system startupen. Allt det andra "följer med" när Python setup körs.

Jag skulle även kunna lägga en egen python_root i min egen process
logiska tabell och t.ex testköra en ny version utan att det "syns".

sodjan skrev:Alltså inom en annan textsträng?

Eller om du har en "vaiabel" som råkar ha samma namn som en fil.
Kommer att skriva texten "Hej" i filen testfil.txt.
Skriver texten "Hej" i filen FOO.

Samma sak gäller för systemet i sig. När systemet bootar så sätt
en root för systemet utifrån den disk som det bootades från: Sedan refererar så klart alla andra logiska namn som pekar på olika
delar av operativsystemet till denna "root": O.s.v

> Eller om du har en "vaiabel" som råkar ha samma namn som en fil.

Ja, då är det ju bara en variabel som innehåller ett filnamn.
Om de är lika eller inte har ingen direkt betydelse.
Och nej, det sker ingen översättning inom texter direkt.
Där gäller som sagt för t.ex "device" som t.ex diskar o.s.v.

Från: http://en.wikipedia.org/wiki/Files-11#Logical_names

> The closest non-DEC operating system to support the concept of logical names is AmigaOS, through the ASSIGN command."

sodjan skrev: Ja, då är det ju bara en variabel som innehåller ett filnamn.

Nej, jag skrev en variabel som heter likadant som filen.

I mitt exempel hade jag en variabel FOO och en fil FOO. Variabeln FOO innehöll ett annat filnamn, så för att inte skriva till filen FOO måste jag "escapa" variabelns namn med $.

Det var ju det du påpekade att man "slipper" med VMS, men jag tycker VMS verkar kräva krångligare konstruktioner?

OK.
Aja, i alla fall inget problem eftersom översättning inte sker i ren text.
Dessutom så har ju Unix/linux ingen motsvarighet till logiska namn, så
em jämförelse på detaljnivå haltar så klart lite.

Som jag sa så gäller automatiken för "device" och liknande.
Översättningen sker för övrigt inte i "shell" eller i applikationer,
det sker i operativsystem (eller filsystemet eller liknande).

sodjan skrev:> ...och följer därmed med t.ex. eventuella ändringar av namn på
> kataloger på disk eller liknande.

Hur "följder de med" om de "evalueras redan när de sätts" ??

(Reservation för att jag kan ha glömt detaljerna kring syntax)

Om jag t.ex. först kör
assign Mittprogram: DH1:Mittprogram

så kommer Mittprogram: motsvara DH1:Mittprogram.
(Det normala och enda vettiga/dokumenterade är att peka på kataloger, men en slags "bugg-feature" gör att en assign i princip också kan peka på en enskild fil. Vad jag minns finns det typ ett enda program som använder detta...).

Om jag sedan gör
rename DH1:Mittprogram DH1:Mittgamlaprogram

så kommer Mittprogram: att motsvara DH1:Mittgamlaprogram

Därefter kan jag om jag vill skapa en ny DH1:Mittprogram-katalog och t.ex lägga in en ny version där, utan att det påverkar redan körande program.

Det finns dock flaggor man kan ge till assign som gör att evalueringen inte utförs när assign'en sätts, utan antingen en gång första gången den används eller varje gång den används (som VMS verkar göra).

Ditt exempel med logicals för Python är ungefär hur det fungerar på amigan, men som vanlig användare kan man inte sätta separata assigns per process, antagligen eftersom AmigaOS inte riktigt är ett fleranvändarsystem fullt ut. Det gör t.ex. att scriptet pcd som medföljer OS'et och vars syfte är att kunna byta till annan disk/katalog och "minnas" föregående katalog/disk behöver lägga med shellprocessens id i assignen.
Står jag t.ex. i DH1:Mittprogram och kör
pcd DH1:Mittgamlaprogram
och jag kör t.ex. shellprocess 7 så kommer scriptet pcd att sätta en assign som heter FROM7: som pekar på DH1:mittprogram. (Kör man pcd utan parameter så växlar man alltså till den disk/katalog som FROM*-assignen pekar på).

Assigns används ofta för sådant som att peka ut var en c-kompilator hittar include-filer o.s.v.

Det finns även nån "special-assigns" som egentligen inte är riktiga assigns eftersom man inte ser dem när man listar assigns, men de fungerar ungefär som en assign. PROGDIR: pekar normalt på katalogen där en körande binär ligger, och är givetvis specifikt per process. Allt möjligt blir spännande tillrört om man själv sätter en riktig assign för PROGDIR:

Något som kan röra till det är evalueringsordning, så kutym är att undvika att döpa diskar till namn som brukar användas på vanligt förekommande assigns o.s.v.

(Ja, en till specialare är att man både kan använda själva enhetsnamnet och volymnamnet som namn på en disk. För hårddiskar har det normalt ingen större användning, men för disketter och annan löstagbar media är det rätt bra. DF0: pekar alltid på första floppydriven, medan t.ex. Workbench: kan peka på den diskett som för ögonblicket sitter i DF0:. Om man tar ur den disketten och stoppar in i DF1: så kommer Workbench: fortfarande peka på den specifika disketten trots att den sitter i DF1:.

Disketternas namn, DF0: o.s.v., är hårdkodat men de flesta andra enheter går att sätta fritt, t.ex. är DH0: för en hårddisk bara praxis och något man sätter vid partitioneringen (medan namnet på volymen som ryms i partitionen sätts vid formatteringen). Det går att sätta "konstiga" namn, men det kan leda till underligheter. Jag minns en tråd nånstans där det framgick att typ 1-2 användare av en c-kompilator hade någon form av problem. Det visade sig att för att lyckas göra nån specialgrej så letade c-kompilatorn upp en process som heter "Workbench" vilket normalt är den process som sköter motsvarigheten till windows explorer.exe, alltså gui'et där man startar program, flyttar filer o.s.v.. En specialare för AmigaOS är dock att varje monterad disk får en process med samma namn som disken, normalt har man då t.ex. en process som heter DH0:. Någon användare hade döpt sin systempartition till just Workbench, och eftersom den partitionen givetvis "startas" före gui'et kommit upp, så hittade C-kompilatorn helt fel process och det uppstod knas. Tumregeln i Amigavärlden har väl alltid varit att i så stor utsträckning som möjligt göra allt på dokumenterade sätt, men i enstaka fall så har det väl varit acceptabelt att göra något odokumenterat för att nå en klar fördel jämfört med vad det dokumenterade fixar).

sodjan skrev:Samma sak gäller för systemet i sig. När systemet bootar så sätt
en root för systemet utifrån den disk som det bootades från:

Kod: Markera allt

$ show logical sys$sysroot  
   "SYS$SYSROOT" = "DSA10:[SYS0.]" (LNM$SYSTEM_TABLE)

Det här är också rätt likt amigan. Vid boot så hårdkodas SYS: till den disk man bootas från, och ett antal assigns sätts också till olika delar inom SYS:, mer specifkt C: sätts till SYS:C (commands, shellkommandona & co), S: sätts till SYS:S (scripts, shellscript och framförallt S:startup-sequence som är shellscriptet som uppstarten börjar med), LIBS: sätts till SYS:Libs (motsvarar t.ex. windows DLL'er), DEVS: sätts till SYS:Devs (ungefär som DLL'er fast specifikt devicedrivers. För att röra till det så ligger normalt ens mountlist som textfil i DEVS:Mountlist, fast det är bara i vissa fall man över huvud taget behöver använda den filen).

I "modernare" versioner av AmigaOS (d.v.s. 2.0 eller nyare) så går det mig veterligen bra att med standard-assignkommandot peka om SYS: och alla assigns som pekar in via SYS:, men i gamla 1.3 och äldre så behövdes det special-tredjepartprogram för att till 100% "släppa taget" om disken man bootat från. Det är inget man normalt behöver, men om man var lycklig nog att ha hårddisk då det begav sig, men samtidigt olycklig nog att inte ha en autobootande hårddiskkontroller, så var man tvungen att boota från diskett och ladda bl.a. hårddiskkontrollerns driver från diskett, och för att datorn inte skulle tjata om att vilja ha den disketten i tid och otid så fick man ta till ett tredjeparttrick utöver att bara assign'a om alla SYS:-relaterade grejer till hårddisken.

En annan grej som verkar vara likt logicals i VMS är att en Assign (från och med AmigaOS 2.0) kan peka på flera ställen.

Jag ser för övrigt ytterligare en likhet mellan VMS och AmigaOS, att flaggorna är RWED istället för bara *ix-världens RWE. Jag tycker det är föredömligt att ha separata flaggor för skrivrättighet och raderingsrättighet. På så sätt kan man skydda sig mot att av misstag radera filer utan att behöva hindra applikationerna från att skriva till dem.

sodjan skrev:Från: http://en.wikipedia.org/wiki/Files-11#Logical_names

> The closest non-DEC operating system to support the concept of logical names is AmigaOS, through the ASSIGN command."

"They resemble Unix environment variables, except they are expanded by the filesystem, instead of the command shell or application program."

Aha, då är jag inte fullt så besviken


Amigan har för övrigt *också* ENV-variabler, men de användes i princip inte före AmigaOS 2.0 (om de ens fanns...).
En specialare är att env-variablerna finns inte bara som processlokala och globala utan även som variabler som överlever omboot. Varje global variabel och variabel som överlever omboot är egentligen en fil som rent tekniskt kan innehålla precis vad som helst. Därför använder många "minst 2.0-krävande" program omboot-överlevande env-variabler för att spara inställningar, ofta som binärfiler. Det här var väl inte en jättebra tanke ihop med den faktiska implementationen eftersom de ombootöverlevande env-variablerna kopieras till flyktiga variabler vid boot. När man installerat femtioelva program som alla har någon/några env-variabler så blir det lätt massor som ska kopieras vid boot. Det ledde till att det skrevs tredjepartprogram som gör kopieringen från ombootöverlevande lagring till flyktig lagring on demand...

Från och med AmigaOS 2.0 (tror jag det var?) så ingår dessutom AREXX (Amiga-varianten av Rexx) som mer avancerat scriptspråk, i det kan man ha sina interna variabler o.s.v., så behovet av env-variabler är rätt lågt.


En sånhär tråd påminner mig för övrigt om att framgångarna för *ix inte beror på att det är särskilt bra, utan att det är bland de minst dåliga OS'en som "vem som helst" kan köra på sin dator, och delvis för att det bitit sig fast som en slags de-facto-standard. De olika kommandoskalen i *ix, ihop med såna grundläggande saker som val av kommandonas namn o.s.v., är i mitt tycke rätt ruttna. Att de ändå är "minst dåliga" kan väl mest skyllas på att kommandotolken och medföljande kommandoradbinärer i Windowsvärlden är ännu sämre.

> men som vanlig användare kan man inte sätta separata assigns per process

Ja, det blir ju en viss begränsning. VMS har nivåerna:
- Process: Den aktuella processen som körs.
- Job: Processen inkl alla sub-processer.
- Group: Alla processer som körs under user med samma group (ungefär GID i Unix).
- System: Ett helt system.
- Cluster: Logiska namn som är gemensama för ett OpenVMS cluster (upp till 96 maskiner).
Det vanliga är att system och process används.

D.v.s att om man gör "$ define /cluster somevar "test"" så syns det på alla maskiner i klustret.

> Det gör t.ex. att scriptet pcd som medföljer OS'et och vars syfte är att kunna byta till
> annan disk/katalog och "minnas" föregående katalog/disk

OK. Normalt sparar man det i en vanlig process symbol.
I exemplet nedan kommer xdir att innehålla sama text som "show default" visar: > Assigns används ofta för sådant som att peka ut var en c-kompilator hittar include-filer o.s.v.

Absolut! C har default kataloger for .H filer, men om de ligger någon annanstans
så kan man definiera DECC$SYSTEM_INCLUDE att peka på aktuell katalog.

> Tumregeln i Amigavärlden har väl alltid varit att i så stor utsträckning som möjligt göra allt på dokumenterade sätt...

I OpenVMS är *allt* dokumenterat och man gör i princip aldrig något odukumenterat.

> Det här är också rätt likt amigan. Vid boot så hårdkodas SYS: till den disk man bootas från...

Ungefär lika, men SYS$SYSBOOT sätts till den disk *och katalog* som systemet bootas från. En fysiskt system disk kan ha massor av SYSn kataloger, en för varje
system i klustret som botar från samma fysiska disk.
Sen blir det lite mer komplext. Varje system har en SYS$SPECIFIC som pekar
på en katalog struktur som är unik per system samt en SYS$COMMON som
pekar på kataloger som är gemensamma i hela klustret: Alla SYSCOMMON kataloger under alla SYSnn är "hard linked" till DSA10:[VMS$COMMON]
vilket är enda ställer som gemensamma filer ligger rent fysiskt.

Så när man kör ett program som SYS$SYSTEM:COPY.EXE så letar systemet först efter
DSA10:[SYS0.SYSEXE]COPY.EXE och sedan DSA10:[SYS0.SYSCOMMON.SYSEXE]COPY.EXE
(där det normalt ligger). Om man har en special variant av COPY.EXE som man vill testa
på ett av systemen i klustret så lägger man det bara i SYS$SPECIFIC:[SYSEXE] så
hamnar det i just det systemets unika SYS$SYSTEM katalog.

Normalt ligger det mesta i SYS$COMMON och enbart t.ex systemunika startup filer
i SYS$SPECIFIC. Alla logiska namn som SYS$SYSTEM (d.v.s alla .EXE) är sökvägar
som först pekar på SYS$SPECIFIC och sedan på SYS$COMMON.

> En annan grej som verkar vara likt logicals i VMS är att en Assign (från och med AmigaOS 2.0) kan peka på flera ställen.

Ja, det är vanligt för att t.ex ha "dev", "test" och "prod" miljöer på samma maskin.
På en maskin som jag hade hand om på Ericsson så låg alla skript under TRACE_COM:
Om man var i "test" miljön så var TRACE_COM en sökväg till först katalogen för test
och sedan katalogen för prod. På så sätt så, om man tester så och behöver enbart ha
de avvikande filerna i test-katalogerna, allt annat körs från prod, de är ju likadana.

> ...ihop med såna grundläggande saker som val av kommandonas namn o.s.v.

Hm...

I VMS gäller normalt att om du vill kolla/visa något så används "show".
Vill då ändra/sätta något så används "set". Sen så kan det vara olika EXEs som körs för olika show/set kommandon, men
det ser man inte direkt. SET kör 25-30 olika EXEs beroende på parametern.
SHOW QUEUE xxx kör SYS$SYSTEM:QUEMAN (Queue manager) o.s.v.