Hur kolla om program X är installerat?

[Johnny Rosenberg]

Skriver ett skript som har vissa beroenden och jag vill att skriptet ska kontrollera att alla beroenden är installerade och om inte i så fall installera dem (om inte användaren säger nej, så klart).

Letade lite på nätet och hittade en himla massa information om helt andra saker, men inget om detta. Letade kanske dåligt, men har sett att det finns en enorm kompetens på detta forum.

Vad är det smidigaste sättet att i ett skript kontrollera om ett program, låt oss säga Xdialog, är installerat på datorn?

Visst kan man göra

Kod: Markera allt

if [ -e /usr/bin/Xdialog ]; then
    blah blah blah
fi

men om programmet mot alla odds skulle finnas någon annanstans vill jag att programmet ska överlista det, om möjligt.

Några bra förslag?
Kort lättförståelig kod och gärna snabb sådan är ett bra mål i sammanhanget…

[Osprey]

Varför inte prova med:

Kod: Markera allt

if [[ $(which Xdialog) != "" ]]; then
	echo "Exists"
fi

[Johnny Rosenberg]

Varför inte prova med:

Kod: Markera allt

if [[ $(which Xdialog) != "" ]]; then
	echo "Exists"
fi

Är fortfarande lite nybörjare även om jag tycker att jag tagit några rejäla kliv sedan jag började lära mig, men vad innebär dubbla []?

Tänkte inte ens på att ”which” existerar, men det är klart att detta borde fungera.

Vad sägs om följande variant på temat?

Kod: Markera allt

which Xdialog > NULL
if [ $? -eq 0 ]; then
   echo "Exists"
fi

Visseligen en rad mer, men är det inte mer pedagogiskt att testa på exit-värdet än på resultatet? Kanske inte i och för sig, kanske mer att betrakta som en betydelselös detalj i sammanhanget.

[Konservburk]

Om du ändå tänker gå på returvärdet kan du lika gärna göra det med en gång utan att använda test i efterhand:

Kod: Markera allt

if which Xdialog >/dev/null 2>&1
then
   echo exists
fi

Eller mer kompakt:

Kod: Markera allt

which Xdialog >/dev/null 2>&1 && echo exists

[jsiei97]

Skriver ett skript som har vissa beroenden och jag vill att skriptet ska kontrollera att alla beroenden är installerade och om inte i så fall installera dem (om inte användaren säger nej, så klart).

Tja, om vi nu bortser från att apt redan gör detta åt dig när du vill installera.

Testa att installera ett program med ouppfyllda beroende med t.ex.

Kod: Markera allt

apt-get install build-essential

Nu kommer apt berätta att han saknar ca en handfull program och
användaren ställs inför frågan om han vill installera dessa.

Och om du har egna program, så konverera dessa till apt paket och lägg upp ett eget repository
som man sedan lägger till i /etc/apt/sources.list.

Mvh Johan

[Johnny Rosenberg]

Om du ändå tänker gå på returvärdet kan du lika gärna göra det med en gång utan att använda test i efterhand:

Kod: Markera allt

if which Xdialog >/dev/null 2>&1
then
   echo exists
fi

Visst ja, /dev/null ska det vara, ja. Jag fick för mig att NULL var en fördefinierad variabel för samma sak, men jag blandarde nog ihop det med något annat.

Eller mer kompakt:

Kod: Markera allt

which Xdialog >/dev/null 2>&1 && echo exists

För att ytterligare demonstrera min totala okunnighet, så tänkte jag passa på att fråga om ”2>&1” som ju ser lite kryptiskt ut, men som vad jag förstått ska dirigera om stderr snarare än stdout. Min fråga är då varför detta skulle behövas i just detta fallet. Jag vill ju bara att inget ska komma ut till terminalen. Eller har &-tecknet någon sorts betydelse att både stderr och stdout kommer att omdirigeras?
Ibland känns det som att de som designat detta ”programspråk” ansträngt sig extra för att göra det så oläsligt och svårbegripligt som möjligt… Jag upplevde det nästan lättare att programmera i hexkod en gång i tiden när man höll på med Motorola 6800 och 6809 på 1980-talet… Fast det blev ju vansinnigt mycket kod för att göra de enklaste saker i och för sig…

[Konservburk]

För att ytterligare demonstrera min totala okunnighet, så tänkte jag passa på att fråga om ”2>&1” som ju ser lite kryptiskt ut, men som vad jag förstått ska dirigera om stderr snarare än stdout. Min fråga är då varför detta skulle behövas i just detta fallet. Jag vill ju bara att inget ska komma ut till terminalen. Eller har &-tecknet någon sorts betydelse att både stderr och stdout kommer att omdirigeras?

2>&1 ser till att stderr (2) hamnar (>) på samma ställe som stdout (&1). I det här fallet i /dev/null (eftersom vi även har >/dev/null). Om du inte redan listat ut det så är 2>&1 till för att dölja det felmeddelande som which spottar ur sig ifall Xdialog inte finns installerat.

[Johnny Rosenberg]

Skriver ett skript som har vissa beroenden och jag vill att skriptet ska kontrollera att alla beroenden är installerade och om inte i så fall installera dem (om inte användaren säger nej, så klart).

Tja, om vi nu bortser från att apt redan gör detta åt dig när du vill installera.

Testa att installera ett program med ouppfyllda beroende med t.ex.

Kod: Markera allt

apt-get install build-essential

Nu kommer apt berätta att han saknar ca en handfull program och
användaren ställs inför frågan om han vill installera dessa.

Så om vi översätter detta till mitt fall: Mitt skript använder Xdialog (okänt vilken version som krävs, men 2.3.1 fungerar bra för mig) och rsync 2.6.4 eller senare. Om inte dessa finns installerade, kommer ju mitt skript inte att fungera.

Så anta att jag i mitt skript lägger till följande:

Kod: Markera allt

gksudo apt-get install xdialog > /dev/null 2>&1

Då kommer ju jag att bli tvungen att mata in mitt lösenord, vare sig jag behöver installera något eller inte. Lite jobbigt i ett skript som jag har tänkt att man ska köra varje dag. Därför behöver jag nog göra ett enkelt test först som inte kräver rättigheter, för det är ju egentligen bara första gången man kör skriptet på maskin X som man behöver kolla om all mjukvara finns installerad.

I och för sig kanske man skulle kunna göra så, att på de ställen i skriptet där dessa program körs kan man ju kolla om körningen gick bra och om man får felmeddelandet att kommadot saknas, låter man skriptet installera programmet…

Och om du har egna program, så konverera dessa till apt paket och lägg upp ett eget repository
som man sedan lägger till i /etc/apt/sources.list.

Mvh Johan

Detta är en annan sak jag funderat på, alltså hur gör man sina egna apt-paket. Har du något bra tips på var man kan tillgodogöra sig information om hur detta går till?
Visst, lugn, jag SKA googla också.

[Osprey]

Om du inte redan listat ut det så är 2>&1 till för att dölja det felmeddelande som which spottar ur sig ifall Xdialog inte finns installerat.

När började which spotta ur sig felmeddelanden för saker som inte är installerade? i vilken shell då??

[Konservburk]

Om du inte redan listat ut det så är 2>&1 till för att dölja det felmeddelande som which spottar ur sig ifall Xdialog inte finns installerat.

När började which spotta ur sig felmeddelanden för saker som inte är installerade? i vilken shell då??

Skalet har ingenting med saken att göra. Debian which ger inte ifrån sig felmeddelanden, men det gör däremot GNU which.

Kod: Markera allt

$ which --version
GNU which v2.19, Copyright (C) 1999 - 2008 Carlo Wood.
GNU which comes with ABSOLUTELY NO WARRANTY;
This program is free software; your freedom to use, change
$ which Xdialogg
which: no Xdialogg in (/usr/local/bin:/usr/bin:/bin)

[Osprey]

Skalet har ingenting med saken att göra. Debian which ger inte ifrån sig felmeddelanden, men det gör däremot GNU which.

Kod: Markera allt

$ which --version
GNU which v2.19, Copyright (C) 1999 - 2008 Carlo Wood.
GNU which comes with ABSOLUTELY NO WARRANTY;
This program is free software; your freedom to use, change
$ which Xdialogg
which: no Xdialogg in (/usr/local/bin:/usr/bin:/bin)

Ok, då vet jag. Alla "whichar" som jag har använt inklusive den i Ubuntu, har hållit tyst om de inte hittat något..

Och skalet hade kunnat ha med det att göra. Det jag syftade på var närmast det faktum att which i Ubuntu/bash inte kläcker ur sig något, däremot skulle vilken shell som helst kunnat ha en wrapper runt kommandot som gjorde det...

[Konservburk]

Ok, då vet jag. Alla "whichar" som jag har använt inklusive den i Ubuntu, har hållit tyst om de inte hittat något..

Eftersom det finns åtminstone en version som inte håller tyst så är det lika bra att kasta stderr.

Och skalet hade kunnat ha med det att göra. Det jag syftade på var närmast det faktum att which i Ubuntu/bash inte kläcker ur sig något, däremot skulle vilken shell som helst kunnat ha en wrapper runt kommandot som gjorde det...

Jag känner inte till något skal som har en inbygg version av which. Men det är mycket möjligt att det finns.

[David Andersson]

Tips: scriptet ska inte kontrollera om dess beroenden är installerade. Det ska paketeringen av skriptet göra, så att beroendet löses när scriptet installeras. På det sättet blir scriptet oberoende av om det själv och dess beroenden installeras med .deb eller .rpm eller .tar.gz.

Scriptet kan kontrollera, med t.ex which, om program det är beroende av finns, men finns de inte bör det bara stanna med en felkod (om det inte kan hitta alternativa program).

Det känns dessutom olämpligt att ha sudo och gksu i script.

[jsiei97]

Och om du har egna program, så konverera dessa till apt paket och lägg upp ett eget repository
som man sedan lägger till i /etc/apt/sources.list.

Detta är en annan sak jag funderat på, alltså hur gör man sina egna apt-paket. Har du något bra tips på var man kan tillgodogöra sig information om hur detta går till?
Visst, lugn, jag SKA googla också.

Då är vi två om denna sak,
det ligger på min lista över saker jag ska lära mig när jag får tid
(vet bara att det är bra att kunna, och att man kan lösa vissa problem... )

Så om du googlar fram någon bra info som funkar så berätta gärna

Mvh Johan