O que é ler um arquivo?

O armário de arquivos que você nunca fecha

Imagine um armário de arquivos em um escritório. Para ler um documento dentro dele, você faz três coisas: abre a gaveta, lê o papel e fecha a gaveta. Todos os programas no seu computador fazem os mesmos três passos quando leem um arquivo: abrir, ler, fechar. Essa sequência é tão fundamental que todos os sistemas operacionais do mundo funcionam assim.

Mas aqui está algo que a maioria dos tutoriais não menciona: a alça da gaveta não é o arquivo em si. Quando seu sistema operacional abre um arquivo, ele dá ao seu programa um file descriptor (descritor de arquivo): um número pequeno (como 3, 4 ou 5) que funciona como uma alça para aquele arquivo aberto. Seu programa usa esse número para ler o conteúdo do arquivo. Quando termina, ele fecha o file descriptor, liberando a alça.

Arquivos são apenas bytes armazenados

Um arquivo é uma sequência de bytes armazenados no seu disco. Um arquivo de texto como notes.txt contém bytes que representam caracteres: letras, números, espaços e quebras de linha. Quando você "lê" um arquivo, seu programa pede ao sistema operacional para copiar esses bytes do disco para a memória, para poder trabalhar com eles.

Aqui está um arquivo de texto com três linhas:

Hello, world!
This is line two.
Goodbye.

No disco, isso é armazenado como uma única sequência de bytes. Os caracteres de nova linha (\n) dizem ao seu terminal onde uma linha termina e a próxima começa. Sem quebras de linha, tudo apareceria em uma única linha longa.

Pense em um arquivo como um rolo de papel. O texto é escrito continuamente, e o caractere de nova linha é como uma marca que diz "comece uma nova linha aqui."

File descriptors: as alças para tudo

Quando um programa inicia, o sistema operacional abre automaticamente três file descriptors para ele:

+------+--------+-------------------------------------+
|  FD  |  Nome  |  Finalidade                         |
+------+--------+-------------------------------------+
|  0   | stdin  | Entrada padrão (teclado)            |
|  1   | stdout | Saída padrão (tela)                 |
|  2   | stderr | Saída de erro padrão (tela)         |
+------+--------+-------------------------------------+

stdin (file descriptor 0) é de onde um programa lê a entrada, geralmente seu teclado. stdout (file descriptor 1) é onde um programa escreve sua saída normal, geralmente a tela do seu terminal. stderr (file descriptor 2) é onde um programa escreve mensagens de erro: também na sua tela, mas por um canal separado.

Por que isso importa? Quando você executa cat notes.txt, aqui está o que acontece por baixo dos panos:

1. O shell inicia o programa cat.
2. cat pede ao SO para abrir notes.txt. O SO retorna um file descriptor (digamos, 3).
3. cat lê bytes do file descriptor 3.
4. cat escreve esses bytes no file descriptor 1 (stdout: sua tela).
5. cat fecha o file descriptor 3.

+------------+      lê       +-----------+
|  notes.txt | ------------> |    cat    |
|  (FD 3)    |   (bytes)     |  programa |
+------------+               +-----+-----+
                                   |
                           escreve | (FD 1)
                                   v
                            +-----------+
                            |  Terminal |
                            |  (stdout) |
                            +-----------+

Esse ciclo de abrir-ler-escrever-fechar é a base de tudo que você vai aprender nas próximas seis aulas.

Por que o cat existe

O nome cat é a abreviação de concatenate (concatenar), que significa "juntar coisas." Seu propósito original era combinar múltiplos arquivos em um único fluxo de saída. Mas os desenvolvedores descobriram que cat com um único arquivo é a forma mais rápida de despejar o conteúdo de um arquivo na tela. Então cat file.txt se tornou a forma mais comum de ler um arquivo pequeno no terminal.

Experimente isso no seu terminal:

$ echo "Hello from the terminal" > greeting.txt
$ cat greeting.txt
Hello from the terminal

O primeiro comando cria um arquivo chamado greeting.txt com uma linha de texto. O segundo comando lê esse arquivo e imprime seu conteúdo na tela. Por baixo dos panos, cat abriu o arquivo, leu seus bytes, escreveu-os no stdout e fechou o file descriptor: tudo em milissegundos.

Ler vs. editar vs. executar

O terminal oferece ferramentas diferentes para diferentes tarefas com arquivos:

Ler é não-destrutivo: você não pode danificar um arquivo ao lê-lo. Isso torna os comandos de leitura seguros para experimentar. Você pode usar cat em qualquer arquivo quantas vezes quiser sem risco.

Por que isso importa para Rails

Aplicações Rails são feitas de dezenas de arquivos: arquivos de configuração como Gemfile e config/database.yml, definições de rotas em config/routes.rb, e arquivos de log em log/development.log. Como desenvolvedor Rails, você vai ler arquivos constantemente:

• Verificando quais gems estão instaladas: cat Gemfile
• Lendo os últimos erros no log: tail log/development.log
• Pesquisando em um arquivo de configuração grande: less config/routes.rb
• Inspecionando sua versão do Ruby: cat .ruby-version

Dominar comandos de leitura de arquivos não é opcional: é uma habilidade essencial que você vai usar todos os dias.

Erros comuns

Erro: Tentar usar cat em um arquivo binário (como uma imagem ou programa compilado).
O que acontece: Seu terminal é inundado com caracteres ilegíveis, e às vezes seu prompt fica corrompido.
Em vez disso: Use file myimage.png primeiro para verificar se um arquivo é texto ou binário antes de lê-lo.

Erro: Usar cat em um arquivo enorme (milhares de linhas).
O que acontece: Seu terminal rola por minutos e você não consegue ver o início.
Em vez disso: Use less para arquivos grandes (você vai aprender na Aula 3) ou head/tail para espiar rapidamente.

Resumo