Wenn Du sie weg lässt, dann piept es nicht auf tty10 sondern evtl. dort, wo es ausgeführt wird, doch kann das auch so piepsen, wie das TTY?

Eigentlich wird die Umleitung benötigt, damit das Piepsen nicht woanders landet. Theoretisch könnte es auch in einem Log landen statt direkt zu piepsen. Das Log würde dann z.B. piepsen, wenn man es mit "cat" ansieht.

Wenn bei Dir ">/dev/tty10" auf der erste Konsole geschrieben wird, dann ist etwas falsch. Denn das sollte von er Shell interpretiert und nicht ausgegeben werden. Bitte versuche mal sowas:Geht das besser?

Zitat

Original von oziris
Geht das besser?

wieso, es piept doch, wo ist das problem?
die umleitung kann er weglassen und ok.

wenn du die ausgabe der leerzeile unterbinden willst, nimm einfach
echo -ne "\007"
die option n unterbindet die ausgabe des newline durch echo.

Ich bin mir eben nicht sicher, dass delix das nicht irgendwo testet und es dann aber woanders implementiert, wo es dann am Ende eben doch im Log landet, statt zu piepsen. Würde die Umleitung funktionieren, dann wäre es ganz sicher, dass es nicht im Log landet und eine komische Zeile gäbe es dann auch nicht; daher der Befehl den ich Vorschlug. ...aber egal, weil delix kann sich ja dann nochmal melden, falls es Probleme gibt.

Zitat

Original von oziris
und eine komische Zeile gäbe es dann auch nicht; daher der Befehl den ich Vorschlug. ...aber egal, weil delix kann sich ja dann nochmal melden, falls es Probleme gibt.

die zeilenschaltung gibt es wegen dem fehlenden n

Ich meine doch nicht nur eine neue Leerzeile, sondern eine komische Zeile mit "> /dev/tty10" drin.

Zitat

Original von delix
auf der 1.Konsole wird bei jedem Piep eine Zeile geschrieben; entweder ein >/dev/tty10 oder wenn's leer ist eben eine Leerzeile.

Daraus schloss ich, dass "> /dev/tty10" nicht von einer Shell interpretiert wird, sondern so ausgegeben wird, als hätte man das ">" in der Shell esaped ("\>") oder ge-quote-et bzw. als würde das ohne Shell oder anstatt einer Shell gestartet.

nein, eine bash wird da höchstwahrscheinlich nicht laufen, aber die ausgabe wird wahrscheinlich auf vc10 landen und das virtuelle terminal piepen lassen.
er kann ja m,al einen text ausgeben, zb

echo "test" > /dev/tty10
und dann mal auf vc10 nachschauen
hilfreich ist auch ein
ls -al /dev/tty10

die aussage es gäbe kein /dev/tty10 halte ich für unsinnig.

der grund für die umleitung > /dev/tty10 ist relativ einfach.
wenn du ein programm in einer interaktiven shell startest, dann sind stdin/stdout und stderr mit einem wirklichen terminal verbunden und die ausgaben zb von echo (ohne ausgabeumleitung) landen auf eben diesem terminal.
wird ein programm jedoch durch das system im hintergrund gestartet (zb durch crond), dann gibt es keine verbindung zu einem realen terminal, weil das programm in einer nichtinteraktiven shell läuft und diese die ausgaben nicht auf ein reales terminal leiten kann. je nach konfiguration können diese ausgaben dann in einer logdatei (wie oziris schon schrieb) oder zb einer mail an root landen. um das zu vermeiden, leiten einige solche ausgaben an ein terminal um, das nicht durch einen getty-prozess belegt ist, an dem also kein user angemeldet sein kann.
in vielen systemen sind nur vc1..vc6 mit gettys belegt und vc7 mit dem X, die restlichen sind frei.
der vorteil ist, dass man mit solchen umleitungen (z.b. > /dev/tty10) die aktuellen meldungen der programme auf einem terminal verfolgen kann und nicht die logs zumüllt und es auch wirklich piepst, denn wenn die ausgabe im log landet, piepst nichts.

und

wieso grabenkrieg?

wir tauschen ganz sachlich argumente aus. grabenkriege sind was für idioten.

gern geschehen

Also hab ich's doch richtig verstanden. Das bedeutet, das Sylpheed das ohne Shell ausführt (sehr ungewöhnlich) oder escape-t bevor es das an die Shell gibt (Einige exec-Funktionen geben Befehle an eine Shell weiter; i.d.R. /bin/sh ). Dadurch wird die Umleitung nicht interpretiert und auf STDOUT ausgegeben, was in diesem Fall das VT ist, auf dem der Xserver mit dem Window-Manager als Client gestartet wurde.
Ich frage mich, warum die Entwickler sich für sowas entschieden haben... verwirrt doch nur unnötig, oder?

das slyp-dingens (kenn ich nicht) läuft wohl als childprozess der startenden konsole (müsste man sich mit pstree mal anschauen) und erbt die umleitungen auf die konsole. der unterschied besteht also im prinzip nur darin, dass einmal die konsole vc/10 und andermal die startende konsole gepiept haben, je nachdem ob er die umleitung eingetragen hatte oder nicht.
sollte das teil im hintergrund laufen (daemon-mode oder was auch immer) dann würde das piepen ohne die umleitung dann auch verschwinden.

wie auch immer, jetzt funktionierts erst einmal so wie delix das wollte.

So könnte es z.B. gehen: