Como parte do procedimento de instalação de um software, eu uso:
curl -s <url-to-targz> | tar -p -x -z -C /
dentro de um script Perl (eu uso qx($command)or system($command), qualquer um serve. Tudo corre bem, e o tar ball é instalado no / do meu sistema, mas quando faço a mesma coisa com um compartilhamento nfs:
curl -s <url-to-targz> | tar -p -x -z -C /my-nfs/opt
Então ocorre o seguinte:
- Quando faço isso no prompt, tudo corre bem (ou seja, todas as minhas permissões que salvei no tar ball ainda estão em vigor).
- Quando faço isso dentro do script Perl (ou de um script de shell, nesse caso), ou
qx($command)mesystem($command)deixa com a situação em que as permissões são alteradas (por exemplo, o que era executável, não é mais executável).
Suspeito que isso tenha a ver com umask (que é 022 no meu sistema), e normalmente o sinalizador -p deve cuidar disso, mas ainda assim não há alegria neste caso. Alguém tem alguma sugestão para mim (além de ler a página de manual :-))?
Eu também tentei algo parecido system("umask xyz; $command"), mas (provavelmente porque $commandestá usando um fork do meu processo, que obtém o umask 022): também sem alegria.
Editar: algumas das respostas indicam que devo usar umask do Perl. Acho que uma umask 000 resolverá o problema (mas verei isso pela manhã, quando estiver no sistema. Umask, porém, tem um efeito diferente em arquivos e diretórios. Existe uma maneira de desabilitar umask completamente durante a execução de meu programa (apesar de mil razões de segurança contra ele).