fork e console

[71104]

scusate se la domanda è banalissima per chi ne capisce di Linux e soprattutto scusate se avrei potuto trovarla in mille altri posti, ma credo di fare molto prima a fare una domanda mirata a voi piuttosto che scervellarmi a pensare delle keyword da rifilare a Google che mi pescano quarantamila cose che non ci pigliano una beneamata.

:D

la domanda, come si sarà intuito dal titolo del topic, è la seguente: come fo, su Linux, a fare in modo che un processo da me forkato abbia una nuova console anziché la stessa del padre? perché siccome il programma in questione è un programma che deve sia stampare su stdout che prelevare da stdin, logicamente se due processi hanno la stessa console succede un discreto casino. :D

grazie :)

[71104]

ah, e scusate se uso termini microsoftiani, ma naturalmente per "console" intendo una finestra di terminale. il processo forkato deve insomma aprirsi su un nuovo terminale con i suoi stdin e stdout nuovi di zecca.

[cionci]

Non credo che esista un modo portabile per fare questo...portabile nel senso di "compatibile con tutte le distro"...
Questo perché non esistono console distinte nell'os che originariamente era in testo...o meglio volendo puoi gestire più console contemporaneamente, ma devi fare 2 login distinti...
Quindi la soluzione più logica è quella di forkare il tuo processo tramite l'esecuzione di una nuova console (kterm o gnome-terminal)...

[ilsensine]

la domanda, come si sarà intuito dal titolo del topic, è la seguente: come fo, su Linux, a fare in modo che un processo da me forkato abbia una nuova console anziché la stessa del padre? perché siccome il programma in questione è un programma che deve sia stampare su stdout che prelevare da stdin, logicamente se due processi hanno la stessa console succede un discreto casino. :D

La domanda è molto "windowsiana" :D nel senso che sei abituato a pensare a una console come ad un oggetto del processo (come un file aperto, ecc). Sui sistemi unix i programmi "vedono" solo dei file descriptor, che - nel caso particolare delle console - sono implementati tramite "pseudoterminali".
Per risolvere compiutamente il tuo problema dovresti padroneggiare i pseudoterminali, e con essi dialogare con dei programmi che implementano quella che chiami "console" (ovvero un rettangolo dove viene stampato testo e dove si può scrivere con la tastiera). Ma per fare delle cose semplici, basta un paio di descrittori interconnessi e il gioco è fatto. Un paio di socket vanno benissimo, ad esempio:

#include <stdlib.h>
#include <stdio.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/socket.h>

int main()
{
int fd[2];
socketpair(AF_UNIX, SOCK_STREAM, 0, fd);
if (fork()==0) {
char cmd[128];
close(fd[0]);
sprintf(cmd, "xterm -Sunused/%d", fd[1]);
system(cmd);
_exit(0);
} else {
dup2(fd[0], fileno(stdout));
dup2(fd[0], fileno(stderr));
dup2(fd[0], fileno(stdin));
close(fd[0]);
close(fd[1]);
printf("Ciao!\n\r");
fflush(stdout);
while(1) {
char c;
if (fread(&c, 1, 1, stdin)!=1)
continue;
fprintf(stderr, "Hai premuto: %c\n\r", c);
}
}
return 0;
}

Nota che (forse perché non usiamo un vero pseudoterminal) ci sono alcune differenze con la console normale; innanzitutto il fflush su stdout non sembra essere effettuato in automatico ogni fine riga (stderr non è bufferizzato e non soffre di questo problema); infine il "\n" non implica anche "\r", che devi dunque aggiungere manualmente.
Spero ti sia utile.

[71104]

uhm uhm :wtf: non me l'aspettavo, speravo che esistesse una risposta semplice come per Windows... :mbe:

ma essendo questa l'ottica allora come dovrebbe fare, nel caso tipico, un processo forkato a prendere da stdin? se entrambi i processi si bloccano su una getchar c'è qualche criterio con cui l'input dell'utente va all'uno o all'altro processo (o a entrambi) oppure è una cosa completamente casuale? in questo secondo caso quindi come faccio, sincronizzo con un semaforo?

[ilsensine]

uhm uhm :wtf: non me l'aspettavo, speravo che esistesse una risposta semplice come per Windows... :mbe:
Mi sembra semplice come risposta...

ma essendo questa l'ottica allora come dovrebbe fare, nel caso tipico, un processo forkato a prendere da stdin? se entrambi i processi si bloccano su una getchar c'è qualche criterio con cui l'input dell'utente va all'uno o all'altro processo (o a entrambi) oppure è una cosa completamente casuale? in questo secondo caso quindi come faccio, sincronizzo con un semaforo?
:D Devi mondare la tua mente dalle finestre e cominciare a ragionare con i file descriptor.
Cosa accade se apri un socket, effettui un fork ed entrambi i programmi tentano di leggere dal socket? La stessa cosa accade su stdin.
Lancia questo programma e tieni premuto invio; vedrai che i dati vanno o a un processo o all'altro, casualmente:

#include <stdlib.h>
#include <stdio.h>
#include <unistd.h>

int main()
{
char buf[128];
if (fork()==0) {
fprintf(stderr, "Child\n");
while (1) {
fgets(buf, sizeof(buf), stdin);
fprintf(stderr, "Child: %s", buf);
}
} else {
fprintf(stderr, "Parent\n");
while (1) {
fgets(buf, sizeof(buf), stdin);
fprintf(stderr, "Parent: %s", buf);
}
}
return 0;
}

ovvero: il risultato è indeterminato. Non devi procedere così.

Tornando a noi, questa versione "rivista" del programma precedente forse ti aiuta a vedere le cose in maniera più simile a windows. Basta con gli hack e usiamo gli pseudoterminali:

// nb devi linkare con -lutil
#include <stdlib.h>
#include <stdio.h>
#include <unistd.h>
#include <pty.h>
#include <termios.h>
#include <signal.h>
#include <sys/types.h>
#include <sys/wait.h>

typedef struct xConsole
{
int master;
int slave;
struct termios tios;
pid_t process;
} xConsole;

xConsole *CreateConsole()
{
xConsole *ret = calloc(sizeof(*ret), 1);
openpty(&ret->master, &ret->slave, NULL, &ret->tios, NULL);
cfmakeraw(&ret->tios);
ret->tios.c_oflag |= OPOST|ONLCR;
tcsetattr(ret->master, TCSAFLUSH, &ret->tios);
ret->process = fork();
if (ret->process==0) {
char cmd[128];
close(ret->slave);
sprintf(cmd, "xterm -S/%d", ret->master);
free(ret);
system(cmd);
_exit(0);
}
usleep(250000); /* Attendi che xterm parta e scriva la sua spazzatura */
return ret;
}

void DestroyConsole(xConsole *c)
{
kill(c->process, SIGTERM);
waitpid(c->process, NULL, 0);
close(c->master);
close(c->slave);
free(c);
}

void SelectConsole(xConsole *c)
{
tcflush(c->master, TCIOFLUSH);
dup2(c->slave, fileno(stdout));
dup2(c->slave, fileno(stderr));
dup2(c->slave, fileno(stdin));
}

void ExecConsoleApp(const char *app)
{
if (fork()==0) {
xConsole *con = CreateConsole();
con->tios.c_lflag |= (ICANON|ECHO);
tcsetattr(con->master, TCSAFLUSH, &con->tios);
SelectConsole(con);
system(app);
DestroyConsole(con);
_exit(0);
}
}

int main()
{
xConsole *con[2];
con[0] = CreateConsole();
con[1] = CreateConsole();
SelectConsole(con[0]);
printf("Ciao!\n");
printf("Premi 2 per passare alla seconda console\n");
printf("Premi q per terminare\n");
printf("Premi e per eseguire un programma interattivo (bash)\n");
while(1) {
char c;
if (fread(&c, 1, 1, stdin)!=1)
continue;
printf("Hai premuto: %c\n", c);
if (c=='1') {
SelectConsole(con[0]);
printf("Console 1 attivata. Premi 2 per passare alla seconda console\n");
} else if(c=='2') {
SelectConsole(con[1]);
printf("Console 2 attivata. Premi 1 per passare alla prima console\n");
} else if (c=='q') {
break;
} else if (c=='e') {
ExecConsoleApp("bash");
}
}
DestroyConsole(con[0]);
DestroyConsole(con[1]);
return 0;
}

[71104]

MA LOOOL, hai nominato le funzioni con una nomenclatura Win32 per farmi sentire più a mio agio o cosa? :rotfl:
aspetta che leggo bene :D
EDIT - comunque grazie dell'interessamento! :)
EDIT2 - e non te ne andare che la discussione non è ancora finita eh :D

[71104]

maronn', e dire che Windows mi risolveva tutto con un unico flag da passare alla CreateProcess T_T
lo so che è un modo di ragionare incompatibile con la piattaforma, ma non riesco a fare a meno di pensare al problema che avevo e a come Windows me lo risolva e Linux no :D

comunque, provando anche a ragionare più compatibilmente con Linux, mi è saltato in testa questo ragionamento: se l'utente del mio programma decide di avviare il sistema operativo senza avviare X (cioè lavora con un unico terminale...) allora non posso pretendere di avere finestre diverse; il sistema però continua ad essere multitasking, e siccome il mio programma deve poter girare anche in questa situazione, ne consegue che devo per forza organizzarmi un qualche sistema di sincronizzazione/gestione dell'unico terminale che ho. quindi a questo punto è solo una questione di design (stavo pensando di tenermi in ogni processo una lista dei processi forkati sui quali è possibile "switchare" la console).

perdonami se ti ho fatto scrivere quel quintale di roba ma purtroppo temo di non poterla proprio usare: :muro: ho ragionato in maniera errata all'inizio dimenticandomi che Linux non parte dal presupposto che... ci sono le finestre :huh:

tra l'altro (solo per curiosità a questo punto), quanto sarebbe stato portabile tra una distro e l'altra richiamare xterm? in quali distro dotate di grafica xterm non è presente?

[ilsensine]

maronn', e dire che Windows mi risolveva tutto con un unico flag da passare alla CreateProcess T_T
lo so che è un modo di ragionare incompatibile con la piattaforma, ma non riesco a fare a meno di pensare al problema che avevo e a come Windows me lo risolva e Linux no :D
Hai scelto la pillola azzurra stamattina, vero? :D

comunque, provando anche a ragionare più compatibilmente con Linux, mi è saltato in testa questo ragionamento: se l'utente del mio programma decide di avviare il sistema operativo senza avviare X (cioè lavora con un unico terminale...) allora non posso pretendere di avere finestre diverse
Puoi allocare un tty. Quei cosi che si vedono premendo ctrl+alt+f1-2-3...
Anche X usa un tty, normalmente su f6.
Puoi anche passare da un tty all'altro, essere informato dal kernel quando l'utente sceglie di cambiare tty, ecc.
Non chiedermi altro che non sono pratico della cosa, ma puoi vedere come funziona getty.

tra l'altro (solo per curiosità a questo punto), quanto sarebbe stato portabile tra una distro e l'altra richiamare xterm? in quali distro dotate di grafica xterm non è presente?
xterm è presente in tutte le distribuzioni, anche se molte non lo installano di default (è comunque di sicuro sui cd). Un modo più "linux friendly" è far sì che sia il terminale (xterm, konsole, rxvt ecc.) a gestire la nuova applicazione; ad es. prova ad eseguire:
konsole --noclose -e ls

[71104]

Hai scelto la pillola azzurra stamattina, vero? :D Matrix l'ho visto però non mi ricordo cosa faceva la pillola blu e cosa faceva quella rossa :D
quella rossa lo faceva uscire da Matrix e quella blu lo faceva tornare alla vita di tutti i giorni o il contrario?

Puoi allocare un tty. Quei cosi che si vedono premendo ctrl+alt+f1-2-3...
Anche X usa un tty, normalmente su f6.
Puoi anche passare da un tty all'altro, essere informato dal kernel quando l'utente sceglie di cambiare tty, ecc.
Non chiedermi altro che non sono pratico della cosa, ma puoi vedere come funziona getty. rotfl? aspetta aspetta che questa cosa mi interessa!! :huh:

ora mi informo meglio, ma mi suona tanto come se fosse fatta apposta a risolvere tutti i miei problemi (sai quando senti il coro angelico e vedi la soluzione con tutte quelle stelline di magia e un'aura di luce attorno? si esatto, come i biscotti Pan di stelle, solo che col coro angelico anziché la musica pop :huh: )

xterm è presente in tutte le distribuzioni, anche se molte non lo installano di default (è comunque di sicuro sui cd). Un modo più "linux friendly" è far sì che sia il terminale (xterm, konsole, rxvt ecc.) a gestire la nuova applicazione; ad es. prova ad eseguire:
konsole --noclose -e ls questo è il colmo! adesso il programmatore deve programmare in modo operating system friendly anziché user friendly :D
ma per ora vada per tty.

[71104]

Hai scelto la pillola azzurra stamattina, vero? :D o ti riferivi al Viagra...? :huh:

[ilsensine]

o ti riferivi al Viagra...? :huh:
L'enoteca ha già aperto, vedo :D

Tiè:

#include <stdlib.h>
#include <stdio.h>
#include <unistd.h>
#include <sys/ioctl.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <linux/vt.h>

int main()
{
int vt0 = open("/dev/tty0", O_RDWR);
int fd;
int req;
char vt[64];
ioctl(vt0, VT_OPENQRY, &req);
sprintf(vt, "/dev/tty%d", req);
fprintf(stderr, "Using vt %s\n", vt);
fd = open(vt, O_RDWR);
dup2(fd, fileno(stdin));
dup2(fd, fileno(stdout));
dup2(fd, fileno(stderr));
close(fd);
ioctl(vt0, VT_ACTIVATE, req);
close(vt0);
system("bash");
return 0;
}

[ilsensine]

(ah ovviamente devi essere root per utilizzare i virtual terminal. Se ti viene da chiedermi il perché, prendi 'sta benedetta pillola rossa una buona volta :p )

[71104]

(ah ovviamente devi essere root per utilizzare i virtual terminal. Se ti viene da chiedermi il perché, prendi 'sta benedetta pillola rossa una buona volta :p ) e massì!! non posso mica interrompere una strada didattica già intrapresa a metà. sentiamo il motivo :)

ma non è che ci sarebbe modo di fare il tutto senza richiamare programmi esterni (nell'ultimo esempio hai richiamato bash), diciamo senza mai utilizzare la funzione system?

[ilsensine]

e massì!! non posso mica interrompere una strada didattica già intrapresa a metà. sentiamo il motivo :)
I tty sono le console di sistema, utilizzati in genere per il login (mgetty) o da programmi quali X. L'utente non ha motivo di utilizzarle direttamente, innanzitutto perché interferirebbe con i programmi che eventualmente la usano, poi perché rischierebbe di causare un DoS (immagina che divertente un programmino che ogni mezzo secondo cambia vt a caso!), quindi perché devo potermi loggare tranquillamente in una console senza chiedermi se è un trojan che sta emulando una console di login di getty per sniffarmi la password. Eccetera :)

ma non è che ci sarebbe modo di fare il tutto senza richiamare comandi esterni (nell'ultimo esempio hai richiamato bash), diciamo senza mai utilizzare la funzione system?
Era solo un esempio; mi serviva un programma interattivo e bash è il primo che mi è venuto in mente.

[71104]

ma cosa dovrebbe succede premendo ctrl+alt+f1, oppure f2, f3... ? :wtf:
ho provato anche ctrl+alt+f6 su una fedora core 7 (ovviamente in modalità grafica), in tutto il monitor non cambia una virgola... :huh:

[71104]

ho anche provato a compilare quel sorgente (l'ultimo, quello in cui lanci bash con system) e a farlo andare dopo aver chiamato su: Linux mi è entrato in modalità testuale e ho provato a premere ctrl+alt+tutti i tasti funzione che ho, uno per volta, manco a dirlo non è cambiato nulla :mbe:
poi siccome non sapevo come ritornare in modalità grafica da bravo windowsista ho premuto ctrl+alt+canc (:asd: ) e mi si è riavviato (lol, mi ricorda Windows 98...)

[71104]

e poi /dev/console che è? se stampo su /dev/console dove mi ritrovo quello che stampo?

corrisponde per caso a /dev/tty0 ? :huh:

[ilsensine]

ma cosa dovrebbe succede premendo ctrl+alt+f1, oppure f2, f3... ? :wtf:
Dovrebbero comparirti le console testuali per il login.
Linux ha un certo numero di terminali "virtuali" (normalmente 63); puoi pensare a un terminale come a un diverso "monitor", dentro il quale puoi eseguire una istanza di X, un programma console, alcuni ci ficcano i log, ecc.
In genere (ma ci sono eccezioni) i terminali virtuali da 1 a 6 sono riservati a mgetty (login in modalità console), il 7 (non il 6, mi ero sbagliato) a X; i successivi sono liberi per istanze aggiuntive di X o altri programmi.
Per passare da un VT all'altro puoi usare, sotto X, la combinazione ctrl+alt+f1..f12 (per i VT successivi è necessario un programma, chvt). Direi che è alquanto "impossibile" che non ti funzioni, è un pò che non tocco fedora ma è così ovunque...

[71104]

ma posso premere ctrl+alt+fx in un momento qualsiasi, schermata qualsiasi? lo posso fare loggato come utente di uso corrente o devo farlo come root?

io accendo la virtual macchine, si avvia tutto, inerisco username e password dell'account limitato (si chiama "a71104" :p) e mi si apre il desktop con le mie icone; premo ctrl+alt+f1 e non cambia nulla :confused:
ctrl+alt+f2... idem
ctrl+alt+f3... idem
ctrl+alt+f4...

:confused:

[ilsensine]

ho anche provato a compilare quel sorgente (l'ultimo, quello in cui lanci bash con system) e a farlo andare dopo aver chiamato su: Linux mi è entrato in modalità testuale e ho provato a premere ctrl+alt+tutti i tasti funzione che ho, uno per volta, manco a dirlo non è cambiato nulla :mbe:
ctrl e alt di sx?

poi siccome non sapevo come ritornare in modalità grafica da bravo windowsista ho premuto ctrl+alt+canc (:asd: ) e mi si è riavviato (lol, mi ricorda Windows 98...)
Tu c'hai grossa crisi... :D
e poi /dev/console che è? se stampo su /dev/console dove mi ritrovo quello che stampo?
E' la console di sistema. Se sei dentro un VT _vero_ (quindi in modalità caratteri...vedi i vari ctrl+alt+fx che non ti funzionano), ti verrà stampato sullo schermo (sul tuo VT attuale) quello che scrivi. Sotto X non funziona, in quanto vengono usati i pseudoterminali.

corrisponde per caso a /dev/tty0 ? :huh:
No

[ilsensine]

ma posso premere ctrl+alt+fx in un momento qualsiasi, schermata qualsiasi? lo posso fare loggato come utente di uso corrente o devo farlo come root?
Sì in un momento qualsiasi. Anzi il "ctrl" è necessario solo sotto X.

io accendo la virtual macchine
Forse dipende dalla virtual machine, non ho _mai_ visto un linux dove ctrl+alt+ non funzionasse. Anzi non mi chiedere come si disabilita, perché...non lo so :D

(perché non installi linux su disco e inscatoli windows dentro la macchina virtuale? :ciapet: )

[71104]

ctrl e alt di sx? ovvio che si, ma la sai la cosa bella? ho provato in questo istante con ctrl+alt+SHIFT (tutto a sinistra) e funziona :D

ho provato con F1 e mi mostra un prompt che dice "localhost login: _"

per tornare in modalità grafica come si fa? e come mai se provo gli altri tasti funzione (compreso F7) non cambia nulla? ste consoles so tutte identiche o ce n'è una sola? :D

[71104]

Sì in un momento qualsiasi. Anzi il "ctrl" è necessario solo sotto X. aaaaaaaaa ecco; quindi ora che sono entrato in un... tty (giusto?) posso premere solamente shift+alt+fx...

(perché non installi linux su disco e inscatoli windows dentro la macchina virtuale? :ciapet: ) hai presente quando un ex-windowsista corrotto a linux ti dice che riesce finalmente ad avere la sensazione del controllo del sistema? :D
ecco, per me la situazione è precisamente simmetrica; con la differenza però che prima non usavo linux :asd:

[71104]

OLèèèèè, quando sono dentro il tty non serve neanche shift: basta solo alt e il tasto funzione :read:

e per tornare in modalità grafica? ho provato alt+f8 e mi mostra un desktop vuoto

[ilsensine]

ovvio che si, ma la sai la cosa bella? ho provato in questo istante con ctrl+alt+SHIFT (tutto a sinistra) e funziona :D

vmware/vmplayer?

[ilsensine]

e per tornare in modalità grafica? ho provato alt+f8 e mi mostra un desktop vuoto
f7

[71104]

:doh: :doh: :doh:

è vero cavolo, uso il vmware player, lo shift serve assieme a ctrl+alt perché se premo anche canc Windows mi piazza il tasc menagger :D

[71104]

f7 ooooook.

detto questo: ma in tutto sono possibili solamente 12 console? :confused:
meno le 7 già allocate...

[ilsensine]

Prova ora a lanciare questo:
startx -- :1
e a passare da ctrl(+shift)+alt+f7 a ctrl(+shift)+alt+f8...

[ilsensine]

detto questo: ma in tutto sono possibili solamente 12 console? :confused:

Ti ho detto che sono 63. Le prime dodici sono accessibili con i tasti funzione, le altre con chvt.

(tralascio di commentare il "solamente"... :asd: )

[71104]

Prova ora a lanciare questo:
startx -- :1
e a passare da ctrl(+shift)+alt+f7 a ctrl(+shift)+alt+f8... e in pratica che avrebbe dovuto fare, creare un nuovo tty? ho provato a farlo e ora se vado su f8 c'è una schermata nera in modalità testuale (totalmente vuota) in cui posso scrivere, ma se torno su f7 mi è apparsa nella... corrispondente linux della system tray (:D) una stella con una vignetta che mi rifila una roba tipo "SELinux is preventing access to files with the default label default_t" :mbe:

[ilsensine]

e in pratica che avrebbe dovuto fare, creare un nuovo tty? ho provato a farlo e ora se vado su f8 c'è una schermata nera in modalità testuale (totalmente vuota) in cui posso scrivere, ma se torno su f7 mi è apparsa nella... corrispondente linux della system tray (:D) una stella con una vignetta che mi rifila una roba tipo "SELinux is preventing access to files with the default label default_t" :mbe:
Mabbaffanzum... :D avrebbe dovuto lanciarti una nuova istanza di X :D
Ok puoi sempre farlo da root, se SELinux non ha nulla in contrario.

[71104]

Ti ho detto che sono 63. Le prime dodici sono accessibili con i tasti funzione, le altre con chvt. ah scusa questa me l'ero persa ^^

(tralascio di commentare il "solamente"... :asd: ) ahò, comincia a dire che 7 sono già allocate e quindi te ne rimarrebbero solo 5; se su una macchina server fai partire 3 programmi server tutti e 3 fatti per allocarsi un paio di tty direi che 12 finiscono in fretta :D

[ilsensine]

ahò, comincia a dire che 7 sono già allocate e quindi te ne rimarrebbero solo 5; se su una macchina server fai partire 3 programmi server tutti e 3 fatti per allocarsi un paio di tty direi che 12 finiscono in fretta :D
/etc/inittab, puoi toglierli anche tutti se ti danno fastidio :cool:
(o aggiungerne altri se sei veramente esoso...max 63 ok? Altrimenti devi modificare il kernel :D )

[ilsensine]

direi che 12 finiscono in fretta :D
Visto l'uso veramente originale che intendi farne, non ne dubito :D

[71104]

Ok puoi sempre farlo da root, se SELinux non ha nulla in contrario. omg, ma me l'ha fatta partire come root... cioè la cartella della home adesso si chiama "root's home" :D è meglio che riavvio :asd:

ok, adesso mi è tutto molto più chiaro. ultima cosa: se ho ben capito allora /dev/console è quell'entità su cui va a finire il tty corrente, ovvero se per esempio vado su ctrl+alt+f1 allora tty0 va a finire su /dev/console...

:huh:

perdona se ho sparato una trafila di p***anate inascoltabili :asd:
in tal caso correggimi :D

[71104]

Visto l'uso veramente originale che intendi farne, non ne dubito :D ma vabbè, a parte gli scherzi per quello che devo fare io 63-7 bastano e avanzano abbondantemente :p

diciamo che co sto programma potrei arrivare ad usarne 5 o 6 :|

[ilsensine]

ok, adesso mi è tutto molto più chiaro. ultima cosa: se ho ben capito allora /dev/console è quell'entità su cui va a finire il tty corrente, ovvero se per esempio vado su ctrl+alt+f1 allora tty0 va a finire su /dev/console...

:huh:

Non mi chiedere molto su /dev/console, è un oggetto alquanto strano. Se dalla tty1 scrivi su /dev/console, l'output finirà nella...tty1. Se ci scrivi dalla tty2, finirà su...tty2. Ovvero, viene connesso dal kernel al VT "attivo".

Credo che rappresenti l'interfaccia di interazione con l'utente.

[ilsensine]

ma vabbè, a parte gli scherzi per quello che devo fare io 63-7 bastano e avanzano abbondantemente :p

tsk ti accontenti di un solo X server quando puoi averne 50...:D

[71104]

Non mi chiedere molto su /dev/console, è un oggetto alquanto strano. Se dalla tty1 scrivi su /dev/console, l'output finirà nella...tty1. Se ci scrivi dalla tty2, finirà su...tty2. Ovvero, viene connesso dal kernel al VT "attivo".

Credo che rappresenti l'interfaccia di I/O di interazione con l'utente. penso più o meno quello che avevo capito io: l'utente scrive sulla console, quello che scrive va a finire su /dev/console, qualche parte di software di Linux non meglio precisata vede che il tty corrente è (per esempio) l'1, e allora l'input preso da /dev/console va sul tty1 e può essere letto da esso.

comunque non credo proprio mi serva, chiedevo solo per completezza.

GRAZIE DI TUTTO!! :cry: