[NUQ] Umgebungsvariablen mit Script erstellen?
Ottmar Ohlemacher
ich hätte gerne mal gewust, wieso ich keine Umgebungsvariable per
Skript erstellen kann...(also was ich fschla und wie es richtig geht).
In der bash Komandozeile geht
a=irgendwas (oder auch export a=irgendwas)
echo a$
irgendwas
Das geht also.
Wenn ich aber a=irgendwas in eine Datei schreibe, der Datei die
Aufführungsrechte gebe und sie ausführe, dann erfolgt keine Ausgabe
von 'irgendwas'.
Ähm...gibt es einen Befehl, mit dem sich nur die lokalen
Umgebungsvariablen darstellen lassen? Im Kofler fand ich nur Befehle,
mit denen alle Umgebungsvariablen - also die lokalen und die globalen
gemeinsam ausgeben ließen.
Ähm...afair bezieht sich der Begriff 'global' bei einer
Umgebungsvariablen darauf, das die Umgebungsvarialbe nicht nur auf der
shell sondern auch in den Prozessen und Unterprozessen dieser shell
gültig sind, hat also wohl nix damit zu tun, dass die
Umgebungsvariable auch in anderen Terminals gültig ist. Gibt es eine
Möglchkeit Variablen zu erstellen, die auf allen Terminals gültig
sind?
Danke für Info.
mfG Ottmar
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Hinweis: In der Vergangenheit wurde des öfteren bemängelt, dass die
Gruppen doucl* durch triviale Fragen für den anspruchsvollen Linuxer
ungeniesbar geworden seien. Da ich aber niemanden durch meine
trivialen Newbiefragen belästigen möchte kennzeiche ich meine Beiträge
in Zukunft durch den Tag [NUQ = New User Question]. Wer also keine
Lust auf New User Questions hat, den bitte ich auf [NUQ] zu filtern.
Danke.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
--
*HINWEIS* Die Mailadresse im Header läuft über einen restriktiv eingestelltes
Spamfilter, für dessen Funktion ich nicht garantieren kann. Sicherer und ohne
Spamfilter erreicht Ihr mich, wenn ihr die Punkte zu meinem Nachnamen ergänzt.
.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.
Martin Schmitz
> ich hätte gerne mal gewust, wieso ich keine Umgebungsvariable per
> Skript erstellen kann...(also was ich fschla und wie es richtig geht).
>
> In der bash Komandozeile geht
>
> a=irgendwas (oder auch export a=irgendwas)
>
> echo a$
>
> irgendwas
>
> Das geht also.
Unwahrscheinlich.
> Wenn ich aber a=irgendwas in eine Datei schreibe, der Datei die
> Aufführungsrechte gebe und sie ausführe, dann erfolgt keine Ausgabe
> von 'irgendwas'.
Wenn Du die Datei mit '. /pfad/zu/datei' einliest, dann geht das, weil
Deine Shell die Kommandos einliest und verarbeitet. Wenn Du die Datei
mit 'sh /pfad/zu/datei' aufrufst, dann gilt die Umgebung nur für die
/bin/sh, die die Datei verarbeitet. Analog dazu verläuft der Aufruf über
'#!/bin/sh'.
> Umgebungsvariable auch in anderen Terminals gültig ist. Gibt es eine
> Möglchkeit Variablen zu erstellen, die auf allen Terminals gültig
> sind?
Nein. Eine Shell-Variable kann zwangsläufig nur für eine Instanz einer
Shell gültig sein.
Martin
Adrian Knoth
> ich hätte gerne mal gewust, wieso ich keine Umgebungsvariable per
> Skript erstellen kann...(also was ich fschla und wie es richtig geht).
Du suchst source bzw. eval.
Um präzise so sein ist deine Frage allerdings nicht linuxtypisch,
aber ich will nicht schon in dieser Wunde bohren ;)
--
mail: a...@thur.de http://adi.thur.de PGP: v2-key via keyserver
I used to drive a Heisenbergmobile, but every time I looked at the
speedometer, I got lost. (old joke, seen in de.talk.jokes)
Adrian Knoth
> ich hätte gerne mal gewust, wieso ich keine Umgebungsvariable per
> Skript erstellen kann...(also was ich fschla und wie es richtig geht).
Du suchst source bzw. eval.
Um präzise zu sein ist deine Frage allerdings nicht linuxtypisch,
aber ich will nicht schon wieder in dieser Wunde bohren ;)
Martin Schmitz
> Ottmar Ohlemacher <> wrote:
>
>> ich hätte gerne mal gewust, wieso ich keine Umgebungsvariable per
>> Skript erstellen kann...(also was ich fschla und wie es richtig geht).
>
> Du suchst source bzw. eval.
'source' ist AFAIK ein bashismus, POSIX ist '.'.
Martin
Adrian Knoth
>>> ich hätte gerne mal gewust, wieso ich keine Umgebungsvariable per
>>> Skript erstellen kann...(also was ich fschla und wie es richtig geht).
>> Du suchst source bzw. eval.
> 'source' ist AFAIK ein bashismus, POSIX ist '.'.
ACK. Nicht portabel. zsh und csh können es auch, ksh nicht. Für
Ottmar ist das zwar egal, '.' ist aber besser.
Helmut Hullen
Du (adi) meintest am 28.12.04:
>>> Du suchst source bzw. eval.
>> 'source' ist AFAIK ein bashismus, POSIX ist '.'.
> ACK. Nicht portabel. zsh und csh können es auch, ksh nicht. Für
> Ottmar ist das zwar egal, '.' ist aber besser.
"source" ist aber besser erkennbar (beim Lesen des Skripts) als ".",
und da bleibt (bei Übertragung per Gedächtnis) der Zwischenraum zum
folgenden Dateinamen auch eher erhalten.
Ich habe es des öfteren erlebt, dass aus
. /pfad/zu/Datei
die geringfügig andere Zeile
./pfad/zu/Datei
wurde.
Viele Grüße!
Helmut
Alexander Skwar
> "source" ist aber besser erkennbar (beim Lesen des Skripts) als ".",
> und da bleibt (bei Übertragung per Gedächtnis) der Zwischenraum zum
> folgenden Dateinamen auch eher erhalten.
Unbestreitbar richtig. Allerdings hilft Dir source nicht viel,
wenn die verwendete Shell den Befehl "source" nicht kennt. Der
Portable Befehlt lautet nunmal ".".
Alexander Skwar
--
"He did decide, though, that with more time and a great deal of mental effort,
he could probably turn the activity into an acceptable perversion."
-- Mick Farren, _When Gravity Fails_
nto
________________________________________________________________________
Sabine 'Sani' Schulz
[...]
> Gibt es eine Möglchkeit Variablen zu erstellen, die auf allen
> Terminals gültig sind?
,----
|
| A login shell first reads commands from the files /etc/profile and then
| .profile if they exist. If the environment variable ENV is set on entry
| to a shell, or is set in the .profile of a login shell, the shell then
| reads commands from the file named in ENV. Therefore, a user should
| place commands that are to be executed only at login time in the
| .profile file, and commands that are executed for every shell inside
| the ENV file.
|
`----
,----
|
| /etc/profile: system-wide .profile file for the Bourne shell (sh(1))
| and Bourne compatible shells (bash(1), ksh(1), ash(1), ...).
|
`----
Ansonsten hat jeder (Benutzer, root) eine .bashrc, wo jeder sich seine
eigenen Umgebungsvariablen setzen kann (z. B."export EDITOR='emacs'".
Gruesse
Sabine
--
Die Energie, die wir brauchen,
bekommen wir aus dem Strom,
gegen den wir schwimmen.
Ottmar Ohlemacher
>* Ottmar Ohlemacher <2ohl> schrieb:
>
>> ich hätte gerne mal gewust, wieso ich keine Umgebungsvariable per
>> Skript erstellen kann...
>
>Das Thema ist nicht Linux-spezifisch. Die thematisch passende
>Newsgroup heißt de.comp.os.unix.shell.
Danke für den Hinweis - werde ich dann zukünftig in der thematisch
passenden Gruppe fragen....
...obwohl...Shells, Skripte und Umgebungsvariabelen etc werden in fast
jedem meiner Linuxbücher thematisiert....
>
>> Hinweis: In der Vergangenheit wurde des öfteren bemängelt,
>[...]
>
>Was ist denn das für ein Käse? Wenn überhaupt, dann gehört sowas in
>die maximal vier Zeilen lange Signatur.
Nein - wieso - eine Signatur hab ich bereits und Käse ist das ganze
auch nicht. Das aber hier auszudiskutieren wäre wohl ein totales
Off-Topic, wenn du aber trotzdem wissen willst, warum das kein Käse
ist, dann schlage eine thematisch passende Gruppe vor und fuppe
dorthin.
mfG Ottmar
Heike C. Zimmerer
> * Ottmar Ohlemacher <2ohl> schrieb:
>
>> Hinweis: In der Vergangenheit wurde des öfteren bemängelt,
> [...]
>
> Was ist denn das für ein Käse?
Ämm ... so wie ich verstanden habe, ist das etwa so: Ottmar ist seit
einiger Zeit auf der Suche nach einer Möglichkeit, seine Gedanken
auszubreiten, ohne dass jemand kommt und sagt, er labere Mist. Diese
bösen Giftnudeln fasst er unter dem Begriff "Regulars" zusammen, ihr
armes Opfer (also sich) als "Newbie". Ich schätze seine Chancen aber
als eher schlecht ein, denn er labert halt wirklich ziemlich viel
Mist ...
Nur so 'n Eindruck.
Gruß,
Heike
Mathias Pohl
[NUQ or NOTNUQ]
> Ämm ... so wie ich verstanden habe, ist das etwa so: Ottmar ist seit
> einiger Zeit auf der Suche nach einer Möglichkeit, seine Gedanken
> auszubreiten, ohne dass jemand kommt und sagt, er labere Mist.
Hat ihn denn schon jemand auf die Möglichkeit eines Blogs hingewiesen?
Gruß,
Mathias
Anton Bachmeier
Kann es sein, dass die Toleranz _einiger_ "Regulars" dem "Mist von
Newbies" gegenüber umgekehrt proportional zu ihrer Erfahrung mit Linux ist?
Nur so 'n Eindruck.
Gruß
Toni
--
_________________________________________________________
Obige Mailadresse dient nur zur Vernichtung von lästigem
Spam.
Mails an mich persönlich senden an a.bac bei gmx.de
Ottmar Ohlemacher
>* Ottmar Ohlemacher <2ohl> schrieb:
>
>> ...obwohl...Shells, Skripte und Umgebungsvariabelen etc werden in
>> fast jedem meiner Linuxbücher thematisiert....
>
> ... und in Solaris-, FreeBSD-, OpenBSD-, NetBSD-, AIX-, HP UX-,
> Irix-, Tru64 UNIX-, Mac OS X-, BeOS-, Amiga-Büchern ...
>
Na gut....bis auf ein paar wenige Unixbücher kann ichs nicht
beurteilen.
Anton Bachmeier
> * Anton Bachmeier <no_spam...@freenet.de> schrieb:
>
>
>>Nur so 'n Eindruck.
>
>
> Ich habe den Eindruck, dass Du Ottmar Postings, die in den letzten
> acht Wochen u.a. in de.comp.os.unix.discussion und
> de.comp.os.unix.linux.misc veröffentlicht worden sind, gar nicht
> kennst. :->
>
> Gruß, Heiko
Nun habe ich vor meiner Antwort bei ...discussion mal nachgeschaut. Da
ich die Gruppe nicht abonniert hatte, habe ich nur die letzten 500
Headerzeilen geholt und bin sofort über eine Diskussion Gurus-Newbies
gestolpert.
Interessant.
Das müssen wir jetzt hier sicher nicht wiederholen.
Für mich sehe ich das so: selbst wenn er gefragt hätte, warum die
Suse-Schachtel grün ist, halte _ich_ mich an die Regeln einer
grundsätzlichen Höflichkeit. Und ich sehe auch keinen Grund, von dem
alten Spruch, dass es keine dummen Fragen, sondern nur dumme Antworten
gibt, abzuweichen.
Ich kann durchaus nachvollziehen, dass es dem einen oder anderen auf den
Senkel geht, als Handbuchersatz dienen zu sollen. Wenn man sich nach der
fünften Frage an den Kopf langt und stöhnt, warum denn der Id..t nicht
endlich mal im Handbuch nachschaut. Trotzdem sollte man sich soweit im
Griff haben, dann eben einfach den Thread zu ignorieren. Soviel Zeit
kostet das nun auch wieder nicht.
Ich vorschlagen, hier abzubrechen und das Thema soweit zu beerdigen.
Ottmar Ohlemacher
>* Anton Bachmeier <no_spam...@freenet.de> schrieb:
>
>> Und ich sehe auch keinen Grund, von dem alten Spruch, dass es keine
>> dummen Fragen, sondern nur dumme Antworten gibt, abzuweichen.
>
>Es gibt durchaus dumme Fragen. Im Kontext des Usenets heißt das:
>Fragen, die sich der Fragesteller innerhalb kürzester Zeit selbst
>hätte beantworten können, sind "dumm".
Dieses, deine obige Formulierung, hat irgend etwas Fieses, und zwar
"Fragen, die sich der Fragesteller innerhalb kürzester Zeit selbst
_hätte_ beantworten können", -
- diesses "hätte beantworten können"....da fehlt was, und zwar, wenn
der Fragesteller gewußt hätte, wo er hätte nachlesen sollen.
Das hat er aber nicht, ansonsten hätte er nicht gefragt.
Logisch bis hierher?
Das Fiese daran ist der Vorwurf, welche den Fragesteller abkanzelt und
disqualifiziert.
Der Antwortgeber erhöht sich damit auf kosten des Fragestellers in
ungeahnte Höhen, weil er ja die Antwort kennt, weil er auch die Plätze
kennt, wo er nachgucken müßte - das muss der Antwortgeber ja auch noch
nicht einmal garnicht, weil er ja die Antwort sowieso kennt.
Von daher gibt es eben keine dummen Fragen, sondern nur dumme
Antworten.
Dumme Antworten, die immer wieder Anlaß zu Flames sind.
Statt dem Fragesteller weiterzuhelfen - sich gegebenenfalls intuitiv
dem Niveau des Fragestellers anzupassen, ist es in bestimmten Gruppen
chic, durch möglichst ein- oder zweisilbige Antworten dem Fragesteller
zu signalisieren, dass seine Frage, sein Anliegen und/oder seine
Person keine umfangreichere Antwort verdient und dass er in einer
bestimmten Gruppe nicht willkommen ist.
Mag sein, dass bei fortgeschritteneren Usern ein einziges Stichwort
ausreicht, um sich selbst weiterzuhelfen, häufig ist es jedoch so,
dass ein einziges Stichwort einem Anfänger nicht ausreicht, um sich
weiterzuhelfen.
Nein - ich komme immer mehr zu der Überzeugung, dass der Vater des
Vorwurfs, jemand stelle dumme Fragen, eine Mischung ist, aus dem
Überdruss vor Fragen, die den Antwortgeber langweilen und einer
gewissen Selbstsucht, in dem sich der Antwortgeber erhöht in dem er
den Fragesteller erniedrigt.
Um sich aber vor den sog. dummen oder langweiligen Fragen zu schützen,
vielleicht auch als Alibi oder als Rechtfertigung, um jemanden
anzuflämen, schwellen die FAQs immer weiter an, damit bloß keiner eine
Frage zum 2. Mal stellt - und wenn, dann will man wenigstens eine
Handhabe haben, um den Fragesteller als DAU hinzustellen - er hätte ja
auch in der FAQ nachlesen können, oder Google anschmeißen können
oder...wo auch immer nachgucken können.
Hätte ein Fragesteller aber vermutet oder gewußt, dass er die Antwort
auf seine Frage in der FAQ oder über Googel oder wo auch immer hätte
finden können, dann hätte er die Frage nicht gepostet, sondern gleich
da nachgeschaut, wo er eine für ihn angemessene Antwort gefunden
hätte.
So findet man denn auch immer wieder Fragen, die mit der Einleitung
beginnen: "Ich hab jetzt schon 1 Stunde rumgegoogelt, die FAQ
durchgesucht und im $Fachbuch hab ich auch nix gefunden...", weil die
Leute ansonsten Flames und dummen Antworten befürchten.
Soviel zum Klima in bestimmten Gruppen, welches ich als alles andere
als angenehm empfinde.
Letztendlich stellt sich denn die Frage nach dem Verständnis und
danach, was denn eine Newsgroup eigentlich ist oder was sie nicht ist
- und vor allem, wer das Recht hat, diese Definition zu treffen.
Nach meiner übergreifenden und wertneutralen Definition ist eine
Newsgroup in erster Linie mal eine Kommunikationsplattform - nicht
mehr und nicht weniger. Alles weitere, was oder wie die
Kommunikationsplattform ist, bestimmen die Nutzer und der Gemeinsinn
dieser Kommunikationsplattform namens "Newsgroup" selbst.
Und imho hat auf einer solchen Kommunikationsplattform, die für Nutzer
unterschiedlichen Niveaus ausgelegt ist, niemand das Recht, die Fragen
eines anderen als zu trivial oder als zu dumm oder was auch immer zu
disqualifizieren. Wenn er (der Spezialist) nun aber glaubt, auf eine
Frage nicht antworten zu wollen, dann möge er das tun, er möge dann
aber auch durch sein passives Verhalten so fair sein, dass er anderen
Antwortgebern und dem Fragesteller selbst die Chance zu einer
sinnvollen Antwort ermöglicht.
Wenn aber die Situation so ist, dass in einer Gruppe
hochqualifizierte- und weitgebildete Spezialisten mit Anfängern
zusammentreffen, so beinhaltet dieses ein gewisses Konfliktpotential.
Dieses äußert sich in den immer wieder auflodernden Flamethreads, in
dem ein _Teil_ der Spezialisten sich von den Anfängerfragen genervt
fühlen und ein enstprechend negatives Antwortverhalten an den Tag
legen, wogegen sie die Betroffenen natürlich wehren.
Das führt entweder zu den allseits bekannten Flamethreads und/oder
dass ein bestmmter Anwenderkreis eben genau diese Gruppen meiden, in
denen "ein scharfer Wind weht".
Beides ist ein unbefriedigender Zustand.
Mein Vorschlag wäre auch weiterhin eine Aufteilung der Fachgruppen in
unterschiedliche Niveaus, wodurch auf der einen Seite der Anfänger die
Möglichkeit erhält, unbefangen seine Anfängerfragen zu artikulieren
und gleichzeitig der Spezialist die Möglichkeit, sich in den für ihn
interessanten Niveauvollen Gruppen zurückzuziehen und sich vor den für
ihn uninterssanten Nebiefragen zu schützen.
Beiden Anwendergruppen - Spezialisten wie Anfängern - bliebe es
natürlich vorbehalten, nach Bedarf und Lust und Laune die jeweils
anderen Gruppen zu frequentieren.
x-Post de.comp.os.unix.linux und de.soc.netzkultur.umgangsformen
f'up2 de.soc.netzkultur.umgangsformen
mfg Ottmar
Juergen Ilse
Anton Bachmeier <no_spam...@freenet.de> wrote:
> Ich kann durchaus nachvollziehen, dass es dem einen oder anderen auf den
> Senkel geht, als Handbuchersatz dienen zu sollen. Wenn man sich nach der
> fünften Frage an den Kopf langt und stöhnt, warum denn der Id..t nicht
> endlich mal im Handbuch nachschaut. Trotzdem sollte man sich soweit im
> Griff haben, dann eben einfach den Thread zu ignorieren. Soviel Zeit
> kostet das nun auch wieder nicht.
Nein, beim besten Willen nicht. Das erste mal versucht man noch zu
helfen (moeglichst in Form von Hilfe zur Selbsthilfe), auch beim
zweiten mal wird i.d.R. weder unfreundlich noch sonderlich ungeduldig
reagiert, aber irgendwann sollte ein Fragesteller mal begriffen haben,
wie er sich selbststaendig informieren kann ... Wenn dieses Stadium
erreicht ist, laesst die Geduld nun mal nach. Es ist dann auch sinn-
voll, recht deutlich zu sagen, was man von ihm haelt: zum einen, damit
derjenige nicht taeglich mit der selben Frage (und evt. Gejammer wie
"weiss das denn wirklich keiner") hier aufschlaegt sondern mitbekommt,
wie sehr er seine Chancen auf brauchbare Antworten verspielt hat, zum
anderen, damit andere Neulinge ihn als das wahrnehmen, als das ihn
auch andere sehen: als abschreckendes Beispiel fuer mangelnde Lern-
bereitschaft. Wenn das nicht passiert, ist die Chance gross, dass das
Niveau der Gruppe in kurzer Zeit soweit absinkt wie damals in dcouln
(bevor die Gruppe geloescht wurde) womit sie dann fuer nahezu alle
endgueltig unbrauchbar wuerde (auch wenn das vielleicht nicht jeder
sofort einsehen wuerde ...).
Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)
Anton Bachmeier
> Hallo,
>
Hallo Juergen, ein gutes Neues Jahr!
Sag mal, was machst du Silvester um diese Zeit?
Ich war zwar beim Jahreswechsel 1999/2000 dabei und durfte arbeiten,
aber ansonsten würde mir um diese Zeit nicht einfallen, den PC
einzuschalten.
> Anton Bachmeier <no_spam...@freenet.de> wrote:
>
>>Ich kann durchaus nachvollziehen, dass es dem einen oder anderen auf den
>>Senkel geht, als Handbuchersatz dienen zu sollen. Wenn man sich nach der
>>fünften Frage an den Kopf langt und stöhnt, warum denn der Id..t nicht
>>endlich mal im Handbuch nachschaut. Trotzdem sollte man sich soweit im
>>Griff haben, dann eben einfach den Thread zu ignorieren. Soviel Zeit
>>kostet das nun auch wieder nicht.
>
>
> Nein, beim besten Willen nicht.
Ist mir jetzt nicht ganz klar, worauf sich dieser Satz bezieht. Auf "man
sich soweit im Griff haben"?
Das erste mal versucht man noch zu
> helfen (moeglichst in Form von Hilfe zur Selbsthilfe), auch beim
> zweiten mal wird i.d.R. weder unfreundlich noch sonderlich ungeduldig
> reagiert, aber irgendwann sollte ein Fragesteller mal begriffen haben,
> wie er sich selbststaendig informieren kann ... Wenn dieses Stadium
> erreicht ist, laesst die Geduld nun mal nach. Es ist dann auch sinn-
> voll, recht deutlich zu sagen, was man von ihm haelt:
Also korrigiere mich, wenn ich mich irre. Aber gerade in deinen Postings
habe ich so etwas nicht in Erinnerung. Du schreibst recht sachlich und
entsprechende "Spitzen" kommen vielleicht in einem Nebensatz vor.
Kann mich jetzt natürlich täuschen, das schiebe ich dann auf den
Neujahrskater:-) Aber irre ich mich nicht, dann bist du doch selber
gerade ein Beispiel dafür, dass man durchaus einen Grundlevel an
Höflichkeit und Toleranz einhalten kann.
zum einen, damit
> derjenige nicht taeglich mit der selben Frage (und evt. Gejammer wie
> "weiss das denn wirklich keiner") hier aufschlaegt sondern mitbekommt,
> wie sehr er seine Chancen auf brauchbare Antworten verspielt hat, zum
> anderen, damit andere Neulinge ihn als das wahrnehmen, als das ihn
> auch andere sehen: als abschreckendes Beispiel fuer mangelnde Lern-
> bereitschaft. Wenn das nicht passiert, ist die Chance gross, dass das
> Niveau der Gruppe in kurzer Zeit soweit absinkt wie damals in dcouln
> (bevor die Gruppe geloescht wurde) womit sie dann fuer nahezu alle
> endgueltig unbrauchbar wuerde (auch wenn das vielleicht nicht jeder
> sofort einsehen wuerde ...).
>
> Tschuess,
> Juergen Ilse (jue...@usenet-verwaltung.de)
Was mit dcouln passierte, kann ich nicht beurteilen. Mag ja auch sein,
dass mir noch einiges an Erfahrung im Usenet fehlt und ich in der
Zukunft auch anders urteilen werde. Ob eine Newsgroup der geeignete Ort
ist, andere zu einem der Allgemeinheit (wer ist das hier in dieser
Gruppe?) wohlfeilen Lernverhalten zu erziehen, bezweifle ich.
Hier und heute plädiere ich für mehr Toleranz auch den sog. dummen
Fragen gegenüber. Das Thema ist einfach zu subjektiv, um eine
vernünftige zielführende Diskussion zu führen. Jeder urteilt anders über
eine Frage, für den einen ist sie dumm, für den anderen schon zu hoch.
Wer ist nun der Ausschlaggebende?
Ich bestreite nicht, dass es sicher einige gibt, die einfach zu faul
sind, im Handbuch oder anderswo nachzuschauen und sofort ins Usenet
posten. Aber die gibt es garantiert in jeder Gruppe. Hier scheint das
allerdings ein größeres Problem zu sein, als anderswo.
Ottmar führt eine Reihe von Beispiel-Gruppen an, in denen der Umgang mit
Neulingen nicht so "rauh" ist, wie hier. Ohne dies in diesen Gruppen
nachzuprüfen deckt sich das auch in etwa mit meiner Erfahrung. Da sollte
man sich doch fragen, warum? Dass hier die Neulinge dümmer sind, als in
bspw. einer Windows-Gruppe glaube ich nicht (eher im Gegenteil :-) ),
also suche ich die Ursache woanders.
Dass es Gruppen gibt, in denen es noch weit rüpelhafter zu geht, darf
nicht angeführt werden. Fehlverhalten anderer entschuldigt nicht die
eigenen Fehler ("Nur weil mein Nachbar seine Kinder halb tot schlägt,
darf ich nicht meine Kinder "nur" grün und blau prügeln").
Juergen Ilse
Anton Bachmeier <no_spam...@freenet.de> wrote:
> Juergen Ilse schrieb am 01.01.2005, 01:48 Uhr:
> Hallo Juergen, ein gutes Neues Jahr!
> Sag mal, was machst du Silvester um diese Zeit?
> Ich war zwar beim Jahreswechsel 1999/2000 dabei und durfte arbeiten,
> aber ansonsten würde mir um diese Zeit nicht einfallen, den PC
> einzuschalten.
Dank starker Erkaeltung bin ich im Bett geblieben und habe nicht
gefeiert. Den Laptop kann ich auch im B ett bedienen ...
>> Anton Bachmeier <no_spam...@freenet.de> wrote:
>>>Ich kann durchaus nachvollziehen, dass es dem einen oder anderen auf den
>>>Senkel geht, als Handbuchersatz dienen zu sollen. Wenn man sich nach der
>>>fünften Frage an den Kopf langt und stöhnt, warum denn der Id..t nicht
>>>endlich mal im Handbuch nachschaut. Trotzdem sollte man sich soweit im
>>>Griff haben, dann eben einfach den Thread zu ignorieren. Soviel Zeit
>>>kostet das nun auch wieder nicht.
>> Nein, beim besten Willen nicht.
> Ist mir jetzt nicht ganz klar, worauf sich dieser Satz bezieht. Auf "man
> sich soweit im Griff haben"?
Auf das "ignorieren des Threads". Die Gruende habe ich weiter unten
genannt.
> Das erste mal versucht man noch zu
>> helfen (moeglichst in Form von Hilfe zur Selbsthilfe), auch beim
>> zweiten mal wird i.d.R. weder unfreundlich noch sonderlich ungeduldig
>> reagiert, aber irgendwann sollte ein Fragesteller mal begriffen haben,
>> wie er sich selbststaendig informieren kann ... Wenn dieses Stadium
>> erreicht ist, laesst die Geduld nun mal nach. Es ist dann auch sinn-
>> voll, recht deutlich zu sagen, was man von ihm haelt:
> Also korrigiere mich, wenn ich mich irre. Aber gerade in deinen Postings
> habe ich so etwas nicht in Erinnerung. Du schreibst recht sachlich und
> entsprechende "Spitzen" kommen vielleicht in einem Nebensatz vor.
Das mag daran liegen, dass ich oftmals etwas mehr Geduld aufbringe
als viele andere Regulars. Es liegt nicht daran, dass ich deren
Verhalten fuer voellig unverstaendlich halten wuerde ...
> Was mit dcouln passierte, kann ich nicht beurteilen.
Der Thread mit der Diskussion um die Loeschung ist bei google archiviert.
IIRC umfasste er so um die 20000 Postings in dang (und den groessten Teil
davon hatte ich wohl damals auch gelesen ...).
> Mag ja auch sein, dass mir noch einiges an Erfahrung im Usenet fehlt
> und ich in der Zukunft auch anders urteilen werde. Ob eine Newsgroup der
> geeignete Ort ist, andere zu einem der Allgemeinheit (wer ist das hier
> in dieser Gruppe?) wohlfeilen Lernverhalten zu erziehen, bezweifle ich.
Ich nicht.
> Hier und heute plädiere ich für mehr Toleranz auch den sog. dummen
> Fragen gegenüber. Das Thema ist einfach zu subjektiv, um eine
> vernünftige zielführende Diskussion zu führen. Jeder urteilt anders über
> eine Frage, für den einen ist sie dumm, für den anderen schon zu hoch.
> Wer ist nun der Ausschlaggebende?
Ich beurteile das nicht anhand des "Niveaus" der Frage sondern z.B.
anhand dessen, wie schwer oder leicht sich die Antwort auch auf anderem
Wege haette finden lassen. Wenn eine Frage in der FAQ beantwortet wird,
ist es unhoeflich, sie trotzdem in der Gruppe zu stellen. Das lesen der
FAQ (und bei der de.comp.os.unix.linux.* Hierarchie der .infos-Gruppe)
wird i.a. *vorausgesetzt* und das sollte wirklich niemanden ueberfordern.
Wer trotzdem vorzieht, andere mit seinen Fragen zu nerven weil er sich
auf diese Weise eine schnellere Antwort erhofft, ist *sehr* unhoeflich
und darf sich ueber entsprechende (auch sehr unhoefliche) Reaktionen
nicht wirklich wundern ...
> Ich bestreite nicht, dass es sicher einige gibt, die einfach zu faul
> sind, im Handbuch oder anderswo nachzuschauen und sofort ins Usenet
> posten.
Ja, und gegen die richtet sich in erster Linie die Kritik.
> Aber die gibt es garantiert in jeder Gruppe. Hier scheint das
> allerdings ein größeres Problem zu sein, als anderswo.
Hier ist es gelegentlich sogar so, dass jemand einfach *behauptet* schon
alle anderen Quellen konsultiert zu haben (obwohl das *nachweislich*
*nicht* stimmt), nur um solchen Vorwuerfen zu entgehen (und er beschwert
sich dann evt. noch ueber die nicht gerade zartfuehlenden Antworten,
wenn der Schwindel auffliegt oder er versucht sich zu verteidigen indem
er weiterhin behauptet "aber ich habe wirklich alles gelesen und nirgends
stand die Antwort" obwohl seine Luege bereits entlarvt wurde ...).
Ja, ich habe so etwas schon erlebt, nei ich war nicht begeistert davon.
> Ottmar führt eine Reihe von Beispiel-Gruppen an, in denen der Umgang mit
> Neulingen nicht so "rauh" ist, wie hier. Ohne dies in diesen Gruppen
> nachzuprüfen deckt sich das auch in etwa mit meiner Erfahrung. Da sollte
> man sich doch fragen, warum? Dass hier die Neulinge dümmer sind, als in
> bspw. einer Windows-Gruppe glaube ich nicht (eher im Gegenteil :-) ),
> also suche ich die Ursache woanders.
Das fachliche Niveau in manchen anderen Gruppen ist mit "unterirdisch
niedrig" noch fast beschoenigend umschrieben. Ich lege keinen besonderen
Wert darauf, dass sich die Linux- (oder die anderen unix-) Gruppen in die
selbe Richtung entwickeln ...
Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)
Helmut Waitzmann
Ottmar Ohlemacher <2ohl......r@web.de> writes:
>ich hätte gerne mal gewust, wieso ich keine Umgebungsvariable per
>Skript erstellen kann...(also was ich fschla und wie es richtig geht).
>
>In der bash Komandozeile geht
>
>a=irgendwas (oder auch export a=irgendwas)
>
>echo a$
>
>irgendwas
>
>Das geht also.
>
>Wenn ich aber a=irgendwas in eine Datei schreibe, der Datei die
>Aufführungsrechte gebe und sie ausführe, dann erfolgt keine Ausgabe
>von 'irgendwas'.
Du meinst folgendes (ich rücke alles 6 Zeichen ein und numeriere jede
Zeile)?
So sieht das Skript "Datei" aus:
---Schnipp---
1 #!/bin/bash
2 a=irgendwas
---Schnapp---
Es hat für Dich mindestens die Zugriffsrechte "Lesen" und "Ausführen".
So rufst Du es auf:
3 ./Datei
Hier erwartest Du die Ausgabe »irgendwas«:
4 echo a$
Sind meine Annahmen soweit richtig?
Zunächst: Du meinst vermutlich statt Zeile 4 eher
4.1 echo $a
, besser:
4.2 echo "$a"
, richtig? (Sei mir nicht böse. Aber für präzise Hilfe ist
absolut buchstabengetreue Schilderung Deiner Frage nötig, sonst kriegst
Du nur zwar korrekte, Dir aber nicht helfende Antworten.) Mit »a$«
kommt kein (mir bekanntes) Shell auf die Idee, nach einer
(Shell-)Variablen Namens »a« zu suchen, mit »"$a"« die meisten Shells
-- vermutlich alle -- hingegen sehr wohl.
Bemerkungen:
Du wirst oft »$a« statt »"$a"« lesen (auch von erfahrenen Shell-Nutzern).
Das ist gefährlich, weil dann Leerraum (Leerstellen, tabulatoren,
Zeilenwechsel) vom Bourne Shell oder bash genutzt werden, um die
Variablenwerte am Leerraum zu zerteilen, was nur selten gewünscht wird.
Genaueres steht auch hier in den manual pages.
Schau genau hin: In Zeile 3 kommt hinter dem "." kein Leerzeichen,
sondern sofort der "/".
>Ähm...gibt es einen Befehl, mit dem sich nur die lokalen
>Umgebungsvariablen
Vorsicht: Umgebungsvariable sind immer lokal, es gibt keine anderen
(s.u.).
>darstellen lassen?
Ja. Um die Umgebungsvariable a darstellen zu lassen, startest
Du das Programm "printenv" mit dem Parameter "a":
printenv a
. Mehr zu den Umgebungsvariablen und zum Programm "printenv" siehe
unten.
Du meinst aber eventuell Shell-interne Variablen. Mehr zu denen am Ende
dieses Beitrags.
>Im Kofler fand ich nur Befehle, mit denen alle Umgebungsvariablen - also
>die lokalen und die globalen gemeinsam ausgeben ließen.
Spricht der Kofler wirklich von zwei Sorten Umgebungsvariablen: den
lokalen und den globalen?
>Ähm...afair bezieht sich der Begriff 'global' bei einer
>Umgebungsvariablen darauf, das die Umgebungsvarialbe nicht nur auf der
>shell sondern auch in den Prozessen und Unterprozessen dieser shell
>gültig sind,
Jein. Der Begriff "global" ist ungeschickt gewählt, denn es steckt keine
globale Gültigkeit sondern ein anderes Konzept dahinter. Es wirkt sich
nur häufig scheinbar so aus (s.u.).
>hat also wohl nix damit zu tun, dass die Umgebungsvariable auch in
>anderen Terminals gültig ist.
Genau. Es hat nichts damit zu tun.
Genug der Vorrede. Bei den Umgebungsvariablen handelt es sich um
Variablen samt den ihnen jeweils zugewiesenen Werten, die in der
sog. Prozessumgebung (process environment) festgehalten werden. Und
jetzt kommt's:
Jeder Prozess hat seine eigene Prozessumgebung. Damit sind
Umgebungsvariable automatisch nie global, sondern jeder Prozess hat seine
eigenen Variablen.
Wann immer ein Prozess einen Kindprozess bekommt, erhält das Kind in
seiner eigenen Prozessumgebung einen gleichen Satz Variabler mit den
gleichen Werten wie die Umgebungsvariablen im Elternprozess: Die
Variablen und ihre Werte werden also kopiert, nicht geteilt. Danach kann
sowohl das Elternteil als auch das Kind jeweils mit den eigenen Variablen
anstellen, was es will: Es kann die Werte ändern, Variable löschen oder
neue erzeugen. Die Variablen des anderen bekommen davon nichts mit!
Du siehst also dreierlei:
(1.) Umgebungsvariable sind nicht global, denn jeder Prozess hat seine
eigenen.
(2.) Für jeden Prozess ist die Startumgebung immer die, die er bei der
Geburt vom Elternteil erhalten hat. Beide, Eltern- und Kindprozess,
können danach unabhängig von einander jeweils ihre eigenen
Umgebungsvariablen beliebig ändern, müssen es aber nicht, sondern
können sie auch lassen, wie sie sind.
(3.) Kein Prozess kann Umgebungsvariablen eines anderen Prozesses ändern,
erzeugen oder löschen.
Und nun ist es so, dass die meisten Prozesse ihre Umgebungsvariablen
nicht ändern. Daher rührt der Eindruck, die Umgebungsvariablen seien
global. Ein Beispiel dafür ist ein das Programm "printenv" ausführender
Prozess.
Auch das Shell ist natürlich ein Prozess und hat seine eigene
Prozessumgebung; und die Kinder, die es erzeugt, erhalten eine Kopie
davon.
Nach dem unter (3.) Gesagten musst Du also, wenn Du willst, dass ein
Shell eine neue Umgebungsvariable "a" bekommt, es veranlassen, sich
selbst eine zu machen. Du kannst dazu keinen anderen Prozess, etwa ein
von ihm erzeugtes Kind, benutzen.
Wie Du oben schreibst, geht das beim bash mit
export a=irgendwas
. Ich empfehle Dir, Dir gleich statt dessen lieber
a=irgendwas && export a
anzugewöhnen. Das hat denselben Effekt, tut aber im Gegensatz zu
export a=irgendwas
auch beim Bourne Shell (sh). Deine Kommandos bleiben dann kompatibel mit
dem traditionellen Shell.
Und nun wolltest Du wissen, ob Du das Shell die Kommandos auch aus einer
Datei entgegennehmen lassen kannst. Ja, es geht, und zwar so:
Schreibe eine Datei "Datei.sh" mit dem Inhalt:
---Schnipp---
a=irgendwas && export a
---Schnapp---
Stelle sicher, dass die Datei Dir Lesezugriff gewährt (das dürfte
normalerweise der Fall sein). Gewähre Dir besser keine
Ausführungsrechte. Das bewahrt Dich davor, sie wie oben in Zeile 3 als
eigenen Kindprozess auszuführen.
Du teilst dem Shell mit, sie zu lesen und die in ihr enthaltenen
Kommandos auszuführen, indem Du dem Shell das Kommando
. ./Datei.sh
gibst. Im bash gibt es dazu auch die gleichbedeutende Variante
source ./Datei.sh
Sie tut aber mit dem Bourne Shell nicht.
Den Dateinamen der Datei kannst Du frei wählen. Es empfiehlt sich aber
oft, ».sh«, ».bash«, ».csh« oder ».tcsh« hinten am Namen zu haben, damit
man auf einen Blick sieht, für welches shell (sh, bash, csh oder tcsh)
die Datei gedacht ist.
Um das ewige Eintippen von
. ./Datei.sh
zu sparen, kannst Du Kommandos auch in eine der Startup-Dateien des
jeweiligen Shells reinschreiben. Welche das sind und wann sie verwendet
werden, steht im jeweiligen Manual-Page des Shells.
Beim bash bieten sich die Dateien "$HOME"/.profile, "$HOME"/.bash_profile
oder "$HOME"/.bashrc an.
>Gibt es eine Möglchkeit Variablen zu erstellen, die auf allen Terminals
>gültig sind?
Es gibt keine (direkte) Möglichkeit. Du kannst aber erreichen, dass in
jedem Shell, das in einem Terminal startet, eine Variable mit dem von Dir
gewünschten Wert erstellt wird.
Jedes bash, das von Dir Kommandos entgegennimmt und kein login shell ist,
liest die Datei "$HOME"/.bashrc und führt die darin enthaltenen Kommandos
aus.
Jedes bash, das ein login shell ist (egal, ob es von Dir Kommandos
entgegennimmt oder nicht), nimmt statt dessen die Datei
"$HOME"/.bash_profile oder, wenn es diese nicht gibt, die Datei
"$HOME"/.profile, das Bourne Shell nur die Datei "$HOME"/.profile.
Wie man ein Shell als login shell startet, das gäbe einen eigenen
Beitrag.
Genaues steht jeweils in den manual pages.
Noch garnichts habe ich Dir jetzt über
echo $a
und Shell-interne Variablen erzählt. Nur ganz kurz: (Fast) alle Shells
kennen nicht nur Umgebungsvariable sondern auch noch Shell-interne
Variable. Diese dürfen zunächst mit Umgebungsvariablen nicht verwechselt
werden.
echo $a
Gibt Dir den Wert der Shell-internen Variable "a" aus. In Zeile 4.2 wird
also allermeist nicht die Umgebungs- sondern die Shell-interne Variable
"a" ausgegeben.
Im Bourne Shell und im bash änderst Du Shell-interne Variable so:
a=irgendwas
. Um gleichzeitig die Umgebungsvariable zu ändern, können beim
Bourne-Shell und dem bash Shell-interne Variable und Umgebungsvariable
aber mit Hilfe des export-Kommandos vereinigt werden: Mit
einem export-Kommando
export a
macht sich die Shell-interne Variable »a« bis in die Prozessumgebung
breit. Danach beziehen sich alle Verwendungen der Variablen »a« auf die
jetzt gleichzeitig Shell-interne als auch Umgebungs-Variable »a«, und
zwar solange, bis durch
unset a
diese Variable gelöscht wird. Damit ist dann allerdings keine Variable
»a« mehr in der Umgebung noch als Shell-interne vorhanden.
Fazit: Du kannst Umgebungsvariablen nur gleichzeitig mit Shell-internen
Variablen ändern, erzeugen oder löschen.
Um dieses Dilemma etwas abzumildern, empfiehlt es sich, der allgemeinen
Übereinkunft zu folgen, für Umgebungsvariablen-Namen keine kleinen
Buchstaben zu verwenden. Jedoch halten sich leider nicht alle daran.
Mir ist schon die Umgebungsvariable »http_proxy« unter die Augen
gekommen.
Um Deine Frage von oben anders zu verstehen und zu beantworten:
>Ähm...gibt es einen Befehl, mit dem sich nur die lokalen
>Umgebungsvariablen darstellen lassen?
Es gibt keinen Befehl, der nur die Shell-internen Variablen, nicht aber
die Umgebungsvariablen darstellt.
Followup-To: de.comp.os.unix.shell
Gruß,
Helmut
--
Wenn Sie mir E-Mail schreiben, stellen | When writing me e-mail, please
Sie bitte vor meine E-Mail-Adresse | precede my e-mail address with
meinen Vor- und Nachnamen, etwa so: | my full name, like
Helmut Waitzmann <x...@example.net>, (Helmut Waitzmann) x...@example.net