Små søde scriptfiler

[Jakob77]

.



Jeg pusler lidt med at lave en menu, som består af en række små scriptfiler, som jeg kan kalde fra terminalen.

Min pointe er, at det er nemmere, hurtigere og mere ergonomisk at taste "ff + Enter" , end det er at række ud efter musen og klikke på firefoxiconet.
Og det er f.eks. nemmere at taste "gcc" end at taste "gnome-commander"
osv..


Jeg har oprettet en mappe ved navn "Menu"
/home/mit-brugernavn/Menu

I den mappe lægger jeg alle mine små scripts


Det første til mappen bliver en fil, som jeg kalder "copytobin" (tester forinden i terminalen, om kommandoen i forvejen virker til noget andet), og jeg giver tilladelse til, at den kan køres som et program (højreklik på filen > Egenskaber osv..).





Indholdet i "copytobin":


sudo cp ~/Menu/* /usr/local/bin/



Så simpelt kan indholdet i en scriptfil være. Kun een linje..!

Jeg gemmer filen, og når den køres, så vil den kopiere alle menufilerne ned i mappen /usr/local/bin/
Til den mappe er der nemlig PATH , så Ubuntu altid kan finde filen, når den kaldes fra terminalen.
Nogle vil måske synes, at det er dobbeltkonfekt at have en mappe "Menu" med de samme filer i stedet for kun at have dem i /usr/local/bin/
Når jeg har valgt at gøre det sådan, så skyldes det primært, at jeg har bedre styr på min backup, når alle mine data er samlet under mappen "home"
Som kladdemappe er "Menu" måske også nemmere at arbejde i, fordi den ikke kræver ekstra login.

Det er selvfølgelig en smagssag og bedre forslag modtages gerne.





Men jeg håber, at I vil være med til at hyggedele "scriptkommandoer", for jeg er meget blank på alt andet end spørgsmål.
Jeg starter lidt forsigtigt:




Når en linje begynder med dette symbol: "#"
Kan man så være sikker på, at den linje ikke køres, og hvad mere kan symbolet umiddelbart bruges til..?



Hvis jeg laver et kørbart script ved navn "x" og i scriptet står der kun "exit"
hvorfor bliver jeg så ikke smidt ud af Terminalen, når jeg kalder "x" fra Terminalen..?



Er "EOF" en kommando, og hvornår skal den i givet fald bruges..?

[lath]

.
Jeg pusler lidt med at lave en menu, som består af en række små scriptfiler, som jeg kan kalde fra terminalen.

Min pointe er, at det er nemmere, hurtigere og mere ergonomisk at taste "ff + Enter" (virker allerede hos alle) , end det er at række ud efter musen og klikke på firefoxiconet.
Og det er f.eks. nemmere at taste "gcc" end at taste "gnome-commander"
osv..

Apropos script kommandoen gcc:

Det kan være en særdeles dårlig ide at kalde et script for 'gcc', da det er navnet for GNU - C compileren, som automatisk startes af pakkesystemet nu og da - specielt hvis man har Virtual Box og dkms pakken installeret
Jeg kan kun anbefale at dkms pakken installeret, da Virtual Box Kerne driveren også opdateres automatisk, når der kommer en ny version af Linux kernen, når den opdateres.

Synaptic om dkms pakken:

Dynamic Kernel Module Support Framework
This package contains the framework for the Dynamic Kernel Module
Support (DKMS) method for installing and updating kernel modules.

dkms pakken har en afhængighed af (bruger) gcc.

Problemet med et gcc script og gcc (GNU C compileren) vil opstå hvis man ændrer PATH således at gcc scriptets sti står før stien til compileren.

Når en linje begynder med dette symbol: "#"
Kan man så være sikker på, at den linje ikke køres, og hvad mere kan symbolet umiddelbart bruges til..?

# betyder at det er en kommentar, og alt efter det tegn ignoreres på resten af den linie

#! (sha-bang) bruges i scripts til at fortælle Linux kernen hvilken fortolker der skal bruges til at afvikle scriptet:

Eksempler:
sha-bang linien for Bash fortolkeren:
#!/usr/bin/bash
sha-bang linien for Python (3.0) fortolkeren:
#!/usr/bin/python3.0

Hvis jeg laver et kørbart script ved navn "x" og i scriptet står der kun "exit"
hvorfor bliver jeg så ikke smidt ud af Terminalen, når jeg kalder "x" fra Terminalen..?

Fordi du afslutter scriptet ikke terminal sessiionen, som startede scriptet. En anden måde at forklare det på at det er 2 forskellige processer (programmer), hvor terminal sessionen er forældre-proces (parent process), og scriptet er barn-proces (child proces). En exit i child processen afslutter selvfølgelig ikke parent processen.

Er "EOF" en kommando, og hvornår skal den i givet fald bruges..?

EOF betyder "End of File", og bruges i en while/for løkke til at læse en linie ad gangen indtil der ikke er flere liner at læse (EOF).

/Lars

EDIT: Tag et kig på The Linux Documentation Project http://www.tldp.org/. I Guides og Howto sektionen finder du BASH begynder guides, og Advanced BASH guides. Derudover er der også man sider for en del linux shell kommandoer. Linux Gazette er et gratis Linux on-line magasin. Sproget er som i mange store projekter - Engelsk.

[Jakob77]

Når jeg vil lave en scriptfil ved navn "f" , som skal kalde Firefox, så kan det gøres simpelt ved at bruge kommandoen "firefox"

Firefox kan kaldes af de fleste fra terminalen med kommandoen "firefox"

Og kommandoen "firefox https://ubuntudanmark.dk/forum"/ åbner firefox direkte i dette forum.


Men når jeg har lavet min scriptfil "f" , så kan jeg ikke mere få argumentet til at virke.
Kommandoen "f https://ubuntudanmark.dk/forum"/ dur altså ikke.

Hvad skal jeg skrive i scriptet for få argumenterne til at virke..?

I DOS ville det have været noget lignenede dette, der skulle stå i scriptet, hvis der skulle være tilladelse til at bruge fire argumenter på kommandoen:

firefox %1 %2 %3 %4

Men hvordan er det i Linux..?

[Jakob77]

Det kan være en særdeles dårlig ide at kalde et script for 'gcc', da det er navnet for GNU - C compileren, som automatisk startes af pakkesystemet nu og da

Ja UPS..!

Der skulle selvfølgelig have stået "ggc" eller "ggg" eller et andet filnavn, som terminalen ikke kan forstå.

Det kan måske godt være lidt vovet at bruge tilfældige kommandoer i terminalen for at tjekke om et filnavnet er ledigt i pathen.
Men er der en bedre måde..?

Jeg frygter lidt, at jeg på et tidspunkt installerer et spil eller noget andet, som lægger en fil i /usr/local/bin/ , og at jeg kommer til at overskrive den.


Hvis man kan holde sig på måtten og være helt stringent, så ingen programfiler hedder det samme, så er der vel ikke noget i vejen for, at man ændrer PATH til f.eks. at søge i "Menu" allerførst, eller kan der også være andre problemer ved det..?

#! (sha-bang) bruges i scripts til at fortælle Linux kernen hvilken fortolker der skal bruges til at afvikle scriptet:

Eksempler:
sha-bang linien for Bash fortolkeren:
#!/usr/bin/bash
sha-bang linien for Python (3.0) fortolkeren:
#!/usr/bin/python3.0

Det forstår jeg desværre ikke så meget af.
Skal scriptet så altid starte med en linje, som fortæller, hvilken der skal bruges..?
Og er kommandoerne forskellige alt efter, hvad man vælger..?
Er der en bestemt fortolker, som virker på alle Linuxmaskiner, og hvilken er Ubuntus foretrukne..?

Jeg famler lidt i blinde, så skulle der være et dumt spørgsmål, så er det tilladt at springe det over.

[lath]

Det kan måske godt være lidt vovet at bruge tilfældige kommandoer i terminalen for at tjekke om et filnavnet er ledigt i pathen.
Men er der en bedre måde..?

Prøv altid at kalde programmet med -h eller --help, og aldrig med superbruger-rettigheder (aldrig sudo, og aldrig imens du er logget ind som root). I det sidste tegn fra en prompt skriver terminalen altid $ hvis du er en almindelig bruger, og # hvis du er root (superbruger).

Hvis man kan holde sig på måtten og være helt stringent, så ingen programfiler hedder det samme, så er der vel ikke noget i vejen for, at man ændrer PATH til f.eks. at søge i "Menu" allerførst, eller kan der også være andre problemer ved det..?

Hvis du tilføjer i sluningen af PATH kommer du aldrig i problemer med system programmer, som vil fundet først. Det betyder så hvis du har et script, som hedder det samme som et system-program, så vil system-programmet blive kaldt istedet for dit script.

#! (sha-bang) bruges i scripts til at fortælle Linux kernen hvilken fortolker der skal bruges til at afvikle scriptet:

Eksempler:
sha-bang linien for Bash fortolkeren:
#!/usr/bin/bash
sha-bang linien for Python (3.0) fortolkeren:
#!/usr/bin/python3.0

Det forstår jeg desværre ikke så meget af.
Skal scriptet så altid starte med en linje, som fortæller, hvilken der skal bruges..?

Ja, det er bedst sådan, ellers vælges standard shell, som normalt er Bash shellen.

Man fortæller hvilken fortolker der skal fortolke scriptet således:

• I første linies første 2 tegn skal der stå "#!" (uden anførselstegn)
• Derefter skrives den absolutte sti til programmet. Her er

  Kode: Vælg alt

  whereis

  terminal-programmet din ven.

Og er kommandoerne forskellige alt efter, hvad man vælger..?

Ja!

Er der en bestemt fortolker, som virker på alle Linuxmaskiner, og hvilken er Ubuntus foretrukne..?

Bash er den foretrukne fortolker på Linux systemer.

Jeg famler lidt i blinde, så skulle der være et dumt spørgsmål, så er det tilladt at springe det over.

Der er ingen dumme spørgsmål her - især hvis spørgsmålet er på baggrund af uvidenhed.

/Lars

[cmay]

når jeg lave en installation af ubuntu har jeg et lille script der fjerne gnome-games og installere alle de restrictive codecs. dette script har ejg lavet i perl men også et i bash. fælles for begge scripts ud over det de gør er at de begge starter med #! og for at de kan køre skal de gøres til kørbare filer hvor jeg plejer at bruge chmod 755 ./scriptfil men sålænge fil rettigheder er sat til kørbar kan man køre dem som scripts. jeg har også en bin mappe i mit home hvor jeg ligger mine egne ting og sager i der kan køres som scripts samt hvis jeg har downloaded themes eller andre uofficelle -deb pakker som brothers printer drivers ligger de deri.
jeg lagde mærke til at der i de indlæg omkring emnet ikke var omtalt (eller jeg overså det) at man skal sætte rettigheder på scripts og ville lige nævne det. dos batch filer har en extention .exe for programmer osv og alle filer der starter med com eller exe eller bat kan køres uden problemer hvorimod i linux skal man selv ind og give filen de tilladelser der skal til for at den kan køre og der behøves ikke exstentions. et ok scriptnavn kan være startfirefox.sh eller bare startfirefox . ungå også at bruge navnet test da der er et program som hedder test i linux som bash shellen altid gerne vil starte istedet.
bash scripts er meget gode til amge ting og man siger egentligt at hvis noget kræver mere end en linje indtastning i terminalen bør man lave et script istedet også kan man også gemme det til næste gang man skal bruge det.

[Jakob77]

lath


Mange tak for dit svar.

Jeg har nu forsøgt at lave et eksempel, som viser min menu.
Det kan godt gøres smartere, men er der ellers noget, som måske bør påtales..?
(Hvis jeg skal opdrages, så er det nok nemmere at gøre det nu end senere. )


Scriptfilen kalder jeg "mm" og den indeholder følgende:

#!/bin/bash
#ovenstående linje kalder bash fortolkeren, som er mest almineligt brugt i Linux - Dette tegn "#" bruges ellers kun til som her at siker, at linjen ikke køres som en kommando.
cd /
#ovenstående linje er ikke så nødvendig, men stiller terminalprompten i roden
cd ~/Menu
#ovenstående linje stiller terminalprompten i mappen "Menu"
clear
#ovenstående linje renser terminalskærmen
echo ""
#ovenstående linje skriver en tom linje på terminalskærmen
echo "JAKOBs MENU:"
#ovenstående linje skriver "JAKOBs MENU:" på terminalskærmen
echo ""
#ovenstående linje skriver en tom linje på terminalskærmen
dir | more
#ovenstående linje viser alle de filer, som ligger i mappen "Menu", hvor promten er , og fylder de mere end en side på skærmen, så vil "| more" sørge for, at de vises side for side.
#nedenstående linje er unødvendig, men EOF betyder "End Of File"
#EOF



Jeg mener bare, at scriptet efter afsluttet kørsel skulle have bragt terminalprompten til mappen "Menu", hvorfor gør den ikke det..?

Har det noget at gøre med mit problem med, at "exit" ikke vil virke på terminalen fra en scriptfil..?





cmay


Mange tak for dit bidrag.

Ja, i DOS kan du lave en bat-fil ved navn "otto.bat" og når du kalder den, så behøver du kun at skrive "otto" for at den bliver fundet i pathen og kørt.
Men i Ubuntu skal du skrive hele navnet. Hedder filen "otto.sh", så er det ikke nok bare at skrive "otto".
Derfor har jeg lidt uartigt besluttet at stryge ekstensionen, indtil jeg møder meget gode argumenter for noget andet.

Når jeg f.eks. vil kalde firefox, så er det måske 2-4 gange så hurtigt at skrive "f" i stedet for "f.sh"

[lath]

Om kommentarer:
Du beder om mine bemærkninger - og det skal du få:
Først skal du lige vide at dette ikke er for jorde/bashe dig, men udelukkende for at gøre dig mere professionel ud i scriptprogrammering som du helt tydeligt er begyndt at lægge arm med .

Dine kommentarer beskriver hvad en kommando gør, og ikke intensionen/meningen med at skrive den/dem. Lav kommentarer som beskriver hvorfor du skriver den her kode (hvad er kodens formål?). Benytter du dig af et ikke så let-gennemskueligt hack(=trick), så skriv hvad tricket gør. Du behøves ikke at lave en kommentar for hver linie, men sådan mere hvor det føles nødvendigt.

Ideen er at når du om lang tid ikke helt ved hvad dit script gør (og den tid vil komme mere før end siden), så har du skrevet kommentarer som giver dig (og andre) mulighed for at finde ud af hvad der sker. Det er især yderst nyttigt, når (ikke hvis) du skal rette en fejl i et program du selv har lavet.

At skrive hvad hver kommando gør er typisk for begyndere - det har jeg også selv lavet engang - indtil en erfaren programmør fortalte det jeg fortæller dig nu.

Har det noget at gøre med mit problem med, at "exit" ikke vil virke på terminalen fra en scriptfil..?

Helt rigtigt, svaret er herunder!

Jeg mener bare, at scriptet efter afsluttet kørsel skulle have bragt terminalprompten til mappen "Menu", hvorfor gør den ikke det..?

Du ændrer kun sti i child processen, ikke parent processen.

EOF

Har du ikke brug for andre steder end hvis du læser fra en fil med for eksempel en while løkke.

Jeg kan kraftigt anbefale at læse guides på http://www.tldp.org/guides.html.
Specielt:

• Introduction to Linux - A Hands on Guide, HTML: http://www.tldp.org/LDP/intro-linux/html/index.html, PDF 1,6 MB: http://www.tldp.org/LDP/intro-linux/intro-linux.pdf
• GNU/Linux Command-Line Tools Summary, HTML: http://www.tldp.org/LDP/GNU-Linux-Tools-Summary/html/index.html, PDF 682 KB: http://www.tldp.org/LDP/GNU-Linux-Tools-Summary/GNU-Linux-Tools-Summary.pdf
• Bash Guide for Beginners, HTML: http://www.tldp.org/LDP/Bash-Beginners-Guide/html/index.html, PDF 1,2 MB: http://www.tldp.org/LDP/Bash-Beginners-Guide/Bash-Beginners-Guide.pdf
• Linux Filesystem Hierarchy, HTML: http://www.tldp.org/LDP/Linux-Filesystem-Hierarchy/html/index.html, PDF 601 KB: http://www.tldp.org/LDP/Linux-Filesystem-Hierarchy/Linux-Filesystem-Hierarchy.pdf
• Advanced Bash-Scripting Guide, HTML: http://www.tldp.org/LDP/abs/html/index.html, PDF 2,4 MB: http://www.tldp.org/LDP/abs/abs-guide.pdf

/Lars

[cmay]

det er langt fra uartigt at stryge extentionen i linux. det er en fordel for så ligne det mere en kommando end et script. jeg bruger aldrig extentioner. i perl frarådes det også at bruge hvis ens operatic system tillader det.
jeg kender ikke bash scripting selv om jeg har flere bøger om det men jeg har ikke læst dem endu. jeg har kun overfladisk kendskab til perl og python og c. c kan også bruges som scripting language men jeg skal kun bruge simple små arbejdsopgave udført en gang imellem så for mig er det nok at kunne lave små scripts på en enkelt linje eller to der gør de trælse ting som installere codecs eller fjerner og installere programmer på en ny frisk installation. eksembelvis så da jeg havde en asus eeepc laved jeg et script der installerede den custom eeepc kernel fra array.org. en bog jeg kan anbefale i forhold til bash og unix generelt er en af brian w kernighan
der hedder the unix programming enviroment. tung læsning hvis man ikke gider beskæftige sig med netop koder da det er en lærebog om c programming og bash scripting men den indeholder en introduktion til brugen af unix samt en forklaring eller snare indføring i systemet. den kan bruges til linux ligeså vel ar jeg bemærket da unix og linux er næsten ens på mange punkter og det er den samme shell der benyttes.

[Jakob77]

cmay

Jeg kan høre, at vi er meget godt på bølgelængde, hvad angår scriptfilnavne uden ekstension.
Og lath har da heller ikke protesteret, men han har heller ikke givet grønt lys, og det har laoshi heller ikke, og det piner mig lidt (noget... en hel del.!).




lath

Mange tak for din kritik, det er helt rigtigt, at det er typiske begyndernøkker at skrive hvad hver linje gør.
Men det er jo også pædagogisk til forumbrug.

Også tak for dine liks til engelske manualer, men det går nok ikke så godt.
De småting, som jeg mangler, det vil være som at lede efter nåle i en høstak.

Det er i øvrigt også meget mere hyggeligt at blive forumundervist af en flink skolelære som dig og alle de andre dygtige drenge.

Hvis du får tid, så skal du bare rulle dig noget mere ud. Det kan vel ikke være så svært at få terminalpromten til at vise det rigtige, børn plejer godt at kunne bestemme noget. Og det med argumenter på scriptfiler, det må du kunne ryste lige ud af ærmet.?

Jeg har også en lille ny vigtig udfordring: Hvad kan jeg skrive i et script, hvis jeg vil have scriptet til at pause og først automatisk genoptage afviklingen, når det er helt sikkert, at der er oprettet en internetforbindelse..?

[laoshi]

han har heller ikke givet grønt lys, og det har laoshi heller ikke, og det piner mig lidt (noget... en hel del.!)

Hvis tingene virker for dig, så behøver du såmænd ikke at få grønt lys fra nogen. Selv vil jeg helst bruge fil-extensions og anvende standard-placeringer af filer. Det gør det noget lettere at finde rundt i. Frihed behøver ikke at være det samme som roderi - og tingene bliver let rodede hvis man ikke bruger bestemte regler for, hvordan tingene virker.
Så personligt gider jeg ikke oprette nye directories til mine scripts for så at skulle huske hvor de er - jeg bruger standardplaceringen /usr/local/bin
Og så kan jeg godt lide at man med et enkelt blik på filnavnet kan se om det er et script, en binær fil, et billede, et OpenOffice-dokument, eller hvad det nu kan være. Det gør også søgning lettere, hvis man bruger de gængse extensions.
Men så længe der ikke er andre som skal kunne finde rundt i dit system, og så længe du selv kan huske hvad du gør - ja, så står det dig frit for at gøre tingene som du helst vil.

[Jakob77]

laoshi

Mange tak for din gode forklaring.

Når jeg fritter dig lidt ekstra, så er det netop fordi, at du i mine øjne er tæt på at være perfektionist, når det angår orden. Så hvis du kan lide min plan, så er den nok ikke helt tosset.

Måske blive det også meget nemmere på en ny Ubuntuversion, når jeg bare skal restore mine data og køre "copytobin"
Og jeg må kunne lave en lille scriptfil, som starter en editor med en tom fil i mappen "Menu", og når jeg har skrevet mit script og lukker editoren, så kører den automatisk "copytobin"
Det er jeg lige ved at tro, at jeg kan lave allerede nu.

Og får jeg lært det med argumenterne, så burde det kunne laves, så jeg f.eks. kun skal skrive "eed x" i terminalprompten for at få mit script med filnavnet "eed" til at åbne filen "x" i en editor i mappen "Menu".
Men dertil mangler jeg en skabelon. Er den meget frygtelig, siden ingen praler med den..?

[laoshi]

Så, Jakob77 - her er lidt du kan lege med:
Jeg har lige digtet et script som jeg kalder åbn_gedit.sh
Det skal selvfølgelig gøres eksekverbart og kan så kaldes fra terminalen med navn efterfulgt af et filnavn (hele stien skal angives). Så åbner du den angivne fil med gedit i superbruger-tilstand. Angiver du intet filnavn bliver du bedt om at gøre det.

Kode: Vælg alt

#!/bin/bash
# Scriptet kaldes fra kommandolinjen med scriptnavn efterfulgt af stien på en fil som man ønsker åbnet i gedit med superbrugerrettigheder. Flemming Christensen (laoshi) marts 2009
if [ $# -eq 0 ]
then
echo "Skriv et filnavn"
else
gksudo gedit $1
fi

---
EDIT: Forbedret udgave juni 2010:

Kode: Vælg alt

#!/bin/bash
# Scriptet kaldes fra kommandolinjen med scriptnavn efterfulgt af stien på en fil som man ønsker åbnet i gedit med superbrugerrettigheder. Findes filen ikke allerede, så oprettes den automatisk. Flemming Christensen (laoshi) marts 2009 - juni 2010
if [ $# -ne 1 ]
then
echo "Angiv et filnavn. Filnavnet må ikke indeholde mellemrum"
else
echo "Åbner filen $1 i gedit med superbrugerrettigheder"
gksudo gedit $1
exec 2> /dev/null
fi
fi

EDIT SLUT
---


Til orientering så angiver $ en variabel. Og der er opstillet betingelser inden for if - fi
Måske det kan inspirere dig!

Jeg vil anbefale dig at give scriptfilerne navne som fortæller lidt om deres virkemåde. Hvis du så vil kalde dem med kortere navne kan du oprette et alias.

Hvis du vil åbne dette script med kommandoen

Kode: Vælg alt

g FILNAVN

så lav alias på flg. måde:

Kode: Vælg alt

alias g='åbn_gedit.sh'

Når du laver alias'er så pas på ikke at bruge indbyggede kommandoer eller programnavne som alias - det kan godt skabe uventede problemer.

EDIT: Et alias som du opretter på denne måde gælder kun så længe terminalen er åben. Men så kan du teste det. Vil du gøre et alias permanent skal du åbne ~/.bash_aliases og tilføje det i en ny linje. Hvis ~/.bash_aliases ikke allerede findes må du selv oprette den.
Derefter skal du åbne ~/.bashrc i gedit. Her lokaliserer du de linjer som ser sådan ud:

Kode: Vælg alt

# Alias definitions.
# You may want to put all your additions into a separate file like
# ~/.bash_aliases, instead of adding them here directly.
# See /usr/share/doc/bash-doc/examples in the bash-doc package.

#if [ -f ~/.bash_aliases ]; then
#    . ~/.bash_aliases
#fi

her skal du fjerne # fra de 3 sidste linjer, så der kommer til at stå

Kode: Vælg alt

# Alias definitions.
# You may want to put all your additions into a separate file like
# ~/.bash_aliases, instead of adding them here directly.
# See /usr/share/doc/bash-doc/examples in the bash-doc package.

if [ -f ~/.bash_aliases ]; then
    . ~/.bash_aliases
fi

Gem og luk. Så bliver din .bash_aliases læst.
En sidste ting du skal gøre for at et permanent alias skal virke er at reloade .bash_aliases og .bashrc- det gør du med

Kode: Vælg alt

. .bash_aliases
. .bashrc

(dvs. punktum ophold punktum+filnavn)

[Artificial Intelligence]

Hvis det er meget små kommandoer du vil execute, kan det god betaler sig at bruge;

sh -c "kommando && kommando etc."

istedet for at bygge et script

[laoshi]

Hvis det er meget små kommandoer du vil execute, kan det god betaler sig at bruge;
sh -c "kommando && kommando etc."
istedet for at bygge et script

Det er jeg helt enig med AI i.
Men drejer det sig om regelmæssigt tilbagevendende opgaver som man vil automatisere, så kan man lege med scripts.
Og Keir Thomas mener, at hvis man skal bruge kommandoer som fylder mere end én linje - så kan man lige så godt lave et script.
Smag og behag og vaner er forskellige - og i Ubuntu har vi rige muligheder for at tilpasse rutiner efter egne behov.