Acabei de encontrar a seguinte pergunta no Unix Programming Environment , o livro clássico de Kernighan e Pike no Unix (encontrei o texto abaixo na p. 79 da edição de 1984, ISBN: 0- 13-937699-2):
Exercise 3-6. (Trick question) How do you get a / into a filename (i.e., a / that doesn't separate components of the path?
Eu tenho trabalhado com o Linux há anos, tanto como usuário final como programador, mas não posso responder a essa pergunta. Não há nenhuma maneira de colocar barras em nomes de arquivos, é absolutamente proibido pelo kernel. Você pode corrigir seu sistema de arquivos por meio do acesso a dispositivos de bloco ou usar caracteres de aparência semelhante do Unicode, mas eles não são soluções.
Eu entendo Linux ≠ Unix, mas o mesmo princípio deve ser aplicado, já que o sistema tem que ser capaz de extrair inequivocamente a hierarquia de diretórios dos caminhos.
Alguém sabe exatamente o que Kernighan e Pike pensavam quando faziam essas perguntas? Qual foi a suposta resposta? O que exatamente é o 'truque'? Ou talvez o sistema Unix original simplesmente permitisse escapar dessa barra de alguma forma?
UPD:
Entrei em contato com Brian Kernighan sobre a questão e foi o que ele respondeu:
The answer is (or was) “You can't.”
Por isso, Timothy Martin estava certo e recebeu o tique-taque verde.
Talvez a resposta seja a mesma como parte da resposta nesta pergunta capciosa:
Como você desce de um elefante? Você não. Você obtém de um ganso.
De "A Prática da Programação" por Brian W. Kernighan e Rob Pike, Ch. 6, pg. 158:
When Steve Bourne was writing his Unix shell (which came to be known as the Bourne shell), he made a directory of 254 files with one-character names, one for each byte value except '%bl0ck_qu0te%' and slash, the two characters that cannot appear in Unix file names.
Eu fiz isso. Isto foi em um sistema UNIX rodando em um PDP-11 por volta de 1980. Eu criei um arquivo chamado "WhatXNow?". Em seguida, usei um "editor" de arquivo binário para editar o dispositivo de disco e alterar o "X" para um "/" no inode (com o sistema de arquivos desmontado).
A vítima nunca descobriu como removê-lo.
Edit: whoops, Barmar está certo, eu não consegui ver a linha lá sobre não corrigir o dispositivo. E sim, foi o diretório que eu editei, não o inode. Já faz um tempo: -)
Qualquer cenário em que / (mais precisamente, um byte - não um caractere - com valor 0x2f; quase todos os kernels Unix intencionalmente ignoram a codificação de caracteres) encontra seu caminho em uma entrada de diretório, sem os blocos brutos de disco terem sido manipulado manualmente, é inquestionavelmente um bug no kernel.
Tais erros acontecem de tempos em tempos. Um caso que eu lembro de ler as notas do patch, é que algumas iterações da era dos anos 90… Eu quero dizer Solaris, mas isso pode estar errado… ofereci um servidor para o AppleTalk Filing Protocol (AFP), que era equivalente ao NFS do MacOS . O problema era que, no MacOS clássico, você tem permissão para colocar / em um componente de nome de caminho; o separador de diretório é : . O servidor AFP foi suposto para fazer o equivalente moral de tr :/ /: ao mapear nomes de caminhos enviados por clientes para arquivos em seu disco, mas eles perderam alguns caminhos de código e porque o servidor foi implementado dentro do kernel , na verdade, poderia escrever entradas de diretório ruins.
(Veja comp.unix FAQ # 2.2 , começando a subseção "E se o nome do arquivo tiver um '/' in it? ", para uma versão mais longa do acima.)