Valgmuligheder under kørsel af script

[lath]

Jeg har altid (det lyder så flot ) brugt en form for logik, der sikkert ikke er logisk for andre.

Den præcise J/N-kode i sh er

Kode: Vælg alt

# Ja / nej funktion
valg_janej() {
    # Gentag hvis ikke der svares ja /nej
    while true
    do
        #$* read ever parameter giving to the yesNo function which will be the message
        echo -n "$* (J/N)? "
        # junk holds the extra parameters yn holds the first parameters
        read jn junk
        #check for difference cases
        case $jn in
            ja|Ja|JA|j|J)
                return 0
                ;;
            nej|Nej|NEJ|n|N)
                return 1
                ;;
        esac
    done   
}


Som du kan se, så har jeg valgt at oprette den som en funktion i sig selv, det giver mig nemlig mulighed for at

Kode: Vælg alt

# Tjek for ja / nej svar
if valg_janej 'Skal noget ekstra køres her?'
then
noget_ekstra
noget_andet
else
noget_andet
fi

noget_ekstra og noget_andet er bare to andre funktioner, som er defineret inden ja/nej-funktionen. Efter at jeg fik ja / nej til at virke, har jeg tilgengæld prøvet at gennemskue hvordan man laver flere ja / nej'er, men svaret er undsluppet mig indtil videre.

Lad os sige, at vi har 3 ting man kan vælge imellem, nemlig A, B og C. De kunne fx være backup 3 forskellige steder. Man kunne sagtens lave en underlig menu

Kode: Vælg alt

echo "Hvad vil du tage backup af?"
(noget choice-kode her)
1 A
2 B
3 C
4 A & B
5 A & C
...


Ikke just optimalt... Smartere ville det være hvis man i stedet fik 3 spørgsmål i træk, hvor der først bliver spurgt J/N til A, så til B og til sidst C. Man kunne godt præsentere ja / nej 3 forskellige steder i scriptet, men det er heller ikke smart, for så skal man sidde ved computeren, og holde øje med hvad den laver. Et rigtigt script tager sine valg i starten, så brugeren ikke skal andet end at starte det op

Noget andet jeg også syntes mangler i ihvertfald mine scripts, er ordentlig håndtering af fejl, og ikke mindst at scriptet skriver hvorhenne det fejlede. Er der nogen af jer der bruger det / ved hvordan det virker?

Som professionel softwareudvikler kan jeg har fortælle at du gør det rigtige.
Laver en funktion, der kan nøjagtig en ting, som så kan genbruges i det uendelige.

Det kaldes dekomposition at opdele en program i flere mindre overskuelige dele, hvor en del gerne skal kunne bruges mere end 1 gang.

Skal du lave en variant hvor der også skrives noget information og så et spørgsmål kan du wrappe din ja-nej funktion ind i en ny funktion der også tager 2 argumenter som er info* og spoergsmaaal. *:information

Jeg ville så vælge at ligge while løkken oppe i ja-nej-med_tekst funktionen. En anden ændring er at bruge en do while (uden true konstanst i while testen) konstruktion i stedet, men det findes ikke i bash.

Jeg ville vælge at kode i python i stedet på dette tidspunkt.
På nogle områder er bash lidt for simpelt, og i Pyhton kan komme noget længere, da der findes mange Python pakker.
Det gælder både til Python terminalprogrammer, og GUI Python programmer med GTK+ eller Qt toolkitet

Som sagt kan man lave et GUI program med et Python script:
I bonus kan man med Python også kode store programmer med GTK+ toolkittet via PyGtk: http://www.pygtk.org/about.html, og så får man lige pludselig pæne grafiske programmer.

/Lars

[NickyThomassen]

Mange tak for de opmuntrende ord, nogen gange er den sværeste at være kritisk overfor sig selv. Og det ville være surt at lærer sig selv noget der ikke er optimalt...

Men hvorfor python?
Sandt at sige kender jeg kun bash og php, så min erfaring er lidt begrænset. Umiddelbart ville jeg have troet at perl var bedre at fortsætte med, og så vidt jeg kan se, så kan de to sprog næsten det samme. Forskellen ligger (så vidt jeg kan se) i at perl er udgivet som open source, og at det i perl skulle være muligt at løse problemer på flere måder (ligesom i php).

Men ellers vil jeg give dig ret, jeg tror også at grænsen for bash'ens formåen er nået. En ting der irriterer mig en del med bash nu, er at dokumentationen enten er forkert, eller ikke dækker den version jeg kører med. Det burde være muligt at bruge en AND som -a, men det virker bare ikke.

[lath]

Mange tak for de opmuntrende ord, nogen gange er den sværeste at være kritisk overfor sig selv. Og det ville være surt at lærer sig selv noget der ikke er optimalt...

Men hvorfor python?
Sandt at sige kender jeg kun bash og php, så min erfaring er lidt begrænset. Umiddelbart ville jeg have troet at perl var bedre at fortsætte med, og så vidt jeg kan se, så kan de to sprog næsten det samme. Forskellen ligger (så vidt jeg kan se) i at perl er udgivet som open source, og at det i perl skulle være muligt at løse problemer på flere måder (ligesom i php).

Men ellers vil jeg give dig ret, jeg tror også at grænsen for bash'ens formåen er nået. En ting der irriterer mig en del med bash nu, er at dokumentationen enten er forkert, eller ikke dækker den version jeg kører med. Det burde være muligt at bruge en AND som -a, men det virker bare ikke.

Jeg ved ikke om du ved det men indenfor programmering er valg af programmeringssprog næsten en religon.
Hvis du for eksempel laver en blog om at sprog X er bedre end sprog Y, er du sikker på at en masse fra sprog X siger ja/klapper dig på ryggen, samtidgt med at du har dem fra sprog Y på nakken (læs flame wars, personangreb og den slags.)

Både Bash, PHP, Perl, og Python er Open Source.

Med programmeringsreligioner in mente vil jeg så vove pelsen og komme med min egen holdning:
Jeg ville foretrække Python - det er nemt at lære, dokumentation er rigtig god, og korrekt, og så er der allerede mange der har lavet moduler der gør en bestemt ting, så når du skal lave noget nyt software kan du i stor stil trække på andres programmeringsarbejde, hvilket er en meget stor hjælp.
Den anden ting som igen er at med modulerne der allerede er lavet og er stabil software er at du slipper for at genopfinde hjulet/den dybe tallerken i andet programmeringssprog.

/Lars

[lath]

@TitanusEramius

Jeg regner nu med at lave det program jeg engang havde gang i, med den modification at det nu er alle de store officielle guides der nu laves om til et program.

Jeg har fået lov af Chr Arvai, så det er hans guide der først bliver et program - og han bliver naturligvis også krediteret som det bør sig, når man har fået lov til at bruges andres arbejde.

Programmet gør det nemt at sætte en feature op: Sæt/fjern flueben på det du ønsker/ikke ønsker at have - resten gør softwaren for dig, og så bliver det vist ikke ret meget nemmere.

jeg har på den lange bane også en ide om at integrere indsamling af oplyninger i en pastebin ved netværksproblemer, det kræver nok lidt esktra oplyninger til hvordan programmet kan integrere sig ind i ubuntudanmark.dk/forum - det er de ændringer i har lavet i forhold til en standard PhpBB(3?) installation.

Jeg bruger ca 1 måned på det her - og så kan man også godt sige at jeg er nået at komme i dybden med at lære Python programmering og bruge PyGTK.

/Lars

[AJenbo]

Jeg vil også forslå at bruge python til smarte scripts og små programmer. Faktisk er software center og ubuntu one lavet i python.

[NickyThomassen]

The Python Software Foundation License (PSFL) is a BSD-style, permissive free software license which is compatible with the GNU General Public License (GPL)

Ah, så langt fik jeg ikke set, jeg så kun at det ikke var GPL

Og jo, jeg kender desværre godt til debatten om "det bedste programmeringssprog", og umiddelbart syntes jeg at den er lige så lidt værd som alle andre debatter om subjektive ting. Som fx distro, bil, religion ... Jeg håber ihvertfald at vi kan holde diskussionen lidt i baggrunden her, for alt andet lige er alle sprog ikke lige gode til alle ting. Jeg ville nødig bygge en GUI med C, det er helt sikkert, men på den anden side er perl eller python måske ikke det bedste på en lille indlejret maskine.

Jamen så tror bare at jeg kigger på python i første omgang. Godt nok finder jeg den løse måde man åbenbart kan programmere i perl på tiltalende, men i det lange løb betyder det nok ikke så meget.

[lath]

Jamen så tror bare at jeg kigger på python i første omgang. Godt nok finder jeg den løse måde man åbenbart kan programmere i perl på tiltalende, men i det lange løb betyder det nok ikke så meget.

Bemærk at Python findes i 2 varianter, den nye er Python version >=3, og den ældre er python 2.7, som også bliver den sidste i python 2.x serien.
De fleste vælger Python 2.7, fordi at langt fra er alle før-omtalte moduler findes til Python 3.x, blandet andet PyGTK (AFAIK).
Du kan installere ekstra python pakker med pypi: http://pypi.python.org/pypi

Der er en skal-jeg-vælge-python2.x-eller-python-3.x-guide på python.org websitet.

Jeg bruger iøvrigt IDLE som udviklingsmiljø - ikke alt for fancy, men har dog behagelig completion, med CTRL+mellemrumstast.
Der er også eric4 som mere ligner et rigtigt IDE: http://eric-ide.python-projects.org/
eric4 er for Python 2.7, og eric5 er for Python 3.x

/Lars

[AJenbo]

Tror vist det kun bliver python3 som standart i Ubuntu 12.10.

Til Python 3 findes der PyGI istedet for PyGTK.

[NickyThomassen]

Jeg kan se at python 2.6.6 automatisk er installeret på Debian 6, men at 3.1.0 kan hentes fra arkiverne efter behov. Jeg har fundet manualen og er gået i gang med den, i første omgang skal jeg have strikket et nyt back-script sammen, så der er lidt at kigge på.

Omkring udviklingsmiljøet regnede jeg egentlig med, at fortsætte med at bruge gedit. På den anden side ser det ud til at idle inkluderer en debugger, og det er ganske givet noget der ville kunne bruges. Så tak for tippet, den må jeg prøve.

Jeg vil også forslå at bruge python til smarte scripts og små programmer. Faktisk er software center og ubuntu one lavet i python.

Jeg kender ikke rigtig one, men softwarecenteret syntes jeg er ret velfungerende, omend måske lidt tungt. Fordelen som jeg ser ved python (og vel også perl), er hvor utrolig bredt det kan bruges. Nærmest alt fra filhåndtering til CGI sammen med apache til databaser. Ganske imponerende faktisk.

[lath]

Tror vist det kun bliver python3 som standart i Ubuntu 12.10.

Til Python 3 findes der PyGI istedet for PyGTK.

Takker for det tip.
Det betyder så at jeg skifter permanent til Python 3 - brug af tekst er nemlig meget nemmere i Python 3 for der er der kun en type af tekst, immutable UTF8.

Jeg kommer nok til at bruge Glade til GUIen, hvis jeg kan slippe af sted med det: Glade er brug af en GUI designer som producerer en xml fil der kan loades af glade, som nu er en del af GTK+ (AFAIK): http://glade.gnome.org/

Det man så gør er at man så fortæller at libglade skal loade ens gui xml-fil, og siger man vis til ens top-vindue, hvorefter ens GUI popper op på skærmen.
Det er dælme smart.

/Lars