---

Jeg har tidligere skrevet lidt småscripts til unix som folk bare har
kunne pakke ud og placere hvor de vil. Nu har jeg dog lavet et lidt
større som jeg gerne vil distribuere.

Dog overvejer jeg hvor i biblioteksstrukturen jeg bør placere filerne
Der er jo mange muligheder lige fra /opt til /usr/bin.

Jeg har ikke kunne google mig frem til noget rigtigt brugbart.

Er der nogen der har nogle definiationer til hvor man bør placere filer?

Martin
--
Besøg http://www.adsltips.dk for guider til
ADSL og opsætning af Cisco/Zyxel/Aethra routere.
Alt jeg skriver på usenet er mine egne personlige meninger
med mindre andet er angivet.

---

On Sat, 08 Oct 2005 11:30:37 +0000, Martin Schultz wrote:

> Jeg har ikke kunne google mig frem til noget rigtigt brugbart.
>
> Er der nogen der har nogle definiationer til hvor man bør placere filer?
Ifølge GNU-specifikationen skal programmer placeres i enten
/usr/local/[s]bin eller /usr/[s]bin.

--
Hilsen/Regards
Michael Rasmussen
http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xE3E80917

---

Michael Rasmussen <mir@miras.org> writes:

> Ifølge GNU-specifikationen skal programmer placeres i enten
> /usr/local/[s]bin eller /usr/[s]bin.

I OS X verdenen er et program en samlet applikationsklump (*.app) som
man kan flytte rundt på efter behov.
--
Thorbjørn Ravn Andersen

---

On Sat, 08 Oct 2005 15:05:21 +0200, Thorbjoern Ravn Andersen wrote:

>
> I OS X verdenen er et program en samlet applikationsklump (*.app) som man
> kan flytte rundt på efter behov.
Hvordan håndteres path så?
--
Hilsen/Regards
Michael Rasmussen
http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xE3E80917

---

Michael Rasmussen <mir@miras.org> writes:

> > kan flytte rundt på efter behov.
> Hvordan håndteres path så?

Af GUI'en der starter programmet.

Programmer lægges sædvanligvis standardsteder så det ville være
trivielt at ekspandere ~/Applications/*.app/x86/bin/ i sin $PATH
udregning.

--
Thorbjørn Ravn Andersen
http://unixsnedkeren.dk - Unix, Java, Web, Netværk, Århus

---

On Sat, 08 Oct 2005 16:41:35 +0200, Thorbjoern Ravn Andersen wrote:

>
> Programmer lægges sædvanligvis standardsteder så det ville være
> trivielt at ekspandere ~/Applications/*.app/x86/bin/ i sin $PATH
> udregning.
Lyder lidt som samme philosofi bagved .NET? Egentlig ikke nogen dårlig
ide, hvis man udelukkende opererer fra GUI, men vil man også kunne
anvende CLI, synes jeg ulemperne er større end fordelene.

--
Hilsen/Regards
Michael Rasmussen
http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xE3E80917

---

Michael Rasmussen <mir@miras.org> writes:

> Lyder lidt som samme philosofi bagved .NET? Egentlig ikke nogen dårlig
> ide, hvis man udelukkende opererer fra GUI, men vil man også kunne
> anvende CLI, synes jeg ulemperne er større end fordelene.

Så længe der ikke er en god GNU-uninstaller synes jeg det basalt er
noget rod med at skovle det hele ned i /usr eller /usr/local, og - jo
- jeg har vedligeholdt systemer med nogen meget gamle /usr/local.

Unixverdenen savner seriøst et standardbegrebet med en samlet pakke
for et givent program (og, nej, det tæller ikke at sige RPM eller DEB
for det er ikke standard).
--
Thorbjørn Ravn Andersen

---

On Sat, 08 Oct 2005 17:08:05 +0200, Thorbjoern Ravn Andersen wrote:

> Unixverdenen savner seriøst et standardbegrebet med en samlet pakke for
> et givent program (og, nej, det tæller ikke at sige RPM eller DEB for det
> er ikke standard).
Det er da på vej
http://www.gnu.org/software/sourceinstall/article.html
--
Hilsen/Regards
Michael Rasmussen
http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xE3E80917

---

Michael Rasmussen <mir@miras.org> writes:

> http://www.gnu.org/software/sourceinstall/article.html

Jeg bemærker en masse grafik, og et meget lavt fokus på
automatisering.

Jeg kan ikke umiddelbart se om der er pakkekonventioner i systemet.

--
Thorbjørn Ravn Andersen

---

On Sat, 08 Oct 2005 19:59:06 +0200, Thorbjoern Ravn Andersen wrote:

>
> Jeg bemærker en masse grafik, og et meget lavt fokus på automatisering.
>
> Jeg kan ikke umiddelbart se om der er pakkekonventioner i systemet.
Det er der. Meningen er, at en hvilken som helst source tar-ball der
overholder GNU's guidelines, skal kunne installeres på en hvilken som
helst computer, der understøtter disse guide lines - det gør mig bekendt
en hvilken som helst *nix variant. Også OS X

--
Hilsen/Regards
Michael Rasmussen
http://keyserver.veridis.com:11371/pks/lookup?op=get&search=0xE3E80917

---

Den 08 Oct 2005 17:08:05 +0200 skrev Thorbjoern Ravn Andersen:
> Michael Rasmussen <mir@miras.org> writes:
>
>> Lyder lidt som samme philosofi bagved .NET? Egentlig ikke nogen dårlig
>> ide, hvis man udelukkende opererer fra GUI, men vil man også kunne
>> anvende CLI, synes jeg ulemperne er større end fordelene.
>
> Så længe der ikke er en god GNU-uninstaller synes jeg det basalt er
> noget rod med at skovle det hele ned i /usr eller /usr/local, og - jo
> - jeg har vedligeholdt systemer med nogen meget gamle /usr/local.
>
> Unixverdenen savner seriøst et standardbegrebet med en samlet pakke
> for et givent program (og, nej, det tæller ikke at sige RPM eller DEB
> for det er ikke standard).

Når du skriver "standard", mener du så "monopol"?

Mvh
Kent
--
Hard work may pay off in the long run, but laziness pays off right now.

---

Kent Friis <nospam@nospam.invalid> writes:

> > Unixverdenen savner seriøst et standardbegrebet med en samlet pakke
> > for et givent program (og, nej, det tæller ikke at sige RPM eller DEB
> > for det er ikke standard).
>
> Når du skriver "standard", mener du så "monopol"?

Hvordan i alverden kan du få den ide.

Har gcc fx monopol?

--
Thorbjørn Ravn Andersen

---

Den 08 Oct 2005 19:59:55 +0200 skrev Thorbjoern Ravn Andersen:
> Kent Friis <nospam@nospam.invalid> writes:
>
>> > Unixverdenen savner seriøst et standardbegrebet med en samlet pakke
>> > for et givent program (og, nej, det tæller ikke at sige RPM eller DEB
>> > for det er ikke standard).
>>
>> Når du skriver "standard", mener du så "monopol"?
>
> Hvordan i alverden kan du få den ide.

Det lyder sådan.

> Har gcc fx monopol?

Som hvad?

Programmeringssprog? Nej, der er både Perl, Python, PHP (sig mig begynder
alle sprog nutildags med P?

C-compiler? Jeg kan ikke lige komme på nogen konkurrenter for tiden (jo
der er Intels compiler, men dens "marked"s-andel er ikke lige så jeg vil
kalde den relevant). Der var Egcs førhen...

Mvh
Kent
--
Hard work may pay off in the long run, but laziness pays off right now.

---

Kent Friis <nospam@nospam.invalid> writes:

> > Hvordan i alverden kan du få den ide.
>
> Det lyder sådan.

Det viser bare at dette er et fattigt medie.

Jeg er ikke interesseret i et monopol, men at GNU værktøjer der bruger
autoconf/automake/whatever installerer i en biblioteksstruktur på en
måde som tillader

1) let afinstallering
2) let håndtering af flere installerede versioner af samme program.
3) mulig placering flere steder så man kan fordele på flere diske.
4) mulighed for "fat binary" så flere arkitekturer kan dele
installationsfiler i videst muligt omfang men hvor der er klar
adskillelse mellem de enkelte arkitekturers filer.
5) gerne metainformation så man kan se hvad der er installeret hvornår
og sådan.
6) Globale indstillinger.
7) Styring af afhængigheder af andre værktøjer. (Hvilken GTK version
kræves der mv - og hvis det er et problem så TESTES der for det i
configure-scirptet).

GNU værktøjerne af i dag håndterer tilpasningen til operativsystemet
og brugerangivelse af diverse variable, men - så vidt jeg ved - ingen
ting om hvordan installation foretages.

> Programmeringssprog? Nej, der er både Perl, Python, PHP (sig mig begynder
> alle sprog nutildags med P?

Nej.

Haskell begynder fx med H.

--
Thorbjørn Ravn Andersen

---

Thorbjoern Ravn Andersen wrote:

>> Lyder lidt som samme philosofi bagved .NET? Egentlig ikke nogen dårlig
>> ide, hvis man udelukkende opererer fra GUI, men vil man også kunne
>> anvende CLI, synes jeg ulemperne er større end fordelene.
> Så længe der ikke er en god GNU-uninstaller synes jeg det basalt er
> noget rod med at skovle det hele ned i /usr eller /usr/local, og - jo
> - jeg har vedligeholdt systemer med nogen meget gamle /usr/local.
> Unixverdenen savner seriøst et standardbegrebet med en samlet pakke
> for et givent program (og, nej, det tæller ikke at sige RPM eller DEB
> for det er ikke standard).

Hvad med http://smartpm.org/ ?
Jeg skal lige nævne at jeg ikke har kikket så meget på det, og heller ikke
lige for tiden er i humør til så meget af det engelske, så måske er det
slet ikke noget du vil være med til at kalde standard install/uinstaller
til Linux (og MAC osX)



--
Med venlig hilsen
Ivar Madsen
--------------------------------------------------------------------------------

---

Thorbjoern Ravn Andersen wrote:
> Unixverdenen savner seriøst et standardbegrebet med en samlet pakke
> for et givent program (og, nej, det tæller ikke at sige RPM eller DEB
> for det er ikke standard).

Det er da meget standard på min Debian :)
Men ja... det var noget lettere på BeOS, hvor man bare kunne pakke et
program ud i en folder og køre det. Skulle der endelige installeres
nogle OS plugins, så lavede man bare drag-n-drop til et symlink, der
pegede det rigtige sted hen.

Peter

---

Peter Mogensen wrote:

>> Unixverdenen savner seriøst et standardbegrebet med en samlet pakke
>> for et givent program (og, nej, det tæller ikke at sige RPM eller DEB
>> for det er ikke standard).
> Det er da meget standard på min Debian :)
> Men ja... det var noget lettere på BeOS, hvor man bare kunne pakke et
> program ud i en folder og køre det. Skulle der endelige installeres
> nogle OS plugins, så lavede man bare drag-n-drop til et symlink, der
> pegede det rigtige sted hen.

Sådan var det også med OS/2.
Men vil det ikke virke, hvis man lagde alle programfiler, og hvad de skal
bruge af lib filer, i samme dir, vil Linux så ikke kunne virke?
MEd Linux har man jo mange lib som er fælles for flere programmer, og så må
man jo nødvendigvis have dem liggende, hvor alle programmerne kan finde
dem,,,


--
Med venlig hilsen
Ivar Madsen
--------------------------------------------------------------------------------

---

Den Sat, 08 Oct 2005 21:50:50 +0200 skrev Ivar Madsen:
> Peter Mogensen wrote:
>
>>> Unixverdenen savner seriøst et standardbegrebet med en samlet pakke
>>> for et givent program (og, nej, det tæller ikke at sige RPM eller DEB
>>> for det er ikke standard).
>> Det er da meget standard på min Debian :)
>> Men ja... det var noget lettere på BeOS, hvor man bare kunne pakke et
>> program ud i en folder og køre det. Skulle der endelige installeres
>> nogle OS plugins, så lavede man bare drag-n-drop til et symlink, der
>> pegede det rigtige sted hen.
>
> Sådan var det også med OS/2.
> Men vil det ikke virke, hvis man lagde alle programfiler, og hvad de skal
> bruge af lib filer, i samme dir, vil Linux så ikke kunne virke?

Du mener "vil programmet så ikke virke" - det kommer an på programmet.
Programmer der installeres vha. Loki Installer (ofte spil) plejer at
kigge efter deres filer i samme mappe som programmet selv.

De libs som der forventes at alle har (fx libc, X) loader programmet
fra de sædvanlige steder, og dem som ikke alle har (fx SDL)
installeres sammen med programmet. Hvis man så har SDL i forvejen,
kan man bare slette den kopi der ligger i programmets mappe, så
bruger den bare systemets i stedet for.

> MEd Linux har man jo mange lib som er fælles for flere programmer, og så må
> man jo nødvendigvis have dem liggende, hvor alle programmerne kan finde
> dem,,,

Man kunne såmænd godt have 100 kopier af det samme lib i forskellige
mappe, hvis man havde alt for meget disk plads

Mvh
Kent
--
Hard work may pay off in the long run, but laziness pays off right now.

---

I dk.edb.system.unix, skrev Kent Friis:
> Man kunne såmænd godt have 100 kopier af det samme lib i forskellige
> mappe, hvis man havde alt for meget disk plads

... og har lyst til at udsætte sig for en meget stor administrativ opgave
når der bliver fundet et sikkerhedshul i det.

Jesper
--
../Jesper Krogh, jesper@krogh.cc, Jabber ID: jesper@jabbernet.dk

---

Thorbjoern Ravn Andersen wrote:
>
> Så længe der ikke er en god GNU-uninstaller synes jeg det basalt er
> noget rod med at skovle det hele ned i /usr eller /usr/local,

Hvis man installerer fra source og lægger det ned i /usr, så
er man selv ude om det. Bortset fra det, så kan det ikke være
særligt svært at tilføje en uninstall feature til autotools
(det er måske allerede sket). At den så ville kræve, at man
stadigt havde sourcen liggende for at vide hvilke filer, der
skal slettes, er så en anden sag. Men det burde nu heller ikke
være særlig svært at smide et uninstall script i $PREFIX/sbin

>
> Unixverdenen savner seriøst et standardbegrebet med en samlet pakke
> for et givent program (og, nej, det tæller ikke at sige RPM eller DEB
> for det er ikke standard).

I så fald tæller .app da i hvert fald slet ikke.

--
Kasper Dupont
Note to self: Don't try to allocate
256000 pages with GFP_KERNEL on x86.

---

Kasper Dupont <kasperd@daimi.au.dk> writes:

> er man selv ude om det. Bortset fra det, så kan det ikke være
> særligt svært at tilføje en uninstall feature til autotools

Det er muligt det ikke er særligt svært, men i så fald er det ikke
slået igennem, hvilket var det jeg savnede.

> > Unixverdenen savner seriøst et standardbegrebet med en samlet pakke
> > for et givent program (og, nej, det tæller ikke at sige RPM eller DEB
> > for det er ikke standard).
>
> I så fald tæller .app da i hvert fald slet ikke.

Sagde jeg det?

Jeg efterlyste bare noget funktionalitet som jeg savner i GNU
software. At diverse distributioner så laver dobbelt og
trippelarbejde med at lave pakker ud af det, er bare beklageligt.

--
Thorbjørn Ravn Andersen

---

Den 09 Oct 2005 13:27:46 +0200 skrev Thorbjoern Ravn Andersen:
> Kasper Dupont <kasperd@daimi.au.dk> writes:
>
>> er man selv ude om det. Bortset fra det, så kan det ikke være
>> særligt svært at tilføje en uninstall feature til autotools
>
> Det er muligt det ikke er særligt svært, men i så fald er det ikke
> slået igennem, hvilket var det jeg savnede.

Næsten alle programmer har idag en "make uninstall". Desværre ikke alle,
men det er jo ikke muligt at tvinge folk (selv Windows-programmer har
ikke altid en uninstall feature).

Det skulle iøvrigt være muligt at lave en

$ make -n uninstall >uninstall.sh

så man ikke behøver at have sourcen liggende. Det skal dog lige siges
at jeg ikke har forsøgt, det er noget af det der står på min todo til
når jeg får god tid.

Mvh
Kent
--
Hard work may pay off in the long run, but laziness pays off right now.

---

Kent Friis <nospam@nospam.invalid> writes:

> Næsten alle programmer har idag en "make uninstall". Desværre ikke alle,
> men det er jo ikke muligt at tvinge folk (selv Windows-programmer har
> ikke altid en uninstall feature).

Det skal være et selvstående script som kan køres uden kildeteksten og
med de faktiske lokationer fra installationen.

> så man ikke behøver at have sourcen liggende. Det skal dog lige siges
> at jeg ikke har forsøgt, det er noget af det der står på min todo til
> når jeg får god tid.

Jeg indrømmer gerne at det også kun har akademisk interesse for mig.

Det skal dog siges at på min Ubuntu boks har jeg valgt at bygge en
Debian pakke af seneste Java og installere DEN for at have den bygget
ind i pakkearkiverne. Det er unødigt bøvlet :(
--
Thorbjørn Ravn Andersen

---

Thorbjoern Ravn Andersen wrote:

> Det skal dog siges at på min Ubuntu boks har jeg valgt at bygge en
> Debian pakke af seneste Java og installere DEN for at have den bygget
> ind i pakkearkiverne. Det er unødigt bøvlet :(

På min Mandrake, har jeg Java pakke i Mandrakes officelle pakkekilder.
(OK det kræver at man er Mandrakeclub medlem) man Debian burde have noget
tilsvarende,,,

--
Med venlig hilsen
Ivar Madsen
--------------------------------------------------------------------------------

---

Ivar Madsen <spam.news.cc@milli.dk> writes:

> På min Mandrake, har jeg Java pakke i Mandrakes officelle pakkekilder.
> (OK det kræver at man er Mandrakeclub medlem) man Debian burde have noget
> tilsvarende,,,

Det kræver der er nogen der gør det, og på et tidspunkt havde jeg et
konkret problem med den 1.4.2_06 der var i Debianpakkesystemet, som
krævede opdatering til den nyeste 1.4.2_09.

Ind imellem rammer man den slags ting.
--
Thorbjørn Ravn Andersen

---

Thorbjoern Ravn Andersen wrote:
>
> Det kræver der er nogen der gør det, og på et tidspunkt havde jeg et
> konkret problem med den 1.4.2_06 der var i Debianpakkesystemet, som
> krævede opdatering til den nyeste 1.4.2_09.

Det problem kunne man nemt løse, hvis der var tale om rpm pakker,
og jeg vil da gå ud fra, at man kan gøre noget tilsvarende med
deb pakker. Hvad jeg ville gøre er følgende:

Download 1.4.2_06 som .src.rpm fil og installer den.
Download 1.4.2_09 og smid den ind i stedet for 1.4.2_06 tar filen.
Åbn .spec filen og ret versionsnummeret. Kør til sidst en rpmbuild
kommando for at lave en binær pakke.

--
Kasper Dupont
Note to self: Don't try to allocate
256000 pages with GFP_KERNEL on x86.

---

Thorbjoern Ravn Andersen wrote:
>
> Programmer lægges sædvanligvis standardsteder så det ville være
> trivielt at ekspandere ~/Applications/*.app/x86/bin/ i sin $PATH
> udregning.

Nej, det er bestemt ikke trivielt. For det første vil PATH
jo så indeholde de directories, der eksisterede da den blev
ekspanderet, og ikke de nuværende. For det andet bliver PATH
mange gange længere og dermed komplet uoverskuelig. For det
tredje kender programmet ikke sin egen placering og kan
derfor ikke finde relaterede filer. For det fjerde ved vi
ikke, hvad der ligger i det bin directory.

--
Kasper Dupont
Note to self: Don't try to allocate
256000 pages with GFP_KERNEL on x86.

---

Kasper Dupont <kasperd@daimi.au.dk> writes:

> Thorbjoern Ravn Andersen wrote:
> >
> > Programmer lægges sædvanligvis standardsteder så det ville være
> > trivielt at ekspandere ~/Applications/*.app/x86/bin/ i sin $PATH
> > udregning.
>
> Nej, det er bestemt ikke trivielt. For det første vil PATH
> jo så indeholde de directories, der eksisterede da den blev
> ekspanderet, og ikke de nuværende.

Bash cacher ikke indholdet af $PATH (imodsætning til fx tcsh), hvorfor
at den alligevel skal løbe det hele igennem hver gang. Her vil det
være trivielt at tilføje almindelig jokertegnsekspandering.

> For det andet bliver PATH mange gange længere og dermed komplet
> uoverskuelig.

Det afhænger jo af hvordan den er sat op.

> For det tredje kender programmet ikke sin egen placering og kan
> derfor ikke finde relaterede filer.

Ikke det? Det mener jeg nu ellers, men jeg har ikke lavet C
programmering i mange år efterhånden.

> For det fjerde ved vi ikke, hvad der ligger i det bin directory.

Er det ikke ligegyldigt i den her sammenhæng?

--
Thorbjørn Ravn Andersen

---

Thorbjoern Ravn Andersen wrote:
>
> Bash cacher ikke indholdet af $PATH (imodsætning til fx tcsh),

Jo den gør. Men det har nu ikke noget med sagen at gøre,
for det her drejer sig slet ikke om caching af stier, men
derimod at du har brug for at ændre PATH variablen i
samtlige kørende shells hver gang du installerer en pakke.
Det kan ikke lade sig gøre.

> hvorfor
> at den alligevel skal løbe det hele igennem hver gang. Her vil det
> være trivielt at tilføje almindelig jokertegnsekspandering.

Hvilket jeg også lige afprøvede, det virker ikke.

>
> > For det andet bliver PATH mange gange længere og dermed komplet
> > uoverskuelig.
>
> Det afhænger jo af hvordan den er sat op.

Sådan som du beskrev det bliver den urimeligt lang.

>
> > For det tredje kender programmet ikke sin egen placering og kan
> > derfor ikke finde relaterede filer.
>
> Ikke det? Det mener jeg nu ellers, men jeg har ikke lavet C
> programmering i mange år efterhånden.

En executable kan ikke finde sit navn på en portabel måde.
Den normale måde at håndtere det på er, at configure
scriptet får at vide hvor filerne skal ligge. Det opretter
så passende definitioner i en header fil som programmerne
compileres imod. Dermed har man placeringen hardcodet i
executables.

>
> > For det fjerde ved vi ikke, hvad der ligger i det bin directory.
>
> Er det ikke ligegyldigt i den her sammenhæng?

Det er ganske afgørende for, om den PATH du foreslog
overhovedet giver mening.

--
Kasper Dupont
Note to self: Don't try to allocate
256000 pages with GFP_KERNEL on x86.

---

I dk.edb.system.unix, skrev Kasper Dupont:
> > Ikke det? Det mener jeg nu ellers, men jeg har ikke lavet C
> > programmering i mange år efterhånden.
>
> En executable kan ikke finde sit navn på en portabel måde.
> Den normale måde at håndtere det på er, at configure
> scriptet får at vide hvor filerne skal ligge. Det opretter
> så passende definitioner i en header fil som programmerne
> compileres imod. Dermed har man placeringen hardcodet i
> executables.

Hmmm..
jesper@ibm:/tmp$ ./test.pl
/tmp
jesper@ibm:/tmp$ cp test.pl /home/jesper/
jesper@ibm:/tmp$ cd /home/jesper/
jesper@ibm$ perl ./test.pl
/home/jesper
jesper@ibm:/tmp$ perl /home/jesper/test.pl
/home/jesper
jesper@ibm$ cat test.pl
#!/usr/bin/perl
use FindBin qw($Bin);
print $Bin . "\n";

Perl ser ud til at kunne finde ud af det.. og det er vel ikke ligefrem
fordi man ikke kan kalde perl for "portabelt".

perldoc FindBin

Jeg bruger den gladeligt for at kunne adskille kommandolinie-programmer
fra deres tilhørende perl-moduler.

Jesper
--
../Jesper Krogh, jesper@krogh.cc, Jabber ID: jesper@jabbernet.dk

---

Jesper Krogh wrote:
>
> Perl ser ud til at kunne finde ud af det.. og det er vel ikke ligefrem
> fordi man ikke kan kalde perl for "portabelt".

Det er så fordi det er et script og ikke en executable.
Fortolkeren må nødvendigvis kende stien til scriptet, og
hvis fortolkeren stiller den oplysning til rådighed for
scriptet, så kan scriptet selvfølgelig finde ud af det.

Til gengæld kan perl ikke nødvendigvis finde ud af hvor
din perl executable ligger.

--
Kasper Dupont
Note to self: Don't try to allocate
256000 pages with GFP_KERNEL on x86.

---

Kasper Dupont <kasperd@daimi.au.dk> writes:

> Til gengæld kan perl ikke nødvendigvis finde ud af hvor
> din perl executable ligger.

perl -le 'print $^X'

--
Peter Makholm | Why does the entertainment industry wants us to
peter@makholm.net | believe that a society base on full surveillance
http://hacking.dk | is bad?
| Do they have something to hide?

---

Peter Makholm wrote:
>
> Kasper Dupont <kasperd@daimi.au.dk> writes:
>
> > Til gengæld kan perl ikke nødvendigvis finde ud af hvor
> > din perl executable ligger.
>
> perl -le 'print $^X'

strace -e readlink perl -le 'print $^X'

Det virker så på Linux, men er ikke særligt portabelt.
Prøver man i stedet for på Solaris får man blot følgende:

# perl -le 'print $^X'
perl

--
Kasper Dupont
Note to self: Don't try to allocate
256000 pages with GFP_KERNEL on x86.

---

> Er der nogen der har nogle definiationer til hvor man bør placere filer?

http://www.pathname.com/fhs/ er måske det du leder efter.

/usr/local er til lokalt installerede programmer, dvs. programmer der
ikke kommer med den distribution man bruger. Men hvis der bliver brugt
et pakkesystem (Debians fx, så dit program er rettet specifikt til
Debian) er det muligvis `mere standard' at placerer programmet uden
for /usr/local. Det er i hvert fald hvad jeg har noteret mig ved
normal brug af Linux (så stol ikke på mig, da jeg i bund og grund ikke
ved meget om det :) ).

Allan Rasmussen

---

Martin Schultz wrote:
>
> Er der nogen der har nogle definiationer til hvor man bør placere filer?

Man bør bruge /usr/local som default og så give mulighed
for at specificere et andet prefix. Under prefix bør man
så bruge lib til libraries, bin til executables, med mindre
det er executables det kun giver mening at køre når man er
root i hvilket fald man bør bruge sbin, og endeligt share
til filer som er arkitektur uafhængige og kan deles mellem
flere maskiner.

Hvis man laver en pakke (f.eks. .deb eller .rpm) udfra
sourcen bør prefix så specificeres som /usr i stedet for
/usr/local. Du skal blot sørge for, at det kan lade sig
gøre.

Autotools gør det nemt for den person, der skal installere
pakken (men ret besværligt for udvikleren).

--
Kasper Dupont
Note to self: Don't try to allocate
256000 pages with GFP_KERNEL on x86.