[Linux/Unix] [/Gurus/helpen/newbies]% ./deel 17

quote:

Op donderdag 20 september 2007 08:34 schreef Iblis het volgende:
Overigens is -i een FreeBSD extension, die weliswaar redelijk ruim ondersteund wordt, maar als je het meer portable moet hebben is het beter voor iets als:
[ code verwijderd ]

Kan je leuker oplossen met perl, is nog portable ook ;)

Als iets niet portable is, is het Perl. Dat zit bij NetBSD niet standaard in de base-install bijvoorbeeld (en terecht). Daar is ’t al snel /usr/local/bin/perl. Perl is zeker geen POSIX.

Portable is redirecten naar een tijdelijk bestand, oude bestand verwijderen en nieuwe hernoemen. Het heeft het bijkomend voordeel dat als de schijf vol raakt terwijl je ermee bezig je oorspronkelijke bestand niet corrupt raakt. (Aannemende dat je gebruik van && of $? maakt).

quote:

Op woensdag 3 oktober 2007 20:20 schreef thabit het volgende:

[..]

Wine gebruiken. Of een VM draaien. Nadeel van wine is dat het niet 100% compatibel is. Nadeel van een VM is dat het loodzwaar is.

En wine werkt alleen op x86, niet op een PPC architectuur, en de VM wel. Nu is het niet waarschijnlijk dat de vraagsteller iets anders dan x86 heeft – maar toch.

quote:

Op woensdag 3 oktober 2007 21:01 schreef Iblis het volgende:
Als iets niet portable is, is het Perl. Dat zit bij NetBSD niet standaard in de base-install bijvoorbeeld (en terecht). Daar is ’t al snel /usr/local/bin/perl. Perl is zeker geen POSIX.

Portable is redirecten naar een tijdelijk bestand, oude bestand verwijderen en nieuwe hernoemen. Het heeft het bijkomend voordeel dat als de schijf vol raakt terwijl je ermee bezig je oorspronkelijke bestand niet corrupt raakt. (Aannemende dat je gebruik van && of $? maakt).

Hoezo zou het niet portable zijn? Perl is beschikbaar voor bijna alle OS'en. Dat het niet in een default install zit doet daar niks aan af. Java is ook portable, ookal wordt Java niet op alle systemen default geinstalleerd. En als je /usr/local/bin/perl moet gebruiken staat het wel in je PATH, en kan je het gewoon met `perl' aanroepen (bash is ook niet altijd te vinden onder /usr/bin/bash).
Ik gebruik perl onder Windows, Unix en Linux, ik hoef geen code aan te passen (Windows stuff ff uitgezonderd met specifieke gevallen) als ik mijn scripts op een andere doos zet. Dat lijkt me redelijk portable.

Perl is zeker geen POSIX: http://perldoc.perl.org/POSIX.html

Verder is perl -p -i -e 's/hier/daar/g' $file net zo makkelijk als je for loop (ik vind het persoonlijk makkelijker). Hoef je je helemaal niet druk te maken over diskspace issues etc etc. (zelfde geldt voor sed -i trouwens). Je doet het nu in 1x zonder extra files aan te maken en te moven.

FreeBSD is trouwens ook perl-loos bij de base install. sed kan je trouwens ook deinstallen en dan is je for-loop ook niet meer portable. Als je de tools niet installeert vervalt de portability altijd, dat wil ik eigenlijk zeggen.

Maar sommige tools maken deel uit van een standaard Unix-systeem (met standaardopties) en sommige niet. Van sommige tools kun je ervan uitgaan dat ze op een Unix-achtige beschikbaar zijn. Dat zijn b.v. /bin/sh, maar niet /bin/bash. Perl is ook geen standaard utility. sed wel, awk ook, maar yes niet. Als iemand moedwillig sed deïnstalleert zodat het onderliggende systeem geen Unix-(achtig) systeem meer is, dan kan dat natuurlijk, maar goed. Het is m.i. fout om aan te nemen dat Perl sowieso wel op een Unix-systeem staat. (Evenals aan te nemen dat sed -i ondersteund wordt.)

Dat Perl zelf portable is, doet daar niets aan af. Het gaat om jouw oplossing, en of die zo naar een ander Unix-systeem omgezet kan worden, en als je Perl gebruikt ben je daar een stuk minder zeker van. Wat standaardcommando's zijn waarover je kunt beschikken kun je bij opengroup.org vinden.

Als perl portable is, waarom zou een perl script dan niet portable zijn?
Tevens zeg je dat perl geen standaard utility is, daar ben ik het al helemaal niet mee eens.
En een Unix machine zonder sed is nog steeds een Unix machine. Afwezigheid van tools/applicaties maken een Unix machine niet minder Unix. Een Unix machine kan perfect zonder sed en awk, zolang je maar perl op die doos hebt.
Om een collega te quoten: "Ik zou niet weten waarom je voor sed en awk zou kiezen als je het in perl kan doen".

Maar goed, ik heb een andere mening dan jij die hebt, daar laat ik het maar bij.

Vraagje: Weet iemand aan progje om op een linux bak in de gaten te houden welke bestanden er geopend worden. Wil namelijk weten wat bepaalde load op een server veroorzaakt . Een soort top idee zeg maar .

Kun je niet je server proces die zaken laten wegschrijven naar een log file?

"lsof" geeft een lijst met alle geopende bestanden op dat moment. "man lsof" voor meer info.

quote:

Op zaterdag 6 oktober 2007 14:15 schreef Visitor.Q het volgende:
Kun je niet je server proces die zaken laten wegschrijven naar een log file?

Het gaat om de al gehele server niet een bepaald process .

quote:

Op zaterdag 6 oktober 2007 14:18 schreef Farenji het volgende:
"lsof" geeft een lijst met alle geopende bestanden op dat moment. "man lsof" voor meer info.

Wow! Dat zijn iets meer resultaten dat ik gehoopt had . Misschien ff een bash scriptje maken wat in de gaten houd welke bestanden het vaakst geopend worden .

quote:

Op donderdag 4 oktober 2007 17:27 schreef slacker_nl het volgende:
Als perl portable is, waarom zou een perl script dan niet portable zijn?
Tevens zeg je dat perl geen standaard utility is, daar ben ik het al helemaal niet mee eens.
En een Unix machine zonder sed is nog steeds een Unix machine. Afwezigheid van tools/applicaties maken een Unix machine niet minder Unix. Een Unix machine kan perfect zonder sed en awk, zolang je maar perl op die doos hebt.
Om een collega te quoten: "Ik zou niet weten waarom je voor sed en awk zou kiezen als je het in perl kan doen".

Maar goed, ik heb een andere mening dan jij die hebt, daar laat ik het maar bij.

Het gaat hier niet om een mening, het gaat hier om wat een Unix-systeem aan utilities moet hebben. Een Unix-systeem dat aan de specificaties voldoet heeft wel sed en awk (als ze dat niet hebben kán het geen Unix zijn) maar niet per se Perl.

Als je op je eigen PC wat moet doen kun je prima Perl gebruiken, wil je echter iets hebben dat zeker weten zonder dependencies (en dat is wel de crux natuurlijk) op een Unix-systeem werkt, dan moet je geen Perl gebruiken. In sommige situaties is Perl een onoverkoombare grote dependency. Ervan uitgaan dat als je voor een Unix-systeem code dat Perl er wel op aanwezig zal zijn is niet handig.

quote:

Op zaterdag 6 oktober 2007 14:24 schreef WyriHaximus het volgende:
Wow! Dat zijn iets meer resultaten dat ik gehoopt had . Misschien ff een bash scriptje maken wat in de gaten houd welke bestanden het vaakst geopend worden .

Standaard krijg je dus alle bestanden, en daar zitten ook netwerk sockets in, devices, allerlei libs, en meer zooi die misschien niet zo relevant zijn. Iig heel veel bestanden. Je kan ook op naam, directory, of type filteren om een wat beter hanteerbare lijst te krijgen - maar ook kun je filteren met bijv grep, wil je bijv snel weten welke mp3 bestanden er zijn geopend op een bepaald moment doe je "lsof | grep mp3"

quote:

Op zaterdag 6 oktober 2007 14:31 schreef Farenji het volgende:

[..]

Standaard krijg je dus alle bestanden, en daar zitten ook netwerk sockets in, devices, allerlei libs, en meer zooi die misschien niet zo relevant zijn. Iig heel veel bestanden. Je kan ook op naam, directory, of type filteren om een wat beter hanteerbare lijst te krijgen - maar ook kun je filteren met bijv grep, wil je bijv snel weten welke mp3 bestanden er zijn geopend op een bepaald moment doe je "lsof | grep mp3"

Ben ff de man page aan het door lezen .

Hoe weet je zo zeker dat de load veroorzaakt wordt door bestanden te openen? Als je een bepaald proces verdenkt kun je ook strace(1) gebruiken om de systemcalls die ’t proces doet te inspecteren.

quote:

Op zaterdag 6 oktober 2007 15:33 schreef Iblis het volgende:
Hoe weet je zo zeker dat de load veroorzaakt wordt door bestanden te openen? Als je een bepaald proces verdenkt kun je ook strace(1) gebruiken om de systemcalls die ’t proces doet te inspecteren.

Niet, maar heb het vermoeden en wil het zeker weten of dat klopt of niet .

quote:

Op zaterdag 6 oktober 2007 14:25 schreef Iblis het volgende:
Het gaat hier niet om een mening, het gaat hier om wat een Unix-systeem aan utilities moet hebben. Een Unix-systeem dat aan de specificaties voldoet heeft wel sed en awk (als ze dat niet hebben kán het geen Unix zijn) maar niet per se Perl.

Dat is natuurlijk onzin wat je nu zegt. Een Unix systeem hoeft helemaal geen sed/awk te hebben (en uiteraard hoeft perl ook ook niet geinstalleerd te zijn) om Unix te zijn. Dat je lichtelijk gestoord bent als je geen sed/awk hebt geinstalleerd daargelaten.

quote:

Als je op je eigen PC wat moet doen kun je prima Perl gebruiken, wil je echter iets hebben dat zeker weten zonder dependencies (en dat is wel de crux natuurlijk) op een Unix-systeem werkt, dan moet je geen Perl gebruiken. In sommige situaties is Perl een onoverkoombare grote dependency. Ervan uitgaan dat als je voor een Unix-systeem code dat Perl er wel op aanwezig zal zijn is niet handig.

Hierover blijven we van mening verschillen. Tuurlijk zijn shell scripts wat makkelijker te porten naar een ander systeem. Maar aan de andere kant, ksh staat ook niet op alle machines en dus kan je ook niet zeggen dat een shellscript portable is (zelfde geldt voor zsh, bash, etc etc). Alleen als je sh compatible scripts maakt kun je zeggen dat het portable is.

Maar zoals gezegd, ik laat het hierbij. Ik ga een perl one-liner niet verdedigen. Gebruik het of niet. Portable of niet

verkeerde topic xD

quote:

Op zaterdag 6 oktober 2007 19:14 schreef slakkie het volgende:

[..]

Dat is natuurlijk onzin wat je nu zegt. Een Unix systeem hoeft helemaal geen sed/awk te hebben (en uiteraard hoeft perl ook ook niet geinstalleerd te zijn) om Unix te zijn. Dat je lichtelijk gestoord bent als je geen sed/awk hebt geinstalleerd daargelaten.

Je hebt hooguit een Unix-achtige als je geen sed of awk hebt.

quote:

Only systems fully compliant with and certified to the Single UNIX Specification qualify as "UNIX®"

En die Single UNIX specification bevat, je raadt het al, sed & awk.

verkeere topic 2

Al die moderne programmeertalen zoals perl, php en python, brrr. Ik hou het gewoon bij C.

quote:

Op zaterdag 6 oktober 2007 19:51 schreef thabit het volgende:
Al die moderne programmeertalen zoals perl, php en python, brrr. Ik hou het gewoon bij C.

als je het kan is het tof ja, maar het is zo lastig xD

lezen kan ik trouwens wel

quote:

Op zaterdag 6 oktober 2007 19:51 schreef thabit het volgende:
Al die moderne programmeertalen zoals perl, php en python, brrr. Ik hou het gewoon bij C.

Het hangt ervanaf wat je moet doen, maar ik verklaar je in veel gevallen voor gek. Python heeft bijvoorbeeld een heel fijne Scientific Python module, die je veel mogelijkheden van Matlab geeft. Dit is een stuk vriendelijker voor de programmeur om rap een programmaatje te maken dat je wat plotjes geeft, of wat enkele Matrixberekeningen uitvoert. Wil je dat in C doet zit je altijd met geheugenmanagement, pointers, en moeilijker libraries te knutselen.

quote:

Op zaterdag 6 oktober 2007 19:39 schreef Iblis het volgende:

En die Single UNIX specification bevat, je raadt het al, sed & awk.

sed voldoet aan de specificatie. Er staat nergens dat sed onderdeel moet uitmaken van het OS om Unix te zijn.

quote:

Only systems fully compliant with and certified to the Single UNIX Specification qualify as "UNIX®"

Maw, een systeem moet sed ondersteunen en andere applicaties die voldoen aan de Single UNIX Specification.
Dit wil zeggen dat sed zonder problemen moet werken als het geinstalleerd is.

quote:

Op zaterdag 6 oktober 2007 20:16 schreef slakkie het volgende:

[..]

sed voldoet aan de specificatie. Er staat nergens dat sed onderdeel moet uitmaken van het OS om Unix te zijn.

Volgens wie staat dat nergens?

quote:

POSIX Shell and Utilities

The system shall provide all the mandatory utilities in the Shell and Utilities volume of IEEE Std 1003.1-2001 with all the functional behavior described therein.

De definitie van shall wordt ook gegeven:

quote:

shall

For an implementation that conforms to IEEE Std 1003.1-2001, describes a feature or behavior that is mandatory. An application can rely on the existence of the feature or behavior.

For an application or user, describes a behavior that is mandatory.

quote:

Op zaterdag 6 oktober 2007 20:26 schreef Iblis het volgende:

Volgens wie staat dat nergens?

Je hebt gelijk, http://www.opengroup.org/onlinepubs/009695399/idx/fidx7.html bewijst mijn ongelijk.

Hallo allemaal
Ben al een tijdje geinteresseerd in Linux en heb het dan eindelijk Ubuntu eens geinstalleerd..
Alles werkt prima tot ik mijn draadloze netwerk wou installeren, dit lukt maar niet.
heb heel http://forum.ubuntu-nl.org/ afgezocht en ik kom er niet uit!
Ik heb een speedtouch 121g..
iemand een oplossing?

Wat is je probleem precies? Welke kaart heb je, wat zijn je instellingen?

quote:

Op dinsdag 9 oktober 2007 10:42 schreef bierbart het volgende:
Hallo allemaal
Ben al een tijdje geinteresseerd in Linux en heb het dan eindelijk Ubuntu eens geinstalleerd..
Alles werkt prima tot ik mijn draadloze netwerk wou installeren, dit lukt maar niet.
heb heel http://forum.ubuntu-nl.org/ afgezocht en ik kom er niet uit!
Ik heb een speedtouch 121g..
iemand een oplossing?

Als je gaat googlen vind je de ndiswrapper oplossing... al geprobeerd?

Hoe kan ik in ubuntu instellen dat al het verkeer naar een bepaalde address range over een ssh tunnel wordt gestuurd? Zeg maar, een soort VPN voor het geval dat ik een adres binnen de range benader? En dat dus voor smb, mail, http, ftp enzo?

quote:

Op dinsdag 9 oktober 2007 18:28 schreef Visitor.Q het volgende:
Hoe kan ik in ubuntu instellen dat al het verkeer naar een bepaalde address range over een ssh tunnel wordt gestuurd? Zeg maar, een soort VPN voor het geval dat ik een adres binnen de range benader? En dat dus voor smb, mail, http, ftp enzo?

Ik ben niet zo goed met Linux, maar ik wil wel een poging doen voor een globale indicatie.

Er is eigenlijk een tweetal mogelijkheden. Je kunt een SOCKS-proxy opzetten, of je kunt echt van een tun-device gebruik maken. Dit moet aan twee kanten opgezet worden.

Een SOCKS-proxy is vrij gemakkelijk, je typt:

ssh -D 8080 username@remote-host

In je browser kun je nu instellen dat-ie een proxy moet gebruiken. Dit is handmatig te doen, maar het is niet handig. Dat geef ik direct toe. Als het permanent moet zijn, is dit denk ik geen optie.

Anders moet je lokaal en remote een network-device aanmaken, tun0 en tun1 bijvoorbeeld, en dan ssh -w 0:1 username@remotehost doen. Dan moet je je firewall instellen dat een bepaalde IP-range over dat tunnel-device wordt gestuurd. Dit is een beetje poor-mans VPN. Want wat je wilt is eigenlijk gewoon VPN werk, en zeker als je het voor applicaties zo transparant wilt, ben je eigenlijk genoodzaakt een soort VPN op te zetten. Naar OpenVPN kijken zou dan ook een optie kunnen zijn.

[edit]
https://help.ubuntu.com/community/SSH_VPN lijkt wel wat voor je te zijn.