> > >rpetre wrote: > >>>Deci 2>&1 nu inseamna ca il versi pe 2 in 1. 1 si 2 sint "file >>>descriptor". >>> >>Adica asa e conventia, orice program care ruleaza are la dispozitie 3 >>file descriptori pe care cineva s-a gandit sa-i boteze 0, 1 si 2 in loc >>de stdin, stdout si stderr. >>Atata cel putin stiu (cred). >> >Nu, raspuns gresit. Kernelul tine niste tabele cu fisierele deschise de >fiecare process (cate una pe proces). File-descriptorii utilizati de >apelurile de nivel jos sunt de fapt indecsi in aceasta tabela. Cand s-a >implementat CRT (C Runtime Library) pe UNIX - care CRT pe majoritatea >sistemelor GNU/Linux se numeste glibc :-) - inca de la primele versiuni >ale acesteia (adica pe primul UNIX, in '71) s-a luat decizia sa se >introduca niste functii ce lucreaza cu "streamuri". Structurile cu care >lucreaza aceste apeluri (flopen, fclose, fprintf, etc.) - FILE* au >undeva inauntru un int - un file descriptor - cu care lucreaza de fapt >kernelul. >Pentru intrarile 0,1, 2 in tabela de fisiere deschise (file descriptorii >0,1,2) - care sunt prin conventie fisierul de intrare, iesire si >raportare erori, s-au declarat niste variabile globale FILE* care li s-a >dat numele stdin, stdout, stderr. >Deci, nu "3 file descriptori pe care cineva s-a gandit sa-i boteze 0, 1 >si 2 in loc de stdin, stdout si stderr", ci exact invers :-) > Adica daca fac un program care lucreaza cu un file descriptor numit, sa zicem, 'gogu', gogu=3 ?
Petre "and just when I thought I got it..." --- Pentru dezabonare, trimiteti mail la [EMAIL PROTECTED] cu subiectul 'unsubscribe rlug'. REGULI, arhive si alte informatii: http://www.lug.ro/mlist/
