você rodou rm -rf ./* achando que estava na pasta do build e estava na home. o ./ significa a partir daqui. e aqui é a pergunta que você não fez, que é onde estou. oi, meu nome é giullia. eu vou explicar o que é o pwd, o que ele faz, por que às vezes ele mente, e a linha de script que te impede de rodar rm na pasta errada.
o TLDR, que é uma explicação rápida, é que o pwd é como se fosse a seta no mapa do shopping. ela não te leva a lugar nenhum, você não se move com ela, mas ela te indica onde você está, para onde você pode ir.
o pwd é print working directory. ele imprime o caminho completo de onde o terminal está no momento, em uma linha. então, começa com a barra, que é a raiz do sistema, e vai até o ponto que você está atualmente. e o ponto que importa. todo comando que você dá sem direcionar o caminho, ele parte dessa pasta. então, se você der um cd, um ls, ele sempre vai partir da pasta atual a não ser que você passe o caminho completo. todos esses comandos, eles usam o aqui atual. e o pwd é o único que te dá esse aqui.
se eu der pwd, ele retorna /home/atchiullia. ele é o comando puro. então, ele retorna o caminho absoluto que começa na raiz da pasta em que eu estou, e essa é minha home. se eu digitar type pwd, ele retorna pwd is a shell builtin. o type, ele diz o que uma palavra é para o shell. o built-in quer dizer que o pwd não é um programa, separado no disco. ele é uma função dentro do próprio bash. então, sendo parte do shell, ele responde com o que o shell tem na memória, não necessariamente o que o kernel tem na memória.
já com o echo $PWD, ele retorna /home/atchiullia, que é a pasta que eu estou no momento. o $PWD é uma variável. então, toda vez que você faz o cd, o bash anota essa variável nova, e te retorna. o pwd sem flag, ele só retorna o que está anotado. é como se ele escrevesse num post-it onde você está atualmente, e vai atualizando cada vez que você vai se movendo dentro do shell. e a fonte da verdade do pwd é esse post-it do shell.
agora, em uma situação que dois caminhos levam para a mesma pasta, um link simbólico resolve. o link simbólico, ele é um atalho. ele é um nome que aponta para outro lugar. é tudo que você precisa saber até o momento. se eu der ln -s, ln de link, s de simbólico, /var/log é o destino, e ~/logs é o atalho, que aponta para ele. ele criou esse atalho, e se eu der cd, o caminho do atalho, ele entra na pasta do atalho. então, nesse caso, ele entrou pelo caminho que ele anotou no post-it, na memória do shell. agora, se eu der pwd, uma flag de physical, -P, ele dá /var/log, que é o caminho físico do kernel para essa pasta. o echo $PWD, ele dá o retorno da variável. se eu utilizar o /bin/pwd, ele retorna /var/log, ou seja, ele pergunta para o kernel, porque ele é um programa fora do bash. então, ele não tem acesso às memórias do shell e dos post-its do shell.
agora, vamos para os números por trás de cada caminho. se eu der ls, -id, /var/log, eu estou perguntando qual é o id dele. ele retornou 61483, /var/log. o -i ele mostra o inode, que é o número de identidade da pasta no disco. e o -d, mostra a pasta em si, não o conteúdo. se eu rodar o mesmo comando com a pasta do atalho, ele retorna o mesmo id, só que com um caminho diferente. o pwd dá o apelido que a gente usou, enquanto o pwd -P dá o nome oficial do kernel. um é o nome que o shell anotou, o outro é o nome real da pasta no disco.
existem dois lados, e um é bem chato. a pasta pode ser removida e o chão pode sumir debaixo dos seus pés. então, se eu fizer um mkdir, que é criar um diretório temporário /tmp/x, e cd de entrar dentro desse diretório, /tmp/x, eu entrei no /tmp/x. se eu der rmdir /tmp/x. ele apagou essa pasta, enquanto eu ainda estou dentro dela. e o linux deixa isso. se eu der pwd, ele vai continuar mostrando, porque ainda está na memória do shell. mas, se eu der pwd -P, ele dá um erro, porque eu acabei de apagar essa pasta. então, ela não existe. mas a memória do shell continua desatualizada, porque eu ainda estou dentro dessa pasta. então, sempre se lembre. o shell lembra, e o kernel sabe. então, ele é a real fonte da verdade dentro da memória das coisas que acontecem dentro do seu OS
agora, o lado perigoso em um script de deploy. se você der cd $BUILD_DIR && rm -rf ./*, que é para deletar tudo, a intenção é entrar na pasta do build e limpar tudo que tem dentro dela. e isso tem dois jeitos de quebrar. se a $BUILD_DIR estiver vazia, o cd fica sem argumento e vai para a home. e o rm limpa a home. e se o $BUILD_DIR tiver um caminho errado, o cd falha. e imprime uma linha vermelha e o script continua na linha de baixo do mesmo jeito. ele não para de rodar. o rm, de remove, ele apaga a pasta em que o script está naquele momento, onde ele foi chamado. e se quem rodou isso foi um cronjob, essa pasta é a home. ou seja, vai apagar a home de novo. esses dois problemas são muito críticos porque o que está na home, às vezes, você não pode perder.
agora, a linha que fica no começo de todo o script do meu homelab. dessa vez eu acho que eu acerto o lado. então, se o cd falha, o bloco da direita roda. e avisa e sai do script com o código 1, que é erro. então, código 1 é erro, código 0 é sucesso. o rm da linha seguinte nunca é alcançado. então, ele não vai rodar na home. as aspas em $BUILD_DIR fazem a variável vazia virar um argumento vazio em vez de sumir. sem as aspas, o cd vazio vai para a home. com as aspas, o cd recebe um argumento vazio, quando o script precisa rodar na pasta em que ele está salvo, de onde for chamado, a gente usa isso aqui. o dirname "$0" dá a pasta em que o script está salvo, e ele roda de onde quer que ele seja chamado antes de apagar, pergunte onde você está. e foi isso. o próximo comando é ls, o que tem aqui.