Tilde (~) dentro do diretório unix de trabalho

Então, eu estou trabalhando em um ambiente UNIX e notei que dentro do meu diretório de trabalho, que fica a quilômetros de distância da minha casa UNIX, existe um ~.

Agora, uma vez no passado, eu fiz rm -rf ~do meu diretório de trabalho e acabei apagando completamente o meu diretório pessoal e tive que envolver a TI.

Eu não quero fazer isso de novo. Ao mesmo tempo, quero saber

Por que é ~criado no meu diretório de trabalho? É um deslizamento incorreto do dedo ao salvar ( :w!mas o que acontece é :w~? !!)
Antes de fazer o check-in, há um script que procura por arquivos ou pastas extras que a p4 não está ciente, portanto, isso ~pode causar um problema. Então, como posso remover o ~diretório do meu trabalho e, ao mesmo tempo, não apagar minha casa?

Eu tenho um comando de backup chamado delque eu uso em vez de rm -rf. Apenas coloca as coisas em um local temporário. Eu poderia usar isso e me livrar do ~. Mas estou mais interessado em saber por que isso acontece e como posso removê-lo?

shell filenames home

— user73631
fonte

Normalmente, o shell substitui ~ no início de um caminho pelo seu diretório pessoal. Use o caminho completo /home/yourUserName/~para acessar o diretório chamado ~.

— Jofel

E ~ otheruser / file pode ser usado para referenciar os diretórios pessoais de outros usuários, por uma questão de integridade.

— godlygeek

Parece uma brincadeira!

— Xolve

Respostas:

Cite-o:

rm -i '~'
rm -i "~"
rm -i \~

Ou referencie-o por um caminho, em vez de apenas um nome de base:

rm -i ./~
rm -i /path/to/~

Observe que, apesar de ser um nome de caractere único com aparência engraçada, conceitualmente não é diferente de se você tivesse criado um arquivo nomeado SOME$PATHexecutando

touch 'SOME$PATH'

E tentou removê-lo fazendo:

rm -i SOME$PATH

( Aviso: a variável SOME$PATH não é citada para o exemplo aqui. Normalmente, ela estaria entre aspas 'SOME$PATH' )

Nos dois casos, o shell está expandindo o nome que você fornece e você precisa impedir isso.

Além disso: não use rm -rfpara remover um arquivo! O objetivo rm -ré dizer que rmnão há problema em remover diretórios. Se você não deseja remover acidentalmente diretórios inteiros ao tentar remover arquivos, não passe habitualmente -r!

— godlygeek
fonte

Acabei de testar isso. :w~no vim criou um arquivo chamado ~. rm ~retornado cannot remove /home/seth it is a directory. rm "~"removeu o arquivo . Apenas para sublinhar não passa -rfautomaticamente .

— Seth

+1 por recomendar omitir opções violentas por padrão. Isso é semelhante a fazer kill -9por padrão, o que eu já vi.

— precisa

Vejo que o exemplo rm -i $FOOintencionalmente não cita a variável pelo bem do exemplo, mas ainda assim: mostrar um exemplo de shell envolvendo rme uma variável não citada como argumento é MUITO RUIM , desculpe, independentemente do contexto. Tenho certeza de que isso pode ser comprovado :) vou acrescentar uma nota - mas talvez você possa mudar um pouco o exemplo?

— Volker Siegel

@VolkerSiegel, Point taken - participei de sua edição, mas a nota de rodapé parecia um pouco pesada demais. Também mudei para um nome de variável com menos probabilidade de causar problemas - a maioria das pessoas não tem um arquivo nomeado SOME/bin:/usr/binem nenhum lugar do sistema de arquivos. :)

— godlygeek

Sim, parece ser bom! (Eu estava quase respondendo: O que? Mão pesada? Você já teve um problema real de citações em sua vida?;) Apenas um pouco desesperado com a quantidade de exemplos de shell errados por aí, em geral ... Ei, é difícil entender mesmo sem exemplos errados! )

— Volker Siegel

O til quando usado sozinho no contexto de ls ~listará o diretório inicial como ~ é um atalho para o diretório inicial. Se você o fez ls ~brown, listará o conteúdo do diretório inicial de brown.

O VIM, salvo indicação em contrário, criará uma cópia de backup de um arquivo alterado: myFile myFile ~.

Esse comportamento é bom, pois cria um backup, mas se você não quiser, adicione ao arquivo .vimrc: set no backup (com o qual acabei de acessar vi ~/.vimrc).

E, é claro, como outros disseram, se você tiver um arquivo chamado ~, simplesmente escape do caractere como \ ~

me 217 % vi this      (saved as :w~)
me 218 % ls
this  ~
me 219 % cat \~
kfdkdfk
me 220 % \rm \~
me 221 % ls
this

— user2592248
fonte

Isso pode ser efetuado por erros de digitação. Se a sua TERM=xtermconfiguração for parecida com a minha, praticamente todas as teclas de função do seu teclado enviarão seqüências de escape como ...

infocmp -1 | grep -n \~ | tail -n3
138:    kich1=\E[2~,
141:    knp=\E[6~,
142:    kpp=\E[5~,

Mais da metade da saída de infocmp -1contém ~contornos de til na minha máquina - e não consigo entender o que a maioria deles faz. Eu sei que zshpelo menos na verdade come a parte escapada da corda na maioria dos casos - e deixa apenas o ~til .

Por exemplo, digitando echothen <space>then F6e <return>imprime ...

/home/mikeserv

A sequência de escape real enviada é ...

kf6=\E[17~

Curiosamente, existem outras dessas seqüências de escape que contêm >caracteres.

infocmp -1 | grep \>
is2=\E[!p\E[?3;4l\E[4l\E>,
rmkx=\E[?1l\E>,
rs2=\E[!p\E[?3;4l\E[4l\E>,

Esses são escapes comumente usados - sequências de redefinição e inicialização. Não é difícil imaginar que um teclado solto ou um esmagamento de botão de algum tipo quando um shell interativo aguarda entrada possa resultar em ~arquivos truncados aleatoriamente ocorrendo em todo o sistema de arquivos. Pelo menos, ocasionalmente surge na minha.

— mikeserv
fonte