terminal-programme ausführen

[timoken]

ich habe lynx installiert. wie schaffe ich es, dass ich (um das programm zu starten) nicht den vollen pfadname "/usr/local/bin/lynx https://www.macuser.de" angeben muss sondern lediglich "lynx https://www.macuser.de"?

 

[dannycool]

einmalig:
echo 'export PATH=/usr/local/bin:$PATH' >> ~/.bashrc

 

[timoken]

unter ~/ liegt jetzt eine Datei namens ".bashrc" mit dem Inhalt "export PATH=/usr/local/bin:$PATH" aber einen effekt hat das nicht gehabt. wenn ich "lynx" eingebe kommt "-bash: lynx: command not found" :-(

 

[Saski]

Gibt's da nicht auch "/usr/bin"? Tu lynx einfach da rein. Diese "local"-Ordner sind eh bescheuert. Sind bei mir standardmäßig auf ".." gesymlinkt

 

[timoken]

statt .bashrc .bash_profile genommen. jetzt funzt es

 

[oneOeight]

Gibt's da nicht auch "/usr/bin"? Tu lynx einfach da rein. Diese "local"-Ordner sind eh bescheuert. Sind bei mir standardmäßig auf ".." gesymlinkt

die sind nicht bescheuert, die trennen von dir selbst installierte software von denen vom system installierten...

 

[ratti]

die sind nicht bescheuert, die trennen von dir selbst installierte software von denen vom system installierten...

Eben.

Bescheuert ist aber, daß Apple */local und /opt nicht mit in die diversen Suchpfade gepackt hat.

Gruß,
Ratti

 

[dannycool]

unter ~/ liegt jetzt eine Datei namens ".bashrc" mit dem Inhalt "export PATH=/usr/local/bin:$PATH" aber einen effekt hat das nicht gehabt. wenn ich "lynx" eingebe kommt "-bash: lynx: command not found" :-(

Aeh ja. Einmal danach bash neu starten bzw. neues Terminalfenster aufmachen, hat noch gefehlt.

 

[maceis]

...
Diese "local"-Ordner sind eh bescheuert. Sind bei mir standardmäßig auf ".." gesymlinkt

Das ist ja wohl oberbescheiden; dann funktioniert nämlich vieles gar nicht mehr.

...
Bescheuert ist aber, daß Apple */local und /opt nicht mit in die diversen Suchpfade gepackt hat.
...

Warum sollte Apple das tun, wo doch diese Verzeichnisse in der Standardinstallation gar nicht existieren?
Und wenn, dann müssten auch ~/bin, /local/bin, /usr/local/bin, /opt/local/bin (wird z. B. von darwinports verwendet),/sw/bin (fink) und /opt/bin mit in die Pfadvariable, oder nicht?
Nein, nein, das ist schon gut so, wie Apple das macht - was der User nicht aktiv einrichtet, geht erstmal nicht automatisch.
Wir sind ja nicht bei winzigweich ;-) (SCNR)

 

[ratti]

Warum sollte Apple das tun, wo doch diese Verzeichnisse in der Standardinstallation gar nicht existieren?
Und wenn, dann müssten auch ~/bin, /local/bin, /usr/local/bin, /opt/local/bin (wird z. B. von darwinports verwendet),/sw/bin (fink) und /opt/bin mit in die Pfadvariable, oder nicht?
Nein, nein, das ist schon gut so, wie Apple das macht - was der User nicht aktiv einrichtet, geht erstmal nicht automatisch.
Wir sind ja nicht bei winzigweich ;-) (SCNR)

Durch diese Voreinstellung funktioniert praktisch nichts, was man sich als Source saugt und selbst kompiliert. Das betrifft ja nicht nur $PATH, sondern auch so schöne Dinge wie PKGDIR oder LD_CONFIG.
Ich fände es sinnvoll, das System entsprechend vorzukonfigurieren und mit leeren Ordnern auszuliefern. /usr/local/bin und /opt/bin sind halt "üblich" und sinnvoll (Möglicherweise sogar in der LSB? Natürlich hat die für Apple keine Gültigkeit, aber es wäre halt schlau.).
~/bin ist da schon eher eine private Vorliebe, und /sw/bin soll dann gefälligst Fink selbst einrichten.

/local/bin ist Quaaaark.

Gruß,
Ratti

 

[timoken]

darauf bin ich auch selbst gekommen. hat aber ned funktioniert. der filename war falsch. muss .bash_profile statt .bashrc heißen.

Aeh ja. Einmal danach bash neu starten bzw. neues Terminalfenster aufmachen, hat noch gefehlt.

 

[maceis]

darauf bin ich auch selbst gekommen. hat aber ned funktioniert. der filename war falsch. muss .bash_profile statt .bashrc heißen.

Täusch Dich da nicht.
Die eine Datei wird von nur loginshells gelesen, die andere nur von nicht-loginshells.
Einzelheiten siehe
man bash
im Abschnitt "INVOCATION".

 

[maceis]

Durch diese Voreinstellung funktioniert praktisch nichts, was man sich als Source saugt und selbst kompiliert. Das betrifft ja nicht nur $PATH, sondern auch so schöne Dinge wie PKGDIR oder LD_CONFIG.
Ich fände es sinnvoll, das System entsprechend vorzukonfigurieren und mit leeren Ordnern auszuliefern.

Darüber ließe sich sicher trefflich streiten; das lassen wir natürlich
IMHO kann man einem User, der eine "Source saugt und selbst kompiliert", auch zutrauen, dass er Ordner anlegt, die PATH-Variable zweckmäßig setzt und --PREFIX=... benutzt. Leere Ordner halte ich persönlich für keine gute Idee.

/usr/local/bin und /opt/bin sind halt "üblich" und sinnvoll ...
~/bin ist da schon eher eine private Vorliebe, und /sw/bin soll dann gefälligst Fink selbst einrichten.

/local/bin ist Quaaaark.
...

Ansichtssache.
~/bin könnte man auch als "üblich" betrachten (oder auch nicht).
/local/bin und /usr/local/bin benutze ich persönlich um "gesaugte und selbst kompilierte" von selbst geschriebenen Programmen zu trennen.
Ist natürlich auch eine persönliche Vorliebe, aber eben weil es deren so viele unterschiedliche gibt, halte ich persönlich wenig von "auf Verdacht" vorkonfigurierten Umgebungen.

 

[ratti]

IMHO kann man einem User, der eine "Source saugt und selbst kompiliert", auch zutrauen, dass er Ordner anlegt, die PATH-Variable zweckmäßig setzt und --PREFIX=... benutzt. Leere Ordner halte ich persönlich für keine gute Idee.

Wenn's nur der Pfad wäre, würde ich mich da nicht so haben. Aber, wie gesagt, $PKGDIR und LD_CONFIG, Pfade für manpages, ... da kommt einiges Zusammen. Und dann ist es ja auch noch eine Frage der Reihenfolge: /usr/local/bin:$PATH, oder lieber $PATH:/usr/local/bin ?

Ehrlich gesagt - mir ist es öfter mal zu kompliziert, als daß ich es hinkriegen würde. Prefix ist ja nur ein kleiner Teil des ganzen.

~/bin könnte man auch als "üblich" betrachten (oder auch nicht).

Klar, was ist "üblich"...
~/bin steht für selbstkompilierte Software, die anderen Userns auf diesem System nicht zur Verfügung stehen sollen. Klassischer Einsatzzweck: Zum Beispiel Shared Server. Aber auf'm Desktop? Hmmm....

/local/bin und /usr/local/bin benutze ich persönlich um "gesaugte und selbst kompilierte" von selbst geschriebenen Programmen zu trennen.

Für /usr/local/bin: Jepp, dafür ist es da.

/usr/bin wären Programme, die beim Booten gebraucht werden, falls /usr auf einem Netzlaufwerk liegt und noch nicht greifbar ist. Da muss ich passen: Sowas ist mir noch nicht untergekommen. Aber was ist denn "/local/bin"?
Da hat aber einer seinen Arm ganz tief drin.

Ist natürlich auch eine persönliche Vorliebe, aber eben weil es deren so viele unterschiedliche gibt, halte ich persönlich wenig von "auf Verdacht" vorkonfigurierten Umgebungen.

Das ist richtig. Aber /usr/local ist ja *die* Voreinstellung für praktisch alles, was an freier Software so kreucht und fleucht. Wenigstens das wäre sehr sinnvoll. Zumal man ja auch nicht alles selbst compiliert - "File::Mac" ist so ein Beispiel, das wird für den CarbonCopyCloner benutzt. Wenn sich sowas auf die Existenz und Einbindung /usr/local/lib/perl58 verlassen könnte - wäre nicht schlecht. So, wie es jetzt ist, grätscht das ganze "perl -MCPAN -eshell" ins Leere.

Gruß,
Ratti

 

[maceis]

...
Und dann ist es ja auch noch eine Frage der Reihenfolge: /usr/local/bin:$PATH, oder lieber $PATH:/usr/local/bin ?

Da geht es doch schon los; nur der Benutzer kann wissen, was er möchte; Wäre das schon vorkonfiguriert, könnte man es wieder mal nur einem teil der Benutzer recht machen.

Klar, was ist "üblich"...
~/bin steht für selbstkompilierte Software, die anderen Userns auf diesem System nicht zur Verfügung stehen sollen. Klassischer Einsatzzweck: Zum Beispiel Shared Server. Aber auf'm Desktop? Hmmm....

Das ist jetzt Deine Definition; Andere untergliedern das evtl. nach anderen Kriterien und legen hier vielleicht den selbskompilierten vim und die selbstkompilierte zsh (jeweils neueste Version) rein, setzen den Pfad auf ~/bin:$PATH und erreichen damit, dass die neuen Versionen vor den vorinstallierten gefunden werden; für den Mitbenutzer (Familie, Uni etc.) bleibt aber alles wie gewohnt.

Für /usr/local/bin: Jepp, dafür ist es da.

Ich glaube, Du hast mich missverstanden; ich benutze zwei unterschiedliche verzeichnisse um selbsgeschriebene Programme von selbstkompilierten Fremdprogrammen zu trennen.

/usr/bin wären Programme, die beim Booten gebraucht werden, falls /usr auf einem Netzlaufwerk liegt und noch nicht greifbar ist. Da muss ich passen: Sowas ist mir noch nicht untergekommen.

Da komm ich nicht mit wenn /usr nicht verfügbar ist, wie soll man dann /usr/local benutzen können? Oder willst Du da opak drüber mounten?
Soweit ich weiss sollen unter OS X Netzwerkverzeichnisse unter /Network angelegt werden (bzw. deren mountpoints). IIRC geht das sogar automatische, wenn man mit hirarischen Netinfo-Domains arbeitet.

Aber was ist denn "/local/bin"?

Es soll Benutzer geben, die hier Ihre selbskompilierte Software speichern, da Sie der Meinung sind, dass /usr (UnixSystemResources
) nicht für UserSoftware benutzt werden soll (Ich würde es nicht so machen, aber wie gesagt: das ist nutzerabhängig)

Das ist richtig. Aber /usr/local ist ja *die* Voreinstellung für praktisch alles, was an freier Software so kreucht und fleucht.

Schon, aber nur als toplevel Verzeichnis.

"File::Mac" ist so ein Beispiel, das wird für den CarbonCopyCloner benutzt. Wenn sich sowas auf die Existenz und Einbindung /usr/local/lib/perl58 verlassen könnte - wäre nicht schlecht.

Es kann sich auf die Existenz von "/Library/Perl/5.8.1" verlassen, so wie andere Module auch (Allerdings erst, wenn es mal bei CPAN eingestellt wird )

So, wie es jetzt ist, grätscht das ganze "perl -MCPAN -eshell" ins Leere.

Kann ich nicht bestätigen, obwohl ich diese Methode (perl -MCPAN -e shell) inzwischen nicht mehr verwende, da ich mit "perl MAKEFILE.pl [Optionen]; make ;sudo make test; sudo make install;" mehr Kontrolle habe.

 

[ratti]

Da geht es doch schon los; nur der Benutzer kann wissen, was er möchte; Wäre das schon vorkonfiguriert, könnte man es wieder mal nur einem teil der Benutzer recht machen.

Allerdings würde /usr/local/bin im Pfad und als leerer Ordner nichts und niemandem etwas schaden. Das fände ich besser als der jetzige Zustand.

Das ist jetzt Deine Definition; Andere untergliedern das evtl. nach anderen Kriterien und legen hier vielleicht den selbskompilierten vim und die selbstkompilierte zsh (jeweils neueste Version) rein, setzen den Pfad auf ~/bin:$PATH und erreichen damit, dass die neuen Versionen vor den vorinstallierten gefunden werden; für den Mitbenutzer (Familie, Uni etc.) bleibt aber alles wie gewohnt.

Stimmt, an die Anwendung hatte ich gar nicht gedacht.

Soweit ich weiss sollen unter OS X Netzwerkverzeichnisse unter /Network angelegt werden (bzw. deren mountpoints). IIRC geht das sogar automatische, wenn man mit hirarischen Netinfo-Domains arbeitet.

Solche Festlegungen sind eher allgemeiner Natur als OS-X-spezifisch. Der Unterschied zwischen /bin und /usr/bin ist der, daß /bin fürs booten gebraucht wird, während /usr/bin Anfangs noch fehlen darf. Sonst könnte man ja auch alles gemeinsam nach /usr/bin kippen.

/Network/irgendwas ist ja keine Systemkomponente in dem Sinne, oder? Zumindest nicht n $PATH enthalten?

Zu /local/bin:

Es soll Benutzer geben, die hier Ihre selbskompilierte Software speichern, da Sie der Meinung sind, dass /usr (UnixSystemResources
) nicht für UserSoftware benutzt werden soll (Ich würde es nicht so machen, aber wie gesagt: das ist nutzerabhängig)

Kann natürlich jeder machen, wie er will - fände ich aber eher ungewöhnlich.
Üblich sind ja eigentlich die */local/*-Hierarchien für Eigenkompilate und /opt für "komisches Zeug" wie z.B. downgeloadete Fremdsoftware, die man einfach als Ordner "en bloc" irgendwo hinschieben muss.

Bei mir sieht es da so aus:
arkeia bin eclipse j2sdk1.4.2_04 man NetBeans3.6 RealPlayer viva

Aber /usr/local ist ja *die* Voreinstellung für praktisch alles, was an freier Software so kreucht und fleucht.

Schon, aber nur als toplevel Verzeichnis.

Das verstehe ich jetzt nicht?

Es kann sich auf die Existenz von "/Library/Perl/5.8.1" verlassen, so wie andere Module auch (Allerdings erst, wenn es mal bei CPAN eingestellt wird )

Dann mischt es sich aber mit anderen Dingen!

Guck mal hier:

@INC contains:
/etc/perl
/usr/local/lib/perl/5.8.4
/usr/local/share/perl/5.8.4
/usr/lib/perl5
/usr/share/perl5
/usr/lib/perl/5.8
/usr/share/perl/5.8
/usr/local/lib/site_perl
/usr/local/lib/perl/5.8.3
/usr/local/share/perl/5.8.3
.

Fünf mal "local".

Kann ich nicht bestätigen, obwohl ich diese Methode (perl -MCPAN -e shell) inzwischen nicht mehr verwende, da ich mit "perl MAKEFILE.pl [Optionen]; make ;sudo make test; sudo make install;" mehr Kontrolle habe.

Komm halt alles mit einem /usr/local-Prefix, ergo: Rennt nicht.
Die CPAN-Shell hat den Vorteil, daß sie automatisch Dependencies nachsaugen kann und Updates zu bereits existenten Modulen findet.

Gruß,
Ratti

 

[maceis]

Aber /usr/local ist ja *die* Voreinstellung für praktisch alles, was an freier Software so kreucht und fleucht.

Schon, aber nur als toplevel Verzeichnis.

Das verstehe ich jetzt nicht?

Damit wollte ich nur sagen, dass '/usr/local' im Pfad wenig bringt, wenn dann '/usr/local/bin'.
Bei Geschichten wie mysqld muss man ohnehin "nacharbeiten".

Es kann sich auf die Existenz von "/Library/Perl/5.8.1" verlassen, so wie andere Module auch (Allerdings erst, wenn es mal bei CPAN eingestellt wird )

Dann mischt es sich aber mit anderen Dingen!

Womit denn, außer mit anderen Perl Modulen?

Guck mal hier:

@INC contains:
/etc/perl
/usr/local/lib/perl/5.8.4
/usr/local/share/perl/5.8.4
/usr/lib/perl5
/usr/share/perl5
/usr/lib/perl/5.8
/usr/share/perl/5.8
/usr/local/lib/site_perl
/usr/local/lib/perl/5.8.3
/usr/local/share/perl/5.8.3
.

Fünf mal "local".

Bei mir sieht das so aus:
@INC contains:
/System/Library/Perl/5.8.1/darwin-thread-multi-2level
/System/Library/Perl/5.8.1
/Library/Perl/5.8.1/darwin-thread-multi-2level/Library/Perl/5.8.1
/Library/Perl
/Network/Library/Perl/5.8.1/darwin-thread-multi-2level
/Network/Library/Perl/5.8.1
/Network/Library/Perl

Kann ich nicht bestätigen, obwohl ich diese Methode (perl -MCPAN -e shell) inzwischen nicht mehr verwende, da ich mit "perl MAKEFILE.pl [Optionen]; make ;sudo make test; sudo make install;" mehr Kontrolle habe.

Komm halt alles mit einem /usr/local-Prefix, ergo: Rennt nicht.
Die CPAN-Shell hat den Vorteil, daß sie automatisch Dependencies nachsaugen kann und Updates zu bereits existenten Modulen findet.

Weiss schon;
Bei mir kennt die CPAN shell aber @INC (s. oben).
Vor einiger Zeit hatte ich beispielsweise Net::SSH:erl mit der CPAN shell installiert.
Das ist ein Modul mit sehr vielen Abhängigkeiten.
Hat problemlos geklappt.

 

[ratti]

Damit wollte ich nur sagen, dass '/usr/local' im Pfad wenig bringt, wenn dann '/usr/local/bin'.

Ja. Nein. Anders.

In $PATH gehört natürlich /usr/local/bin. Mit "/usr/local/" meine ich eigentlich das ganze Geraffel, was noch so dranhängt:
Das "man" auch in /usr/local/man sucht. Daß PKGDIR in /usr/local/include sucht. Libs können auch in der local-Struktur liegen. Und dann gibt es für root auch noch /usr/local/sbin.
Zu einer kompletten Unterstützung gehört ja etwas mehr als $PATH.

Das war eigentlich auch immer mein Problem: Wenn ich unter OS X was kompiliert habe, dann will ich es ja durchaus nach /usr/local/* haben. Dann ist es erstmal nicht im Pfad und nicht in den manpages.
Wenn ich dann, abhängig davon, das nächste Tool kompiliere, findet es seinen Kram nicht - bis hin zu Monstern wie $QTDIR... ich sehe mich fachlich außer Stande, alle Pfade in allen Build- und Systemtools zu ergänzen, wie ich sie von Linux her kenne. In meiner Verzeiflung habe ich sogar schonmal was nach /usr kompiliert. Grrr... %-)

Dann mischt es sich aber mit anderen Dingen!

Womit denn, außer mit anderen Perl Modulen?

Mit eben diesen.
Und mit den manpages.

Gruß,
Ratti

 

[maceis]

Dann mischt es sich aber mit anderen Dingen!

Womit denn, außer mit anderen Perl Modulen?

Mit eben diesen.

Also, da komm ich nicht mit.
In /Library/Perl liegt erstmal nichts (außer ein paar Kleinigkeiten, die dort auch hingehören); die Module, die mit Perl kommen, liegen in /System/Library/Perl/.
Wenn das stattdessen /usr/local/Perl/irgendwas wäre, würden sich halt da die selbstinstallierten Perl-Module mischen.
Wo ist bitte der Unterschied?

Und mit den manpages.

Da drin liegt nicht eine einzige manpage.
Was das angeht ist OS X tatsächlich broken, da die man pages von selbstinstallierten Modulen in / angelegt weren.
Ich lösch die immer, da man die nicht braucht (-> perldoc); wenn man die Doku unbedingt mit "man" ansehen will, muss man die halt verschieben; auch das überlebt man

 

[ratti]

Also, da komm ich nicht mit.
In /Library/Perl liegt erstmal nichts (außer ein paar Kleinigkeiten, die dort auch hingehören); die Module, die mit Perl kommen, liegen in /System/Library/Perl/.

Ah, das wusste ich nicht, dass der leer ist. Damit wäre er ja eigentlich gut geeignet. Aber ich nehme an, daß handgemachte Sachen nicht von alleine dort landen?

Dann bräucht man ja bloß einen Symlink in /usr/local, der die "üblichen" Verzeichnisse einfach dort hinlinkt, und man könnte aus dem Stand kompilieren.

Wenn das stattdessen /usr/local/Perl/irgendwas wäre, würden sich halt da die selbstinstallierten Perl-Module mischen.
Wo ist bitte der Unterschied?

Ich war davon ausgegangen, daß sich dort Apple-System-Module mit selbstgedrehten mischen. Das wäre ein Problem.
Alles, was Eigenbau ist, soll sich natürlich miteinander mischen.

Da drin liegt nicht eine einzige manpage.

Die gehören nach /usr/local/man, selbiges in den Suchpfad von man.

Was das angeht ist OS X tatsächlich broken, da die man pages von selbstinstallierten Modulen in / angelegt weren.
Ich lösch die immer, da man die nicht braucht (-> perldoc); wenn man die Doku unbedingt mit "man" ansehen will, muss man die halt verschieben; auch das überlebt man

Ich denke, es wäre einfach schön, wenn auf Apple-Systemen die Pfade bereits existieren würden, die als Defaults in den Sourcen schon drinstehen, und auch entsprechend eingebunden wären. Das wäre für alle Beteiligten am einfachsten. Bei vielen Linux-Distris sind das dann auch bloß Symlinks auf die alleinseligmachende Wunschstruktur der jeweilgen Distri. Natürlich kann man Apple nicht vorschreiben, sich an offene Standars zu halten - sinnvoll wäre es aber allemal.

Ob man darüber hinaus Pfade wie ~/bin einbindet, ist eigentlich eine ganz andere Frage - das hat mit "Defaults" nichts mehr zu tun. Ich fände aber auch das klug.

Gruß,
Ratti