Shell scripting

#1 - Qw_freak
19. sep. 2012 08:24

Nogen der kan gfortælle mig hvad det her betyder?

installprefix='@DESTDIR@'

hvad gør @érne??

Ja, jeg er ret grøn i det! :)

#2 - Mort
19. sep. 2012 09:06

Du må vist være lidt mere specifik...

Hvad er det for et scripting sprog du henviser til?
Hvilket operativsystem?

Windows understøtter en hel række af scripting sprog til shell scripting.

#3 - fjols
19. sep. 2012 09:08

Givet overskriften og at hans tidligere spørgsmål går jeg ud fra der menes Bash (eller afarter).

Er @ ikke fordi det er en variabel "udefra"?

#4 - Qw_freak
19. sep. 2012 09:43

fjols (3) skrev:
Givet overskriften og at hans tidligere spørgsmål går jeg ud fra der menes Bash (eller afarter).

Er @ ikke fordi det er en variabel "udefra"?

Rigtigt, undskyld, det er´ shell script..

Det lyder helt rigtigt at @ gør det.....

#5 - kasperd
19. sep. 2012 09:50

Qw_freak (1) skrev:
hvad gør @érne??

I bash gør de ingenting. Hvis ovenstående linje blev brugt i et shellscript, så vil variablen komme til at indeholde en streng med de @er uden nogen særlig behandling, nøjagtigt som hvis det havde været ganske almindelige bogstaver.

Men navnet installprefix får mig til at tænke at det nok er noget autoconf/automake funktionalitet. I så fald er det du har fat i ikke et shell script, men derimod en slags template, som bruges til at lave et shellscript. Og det er et af disse auto-tools, som håndterer @ specielt og erstatter det med en anden streng.

Men jeg kender ikke de værktøjer så godt, så jeg ved ikke, hvordan @ håndteres der.

Hvis du fortæller os filens navn kan jeg måske give et bedre bud.

#6 - Qw_freak
19. sep. 2012 09:55

#5
Jamend et er helt præcist dette script til at configurere perl:
http://cgit.openembedded.org/openembedded-core/tre...

#7 - kasperd
19. sep. 2012 10:13

Qw_freak (6) skrev:
Jamend et er helt præcist dette script til at configurere perl

Det script gør ingenting. Hvis du kører det defineres en helt masse variabler, som så forsvinder igen med det samme, fordi scriptet afslutter.

Det må være beregnet til at blive inkluderet et andet sted fra. Koden der inkluderer det kunne se ud som

source config.sh

eller

. config.sh

Begge gør det samme. . er blot et kortere navn for source kommandoen.

#8 - Qw_freak
20. sep. 2012 07:16

kasperd (7) skrev:
Qw_freak (6) skrev:
Jamend et er helt præcist dette script til at configurere perl
Det script gør ingenting. Hvis du kører det defineres en helt masse variabler, som så forsvinder igen med det samme, fordi scriptet afslutter.

Det må være beregnet til at blive inkluderet et andet sted fra. Koden der inkluderer det kunne se ud som
source config.sh
eller
. config.sh
Begge gør det samme. . er blot et kortere navn for source kommandoen.

Det gør den også, den bliver kørt fra filen perl_5.14.2.bb filen som køre den sammen med Perl kildkodens "Configure" script.

#9 - kasperd
20. sep. 2012 11:53

Qw_freak (8) skrev:
den bliver kørt fra filen perl_5.14.2.bb

I samme fil er der en sed kommando, som ændrer @DESTDIR@.

#10 - arne_v
20. sep. 2012 15:16

#problem

Script der updaterer en script template som så køres er altid en god kandidat til mest obfuscated build process.

:-)

#11 - Qw_freak
20. sep. 2012 15:39

kasperd (9) skrev:
I samme fil er der en sed kommando, som ændrer @DESTDIR@.

ja, men til hvad?

Grunden til mit spørgsmål ligger i at DESTDIR bliver fyldt to gange så den bliver til

/usr/local/i686sdk/perl-5.14.3/usr/local/i686sdk/perl-5.14.3....

arne_v (10) skrev:
#problem

Script der updaterer en script template som så køres er altid en god kandidat til mest obfuscated build process.

:-)

hehe, prøv at kigge i: Perls Configure script
Fy for pokker...

#12 - kasperd
20. sep. 2012 15:40

arne_v (10) skrev:
Script der updaterer en script template som så køres er altid en god kandidat til mest obfuscated build process.

Sådan har autoconf og automake gjort lige så længe som jeg har kendt til dem.

Om man vil kalde det for en del af build processen kan diskutteres. Hvis man ændret sourcen er det nok at køre make igen uden at man behøver regenerere sin Makefile.

#13 - kasperd
20. sep. 2012 15:46

Qw_freak (11) skrev:
ja, men til hvad?

Der er ' omkring, så der er ingen tegn som har nogen speciel betydning (bortset fra det afsluttende '-tegn selvfølgelig.)

Det bliver bare erstattet med ${prefix}, som er shellkode til at aflæse prefix variablen.

#14 - Qw_freak
20. sep. 2012 15:55

Det værste er at jeg slet ikke arbejder med perl, men open embeddeds qt-sdk-toolchain kræver den, og der er en fejl i deres bitbake opskrift..

#15 - arne_v
20. sep. 2012 16:18

kasperd (12) skrev:
Sådan har autoconf og automake gjort lige så længe som jeg har kendt til dem.

Jep.

Men det bliver det ikke bedre af.

kasperd (12) skrev:
Om man vil kalde det for en del af build processen kan diskutteres. Hvis man ændret sourcen er det nok at køre make igen uden at man behøver regenerere sin Makefile.

Det er kun første gang der skal buildes eller efter en breaking ændring af tool chain der er brug for at køre dem.

Men jeg vil stadig kalde dem en del af build process, selvom de ikke køres hver gang.

De skal bruges hvis man builder fra scratch ved udcheck fra source control.

#16 - arne_v
20. sep. 2012 16:24

#14

Teknologi bloat er desværre ret almindeligt.

En eller flere udviklere som står bag det projekt er sikkert super skrappe til Perl og sh/bash, men glemte at tænke på at det ikke nødvendigvis gælder for alle dem som skal arbejde med projektet.

Man må antage at dem som skal udvikle med Qt kan C/C++, men det er et problem at antage at de kender andre tekonologier X, Y og Z.

mboost-dp1

Nyheder

Seneste kommentarer i nyheder

Seneste kommentarer i forum