SO - Alto nivel.

[cortex]

hehehe!


parabéns pela aula Marcelo!!

[enigmabox]

O Marcelo, deu uma pequena aulinha porque é meio "leigo em Linux"...hahaha
Pergunta sobre o unix do MAC....vai escrever um livro aqui!!!!
Outra coisa, esta hierarquia de diretorios do Unix segue um padrão, mas em algumas versões de linux/unix, podem ter alguns comandos diferentes ou alguns arquivos de configuração do sistema alocados em outros subdiretorios.
Por exemplo, analisando os sistemas Solaris10, Linux Debian e MACOSX, é possível ver que alguns arquivos de configuração estão em diretorios ou subdiretorios diferentes.
Dependendo da aplicação a ser executada, se for compilado no sistema, via gcc por exemplo, pode funcionar sem problemas, mas se portar esta mesma aplicação compilada de um sistema para outro, as vezes pode apresentar problemas.

[polesapart]

Como o marcelo citou, existem normas (standards) como a FHS.

Estas normas foram criadas a posteriori, décadas depois do unix ter sofrido mutações e criado filhotes com "sotaques" diferentes. Então a aderência aos standards costuma ser parcial.

No caso do Linux, você tinha o slackware, o red hat & o debian. Cada um com uma política mais ou menos diferenciada. Como a red hat & as empresas que clonavam o red hat e revendiam pelo triplo do preço (ou não, vide conectiva) focaram em atender soluções em ambiente corporativo, onde a normatização é uma questão de necessidade (Um amigo, que o marcelo conhece, o xsandro, cuidava de não sei quantas centenas de servidores na embratel, imagina a trabalheira se cada um for uma penteadeira de p*** enfeitada diferente), acabaram tentando se padronizar primeiro. Logo em seguida vieram os debian-like com suas tentativas de padronização open source. Como tudo feito por um monte de gente que discorda, levou um tempo até sair algo realmente unificado.

O slackware gozou de uma posição privilegiada, pois como foi a primeira distribuição linux a ter uma massa de usuários (isso começou antes da internet chegar aqui no br e conseqüentemente apenas meia duzia de pessoas conheciam o Linux ainda), a sua hierarquia de diretórios & outros detalhezinhos de personalidade foi de certa forma um padrão per se por muito tempo.

Uma coisa que impactava bastante é que nesta época a criatividade das pessoas estava em alta, então surgiam muitos aplicativos novos, e forks (derivações) de outros, e cada um sugeria uma árvore de instalação conforme a cabeça de quem escreveu (arquivos de config iam parar do /etc ao /usr/lib , passando por /var/etc /var/lib/aplicativo, /usr/etc e por aí vai). Isso tudo na mesma distribuição e independente de qual fosse, então era meio caótico.

Hoje de certa forma a situação está mais confortável, com maior aderência as normas. Eu digo as normas, por que ainda existem várias, cada unix sempre vai ter sua "personalidade", mas como o marcelo falou, isto é algo que vc acostuma com o tempo. No meu caso a única coisa que não acostumo é quando o shell do unix é tapadão, aí dou um jeito de instalar o bash

[fabim]

não deem bola para o marcelo, ele é um anarfalbético sobre unix e linux..

Mas mesmo assim, gostei das aulas, e tem algo mais a acrescentar seguindo a lógica ?

Tipo, que tal falar sobre a forma que o shell fala com o kernel e acessa e trata os perifericos>!

[msamsoniuk]

não deem bola para o marcelo, ele é um anarfalbético sobre unix e linux..

Mas mesmo assim, gostei das aulas, e tem algo mais a acrescentar seguindo a lógica ?

Tipo, que tal falar sobre a forma que o shell fala com o kernel e acessa e trata os perifericos>!

entao meo, o shell eh uma aplicacao como qualquer outra.

um shell simples (nem testei) pode ser feito com poucas linhas:

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

int main()
{
char buffer[1024];
do
{
printf("$ "); // imprime prompt
fflush(stdout);
gets(buffer); // pega comandos
sscanf(buffer,"%s %s %s %s",argv[0],argv[1],argv[2],argv[3]); // faz o parse
if(fork()) execv(getenv("PATH"),argv); // forka e roda o comando
wait(); // espera o comando terminar

} while(1);
}

a interface com o kernel eh o que vc esta vendo: stdio, fork, exec, wait. claro, os shells existentes sao rebuscados pq eh possivel escrever programas completos no shell.

a ideia eh automatizar, por exemplo, quando eu trampava com TI havia um script periodico que ficava rodando e testava para ver se os servicos estavam ativos. em caso de falha, ele tentava subir o servico, por exemplo:

ps -C httpd > /dev/null || sh /etc/rc.d/rc.httpd start
ps -C sshd > /dev/null || sh /etc/rc.d/rc.sshd start
...

em essencia: ps mostra os processos na maquina e ps -C mostra um nome e particular. se o comando ps nao tiver sucesso, ele retorna um codigo de erro, ao inves de 0. a saida padrao eh redirecionada para o /dev/null pq nao eh importante e o codigo de erro avaliado pelo operador || do shell, que possui a seguinte sintaxe:

comando && comando sucesso || comando falha

eh similar ao teste?verdade:falso do C. se vc quiser, pode escrever como um if tambem:

if ! ps -C httpd
then
sh /etc/rc.d/rc.httpd start
fi

o ! inverte o estado, para nao fazer um else... ou entao pode fazer um while processando linha a linha:

ps -ef | while read i
do
echo $i | if ! grep httpd
then
sh /etc/rc.d/rc.httpd start
if
echo $i | if ! grep sshd
then
sh /etc/rc.d/rc.sshd start
fi
done

e por aih vai.

periferico no shell nao eh muito melhor que qq aplicacao trata, pq o shell nao trata. para ele, soh existe arquivo e arquivo. mas veja que sorte, o unix eh construido mapeando perifericos em arquivos!

entao para ver o mbr do seu hd, se vc tiver permissao:

cat /dev/sda | hexdump -C | more

lembrando que na verdade o cat eh um comando de uso geral para concatenar arquivos. se vc nao fizer uma cagada tipo redirecionar para o seu disco, vc nao vai danificar nada. se vc fizer isso:

cat arquivo > /dev/sda

o cat vai escrever zueiras no seu mbr e fuder sua maquina. veja que nao tem nada especial, /dev/sda eh apenas um arquivo como qq outro e cat vai fazer algo simples como:

int main(int argc, char **argv)
{
char buffer[1024];
int size;
fd = open(argv[1],O_RDONLY);
while(size=read(fd, buffer, 1024))
write(1,buffer,size);
}

esse tipo de exemplo por sinal tem lah no livro do K&R, que eh outro classico que eu recomendo ler tambem! e tem que ler o livro do minix! rapido!

[polesapart]

Uma coisa bacana no shell é que ele tem uma lista de comandos internos, que ele mesmo processa, mas qualquer executável do sistema acaba virando um comando que estende a sua funcionalidade.

E o unix é cheio deles: qualquer instalação normal tem ferramentas poderosas como rev, grep, awk, cat, cut, e claro, o famoso sed.

Em tese, daria pra comparar com o command.com do ms-dos ... e com os utilitarios grep.exe e outras tralhas. Mas só em tese, pq é como comparar um monociclo de palhaço com uma lamborguini

[msamsoniuk]

o monociclo de palhaco eh realmente bem apropriado, pq mostra exatamente como fica um usuario de sistema operacional microsoft quando ele tenta usar o sistema hahaha

Uma coisa bacana no shell é que ele tem uma lista de comandos internos, que ele mesmo processa, mas qualquer executável do sistema acaba virando um comando que estende a sua funcionalidade.

E o unix é cheio deles: qualquer instalação normal tem ferramentas poderosas como rev, grep, awk, cat, cut, e claro, o famoso sed.

Em tese, daria pra comparar com o command.com do ms-dos ... e com os utilitarios grep.exe e outras tralhas. Mas só em tese, pq é como comparar um monociclo de palhaço com uma lamborguini

[polesapart]

É bacana jogar uma terminologia:

kernel = núcleo, parte interna.
shell = concha, a parte mais externa, a "casca".

Voltando lá aos bons tempos onde interface gráfica era coisa de frutinha, quando o sistema bootava, o kernel carregava o init, que fazia as tarefas de configurar o ambiente (montar sistemas de arquivo, configurar quotas, etc.) e iniciava os daemons, que é o equivalente no unix ao que no windows chamam de "serviços", ou seja, aplicações que rodam em background (sem interface direta com o console, e portanto, com o usuário), e, finalmente, os controladores de terminal (getty e equivalentes), que configuravam os terminais de texto (console local ou via porta serial; Alguém lembra nas repartições públicas daqueles terminais vt-100 com tela verde?, e zilhões de quilômetros de cabos RS-422?).

Os getty tem uma função simples: configuram os parametros do terminal, exibem a mensagem de pre-login (basicamente eles leem um arquivo chamado /etc/issue, e logam ele na tela), e leem uma unica linha digitada pelo usuario: o nome de login.

A partir daí, ele faz um exec() para o executavel /bin/login , usando o nome de login digitado.

Esse programa faz a validacao das credenciais de segurança, geralmente pedindo e validando a senha do usuário, e caso passe, ele usa (dentre outras) as chamadas de sistema fork() (para criar um processo filho), setsid() (para criar um novo grupo de processos, não vou entrar em detalhes), setuid()/setgid() (para mudar as permissoes do processo [que originalmente roda como root] para aqueles do usuário autenticado), e, finalmente, faz um exec() para o shell do sistema, ou aquele informado para o usuario, no arquivo /etc/passwd ou algo equivalente.

O processo login herda os seguintes descritores de arquivo do getty(): descritor de arquivo zero: associado ao terminal, em modo leitura; Descritores 1 & 2, associados ao terminal, em modo escrita.

Tanto o login, quanto o shell que herda dele, associam estes descritores, respectivamente, ao que na terminologia ansi c se chama por entrada padrão, saída padrão, e saída de erros padrão.

Quando a biblioteca C mapeia estes descritores aos sistemas de mais alto nível, com buffers, ela o faz criando os famosos objetos FILE * chamados, respectivamente, de stdin, stdout, e stderr.

O shell, então, roda em modo interativo, lendo comandos que o usuário passa, e executando.

Cada subprocesso que o shell cria, por exemplo, quando você chama um comando externo (grep, cat, etc.), herda estes descritores de arquivos associados ao terminal.

Mas o shell possui uma semantica interessante.

Ao inves de:

cat /etc/issue

que faria a leitura do arquivo issue, jogando a saida do comando na saida padrao, associada ao terminal, o usuario pode fazer:

cat /etc/issue >/dev/null

O que o shell faz no primeiro caso é um fork() e um exec("/bin/cat" ...), no segundo caso, ele antes abre o arquivo /dev/null e associa ele ao descritor 1, o que faz com que o cat, quando execute, jogue a saida ao arquivo /dev/null ... que nada mais é do que um dispositivo de entrada & saída cujo driver do kernel simplesmente descarta tudo que é gravado nele.

Outros recursos bacanas são os pipes:

se o usuario digita:

whoami | rev

O shell vai pegar a saida padrão do comando whoami (descritor de arquivo 1) e ligá-lo, através de um "pipe" (um mecanismo do unix que faz com que o que for gravado num descritor de arquivo, apareça para leitura em outro), ao descritor de arquivo zero que o processo rev herda. Finalmente, a saida do comando rev, como nao foi redirecionada para lugar algum, vai parar na saída padrão do terminal.

todas estas chamadas de sistema, a implementação de mecanismos de leitura e gravação de arquivos, são, salvo nos raros casos em que é apenas uma abstração provida pela libc, providos pelo kernel.

O que o shell faz é tornar boa parte desta infra-estrutura acessível ao usuário, através de comandos (diretos ou indiretos).

O bacana é que os programas no unix são independentes do shell, e vice-versa, vice? Então dá pra usar o csh, ash, bash, e uma infinidade de outras coisas. Tinha um usuário com conta num provedor onde trabalhei que usava o tclsh, o que considero uma heresia digna de ir pra fogueira, infelizmente pra mim, o unix surgiu bem depois da inquisição e eu não fazia parte de nenhum comitê inquisitor.

Sou contra a pena de morte, mesmo em casos de barbárie, mas pra quem usar tclsh, eu abro uma exceção

[xultz]

Falando em if do shell, me lembro que dá prá usar for no shell (foi o polesapart que me ensinou). Algo do tipo
for i in $(seq 0 100) ; wget www.sitedemulherpelada.com/mulhermelancia$i.jpg ; done
Acho que era algo do tipo. Baixei muito arquivos importantes com esse tipo de comando...

[polesapart]

Falando em if do shell, me lembro que dá prá usar for no shell (foi o polesapart que me ensinou). Algo do tipo
for i in $(seq 0 100) ; wget www.sitedemulherpelada.com/mulhermelancia$i.jpg ; done
Acho que era algo do tipo. Baixei muito arquivos importantes com esse tipo de comando...

era algo assim:

Código: Selecionar todos

for ((i = 1; i < 101; i++)) ; do wget www.xultz-porn.com/files/Laetitia-Casta-$i.jpg ; done

[xultz]

Eu tenho certeza que eu usava o seq, mas sempre tinha que correr atrás do manpage prá ver como o bicho funcionava...

[polesapart]

Bom, então vc aprendeu essa sozinho hahahaa
seria:

for i in `seq 0 100` ; do ... ; done

[fabim]

sam, novamente.
Eu li umas 3 vezes tentando enchergar nexo e nao consegui.
Imagina uma pa de arquivo.
Vou compilar tudo agora no eclipse pra gerar o bin....
Quando voce diz que o shell é um app, como outro qualquer. E voce ainda deu exemplos...

O terminal que eu digito...
O terminal é o shell propriamente dito, que chama os comandos nativos do kernel ? fork etc.
Ou seja, aqueles comandos, que o shell pode interpretar de varias formas diferentes, e chamar comandos do kernel!!

Entendi ou tem que incrementar algo ?

[msamsoniuk]

nao sei se eu entendi o que vc entendeu hehehe

entao, vamos pensar em algo bem simples, voltando aos primordios do universo onde estes conceitos surgiram! vamos supor que vc tem algo tipo pic, mas um pouco melhorado, como um 68000 com uma eprom e uma sram, bem como uma interface serial dupla 68681.

como eu havia falado, processadores de verdade costumam ter niveis de seguranca. e o 68000 possui dois niveis: modo supervisor e modo usuario. isso eh replicado pelo hardware para os pinos externos e permite que vc selecione areas de memoria conforme o nivel de acesso. assim, uma montagem comum seria mapear apenas uma area da sram com acesso em modo usuario, de modo que qualquer tentativa de ler a eprom, a interface serial ou areas privilegiadas da sram resultem em uma excessao de violacao de privilegio.

entao a unica forma da aplicacao, um shell, por exemplo, em modo usuario transmitir e receber dados pela serial seria atraves de syscalls para o kernel, o que eh feito atraves de traps no caso do 68000. quando vc roda uma trap, existe uma passagem de modo usuario para supervisor, invocando o kernel de modo que ele analise a stack do usuario e processe a solicitacao, verificando se nao existe nenhuma inconsistencia. por exemplo, duas aplicacoes nao vao poder usar a mesma serial, ou seja, um processo nao pode zuar o outro!

soh detalhando o mecanismo de trap:

suponha que vc tem um printf(). o printf passa pela libc onde existe todo um codigo de modo usuario que processa as strings e gera os buffers para serem impressos. o resultado final disso eh um write(). esse write na libc nao tem como chegar ateh a serial a nao ser por uma trap. entao em um determinado ponto existe um wrapper em asm que empilha os dados da syscall do write e chama a trap. a aplicacao morre e o kernel aparece.

o kernel tem sua propria stack separada e assim pode processar a stack de modo usuario com tranquilidade. ele vai ler os parametros do write, detectar que eh para a serial e entao encaminhar o buffer para o device driver. possivelmente neste momento ele vai encerrar o trabalho no kernel e escalonar a execucao de alguma outra aplicacao ou da mesma, se nao tiver mais nada na fila.

o device driver em si varia bastante. no caso de portas seriais, quando chega algo, temos uma interrupcao indicando que existe algo na fifo de recepcao. no caso da fifo de transmissao, temos uma interrupcao indicando que a fifo esta vazia. as vezes a interrupcao jah veio antes, entao o driver sabe disso e apenas faz um wakeup de transmissao. obviamente, a aplicacao nao ve nada disso!

e assim o kernel faz os dados fluirem pela serial sem que a aplicacao chegue nem perto do hardware.

ok. agora vamos para o tal do shell... imagine algo como:

char buffer[256];

do
{
gets(buffer);
if(!strcmp(buffer,"exit")) return 0;
if(!strcmp(buffer,"ls")) printf("comando ls\n");
...

} while(1);

ali no gets() a libc na verdade converte para um read(), que vira uma trap e invoca o kernel. a aplicacao fica blockada, esperando ateh que apareca algo na serial. se tiver algo na serial, vai ter algo no buffer do read e assim a aplicacao eh escalonada para rodar pelo kernel, retornando o read() e fazendo o processamento, que no caso consiste apenas em imprimir coisas. novamente, imprimir pela libc vai virar varios write(), sendo que se o buffer de transmissao encher, o write() fica blockado e nao retorna ateh o buffer sair pela serial. com isso vc percebe que o kernel controla o fluxo de execucao tambem, mas isso eh transparente.

bom, se vc incrementar seu shell, vc vai ter fork, exec, etc. novamente, sao chamadas que vao passear pela libc, virar uma trap e invocar o kernel. processamento de disco? rede? video? nao muito diferente de uma interface serial. o principio do negocio eh que o kernel usa o hardware e encapsula as funcionalidades de modo que uma aplicacao nao consiga zuar o sistema.

e isso eh essencial para a existencia de sistemas multi-tarefa e multi-usuarios.

[msamsoniuk]

Bom, então vc aprendeu essa sozinho :P hahahaa
seria:

for i in `seq 0 100` ; do ... ; done

awk eh o que comanda! :D

Código: Selecionar todos

echo "SGGK://DDD.XOVZM-SLHGVW-TZOOVIRVH.XLN/RORPVNLMRXZ/NL006/RMWVC.KSK?RW=628712" | awk -F/ '{ for(i=0;i!=26;i++) gsub(sprintf("%c",90-i),sprintf("%c",97+i)); URL=$0; gsub("[?]","."); sub($NF,""); DIR=$0; FS="[<>=]"; CMD="wget -qO- "URL; while (CMD | getline $0 && !ERRNO) { gsub(""",""); for(i=1;i<NF;i++) if($i~/(HREF)|(href)/ && $(i+1)~/(jpg|JPG)/) print("wget -c "DIR $(i+1));  }; close(CMD) }'