Discussion:
Passwort verdeckt eingeben
(zu alt für eine Antwort)
Ralph-Lehmann
2003-10-02 08:30:36 UTC
Permalink
Hi,

ich habe da ein Shell-Script, welches die Eingabe von Benutzerdaten
erfordert. Gibt es eine einfache Möglichkeit, die Eingabe des Passwortes zu
verstecken z.B. so, wie am login-prompt, mit Sternchen o.ä.?

Vielen Dank schon jetzt!

Ralph
Schamil Wackenhut
2003-10-02 08:35:16 UTC
Permalink
Post by Ralph-Lehmann
ich habe da ein Shell-Script, welches die Eingabe von Benutzerdaten
erfordert. Gibt es eine einfache Möglichkeit, die Eingabe des Passwortes zu
verstecken z.B. so, wie am login-prompt, mit Sternchen o.ä.?
stty -echo

Mit Sternchen? So sieht man doch direkt wieviel Buchstaben der Benutzer
eingegeben hat :)
Maik Zumstrull
2003-10-02 11:21:46 UTC
Permalink
Post by Ralph-Lehmann
ich habe da ein Shell-Script, welches die Eingabe von Benutzerdaten
erfordert. Gibt es eine einfache Möglichkeit, die Eingabe des
Passwortes zu verstecken z.B. so, wie am login-prompt, mit Sternchen
o.ä.?
Die bash kennt "read -s".
Frank Meyer
2003-10-02 12:20:18 UTC
Permalink
Post by Maik Zumstrull
Die bash kennt "read -s".
Igitt. Warum immer solche Bashisms?

Heutzutage kann kaum noch einer portable Shell-Scripts schreiben,
wenn er mit der bash angefangen hat. Diese Shell verseucht die
Sprache.

Frage: Gibt es eine Art "Validator" für Bourne-kompatible Shell-Scripts?

Frank
Hauke Laging
2003-10-02 19:15:27 UTC
Permalink
Post by Frank Meyer
Igitt. Warum immer solche Bashisms?
Heutzutage kann kaum noch einer portable Shell-Scripts schreiben,
wenn er mit der bash angefangen hat. Diese Shell verseucht die
Sprache.
Quatsch.

- Man könnte alle Shells bis auf eine abschaffen, wenn es nicht
"erlaubt" wäre, Spezialitäten zu benutzen.

- bash dürfte die meistbenutzte Shell sein.

- Wenn einer ein portables oder auf einer speziellen Shell
lauffähiges Script benötigt, dann steht es im frei, das in seinem
Posting mitzuteilen. Er wird dann kaum mit unpassenden Antworten
belästigt werden.

- Wer "so wenig" Ahnung hat, dass er hier Fragen stellt, die beinahe
jeder "irgendwie" beantworten kann, der ist einerseits aller
Wahrscheinlichkeit eh bash-Benutzer und braucht andererseits keine
Portabilität. Wer sich von der bash entfernt hat, wird üblicherweise
soviel Experte sein, dass er die bash-Lösungen sowohl nicht mehr
nötig hat als auch leicht anpassen kann.


Hauke
--
Die Ein-Mann-Unix-Entwicklungsabteilung: http://cr.yp.to
**********
Helfen Sie Open Source! Petition gegen Softwarepatente
http://petition.eurolinux.org/index_html
Frank Meyer
2003-10-02 22:38:24 UTC
Permalink
Post by Hauke Laging
- Man könnte alle Shells bis auf eine abschaffen, wenn es nicht
"erlaubt" wäre, Spezialitäten zu benutzen.
Diese NG heißt de.comp.os.unix.shell und nicht de.comp.os.unix.bash.
Post by Hauke Laging
- bash dürfte die meistbenutzte Shell sein.
Ja und? bashisms sind in 95% aller Fälle hyperfluid, weil es meist
auch mit Standard-Mitteln geht.

Wenn ich sehe, daß Leute verzweifelt ein Software-Paket für fli4l
adaptieren wollen und dann an den bash-Spezialitäten scheitern, welche
in den Scripts verwendet werden, könnte ich graue Haare kriegen[1].
Und alles nur, weil die Programmierer zu blöd sind, sich auf
Bourne-Shell-Standards zu beschränken. Ein "read -s" ist überflüssig,
weils mit

stty -echo; read -s foo; stty echo

genauso gut geht. Aufzählen könnte man da dutzende von weiteren Fällen.
Post by Hauke Laging
- Wenn einer ein portables oder auf einer speziellen Shell
lauffähiges Script benötigt, dann steht es im frei, das in seinem
Posting mitzuteilen. Er wird dann kaum mit unpassenden Antworten
belästigt werden.
Nun, die Antworten werden von vielen gelesen, die auch was dabei lernen
wollen. Daher ist eine portable Lösung für die Allgemeinheit von
wesentlich größerem Nutzen als proprietärer Unsinn.
Post by Hauke Laging
- Wer "so wenig" Ahnung hat, dass er hier Fragen stellt, die beinahe
jeder "irgendwie" beantworten kann, der ist einerseits aller
Wahrscheinlichkeit eh bash-Benutzer und braucht andererseits keine
Portabilität.
Wichtig ist immer ein Verständnis für die Sprache und Syntax. Daß
dabei auch eine konkrete Lösung für den OP rausspringen kann, halte
ich eher für einen angenehmen Nebeneffekt.
Post by Hauke Laging
Wer sich von der bash entfernt hat, wird üblicherweise
soviel Experte sein, dass er die bash-Lösungen sowohl nicht mehr
nötig hat als auch leicht anpassen kann.
Ein "bash-Experte" kann überhaupt keine portablen Scripts mehr schreiben,
genausowenig, wie ein C++-Programmierer, der direkt mit C++ statt C
angefangen hat, nicht mehr in der Lage ist, ein reinrassiges C-Programm
zu schreiben. Er kann nämlich nicht mehr unterscheiden, welche Sprachelemente
zu C gehören und welche nicht.

Hier wurde vor einiger Zeit vehement gegen proprietäre Shells wie
z.B. die bsh von Helmut Schellong vorgegangen. Zu Recht.

Gruß,

Frank
Frank Meyer
2003-10-02 22:51:11 UTC
Permalink
Post by Frank Meyer
stty -echo; read -s foo; stty echo
Sorry, sollte

stty -echo; read foo; stty echo

heißen.

Frank
Hauke Laging
2003-10-02 23:52:15 UTC
Permalink
Post by Frank Meyer
Post by Hauke Laging
- Man könnte alle Shells bis auf eine abschaffen, wenn es nicht
"erlaubt" wäre, Spezialitäten zu benutzen.
Diese NG heißt de.comp.os.unix.shell und nicht
de.comp.os.unix.bash.
Und? Ist bash deshalb OT?
Post by Frank Meyer
Ja und? bashisms sind in 95% aller Fälle hyperfluid, weil es meist
auch mit Standard-Mitteln geht.
Welchen Wert hat diese Aussage? Mal abgesehen davon, was die 5% sein
sollen, die sich nur mit bash lösen lassen. In einer ähnlichen
Größenordnung, wie Du sie nennst, spielt Portabilität keine Rolle.
Post by Frank Meyer
Wenn ich sehe, daß Leute verzweifelt ein Software-Paket für fli4l
adaptieren wollen und dann an den bash-Spezialitäten scheitern,
welche in den Scripts verwendet werden, könnte ich graue Haare
kriegen[1].
Du bringst ein sehr gutes Beispiel dafür, wo der Einsatz proprietärer
Techniken ungeschickt ist, nämlich bei "öffentlichem" Code, der auf
einer Vielzahl von Systemen eingesetzt wird. Dem würde ich nie
wiedersprechen.

Die meisten Leute, die Shellcode schreiben, machen das aber nicht für
öffentliche Projekte und sind deshalb nicht denselben Anforderungen
ausgesetzt.
Post by Frank Meyer
Nun, die Antworten werden von vielen gelesen, die auch was dabei
lernen wollen. Daher ist eine portable Lösung für die Allgemeinheit
von wesentlich größerem Nutzen als proprietärer Unsinn.
Verleihst Du Deinem Argument mehr Gewicht, wenn Du von "Unsinn"
sprichst, wo für jedermann erkennbar keiner ist? Man springt beim
Lernen nicht von 0 auf 100. Ein read -s ist viel einfacher zu
verstehen als die stty-Konstrukte - so gut sie auch sein mögen. Du
solltest es mit Deinem Lern-und-Lehranspruch nicht zu weit gehen.
Post by Frank Meyer
Post by Hauke Laging
Wer sich von der bash entfernt hat, wird üblicherweise
soviel Experte sein, dass er die bash-Lösungen sowohl nicht mehr
nötig hat als auch leicht anpassen kann.
Ein "bash-Experte" kann überhaupt keine portablen Scripts mehr schreiben,
Ich meinte ja nicht speziell bash-Experten. Gerade in dem
angesprochenen Fall - jemand benutzt eine andere Shell - muss man
davon ausgehen, dass der Betroffene sehr gut erkennt, was Bashismus
ist und was nicht.
Post by Frank Meyer
Hier wurde vor einiger Zeit vehement gegen proprietäre Shells wie
z.B. die bsh von Helmut Schellong vorgegangen. Zu Recht.
Aber (primär) aus einem anderen Grund, nämlich der, anders als bei
GPL-Software, prinzipiell kritischen Verfügbarkeit. Ansonsten
landete man wieder bei meinem Argument, dass man sonst alle Shells
bis auf eine einstampfen könnte.


CU

Hauke
--
Die Ein-Mann-Unix-Entwicklungsabteilung: http://cr.yp.to
**********
Helfen Sie Open Source! Petition gegen Softwarepatente
http://petition.eurolinux.org/index_html
Frank Meyer
2003-10-03 22:28:38 UTC
Permalink
Post by Hauke Laging
Post by Frank Meyer
Diese NG heißt de.comp.os.unix.shell und nicht
de.comp.os.unix.bash.
Und? Ist bash deshalb OT?
Natürlich nicht.
Post by Hauke Laging
Du bringst ein sehr gutes Beispiel dafür, wo der Einsatz proprietärer
Techniken ungeschickt ist, nämlich bei "öffentlichem" Code, der auf
einer Vielzahl von Systemen eingesetzt wird. Dem würde ich nie
wiedersprechen.
Diese Newsgroup ist öffentlich. Damit ist auch der hier veröffentlichte
Code öffentlich. Wenn ich hier Code veröffentliche, dann nicht für den
OP, sondern für die Leser der Newsgroup.
Post by Hauke Laging
Die meisten Leute, die Shellcode schreiben, machen das aber nicht für
öffentliche Projekte und sind deshalb nicht denselben Anforderungen
ausgesetzt.
Ok. Und sie haben später 'ne Menge Arbeit beim Portieren auf ein
anderes System.
Post by Hauke Laging
Verleihst Du Deinem Argument mehr Gewicht, wenn Du von "Unsinn"
sprichst, wo für jedermann erkennbar keiner ist? Man springt beim
Lernen nicht von 0 auf 100. Ein read -s ist viel einfacher zu
verstehen als die stty-Konstrukte - so gut sie auch sein mögen. Du
solltest es mit Deinem Lern-und-Lehranspruch nicht zu weit gehen.
Och, ich finde es nicht schlecht, wenn man hier auch ein wenig
Verständnis für die Funktionsweise eines Betriebssystems, auf welcher
die Shell läuft, mitbekommt. Der stty-Befehl gehört dazu.
Post by Hauke Laging
Aber (primär) aus einem anderen Grund, nämlich der, anders als bei
GPL-Software, prinzipiell kritischen Verfügbarkeit. Ansonsten
landete man wieder bei meinem Argument, dass man sonst alle Shells
bis auf eine einstampfen könnte.
Das ist Deine Ansicht. Nicht meine.

Frank
Erkan Yanar
2003-10-02 22:38:59 UTC
Permalink
Post by Hauke Laging
Post by Frank Meyer
Igitt. Warum immer solche Bashisms?
Heutzutage kann kaum noch einer portable Shell-Scripts schreiben,
wenn er mit der bash angefangen hat. Diese Shell verseucht die
Sprache.
Quatsch.
- Man könnte alle Shells bis auf eine abschaffen, wenn es nicht
"erlaubt" wäre, Spezialitäten zu benutzen.
- bash dürfte die meistbenutzte Shell sein.
- Wenn einer ein portables oder auf einer speziellen Shell
lauffähiges Script benötigt, dann steht es im frei, das in seinem
Posting mitzuteilen. Er wird dann kaum mit unpassenden Antworten
belästigt werden.
- Wer "so wenig" Ahnung hat, dass er hier Fragen stellt, die beinahe
jeder "irgendwie" beantworten kann, der ist einerseits aller
Wahrscheinlichkeit eh bash-Benutzer und braucht andererseits keine
Portabilität. Wer sich von der bash entfernt hat, wird üblicherweise
soviel Experte sein, dass er die bash-Lösungen sowohl nicht mehr
nötig hat als auch leicht anpassen kann.
Desto mehr Konjunktive , desto weniger Aussage.


tschazu
erkan
--
über den grenzen muß die freiheit wohl wolkenlos sein
Hauke Laging
2003-10-02 23:27:03 UTC
Permalink
Post by Erkan Yanar
Desto mehr Konjunktive , desto weniger Aussage.
Wenn man sich bemüht, vermeintlich kluge Sätze zu verfassen, dann
sollten die zumindest dann halbwegs korrekt sein, wenn sie nur aus
sechs Wörtern bestehen.

Inhaltliche Ansprüche mal ganz hinten angestellt.


Hauke
--
Die Ein-Mann-Unix-Entwicklungsabteilung: http://cr.yp.to
**********
Helfen Sie Open Source! Petition gegen Softwarepatente
http://petition.eurolinux.org/index_html
Erkan Yanar
2003-10-02 23:37:04 UTC
Permalink
Post by Hauke Laging
Post by Erkan Yanar
Desto mehr Konjunktive , desto weniger Aussage.
Wenn man sich bemüht, vermeintlich kluge Sätze zu verfassen, dann
sollten die zumindest dann halbwegs korrekt sein, wenn sie nur aus
sechs Wörtern bestehen.
Inhaltliche Ansprüche mal ganz hinten angestellt.
Na komm, als ob der Satz unwahr ist.

tschazu
erkan
--
über den grenzen muß die freiheit wohl wolkenlos sein
Hauke Laging
2003-10-03 00:01:37 UTC
Permalink
Post by Erkan Yanar
Na komm, als ob der Satz unwahr ist.
Ist er, natürlich. Vielleicht wäre sinnlos der bessere Ausdruck.

Und nein, ich werde mich nicht bemühen, das nachzuweisen. Das ist
regelmäßig das Vorrecht desjenigen, der Behauptungen aufstellt,
nicht das desjenigen, der sie anzweifelt...


CU

Hauke
--
Die Ein-Mann-Unix-Entwicklungsabteilung: http://cr.yp.to
**********
Helfen Sie Open Source! Petition gegen Softwarepatente
http://petition.eurolinux.org/index_html
Erkan Yanar
2003-10-03 00:21:17 UTC
Permalink
Post by Hauke Laging
Post by Erkan Yanar
Na komm, als ob der Satz unwahr ist.
Ist er, natürlich. Vielleicht wäre sinnlos der bessere Ausdruck.
*lol* läßt tief blicken.
Post by Hauke Laging
Und nein, ich werde mich nicht bemühen, das nachzuweisen. Das ist
regelmäßig das Vorrecht desjenigen, der Behauptungen aufstellt,
nicht das desjenigen, der sie anzweifelt...
Das ist dann aber keine Behauptung?!

tschazu
erkan
--
über den grenzen muß die freiheit wohl wolkenlos sein
Hauke Laging
2003-10-03 00:45:06 UTC
Permalink
Post by Erkan Yanar
Post by Hauke Laging
Und nein, ich werde mich nicht bemühen, das nachzuweisen. Das ist
regelmäßig das Vorrecht desjenigen, der Behauptungen aufstellt,
nicht das desjenigen, der sie anzweifelt...
Das ist dann aber keine Behauptung?!
Das ich mich nicht bemühen werde, hat für mich eher den Charakter
einer Tatsache.


Gute Nacht.
--
Die Ein-Mann-Unix-Entwicklungsabteilung: http://cr.yp.to
**********
Helfen Sie Open Source! Petition gegen Softwarepatente
http://petition.eurolinux.org/index_html
Juergen P. Meier
2003-10-03 09:05:47 UTC
Permalink
Post by Hauke Laging
Post by Frank Meyer
Igitt. Warum immer solche Bashisms?
Heutzutage kann kaum noch einer portable Shell-Scripts schreiben,
wenn er mit der bash angefangen hat. Diese Shell verseucht die
Sprache.
Quatsch.
- Man könnte alle Shells bis auf eine abschaffen, wenn es nicht
"erlaubt" wäre, Spezialitäten zu benutzen.
Unsinn. Es geht nicht um die Schell, sondern um Scripte.
Post by Hauke Laging
- bash dürfte die meistbenutzte Shell sein.
Wo? Durch wen? Outbreak Exzess ist der Meistbenutzte Newsreader, Also
sollen wir alle auf das englische Wort "begin" verzichten und nur noch
Einleitungsromane verfassen, Umlaute unkodiert herumstehen lassen und
TOFU Muell produzieren und Wuermer verbreiten?

Denk bitte nochmal nach.
Post by Hauke Laging
- Wenn einer ein portables oder auf einer speziellen Shell
lauffähiges Script benötigt, dann steht es im frei, das in seinem
Posting mitzuteilen. Er wird dann kaum mit unpassenden Antworten
belästigt werden.
Irrtum. Vielleicht moechtest du erst nochmal die Charte von hier
lesen. Diese Annahme ist hier *IMPLIZIERT*.

Jemand, der /keinen/ portablen schell code haben will, muss das in
seinem Posting extra mitteilen.

So herum wird ein Schuh draus.
Post by Hauke Laging
- Wer "so wenig" Ahnung hat, dass er hier Fragen stellt, die beinahe
jeder "irgendwie" beantworten kann, der ist einerseits aller
Wahrscheinlichkeit eh bash-Benutzer und braucht andererseits keine
Und benutzt Ausguck Schnellzug, also lasst gefaelligst das mit dem
Mime-codieren, korrektem Quoting und verwendet nicht das Wort "begin".

Tsk.
Post by Hauke Laging
Portabilität. Wer sich von der bash entfernt hat, wird üblicherweise
soviel Experte sein, dass er die bash-Lösungen sowohl nicht mehr
nötig hat als auch leicht anpassen kann.
Ich kann dich wirklich nicht verstehen.

Juergen
--
Juergen P. Meier - "This World is about to be Destroyed!"

If you think technology can solve your problems you don't understand
technology and you don't understand your problems. (Marcus Ranum)
Hauke Laging
2003-10-03 14:24:30 UTC
Permalink
Post by Juergen P. Meier
Post by Hauke Laging
- Man könnte alle Shells bis auf eine abschaffen, wenn es nicht
"erlaubt" wäre, Spezialitäten zu benutzen.
Unsinn. Es geht nicht um die Schell, sondern um Scripte.
Was soll denn da jetzt der relevante Unterschied sein? Wenn man zehn
Shells hätte, die alle mit exakt derselben Syntax und demselben
Fubnktionsumfang arbeiten, wäre ich kaum bereit, die als
unterschiedlich anzuerkennen, auch wenn der jeweilige Quallcode noch
so individuell wäre.
Post by Juergen P. Meier
Post by Hauke Laging
- bash dürfte die meistbenutzte Shell sein.
Wo? Durch wen?
Sowohl Unix-Benutzer insgesamt als auch diejenigen, die hier Threads
eröffnen, mit ihren Fragen hierherkommen. Aber das ist natürlich nur
mein Eindruck, wissen kann ich das nicht (und wohl auch sonst
keiner).
Post by Juergen P. Meier
Outbreak Exzess ist der Meistbenutzte Newsreader,
Also sollen wir alle auf das englische Wort "begin" verzichten und
nur noch Einleitungsromane verfassen, Umlaute unkodiert herumstehen
lassen und TOFU Muell produzieren und Wuermer verbreiten?
Denk bitte nochmal nach.
Klar, mache ich gerne. OE ist ein Einzelphänomen, bash aber eine
Shell unter vielen. Bei dieser Diskussion geht es ja nur
vordergründig um bash. Wenn man Portabilität erzwingt, ist (fast)
jede andere Shell "genauso schlecht" wie bash, weil im Detail nicht
portabel.

Außerdem muss auf bash-User ja keine besondere Rücksicht genommen
werden - im Gegensatz zu OE. Die beiden Fälle liegen genau umgekehrt
zueinander.

Eine passende Analogie wäre, das Antworten auf Fragen zur Bedienung
von Usenet nur auf OE gemüntzt gegeben würden.
Post by Juergen P. Meier
Irrtum. Vielleicht moechtest du erst nochmal die Charte von hier
lesen. Diese Annahme ist hier *IMPLIZIERT*.
Mag sein, ich sehe das da aber nicht.


Ich will hier niemanden bekehren. Ich behaupte auch gar nicht, dass
es in irgendeiner Weise schlecht sei, Portabilität anzustreben. Ich
halte bloß nichts davon, auf Leuten herumzuhacken, die eine als
solche gekennzeichnete bash-Lösung bringen.

Aber da bin ich als Nur-bash-Benutzer natürlich (prinzipiell) selber
betroffen und damit voreingenommen.


CU

Hauke
--
Die Ein-Mann-Unix-Entwicklungsabteilung: http://cr.yp.to
**********
Helfen Sie Open Source! Petition gegen Softwarepatente
http://petition.eurolinux.org/index_html
Heiko Berges
2003-10-03 11:45:33 UTC
Permalink
Post by Hauke Laging
Post by Frank Meyer
Igitt. Warum immer solche Bashisms?
Heutzutage kann kaum noch einer portable Shell-Scripts schreiben,
wenn er mit der bash angefangen hat. Diese Shell verseucht die
Sprache.
Quatsch.
- Man könnte alle Shells bis auf eine abschaffen, wenn es nicht
"erlaubt" wäre, Spezialitäten zu benutzen.
- bash dürfte die meistbenutzte Shell sein.
Was heißt meistbenutzt? Die meisten Installationen? Da setze ich
tcsh dagegen. Oder die meistaufgerufene? Das ist aber eher /bin/sh,
auch wenn die entsprechenden Skripte oft mit gnuismen durchsetzt sind.

Oder die Shell, die man am wahrscheinlichsten auf irgendeinem Unix
neben /bin/sh findet? Das wäre dann aber ksh88.

Ich persönlich finde den Anspruch dieser Gruppe, portable Lösungen
zu produzieren, ausgesprochen nützlich, da fällt man nämlich nicht
so leicht eines Tages mit Dingen wie ${!v} auf die Nase.


Heiko
Heiner Steven
2003-10-03 16:41:12 UTC
Permalink
Post by Hauke Laging
Post by Frank Meyer
Igitt. Warum immer solche Bashisms?
Heutzutage kann kaum noch einer portable Shell-Scripts schreiben,
wenn er mit der bash angefangen hat. Diese Shell verseucht die
Sprache.
Quatsch.
- Man könnte alle Shells bis auf eine abschaffen, wenn es nicht
"erlaubt" wäre, Spezialitäten zu benutzen.
Andererseits hift es keinem, wenn die gleiche Funktionalität
in verschiedenen Shells unterschiedlich implementiert wird.
Beispiel:

a=$[ 1 + 1 ]

versteht nur die BASH, aber

((a=1+1))

verstehen BASH, ksh, und ksh93 (wahrscheinlich auch zsh).

Ausserdem gibt es neben dem Funktionsumfang noch andere
Kriterien zur Auswahl einer Shell, z.B. Geschwindigkeit,
Portabilität der verwendeten Sprache, Verfügbarkeit.
Post by Hauke Laging
- bash dürfte die meistbenutzte Shell sein.
Oder "csh"/tcsh. Das heisst aber nicht, dass man deshalb
die Portabilität ignorieren kann. Mehr als 90% der Web-Benutzer
verwenden den Internet Explorer - sollte man deshalb alle
anderen Browser aussen vor lassen?
Post by Hauke Laging
- Wenn einer ein portables oder auf einer speziellen Shell
lauffähiges Script benötigt, dann steht es im frei, das in seinem
Posting mitzuteilen. Er wird dann kaum mit unpassenden Antworten
belästigt werden.
Viele Anfänger wissen gar nicht, dass es verschiedene Shells
gibt. Es hilft, wenn man ihnen die Vor- und Nachteile
(z.B. Portabilität) einer gegebenen Lösung mitteilt.

Meine Erfahrung ist, dass 90% der BASH benutzer sie deshalb
verwenden, weil sie (a) "da ist" (default /bin/sh), und
(b) weil die Cursortasten funktionieren.

Dies sind gute Gründe, eine interaktive Shell auszuwählen.

Für Shell-Skripte dagegen spielen die interaktiven Fähigkeiten
einer Shell überhaupt keine Rolle. Andere Faktoren (z.B.
Portabilität, Schnelligkeit, Einfachheit des Skriptes)
sind wichtiger.
Post by Hauke Laging
- Wer "so wenig" Ahnung hat, dass er hier Fragen stellt, die beinahe
jeder "irgendwie" beantworten kann, der ist einerseits aller
Wahrscheinlichkeit eh bash-Benutzer und braucht andererseits keine
Portabilität. Wer sich von der bash entfernt hat, wird üblicherweise
soviel Experte sein, dass er die bash-Lösungen sowohl nicht mehr
nötig hat als auch leicht anpassen kann.
Du meinst also

(1) wer Anfänger ist, verwendet die BASH
(2) wer keine Ahnung hat, interessiert sich nicht für Portabilität

Diese Annahmen sind meiner Ansicht nach absolut nicht zu halten.
Es gibt auch UNIX-Benutzer, die kein Linux verwenden (und damit
wahrscheinlich keine Bash). Dazu kommt, dass die meisten
BASH-spezifischen Konstrukte in Shell-Skripten nicht verwendet
werden, weil sie einfacher oder die einzige Möglichkeit sind
ein Problem zu lösen, sondern weil der Programmierer einfach
nicht weiss, dass sie unportabel sind. Ein gelegentlicher
Hinweis auf Portabilitätsprobleme, oder vielleicht sogar
eine portable Alternativlösung würden uns allen helfen
z.B. unportable "configure" Skripten zu vermeiden.

Aus diesem Grund finde ich es zwar in Ordnung, Lösungen
anzugeben die nur in einer spezifischen Shell funktionieren,
man sollte dies aber auch klarstellen.

Heiner
--
___ _
/ __| |_ _____ _____ _ _ Heiner STEVEN <***@nexgo.de>
\__ \ _/ -_) V / -_) ' \ Shell Script Programmers: visit
|___/\__\___|\_/\___|_||_| http://www.shelldorado.com/
Hauke Laging
2003-10-03 16:55:38 UTC
Permalink
Post by Heiner Steven
Andererseits hift es keinem, wenn die gleiche Funktionalität
in verschiedenen Shells unterschiedlich implementiert wird.
a=$[ 1 + 1 ]
versteht nur die BASH, aber
Ich habe mir das verwundert angeguckt und gedacht: "Was ist denn das
für eine Syntax, seit wann kann bash so was?" Und siehe da, es
funktioniert auch nicht.

bash: 1 + 1 : syntax error: operand expected (error token is
" 1 + 1 ")
Post by Heiner Steven
Oder "csh"/tcsh. Das heisst aber nicht, dass man deshalb
die Portabilität ignorieren kann. Mehr als 90% der Web-Benutzer
verwenden den Internet Explorer - sollte man deshalb alle
anderen Browser aussen vor lassen?
Nein, auf keinen Fall. Deshalb habe ich in einem anderen Posting auch
klar zwischen (potentiell) "öffentlichem" (da ging es um fi4l) und
"privatem" Einsatz unterschieden. Womit andere in Berührung kommen,
das sollte in jeder Hinsicht vorbildlich sein. Dazu gehört auch der
Stil (Kommentierung usw.).
Post by Heiner Steven
Portabilität, Schnelligkeit, Einfachheit des Skriptes)
sind wichtiger.
Pick two ;-)
Post by Heiner Steven
Du meinst also
(1) wer Anfänger ist, verwendet die BASH
(2) wer keine Ahnung hat, interessiert sich nicht für Portabilität
Ja.
Post by Heiner Steven
Es gibt auch UNIX-Benutzer, die kein Linux verwenden (und damit
wahrscheinlich keine Bash).
Das sind in der Tendenz wohl eher weniger die Anfänger.
Post by Heiner Steven
Dazu kommt, dass die meisten
BASH-spezifischen Konstrukte in Shell-Skripten nicht verwendet
werden, weil sie einfacher oder die einzige Möglichkeit sind
ein Problem zu lösen, sondern weil der Programmierer einfach
nicht weiss, dass sie unportabel sind.
Klar, geht mir ständig so. Ich denke aber, dass es einfacher ist,
erst mal eine Shell zu lernen und sich dann zu einem umfassenderen
Verständnis (das u.a. Portabilität beinhaltet) hochzuarbeiten, als
mit der Luxuslösung anzufangen.
Post by Heiner Steven
Ein gelegentlicher
Hinweis auf Portabilitätsprobleme, oder vielleicht sogar
eine portable Alternativlösung würden uns allen helfen
z.B. unportable "configure" Skripten zu vermeiden.
Sehe ich genauso.
Post by Heiner Steven
Aus diesem Grund finde ich es zwar in Ordnung, Lösungen
anzugeben die nur in einer spezifischen Shell funktionieren,
man sollte dies aber auch klarstellen.
Genau deshalb habe ich ja diesen Teilthread angefangen: Da hat jemand
- wie ich es auch ständig mache - gesagt "In der bash kannst Du Dein
Problem folgendermaßen lösen", und dafür ist ein anderer auf ihn
losgegangen. Das finde ich kontraproduktiv.


CU

Hauke
--
Die Ein-Mann-Unix-Entwicklungsabteilung: http://cr.yp.to
**********
Helfen Sie Open Source! Petition gegen Softwarepatente
http://petition.eurolinux.org/index_html
Heiner Steven
2003-10-03 18:42:39 UTC
Permalink
Post by Hauke Laging
Post by Heiner Steven
Andererseits hift es keinem, wenn die gleiche Funktionalität
in verschiedenen Shells unterschiedlich implementiert wird.
a=$[ 1 + 1 ]
versteht nur die BASH, aber
Ich habe mir das verwundert angeguckt und gedacht: "Was ist denn das
für eine Syntax, seit wann kann bash so was?" Und siehe da, es
funktioniert auch nicht.
bash: 1 + 1 : syntax error: operand expected (error token is
" 1 + 1 ")
$ bash
$ shtype
BASH 2.05b.0(1)-release
$ echo $[ 1 + 1 ]
2
$ uname -a
Linux goethe 2.4.20-4GB #1 Wed Aug 6 18:26:21 UTC 2003 i686 unknown unknown GNU/Linux
$ cat /etc/SuSE-release
SuSE Linux 8.2 (i586)
Post by Hauke Laging
Post by Heiner Steven
Oder "csh"/tcsh. Das heisst aber nicht, dass man deshalb
die Portabilität ignorieren kann. Mehr als 90% der Web-Benutzer
verwenden den Internet Explorer - sollte man deshalb alle
anderen Browser aussen vor lassen?
Nein, auf keinen Fall. Deshalb habe ich in einem anderen Posting auch
klar zwischen (potentiell) "öffentlichem" (da ging es um fi4l) und
"privatem" Einsatz unterschieden.
Vom Prinzip her stimme ich Dir zu. In der Realität ist
Portabilität (genau wie Sicherheit) aber kein Ein-/Ausschalter.
Ich kann nicht von einem Tag auf den anderen Sagen: "Na ja,
jetzt schreibe ich mein Skript einfach einmal portabel", oder
"jetzt mache ich ein Skript einfach mal absolut sicher".
Dazu gehört viel Übung und Erfahrung, und die bekommt
man nur durch andauernde Bemühungen.

Auch bei "privatem" und "öffentlichem" Einsatz gebe
ich Dir prinzipiell recht, aber auch dort gilt das Gleiche.
Oft ist "das Skript ist doch nur für mich" eine Ausrede
für Schlampigkeit.
Post by Hauke Laging
Womit andere in Berührung kommen,
das sollte in jeder Hinsicht vorbildlich sein. Dazu gehört auch der
Stil (Kommentierung usw.).
Post by Heiner Steven
Portabilität, Schnelligkeit, Einfachheit des Skriptes)
sind wichtiger.
Pick two ;-)
Post by Heiner Steven
Du meinst also
(1) wer Anfänger ist, verwendet die BASH
(2) wer keine Ahnung hat, interessiert sich nicht für Portabilität
Ja.
Aua. Auch ich war einmal ein Anfänger, verwendete aber nicht
die BASH.

Allerdings interessierte ich mich zu diesem Zeitpunkt aber
wirklich nicht sehr für Portabilität. Das kam erst,
als ich meine Skripten mit verschiedenen Unixen verwendete.
Post by Hauke Laging
Post by Heiner Steven
Es gibt auch UNIX-Benutzer, die kein Linux verwenden (und damit
wahrscheinlich keine Bash).
Das sind in der Tendenz wohl eher weniger die Anfänger.
Nicht unbedingt. Viele PC-Nutzer kommen erst bei
ihrer Arbeit mit UNIX in Berührung.
Post by Hauke Laging
Post by Heiner Steven
Dazu kommt, dass die meisten
BASH-spezifischen Konstrukte in Shell-Skripten nicht verwendet
werden, weil sie einfacher oder die einzige Möglichkeit sind
ein Problem zu lösen, sondern weil der Programmierer einfach
nicht weiss, dass sie unportabel sind.
Klar, geht mir ständig so. Ich denke aber, dass es einfacher ist,
erst mal eine Shell zu lernen und sich dann zu einem umfassenderen
Verständnis (das u.a. Portabilität beinhaltet) hochzuarbeiten, als
mit der Luxuslösung anzufangen.
Mit der "Luxuslösung" anfange ist BASH? Ich würde liebend
gerne ausschließlich ksh93 verwenden, da die Programmiersprache
mächtiger als die von BASH ist (z.B. assoziative Arrays, vergleichbar
mit Perl "Hashes"), aber leider ist sie (noch)
nicht ausreichend verbreitet. Vielleicht sehen wir ja irgendwann
einen POSIX-Standard, der den Funktionsumfang der ksh93
voraussetzt. Dies würde eine weitere Verbreitung garantieren.
Ob die Funktionalität dann von ksh93 oder von BASH zur
Verfügung gestellt wird, ist mir eigentlich gleich ;-)
Post by Hauke Laging
Post by Heiner Steven
Ein gelegentlicher
Hinweis auf Portabilitätsprobleme, oder vielleicht sogar
eine portable Alternativlösung würden uns allen helfen
z.B. unportable "configure" Skripten zu vermeiden.
Sehe ich genauso.
Post by Heiner Steven
Aus diesem Grund finde ich es zwar in Ordnung, Lösungen
anzugeben die nur in einer spezifischen Shell funktionieren,
man sollte dies aber auch klarstellen.
Genau deshalb habe ich ja diesen Teilthread angefangen: Da hat jemand
- wie ich es auch ständig mache - gesagt "In der bash kannst Du Dein
Problem folgendermaßen lösen", und dafür ist ein anderer auf ihn
losgegangen. Das finde ich kontraproduktiv.
Vielleicht war das nicht sehr produktiv. Besser ist es
natürlich (wie Erkan es vormachte) einfach eine Alternativlösung
aufzuzeigen.

Heiner
--
___ _
/ __| |_ _____ _____ _ _ Heiner STEVEN <***@nexgo.de>
\__ \ _/ -_) V / -_) ' \ Shell Script Programmers: visit
|___/\__\___|\_/\___|_||_| http://www.shelldorado.com/
Hauke Laging
2003-10-04 16:09:26 UTC
Permalink
Post by Heiner Steven
Post by Hauke Laging
Ich habe mir das verwundert angeguckt und gedacht: "Was ist denn
das für eine Syntax, seit wann kann bash so was?" Und siehe da, es
funktioniert auch nicht.
bash: 1 + 1 : syntax error: operand expected (error token is
" 1 + 1 ")
$ bash
$ shtype
BASH 2.05b.0(1)-release
$ echo $[ 1 + 1 ]
2
$ uname -a
Linux goethe 2.4.20-4GB #1 Wed Aug 6 18:26:21 UTC 2003 i686 unknown
unknown GNU/Linux $ cat /etc/SuSE-release
SuSE Linux 8.2 (i586)
Unter welchem Stichwort finde ich was dazu? "$[" taucht in man bash
anscheinend nicht auf.

Und warum funktioniert das bei der Variablenzuweisung nicht, aber bei
echo?


CU

Hauke
--
Die Ein-Mann-Unix-Entwicklungsabteilung: http://cr.yp.to
**********
Helfen Sie Open Source! Petition gegen Softwarepatente
http://petition.eurolinux.org/index_html
Ingo van Lil
2003-10-04 16:37:43 UTC
Permalink
Post by Hauke Laging
Post by Heiner Steven
$ echo $[ 1 + 1 ]
2
Unter welchem Stichwort finde ich was dazu? "$[" taucht in man bash
anscheinend nicht auf.
Keine Ahnung, ich hab auch nichts dazu gefunden. Aber gut zu wissen, daß
es nicht portabel ist, ich habe die Syntax bisher immer so verwendet.
Ist a=$((1+1)) portabel oder nur ((a=1+1))?
Post by Hauke Laging
Und warum funktioniert das bei der Variablenzuweisung nicht, aber bei
echo?
Wie meinen?

***@marvin:~>echo $[1+1]
2
***@marvin:~>a=$[1+1]
***@marvin:~>echo $a
2

Tschau,
Ingo
--
Hobbes: How come we play war and not peace?
Calvin: Too few role models. -- Bill Watterson, Calvin and Hobbes
Hauke Laging
2003-10-04 17:29:58 UTC
Permalink
Post by Ingo van Lil
Post by Hauke Laging
Und warum funktioniert das bei der Variablenzuweisung nicht, aber
bei echo?
Wie meinen?
2
Wie ich schon eingangs auf Heiner antwortete, klappt das bei mir
nicht:
a=$[ 1 + 1 ]
bash: 1 + 1 : syntax error: operand expected (error token is
" 1 + 1 ")

Oho, ich komme der Sache näher. Das eben war der von Heiner kopierte
Code. Deine Variante - also ohne Leerzeichen - funktioniert.


CU

Hauke
--
Die Ein-Mann-Unix-Entwicklungsabteilung: http://cr.yp.to
**********
Helfen Sie Open Source! Petition gegen Softwarepatente
http://petition.eurolinux.org/index_html
Ingo van Lil
2003-10-04 17:59:08 UTC
Permalink
Post by Heiner Steven
a=$[ 1 + 1 ]
bash: 1 + 1 : syntax error: operand expected (error token is
" 1 + 1 ")
Oho, ich komme der Sache näher. Das eben war der von Heiner kopierte
Code. Deine Variante - also ohne Leerzeichen - funktioniert.
Du hast eine merkwürdige bash.

***@marvin:~>a=$[ 1 + 1 ]
***@marvin:~>echo $a
2
***@marvin:~>bash --version
GNU bash, version 2.05b.0(2)-release (i586-pc-linux-gnu)
Copyright (C) 2002 Free Software Foundation, Inc.

Tschau,
Ingo
--
Hobbes: How come we play war and not peace?
Calvin: Too few role models. -- Bill Watterson, Calvin and Hobbes
Juergen Salk
2003-10-04 19:50:04 UTC
Permalink
Post by Ingo van Lil
Ist a=$((1+1)) portabel oder nur ((a=1+1))?
Genau genommen ist weder das eine noch das andere portabel.
Wirklich portabel (wenn man die Bourne-Shell zum Maß aller Dinge
macht) ist »a=`expr 1 + 1`«.

»a=$((1+1))« muss immerhin noch mit allen POSIX-Shells
funktionieren. Bei »((a=1+1))« (bzw. »let a=1+1«) ist
es dagegen nicht garantiert (siehe z.B. ash).

Beste Grüsse - Jürgen
Christian Schneider
2003-10-04 16:41:44 UTC
Permalink
Post by Hauke Laging
Post by Heiner Steven
Post by Hauke Laging
Ich habe mir das verwundert angeguckt und gedacht: "Was ist denn
das für eine Syntax, seit wann kann bash so was?" Und siehe da, es
funktioniert auch nicht.
bash: 1 + 1 : syntax error: operand expected (error token is
" 1 + 1 ")
$ bash
$ shtype
BASH 2.05b.0(1)-release
$ echo $[ 1 + 1 ]
2
$ uname -a
Linux goethe 2.4.20-4GB #1 Wed Aug 6 18:26:21 UTC 2003 i686 unknown
unknown GNU/Linux $ cat /etc/SuSE-release
SuSE Linux 8.2 (i586)
Unter welchem Stichwort finde ich was dazu? "$[" taucht in man bash
anscheinend nicht auf.
"Arithmetische Expandierung" waer 'n Versuch wert ;)
Post by Hauke Laging
Und warum funktioniert das bei der Variablenzuweisung nicht, aber bei
echo?
Damit erhaelt man nur(ß) den Ausdruck zurueck, weil alles was zwischen
den (eckigen) Klammern steht so behandelt wird, als stuende es zwischen
»"..."« (wobei man auch schachteln kann):
#v+
dreckskind:~ # echo $((1+1 ))
2
dreckskind:~ # echo $[1 +1]
2
dreckskind:~ # echo $((23+$[42/2]))
44
#v-
--
BOFH excuse #364:

Sand fleas eating the Internet cables
Christian Schneider
2003-10-04 16:43:08 UTC
Permalink
Post by Hauke Laging
Post by Heiner Steven
Post by Hauke Laging
Ich habe mir das verwundert angeguckt und gedacht: "Was ist denn
das für eine Syntax, seit wann kann bash so was?" Und siehe da, es
funktioniert auch nicht.
bash: 1 + 1 : syntax error: operand expected (error token is
" 1 + 1 ")
$ bash
$ shtype
BASH 2.05b.0(1)-release
$ echo $[ 1 + 1 ]
2
$ uname -a
Linux goethe 2.4.20-4GB #1 Wed Aug 6 18:26:21 UTC 2003 i686 unknown
unknown GNU/Linux $ cat /etc/SuSE-release
SuSE Linux 8.2 (i586)
Unter welchem Stichwort finde ich was dazu? "$[" taucht in man bash
anscheinend nicht auf.
"Arithmetische Expandierung" waer 'n Versuch wert ;)
Post by Hauke Laging
Und warum funktioniert das bei der Variablenzuweisung nicht, aber bei
echo?
Damit erhaelt man nur(?) den Ausdruck zurueck, weil alles was zwischen
den (eckigen) Klammern steht so behandelt wird, als stuende es zwischen
»"..."« (wobei man auch schachteln kann):
#v+
dreckskind:~ # echo $((1+1 ))
2
dreckskind:~ # echo $[1 +1]
2
dreckskind:~ # echo $((23+$[42/2]))
44
#v-
--
BOFH excuse #364:

Sand fleas eating the Internet cables
Andreas Jaeger
2003-10-04 12:54:54 UTC
Permalink
Post by Heiner Steven
Meine Erfahrung ist, dass 90% der BASH benutzer sie deshalb
verwenden, weil sie (a) "da ist" (default /bin/sh), und
(b) weil die Cursortasten funktionieren.
Treffen diese beiden Kriterien nicht auch auf /bin/tcsh zu?

Ich habe eher den Eindruck, die bash ist deswegen so beliebt,
weil sie unter Linux die Default-Shell darstellt. Oder war
sie vor Linux auch schon so verbreitet?
Ralf Draeger
2003-10-04 13:55:32 UTC
Permalink
Post by Andreas Jaeger
Post by Heiner Steven
Meine Erfahrung ist, dass 90% der BASH benutzer sie deshalb
verwenden, weil sie (a) "da ist" (default /bin/sh), und
(b) weil die Cursortasten funktionieren.
Treffen diese beiden Kriterien nicht auch auf /bin/tcsh zu?
Ich habe eher den Eindruck, die bash ist deswegen so beliebt,
weil sie unter Linux die Default-Shell darstellt. Oder war
sie vor Linux auch schon so verbreitet?
Es gab schon immer den Konsens, dass die Bourne-Derivate (mit ksh) zum
Skripten sind und man sich bei der Interaktion je nach Gusto entscheidet.

Die bash ist deshalb so beliebt, weil sie (fast) alles kann, was auch die
ksh kann, und dazu GPL. Die ksh hat einige sehr interessante Sachen, die
auch die pdksh nicht bietet (z.B. daß die letzte Pipe in der aktuellen
Shell ausgeführt wird), aber leider war sie zu lange nicht frei verfügbar.

Zu Deiner Frage: AFAIK ist bash Teil des GNU Projektes und wahrscheinlich
älter als Linux, allerdings ist sie erst mit Linux richtig hochgekommen,
da alle kommerziellen Systeme schon lange mit ksh ausgeliefert wurden und
diese dort sehr beliebt war.

Noch zwei Worte zu dem ganzen Geranzel:

Ad 1 steht es jedem Fragesteller frei auf eine Antwort zu sagen, "Bei mir
geht das aber nicht, weil ich mit der blahsh arbeite" und ihm werden dann
sicherlich auch einige Antworten gegeben, wie er es in jener welchen auch
hinkriegt.
Sofern die Lösung auf seinem System (nach Möglichkeit ohne ruminstallieren)
ans laufen kommt, ist er froh, daß sein Problem gelöst ist, womit ist
letztendlich egal.

Ad 2 sollte man immer im Auge behalten, was das Ziel ist. Ich gehe mal
davon
aus, daß mehr als 90% aller Skripte das arbeiten am eigenen System
erleichtern
sollen - da ist man nicht auf Portabilität angewiesen - warum sollte ich
auch
z.B. auf die erweiterten Regexps in sed verzichten, wenn es darum geht
meine
Logfiles auf meinem Server zu checken. Bei einer Neuinstallation (oder
einem
Systemwechsel) wird wohl meistens ein Superset an Optionen oder Programmen
zur Verfügung stehen, schliesslich ist das System in der Regel neuer als
das, welches es ersetzt. Und wenn nicht, dann kann ich mein Skript (so ich
es denn
überhaupt noch brauche) auch neuschreiben oder partiell umändern.

Schlussendlich finde ich immer den Aha-Effekt recht nützlich, ach, das kann
man damit also auch machen, schliesslich liest nicht nur der Fragesteller
mit, sondern auch etliche Andere und zum Lernen ist man nie gut genug.

Die Katze frisst Mäuse roh, ich nicht mal gekocht, dennoch verbiete ich es
ihr nicht; eine Haltung, die so manchem im Usenet guttäte, sonst fühlen
sich
diejenigen, die Lösungen anbieten könnten nicht mehr dazu bereit dies auch
zu tun und das Ganze geht dann den Bach runter.
--
Ceterum censeo fenestram esse deletam. -- Cicero after the XP-
Bug.
Erkan Yanar
2003-10-02 23:16:48 UTC
Permalink
Post by Ralph-Lehmann
Hi,
ich habe da ein Shell-Script, welches die Eingabe von Benutzerdaten
erfordert. Gibt es eine einfache Möglichkeit, die Eingabe des Passwortes zu
verstecken z.B. so, wie am login-prompt, mit Sternchen o.ä.?
susv3 kompatibel dürfte folgendes sein:

#v+
#!/bin/sh

old=$(stty -g)
stty -icanon -echo
pass=""
while a=$(dd bs=1 count=1 2>/dev/null);do
if [ "x$a" = "x" ]
then break
fi
pass=${pass}$a
printf '*'
done

stty $old
#v-

tschazu
erkan
--
über den grenzen muß die freiheit wohl wolkenlos sein
Heiner Steven
2003-10-03 16:56:25 UTC
Permalink
[...]
Post by Erkan Yanar
Post by Ralph-Lehmann
ich habe da ein Shell-Script, welches die Eingabe von Benutzerdaten
erfordert. Gibt es eine einfache Möglichkeit, die Eingabe des Passwortes zu
verstecken z.B. so, wie am login-prompt, mit Sternchen o.ä.?
[...]
Post by Erkan Yanar
#v+
#!/bin/sh
old=$(stty -g)
stty -icanon -echo
pass=""
while a=$(dd bs=1 count=1 2>/dev/null);do
if [ "x$a" = "x" ]
then break
fi
pass=${pass}$a
printf '*'
done
stty $old
#v-
Eine sehr gute Lösung. Da wir zu diesem Thema auch über
Post by Erkan Yanar
#!/bin/sh
old=$(stty -g)
Die erste Zeile impliziert eine Bourne-Shell, diese Art
der Kommandosubstitution funktioniert aber erst mit
der KornShell oder BASH/zsh.

Portabler wäre
old=`stty -g`
Post by Erkan Yanar
stty -icanon -echo
pass=""
pass=

reicht schon aus.
Post by Erkan Yanar
while a=$(dd bs=1 count=1 2>/dev/null);do
while a=`dd ...`
Post by Erkan Yanar
if [ "x$a" = "x" ]
then break
fi
Dies ist eine korrekte, portable Abfrage. Sie könnte
kürzer wie folgt geschrieben werden:

[ x"$a" = x ] && break

In der KornShell wäre folgendes möglich:

[[ -z $a ]] && break
Post by Erkan Yanar
pass=${pass}$a
pass=$pass$a

(Klammern sind überflüssig)
Post by Erkan Yanar
printf '*'
"printf" ist nicht überall vorhanden.
KornShell:

print -u2 '*'
Post by Erkan Yanar
done
stty $old
Wie gesagt, das Skript ist korrekt und funktioniert,
es könnte nur noch etwas optimiert (und portabler gemacht)
werden.

Heiner
--
___ _
/ __| |_ _____ _____ _ _ Heiner STEVEN <***@nexgo.de>
\__ \ _/ -_) V / -_) ' \ Shell Script Programmers: visit
|___/\__\___|\_/\___|_||_| http://www.shelldorado.com/
Erkan Yanar
2003-10-03 18:15:28 UTC
Permalink
Post by Heiner Steven
[...]
Post by Ralph-Lehmann
ich habe da ein Shell-Script, welches die Eingabe von Benutzerdaten
erfordert. Gibt es eine einfache Möglichkeit, die Eingabe des Passwortes zu
verstecken z.B. so, wie am login-prompt, mit Sternchen o.ä.?
[altes Skript]
Post by Heiner Steven
Eine sehr gute Lösung. Da wir zu diesem Thema auch über
[neues Skript]

Hallo Heiner,
danke für die Anmerkungen. Ich gestehe, daß bei mir /bin/sh immer eine
susv3-Shell meint. Ich mit protabel, portabel zu susv3 meine und

1. Eine Vorliebe für die $() habe (die gedeckt ist).
2. print im Standard nicht zu finden ist (nicht mal in der Bash ;-)
3. Das stty -icanon auf der AIX so eh nicht klappt.
4. Alle weiteren Anmerkungen rechtens sind. (Bis das ich keine Ahnung von
ksh habe.)

tschazu
erkan
--
über den grenzen muß die freiheit wohl wolkenlos sein
Internicserver
2003-10-12 08:34:40 UTC
Permalink
Redhat, SUSE, Debian, FreeBSD oder Windows
*TÜV-zertifiziertes grosstes Rechenzentrum in Europa mit USV,
Notstromversorgung und CO2-Brandschutz Backbone mit 4.3 GBit Internetbackbone.
Dedizierter Firewall-Schutz, individuell konfigurierbar als Packet-Filter.
Überwachung der Server rund um die Uhr auf die vitalen Dienste
HTTP/FTP/SMTP/POP3).
http://serverhaus.de/jobs.asp

Loading...