Hallo! Ich benötige den Linuxbefehl der via shell variablen ( pfade ) setzt - wie unter dos z.b. set tmp=/C:\tmp via manpage set kam ich nur in mögliche shellbefehle :-( und der linuxbefehl set ist auch ned richtig ( zuminderst funktionierts ned ) Irgend ne idee wo ich infos dazu finde ? -- Quidquid latine dictum sit, altum viditur. (Whatever is said in Latin sounds profound.) ---------------------------------- Worker am Seti@Home - Projekt Registierter Linux - User #177159 ICQ - UIN : 51735624
Marco_Jaeger@gmx.de wrote:
Hallo!
Ich benötige den Linuxbefehl der via shell variablen ( pfade ) setzt - wie unter dos z.b. set tmp=/C:\tmp
via manpage set kam ich nur in mögliche shellbefehle :-( und der linuxbefehl set ist auch ned richtig ( zuminderst funktionierts ned )
bash/ksh/sh:
export
Irgend ne idee wo ich infos dazu finde ? man bash -> BUILTIN COMMANDS
Gruß, daniel
On Tue, 1 May 2001, Daniel Wolpert wrote:
Marco_Jaeger@gmx.de wrote: [...]
Ich benötige den Linuxbefehl der via shell variablen ( pfade ) setzt - wie unter dos z.b. set tmp=/C:tmp
Man muß zunächst mal Shell- und Environment-Variablen unterscheiden. Wenn ich mich nicht irre, sind Shell-Variablen etwas, was nur in jeweiligen Shell-Instanz lebt und nicht "vererbt" wird während Environment-Variablen auch Tochter-Shells und anderen von der Shell gestarteten Programmen "zur Verfügung" stehen.
[...] bash/ksh/sh: export
=<VALUE>
Setzt in der Tat eine Environment-Variable. Eine Shell-Variable setzt man
in diesen Shells, indem man einfach "
csh/tcsh: set
=<VALUE>
Setzt - im Gegensatz zu obigem - eine *Shell*-Variable. Eine Environment-
Variable setzt man in der csh und der tcsh mittels "setenv
Hi leider haben eure Tips nichts gebracht. die Variablen werden nicht gesetzt. Weder mit set noch mit export - ursache des problems : ich habe aus dem Web ein prog gesaugt das via mit einem prog seine umgebungsvariablen setzen will ( xxx_home / xxx_bin / xxx_config / ... ) im original steht : setenv XXX_HOME=/usr/xxx setenv XXX_BIN=$XXX_HOME/bin .... bzw in einem alternativprog mit : ${XXX_HOME:=/usr/xxx} : ${XXX_BIN:=$XXX_BIN/bin} ... export XXX_HOME XXX_BIN .... aber weder das eine - noch das andere setzen die variablen - und von hand klappt ebensowenig :-(( - weder mit set noch einem anderen -- If you think the United States has stood still, who built the largest shopping center in the world? -- Richard Nixon ---------------------------------- Worker am Seti@Home - Projekt Registierter Linux - User #177159 ICQ - UIN : 51735624
Moin Marco_Jaeger, * Marco_Jaeger schrieb am 01 May 2001:
die Variablen werden nicht gesetzt.
ich habe aus dem Web ein prog gesaugt das via mit einem prog seine umgebungsvariablen setzen will ( xxx_home / xxx_bin / xxx_config / ... ) im original steht :
setenv XXX_HOME=/usr/xxx setenv XXX_BIN=$XXX_HOME/bin ....
bzw in einem alternativprog mit : ${XXX_HOME:=/usr/xxx} : ${XXX_BIN:=$XXX_BIN/bin} ... export XXX_HOME XXX_BIN ....
XXX_HOME=/usr/xxx XXX_BIN=$XXX_HOME/bin export XXX_HOME XXX_BIN Gruß, Sebastian -- Do not meddle in the affairs of Wizards, for they are subtle and quick to anger. Sebastian Helms - http://www.helms.sh - mailto:mail@helms.sh (PGP welcome) SuSE-Linux-Mailinglisten-FAQ: http://www.helms.sh/faq/
On Die, 01 Mai 2001, Sebastian Helms wrote:
* Marco_Jaeger schrieb am 01 May 2001:
die Variablen werden nicht gesetzt.
Du rufst das shell-script auf, richtig? Dann laeuft das script in einer subshell und _nur_ in dieser (und mittels export in den von dieser subshell aufgerufenen Programmen). Wenn du aber in der _aktuellen_ shell die Variablen setzen willst (und das willst du vermutlich) so musst du das script mittels source in der aktuellen shell ausfuehren. Also ~ $ source <script> oder auch: ~ $ . <script> siehe man bash.
bzw in einem alternativprog mit : ${XXX_HOME:=/usr/xxx} : ${XXX_BIN:=$XXX_BIN/bin} ... export XXX_HOME XXX_BIN ....
Das ist schon richtig so.
XXX_HOME=/usr/xxx XXX_BIN=$XXX_HOME/bin export XXX_HOME XXX_BIN
Ist nicht unbedingt was gewuenscht ist. Das : ${VARIABLE:=WERT} Aus man bash: ${parameter:=word} Assign Default Values. If parameter is unset or null, the expansion of word is assigned to parame ter. The value of parameter is then substituted. Positional parameters and special parameters may not be assigned to in this way. Ist also die Variable schon gesetzt wird sie nicht geaendert. Die normale Version mit VARIABLE=WERT ueberschreibt evtl. gesetzte Werte. -dnh -- Today on Handyman's Corner, we're going to take some ordinary dice, some Bondo to fill in the holes, a Dremel tool with a pointy bit to carve the words "REBOOT", "RETRY", and "REINSTALL" in the faces, and a bit of paint to make it look pretty. ITWDFYHTSALFYH. [A. de Boer on adminning Win]
* Sebastian Helms schrieb am 01.Mai.2001:
* Marco_Jaeger schrieb am 01 May 2001:
bzw in einem alternativprog mit : ${XXX_HOME:=/usr/xxx} : ${XXX_BIN:=$XXX_BIN/bin} ... export XXX_HOME XXX_BIN ....
XXX_HOME=/usr/xxx XXX_BIN=$XXX_HOME/bin
export XXX_HOME XXX_BIN
Oder auch XXX_HOME=/usr/xxx XXX_BIN=${XXX_HOME} Bernd -- Welches Buch ist zu empfehlen? Schon mal bei SuSE vorbeigesehen? http://www.suse.de/de/produkte/buecher/index.html oder die Empfehlungen der SuSE-Entwickler auf dem eigenen Rechner? file:///usr/shar/doc/sdb/de/html/literatur.html |Zufallssignatur 5
Hallo ! Weitergekommen bin ich noch keinen Milimeter - trotz manpages zu set und export :-(( Fakten : habe ein programm , mit zwei versionen zum Setzen der umgebungsvariablen ( siehe anhang... - das .org ist von mir , damit ich weiß, welche files unverändert sind ; ) zum ausführen benutze ich die Standard konsole unter KDE ( bash ) in env.csh.ex habe ich einmal setenv mit set und einmal mit export getauscht - beides fehlanzeige. wenn ich danach das prog aufrufe findet es seine konfigs nicht ( in derselben Bash!! ) egal ob export xxx= dir , set xxx= dir oder xxx=dir export xxx dito gilt, wenn ich dasselbe von hand macxhe : config not found - Aborted. Dasselbe gilt wenn ich es auf einer tty-konsole versuche - weder als user - noch als root. ( rechte sind, dort generell auf lesen und ausführen für alle - nur root und gruppe können schreiben ) - an denen kann es also auch nicht liegen... irgendeine idee woran es liegen kann ?? -- Gosh that takes me back... or is it forward? That's the trouble with time travel, you never can tell." -- Doctor Who "Androids of Tara" ---------------------------------- Worker am Seti@Home - Projekt Registierter Linux - User #177159 ICQ - UIN : 51735624
Hallö Marco! Am Dienstag, 8. Mai 2001 18:31 schrieb Marco_Jaeger@gmx.de:
Hallo !
Weitergekommen bin ich noch keinen Milimeter - trotz manpages zu set und export :-((
Fakten : habe ein programm , mit zwei versionen zum Setzen der umgebungsvariablen ( siehe anhang... - das .org ist von mir , damit ich weiß, welche files unverändert sind ; ) zum ausführen benutze ich die Standard konsole unter KDE ( bash )
in env.csh.ex habe ich einmal setenv mit set und einmal mit export
AFAIK hilft es nicht viel, wenn man die bash benutzt, Umgebungsvariablen in einer Konfigurationsdatei für csh (C-Shell) zu setzen. Versuch das ganze doch mal in der Datei /home/user/.bashrc mit export. Grüße Manfred Gahr
On Die, 08 Mai 2001, Marco_Jaeger@gmx.de wrote:
weiß, welche files unverändert sind ; ) zum ausführen benutze ich die Standard konsole unter KDE ( bash )
Und wie? Rufst du das script nur auf? Dann klappt das natuerlich nicht, du musst das script sourcen! Dann sollte in der bash das mit den ': ${...}' plus export klappen. -dnh, sich wiederholend -- 53: Kostenloser Support durch unsere Hotline "0180 5..." oder "0190 ..."
On Die, Mai 08, 2001 at 06:31:40 +0200, Marco_Jaeger@gmx.de wrote:
Hallo !
Weitergekommen bin ich noch keinen Milimeter - trotz manpages zu set und export :-((
Fakten : habe ein programm , mit zwei versionen zum Setzen der umgebungsvariablen ( siehe anhang... - das .org ist von mir , damit ich weiß, welche files unverändert sind ; ) zum ausführen benutze ich die Standard konsole unter KDE ( bash )
Die Syntax in Deiner sh-Variante - was soll das sein? Shell-Syntax ist das auf jeden Fall nicht. Ich weiss nicht, was ISS sein soll, aber in einer (Bourne-artigen) Shell sieht das so aus: ISS_HOME=/iss export ISS_HOME oder export ISS_HOME=/iss oder ISS_HOME=/iss export ISS Wenn Du darauf zugreifen willst, dann: ISS_SONSTNOCHWAS=$ISS_HOME/sonstnochwas Du hast zwar geschrieben, dass Du das ausprobiert hättest, aber gesehen habe ich das in Deinen Scripts nicht! Jan
On Die, 08 Mai 2001, Jan Trippler wrote:
On Die, Mai 08, 2001 at 06:31:40 +0200, Marco_Jaeger@gmx.de wrote:
Die Syntax in Deiner sh-Variante - was soll das sein? Shell-Syntax ist das auf jeden Fall nicht.
Das ist eine bash-Erweiterung (also nicht sh). : ${ISS_HOME:=/iss} export ISS_HOME Das : ist dabei der leere Befehl, der noetig ist, damit dann die ${} expandierung gemacht wird (denn nur ${} wuerde expandiert werden und dann versucht auszufuehren...) Zu der ${VARIABLE:=WERT} Syntax findet sich in man bash (nach := suchen): ${parameter:=word} Assign Default Values. If parameter is unset or null, the expansion of word is assigned to parame ter. The value of parameter is then substituted. Positional parameters and special parameters may not be assigned to in this way. AFAIK ist '${parameter=word}' eine aequivalente Form. Ein Beispiel: $ echo $FOO $ : ${FOO=foo} $ echo $FOO foo $ : ${FOO=bar} $ echo $FOO foo $ : ${FOO:=bar} $ echo $FOO foo $ FOO=bar $ echo $FOO bar Der ganze Abschnitt EXPANSION ist lesenswert, besonders natuerlich der Abschnitt Parameter Expansion, in dem die diversen ${} Varianten erklaert werden. -dnh -- When you say "I wrote a program that crashed Windows", people just stare at you blankly and say "Hey, I got those with the system, *for free*". -Linus Torvalds
Am Dienstag, 8. Mai 2001 18:31 schrieb Marco_Jaeger@gmx.de:
in env.csh.ex habe ich einmal setenv mit set und einmal mit export
setenv ist mir bisher unter linux noch nicht untergekommen, ...
getauscht - beides fehlanzeige. wenn ich danach das prog aufrufe findet es seine konfigs nicht ( in derselben Bash!! ) egal ob
Stop mal, Du startest das Script, das kriegt seine Shell (sh oder csh, haben mit der bash direkt nix mehr zu tun), setzt dort die Variablen, beendet sich, Shell und Variablen sind weg und Du startest jetzt ein Programm, das die Variablen benötigt? Das kann nicht gehen! Nimm den Start des Programms ins Script und es müsste klappen. -- Machs gut | http://www.iiv.de/schwinde/buerger/tremmel/ | http://www.knightsoft.de Manfred | http://www.knightsoft-net.de
Manfred Tremmel wrote:
in env.csh.ex habe ich einmal setenv mit set und einmal mit export
setenv ist mir bisher unter linux noch nicht untergekommen, ...
Was hat das mit Linux zu tun? Ich kenne Leute, die Arbeiten mit zsh, und viele bevorzugen tcsh. Letztere benutzt z.B. setenv.
Stop mal, Du startest das Script, das kriegt seine Shell (sh oder csh, haben mit der bash direkt nix mehr zu tun)
sh doch: file /bin/sh /bin/sh: symbolic link to bash - Matthias
Matthias Kleine schrieb:
Manfred Tremmel wrote:
in env.csh.ex habe ich einmal setenv mit set und einmal mit export
setenv ist mir bisher unter linux noch nicht untergekommen, ...
Was hat das mit Linux zu tun? Ich kenne Leute, die Arbeiten mit zsh, und viele bevorzugen tcsh. Letztere benutzt z.B. setenv.
Stop mal, Du startest das Script, das kriegt seine Shell (sh oder csh, haben mit der bash direkt nix mehr zu tun)
sh doch:
file /bin/sh /bin/sh: symbolic link to bash
muss aber nicht unbedingt sein. Denn sh ist afaik nur ein symbolischer link auf die standard shell im System und die ist bei Suse standardmässig halt die bash. kann auf anderen systemen aber genausogut zsh, csh, tcsh oder was anderes sein. -fen -- 37: Even though our path is completely different from the warrior arts of the past, it is not necessary to abondon totally the old ways. Absorb venerable traditions into this Art by clothing them with fresh garmets, and build on the classic styles to create better forms.
Daniel Brachmann wrote:
file /bin/sh /bin/sh: symbolic link to bash
muss aber nicht unbedingt sein. Denn sh ist afaik nur ein symbolischer link auf die standard shell im System und die ist bei Suse standardmässig halt die bash. kann auf anderen systemen aber genausogut zsh, csh, tcsh oder was anderes sein.
/bin/sh sollte ein Link auf eine Bourne Shell-kompatible Shell sein, weil schlicht und einfach alle Skripte, die ein #!/bin/sh auf der Stirn stehen haben (und davon gibt es viele, die schon viele Jahre alt sind), nicht mehr laufen würden, wenn /bin/sh auf eine csh-Verwandte zeigt. csh Programmierer sind im allgemeinen auch schlau genug #!/bin/csh an den Beginn ihrer Skripte zu schreiben. Was ist außer dem eine systemweite Standardshell? Ich kenne nur Einträge in /etc/passwd (oder den entsprechenden NIS-Mechanismus), was ist denn Deiner Meinung nach der systemweite Fallback? - Matthias
Matthias Kleine schrieb:
Daniel Brachmann wrote:
file /bin/sh /bin/sh: symbolic link to bash
muss aber nicht unbedingt sein. Denn sh ist afaik nur ein symbolischer link auf die standard shell im System und die ist bei Suse standardmässig halt die bash. kann auf anderen systemen aber genausogut zsh, csh, tcsh oder was anderes sein.
/bin/sh sollte ein Link auf eine Bourne Shell-kompatible Shell sein, weil schlicht und einfach alle Skripte, die ein #!/bin/sh auf der Stirn stehen haben (und davon gibt es viele, die schon viele Jahre alt sind), nicht mehr laufen würden, wenn /bin/sh auf eine csh-Verwandte zeigt. csh Programmierer sind im allgemeinen auch schlau genug #!/bin/csh an den Beginn ihrer Skripte zu schreiben.
soirry aber das argoument zieht nicht. Programmierer sollten auch eben so schlau sein ein #!/bin/bash an den Beginn ihrer Skripte zu schreiben
Was ist außer dem eine systemweite Standardshell? Ich kenne nur Einträge in /etc/passwd (oder den entsprechenden NIS-Mechanismus), was ist denn Deiner Meinung nach der systemweite Fallback?
ich verstehe deine Frage nicht. /bin/sh ist ein symlink auf die normalerweise im system genutzte shell, das kann je nach vorliebe bash, zsh, csh oder was anderes sein. der eintrag in /etc/passwd ist die shell die der user kriegt wenn er sich einloggt und hat mit /bin/sh in erster linie nichts zu tun. -fen -- 57: The key to good technique is to keep your hands, feet, and hips straight and centered. If you are centered, you can move freely. The physical center is your belly; if your mind is set there as well, you are assured of victory in any endeavor.
Daniel Brachmann wrote:
soirry aber das argoument zieht nicht. Programmierer sollten auch eben so schlau sein ein #!/bin/bash an den Beginn ihrer Skripte zu schreiben
Quatsch. Es gibt abertausende von lauffähigen /bin/sh - Skripten aus Zeiten, als es noch gar keine bash gab. Offensichtlich hast Du noch in keiner professionellen Umgebung gearbeitet, die Unix länger als 5 Jahre benutzt.
ich verstehe deine Frage nicht. /bin/sh ist ein symlink auf die normalerweise im system genutzte shell, das kann je nach vorliebe bash, zsh, csh oder was anderes sein.
Aus den von mir genannten Gründen. Und nicht, weil es eine Standardshell wäre. - Matthias
Hallo, * Daniel Brachmann schrieb am 10.Mai.2001:
Matthias Kleine schrieb:
Daniel Brachmann wrote:
/bin/sh sollte ein Link auf eine Bourne Shell-kompatible Shell sein,
ACK
weil schlicht und einfach alle Skripte, die ein #!/bin/sh auf der Stirn stehen haben (und davon gibt es viele, die schon viele Jahre alt sind), nicht mehr laufen würden, wenn /bin/sh auf eine csh-Verwandte zeigt. csh Programmierer sind im allgemeinen auch schlau genug #!/bin/csh an den Beginn ihrer Skripte zu schreiben.
Es ist noch viel einfacher. /bin/sh ist die Bourneshell. Die hatte nie einen anderen Namen. Wenn sie heute nicht mehr dabei ist, so sollte es zumindest kompatibel sein. Genauso wie /bin/csh ein Symlink auf /bin/tcsh ist.
soirry aber das argoument zieht nicht. Programmierer sollten auch eben so schlau sein ein #!/bin/bash an den Beginn ihrer Skripte zu schreiben
Die Schreibweise #! irgendwas gibt es erst seit Mitte der 80er Jahren des letzten Jahrhunderts. Vorher gab es sowas nicht. Skripte die aus dieser Zeit stammen, gehen davon aus, das sie von der Bourneshell aufgerufen wurden.
Was ist außer dem eine systemweite Standardshell? Ich kenne nur Einträge in /etc/passwd (oder den entsprechenden NIS-Mechanismus), was ist denn Deiner Meinung nach der systemweite Fallback?
Ist /bin/sh, wenn in der /etc/passwd nichts eingetragen ist, so wird /bin/sh genommen.
ich verstehe deine Frage nicht. /bin/sh ist ein symlink auf die normalerweise im system genutzte shell, das kann je nach vorliebe bash, zsh, csh oder was anderes sein.
Nein, siehe oben. /bin/sh ist der Name der Bourneshell.
der eintrag in /etc/passwd ist die shell die der user kriegt wenn er sich einloggt und hat mit /bin/sh in erster linie nichts zu tun.
/bin/sh ist der Defaultwert. Im übrigen sollten Skripte Bournshellkompatibel sein, denn die Bournshell läuft auf jedem UNIX. Außerdem mag die Bournshell auf der Komandozeile ja fürchterlich sein, nur mit der Backspacetaste zu editieren und keinerlei History, Ergänzung oder was sonst noch, aber für Skripte hat es keine wesentliche Neuerungen gegeben. Bernd -- Homepages von deutschsprachigen Linux-Gurus: Kristian Köhntopp: http://www.koehntopp.de/kris/artikel/ Sven Guckes: http://www.math.fu-berlin.de/~guckes/sven Robin S Socha: http://socha.net/index2.html |Zufallssignatur 10
Bernd Brodesser schrieb:
Hallo,
* Daniel Brachmann schrieb am 10.Mai.2001:
Matthias Kleine schrieb:
Daniel Brachmann wrote:
/bin/sh sollte ein Link auf eine Bourne Shell-kompatible Shell sein,
ACK
weil schlicht und einfach alle Skripte, die ein #!/bin/sh auf der Stirn stehen haben (und davon gibt es viele, die schon viele Jahre alt sind), nicht mehr laufen würden, wenn /bin/sh auf eine csh-Verwandte zeigt. csh Programmierer sind im allgemeinen auch schlau genug #!/bin/csh an den Beginn ihrer Skripte zu schreiben.
Es ist noch viel einfacher. /bin/sh ist die Bourneshell. Die hatte nie einen anderen Namen. Wenn sie heute nicht mehr dabei ist, so sollte es zumindest kompatibel sein.
Genauso wie /bin/csh ein Symlink auf /bin/tcsh ist.
soirry aber das argoument zieht nicht. Programmierer sollten auch eben so schlau sein ein #!/bin/bash an den Beginn ihrer Skripte zu schreiben
Die Schreibweise #! irgendwas gibt es erst seit Mitte der 80er Jahren des letzten Jahrhunderts. Vorher gab es sowas nicht. Skripte die aus dieser Zeit stammen, gehen davon aus, das sie von der Bourneshell aufgerufen wurden.
Was ist außer dem eine systemweite Standardshell? Ich kenne nur Einträge in /etc/passwd (oder den entsprechenden NIS-Mechanismus), was ist denn Deiner Meinung nach der systemweite Fallback?
Ist /bin/sh, wenn in der /etc/passwd nichts eingetragen ist, so wird /bin/sh genommen.
ich verstehe deine Frage nicht. /bin/sh ist ein symlink auf die normalerweise im system genutzte shell, das kann je nach vorliebe bash, zsh, csh oder was anderes sein.
Nein, siehe oben. /bin/sh ist der Name der Bourneshell.
der eintrag in /etc/passwd ist die shell die der user kriegt wenn er sich einloggt und hat mit /bin/sh in erster linie nichts zu tun.
/bin/sh ist der Defaultwert. Im übrigen sollten Skripte Bournshellkompatibel sein, denn die Bournshell läuft auf jedem UNIX. Außerdem mag die Bournshell auf der Komandozeile ja fürchterlich sein, nur mit der Backspacetaste zu editieren und keinerlei History, Ergänzung oder was sonst noch, aber für Skripte hat es keine wesentliche Neuerungen gegeben.
hmm wieder was dzu gelernt :-p -fen -- 61: Functioning harmoniously together, right and left give birth to all techniques. The left hand takes hold of life and death; the right hand controls it. The four limbs of the body are the four pillars of heaven, and manifest the eight directions, yin and yang, inner and outer.
Am Donnerstag, 10. Mai 2001 09:21 schrieb Matthias Kleine:
setenv ist mir bisher unter linux noch nicht untergekommen, ...
Was hat das mit Linux zu tun? Ich kenne Leute, die Arbeiten mit zsh, und viele bevorzugen tcsh. Letztere benutzt z.B. setenv.
Ich sag ja nicht, dass es das nicht gibt, ich kenns halt nicht, sorry.
Stop mal, Du startest das Script, das kriegt seine Shell (sh oder csh, haben mit der bash direkt nix mehr zu tun)
sh doch:
file /bin/sh /bin/sh: symbolic link to bash
Dann ist es wieder ne bash, die hat aber mit der bash, von der aus gestartet wird auch wieder nix zu tun, zumindestens nicht in die Rechtung (Kinder erben von ihren Eltern, nicht umgekehrt, fast wie im richtigen Leben) -- Machs gut | http://www.iiv.de/schwinde/buerger/tremmel/ | http://www.knightsoft.de Manfred | http://www.knightsoft-net.de
* Marco_Jaeger@gmx.de schrieb am 01.Mai.2001:
leider haben eure Tips nichts gebracht.
die Variablen werden nicht gesetzt.
Weder mit set noch mit export
Kann es sein, daß Du ein Programm aufrufen möchtest, daß Dir die Umgebungsvariablen Deines aktuellen Prozesses verändern soll? Das geht nicht. Kein Kindprozeß kann die Umgebung des Elternprozesses verändern. Keine Chance. Du kanst es nur machen, indem Du keinen neuen Prozeß aufrufst. Etwa indem Du es in ~/.bashrc schreibst oder ein alias setzt oder aber ein Shellskript mit . bzw. source aufrufst. Dann wird kein neuer Prozeß generiert. Wenn Du aber schreibst, daß es auch nicht von Hand klappt wundert es mich doch ein Wenig. Ich habe den Thread nicht verfolgt, da ich nicht weiß, was ein Dos-Set ist. Bernd -- Probleme mit dem Drucker? Schon die Druckercheckliste beachtet? http://localhost/doc/sdb/de/html/drucker-howto.html | Auch lesenswert: Oder schon das Drucker-HOWTO gelesen? | man lpr file://usr/shar/doc/howto/de/DE-Drucker-HOWTO.txt.gz | Zufallssignatur 3
Marco_Jaeger@gmx.de wrote:
ich habe aus dem Web ein prog gesaugt das via mit einem prog seine umgebungsvariablen setzen will ( xxx_home / xxx_bin / xxx_config / ... ) im original steht :
setenv XXX_HOME=/usr/xxx setenv XXX_BIN=$XXX_HOME/bin ....
setenv wird in der tcsh benutzt (zumindest auf einer Sun).
bzw in einem alternativprog mit : ${XXX_HOME:=/usr/xxx} : ${XXX_BIN:=$XXX_BIN/bin} ... export XXX_HOME XXX_BIN ....
für bash und kompatible.. Was für eine Shell benutzt Du denn? Michael
Nur der Vollständigkeit halber: On Mit, Mai 02, 2001 at 05:18:01 +0100, Michael Gerdelmann wrote: [...]
NÖ, ums genau zu nehmen :-) Entweder
export name=wert
Das geht nur bei bash und Abarten, für (Bourne) sh und ksh klappt das nicht.
oder
name=wert export name
Das ist der 100% kompatible Weg. BTW: Der export verkraftet auch mehrere Parameter, also: name1=wert1 name2=wert2 export name1 name2 Jan
On 2001.05.01 13:26:22 +0200 Marco_Jaeger@gmx.de wrote:
Hallo!
Ich benötige den Linuxbefehl der via shell variablen ( pfade ) setzt - wie unter dos z.b. set tmp=/C:\tmp
via manpage set kam ich nur in mögliche shellbefehle :-( und der linuxbefehl set ist auch ned richtig ( zuminderst funktionierts ned )
Irgend ne idee wo ich infos dazu finde ?
man bash Dort nach export suchen Gruß Jörg -- www.lug-untermain.de - Dipl.-Ing. Jörg Schütter joerg.schuetter@gmx.de
Hallo! Am Dienstag, 1. Mai 2001 13:26 schrieb Marco_Jaeger@gmx.de:
Hallo!
Ich benötige den Linuxbefehl der via shell variablen ( pfade ) setzt - wie unter dos z.b. set tmp=/C:\tmp
Das funktioniert z.B. in der bash folgendermaßen: export VARIABLENNAME=WERT wenn Du eine Variable ergänzen willst (z.B. PATH): export PATH=irgendeinVerzeichnis:$PATH setzt den Pfad irgendeinVerzeichnis vor (!!!) den ursprünglichen Pfad, so daß Befehle die sich dort befinden vor denen in anderen Verzeichnissen gefunden werden. Hast Du z.B. ein Programm mit Namen test in irgendeinVerzeichnis, so wird dieses statt dem UNIX-Befehl test benützt... export PATH=$PATH:irgendeinVerzeichnis setzt irgendeinVerzeichnis nach dem ursprünglichen PATH.
via manpage set kam ich nur in mögliche shellbefehle :-( und der linuxbefehl set ist auch ned richtig ( zuminderst funktionierts ned )
Irgend ne idee wo ich infos dazu finde ?
man export hilft auch weiter... Grüße Manfred Gahr
Hallo, On Tue, 01 May 2001 at 14:18 +0200, Manfred Gahr wrote:
Am Dienstag, 1. Mai 2001 13:26 schrieb Marco_Jaeger@gmx.de:
Hallo!
Ich benötige den Linuxbefehl der via shell variablen ( pfade ) setzt - wie unter dos z.b. set tmp=/C:\tmp
Das funktioniert z.B. in der bash folgendermaßen:
export VARIABLENNAME=WERT
wenn Du eine Variable ergänzen willst (z.B. PATH):
export PATH=irgendeinVerzeichnis:$PATH
setzt den Pfad irgendeinVerzeichnis vor (!!!) den ursprünglichen Pfad, so daß Befehle die sich dort befinden vor denen in anderen Verzeichnissen gefunden werden. Hast Du z.B. ein Programm mit Namen test in irgendeinVerzeichnis, so wird dieses statt dem UNIX-Befehl test benützt...
test ist ein Shell-Builtin, das vor irgendeinem Programm im $PATH benutzt wird. Nur der komplette Pfad bringt was. Gruß, Bernhard -- Irgendein Linux-Problem. Schonmal in die SuSE-Support-Datenbank geschaut? http://sdb.suse.de/sdb/de/html/index.html | Oder ins Listenarchiv? http://www.geocrawler.com/lists/3/Suse-Linux/287/0/ | http://lists.suse.com ******************** Gnu PGP-Key: DDAF6454 * Tux# 171705 * ICQ# 98361051
participants (14)
-
Bernd Brodesser -
Bernhard Walle -
Daniel Brachmann -
Daniel Wolpert -
David Haller -
Henning Hucke -
Jan.Trippler＠t-online.de -
Jörg Schütter -
M.A.N.E＠t-online.de -
Manfred Tremmel -
Marco_Jaeger＠gmx.de -
Matthias Kleine -
Michael Gerdelmann -
Sebastian Helms