Svenska ElektronikForumet

Hej,

Jag har ett konstigt problem med en Linux enviroment variable.
Den verkar inte gå att skriva över, jag måste tabort den med unset först.

> setenv LSF_TIMEOUT 960
> echo VAR $LSF_TIMEOUT
VAR

Men om jag gör unset så fungerar det:
> unset LSF_TIMEOUT
> setenv LSF_TIMEOUT 960
> echo $LSF_TIMEOUT
960

Någon som vet varför?

> echo VAR $LSF_TIMEOUT
> echo $LSF_TIMEOUT

Jag kan inget om Linux, men varför är det olika?

"setenv is a built-in function of the C shell (csh)"
Använder du csh? Vilken distribution?
Vanligtvis har man i Linux skalet bash eller dash (ubuntu).

I första exemplet
> echo VAR $LSF_TIMEOUT
ekar du texten "VAR" och inte variabeln $LSF_TIMEOUT

Hej,

Problemet är att när jag försöker skriva över LSF_TIMEOUT så går inte det.
Jag måste först använda unset och sedan setenv

Vilket är märkligt för det fungerar på andra variabler.

Jo, men det berättade du ju i första inlägget.

Har du testat det som Sodjan och SvenW skrev?
Dvs att "VAR" förmodligen inte ska vara med.

> Problemet är att...

...du uppenbarligen fullständigt saknar förmåga att läsa andras inlägg.

I ena exemplet skrivs bara variabeln, i de andra skriva texten VAR följt av variabeln.

Men i sh/bash är det väl export man ska använda?

Första googleträffen på "change environment variable bash"
http://genepath.med.harvard.edu/mw/Bash ... bash_shell

du får nog ge lite mer info. Vilket OS och vilket skal t.ex. Kör du detta från ett script?

Såhär ser det ut när jag kör csh: Jag tyckte det var lustigt att unset inte har någon effekt, så jag läste man-sidan "man csh" och det är unsetenv man ska använda:

Hör inte denna tråd hemma i >>Övrigt >>Programmerig?

shellvariabler känns ganska långt ifrån programmering iofs ?

JimmyAndersson skrev:Jo, men det berättade du ju i första inlägget.

Har du testat det som Sodjan och SvenW skrev?
Dvs att "VAR" förmodligen inte ska vara med.

Det är inte det som är problemet. Utan problemet är att enviroment variablen inte får något värde.
Skulle inte haft med VAR i mitt exempel, det var förvirrande ber om ursäkt för det.
VAR har altså ingenting med detta att göra.

Kör följande:

pbgp skrev:du får nog ge lite mer info. Vilket OS och vilket skal t.ex. Kör du detta från ett script?

Såhär ser det ut när jag kör csh:

Kod: Markera allt

$ csh
% echo $LSF_TIMEOUT
LSF_TIMEOUT: Undefined variable.
% setenv $LSF_TIMEOUT 100
LSF_TIMEOUT: Undefined variable.
% setenv LSF_TIMEOUT 100
% echo $LSF_TIMEOUT
100
% setenv LSF_TIMEOUT 960
% echo VAR $LSF_TIMEOUT
VAR 960
% unset LSF_TIMEOUT
% echo $LSF_TIMEOUT
960
% setenv LSF_TIMEOUT 960
% echo $LSF_TIMEOUT
960
% 

Jag tyckte det var lustigt att unset inte har någon effekt, så jag läste man-sidan "man csh" och det är unsetenv man ska använda:

Kod: Markera allt

% unsetenv LSF_TIMEOUT
% echo $LSF_TIMEOUT
LSF_TIMEOUT: Undefined variable.

Det är EXAKT det här jag hade förväntat mig, och 99.9% av alla gånger så är det precis så här det fungerar.
Men ibland så har jag märkt detta problemet, finns säkert någon bra förklaring.

Verkar som om det händer efter jag kör ett script som avbryts pga av ett fel, väldigt komplicerat script som inte jag har gjort.
Jag får gå till botten med hur detta scriptet kan *låsa* en enviroment variabel. (scriptet mecklar med env. variabler och startar andra shells).

Tänkte ifall det var någon Linux expert här på forumet som visste var det kunde bero på.

EDIT:

Hittade felet!
Det finns en tom variable som heter LSF_TIMEOUT.
Det förklarar var unset fungerar istället för unsetenv. Tack pbgp för att du påpekade det.
Altså: Ingen raketforskning direkt

OK, där ser man...

Men då måste det finnas någon definierad "search order" för echo kommandot.
Hur vet man om det är en lokal variabel eller en environment variabel man ser?

> set ENVAR=
> setenv ENVAR 2000
> echo $ENVAR

Hur skriver man om man vill göra echo på *environment* variabeln ENVAR?

Angående search order så har jag ingen aning!
Känns väldigt förvirrande att ha variabler och env. variabler med samma namn. Kanske finns det någon fiffiig anledning.

OK.
Så det går alltså att hitta orsaken via set och printenv utan att ha
specifik kunskap om de script som satta variablerna?

> Angående search order så har jag ingen aning!

Om du gör:

set ENVAR 1000
setenv ENVAR 2000
echo ENVAR

vilket värde visas?

Om det finns en definierad och dokumenterad "search order" så är ju en orsak
till att ha samma namn att man har ett system default som ("environment") kan
överridas (vid t.ex tester) med en process lokal symbol.

Det förutsätter att search order är "först lokal, sedan environment", inte tvärtom.

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.

Finns det fler nivåer än två? Kan t.ex en GID ha en egen uppsättning?
Eller är det bara "alla" eller "process/shell" och inget däremellan ?

Unix skal är väl lika gamla som Unix själv och det finns väl ett halvdussin varianter eller fler.
sh, ash, bash, dash, ksh, mksh, zsh, csh, wish ...
Att förstå dem är inte lätt och att programmera shellscripts är svartkonst.
Det är i alla fall min personliga åsikt, och troligen inte bara min.
Möjligen är det just dessa som skrämmer bort folk från Linux
Skripter skriver jag hellre i Perl.
Inget bra svar på någon fråga, bara mitt credo.