Um executável movido para outro diretório ainda funcionará?

1

Gostaria de saber se mover um executável para um diretório diferente de onde ele está instalado não fará com que funcione? Lembrei-me de que é o caso do Windows XP ao executar o executável clicando em seu ícone. No terminal Linux, parece que, com o caminho especificado corretamente, o executável ainda pode funcionar? Obrigado pela clarificação! Saudações!

windows linux

— Tim
fonte

Quando você mudou, o que aconteceu?

No Windows, como algum erro de tempo de execução. No Linux, nada aconteceu ainda. Estou especialmente interessado no caso Linux: como tornar essa mudança segura?

— Tim

4

Enquanto o executável puder encontrar suas dependências (outras DLLs no Windows, por exemplo), ele funcionará. Se não puder, por qualquer motivo (ou seja, pressupõe que eles estejam no mesmo diretório), não será.

Infelizmente, as mensagens de erro que você sai do Windows nem sempre são as mais úteis, então você pode ter problemas para localizar todos os arquivos necessários.

— ChrisF
fonte

Embora o executável possa funcionar, pelo menos no Windows, uma vez que as informações de desinstalação são gravadas no registro, esses caminhos estarão incorretos e a tentativa de desinstalar o aplicativo resultará em um erro, e o Windows apenas excluirá a entrada da lista. Geralmente não é uma boa ideia mover o diretório.

— Will Eddins 31/08/09

@Guard - bom ponto.

— ChrisF

2

Isso depende 100% da aplicação.

Um aplicativo por si só só precisa descobrir suas dependências ou a lista de DLLs necessárias para executar. Ele será procurado no diretório atual na maioria das vezes, portanto, isso geralmente não é um problema.

O maior problema está no registro. Se o aplicativo tiver gravado o local em que foi instalado no registro, poderá procurar certos arquivos no diretório antigo em tempo de execução.

Se você instalou o aplicativo, ele também será armazenado no registro e a desinstalação dos programas Adicionar / Remover não funcionará mais.

Se o aplicativo não usar o registro, ele poderá ser movido sem conseqüências. Muitos aplicativos portáteis que executam flash drives seguem essa abordagem e, como resultado, podem ser movidos ou excluídos conforme necessário.

— Will Eddins
fonte

1

Então, aqui está o truque:

Vá para C: \ Usuários \\ AppData \ Local \
Excluir IconCache.db
Mate explorer.exe do gerenciador de tarefas
Novamente inicie o explorer.exe

Funcionará, você verá o seu novo ícone quando copiar / mover da próxima vez.

— Manas
fonte

0

usualmente. Se houver bibliotecas compartilhadas, elas também precisarão ser movidas ou um conjunto de caminhos para encontrá-las, dependendo do sistema operacional.

— Jay
fonte

dependendo do sistema operacional, o tipo de bibliotecas, o tipo de aplicação, etc ... há uma série de variáveis

— Max Schmeling

Para Linux, as bibliotecas compartilhadas são adicionadas ao /etc/ld.so.conf global (e o /etc/ld.so.cache é atualizado com a execução do ldconfigcomando) ou gerenciadas pela configuração de um LD_LIBRARY_PATH ou outro LD_ * configurações do ambiente. Normalmente, você escreve um invólucro de duas ou três linhas para definir o (s) valor (es) LD_ * e, em seguida, executa seu destino. Você NÃO deve apenas colocar as configurações LD_ * no seu ambiente geral de shell! Considerações semelhantes se aplicam a qualquer sistema GNU libc, é claro, e algumas delas se aplicam a outra versão do UNIX.

— Jim Dennis

0

Não há motivo técnico para que você não possa mover um executável para qualquer diretório que você queira e executá-lo. O executável em si não deve saber ou se importar com o nome do arquivo ou com o diretório. No entanto, o executável deve ser capaz de encontrar outros arquivos que deseja abrir, como arquivos de configuração, dados, bibliotecas compartilhadas etc. Muitas vezes, o executável será gravado de forma a esperar encontrar essas coisas no mesmo diretório em que é executado ou em um subdiretório, por exemplo, o executável pode esperar que, se for executado em:

/ foo / baz / bin / executável

Que seus arquivos de configuração estão em

/ foo / baz / etc / configfile

Contanto que você tenha certeza de que o executável pode encontrar outros arquivos que ele precisa abrir, você poderá movê-lo conforme necessário. No Linux, o comando 'strace' pode ser útil para isso, você pode executar o exe sob strace e ver quais arquivos estão tentando abrir e eles os agarram e os movem. Além disso, para bibliotecas compartilhadas, 'ldd' é útil, pois informa quais bibliotecas compartilhadas o executável tentará abrir e quais não está encontrando.

— bdk
fonte

Obrigado! No seu exemplo, se eu mover / foo / baz como um todo, tudo ficará bem? Eu me pergunto por que essa mudança de um diretório de pacote inteiro geralmente é viável no Linux. Se os arquivos dependentes estiverem "no mesmo diretório em que é executado ou em um subdiretório" do mesmo pacote, eles sempre são especificados no executável como caminho relativo? Se os arquivos dependentes estiverem em algum diretório geral como / usr / local, / usr etc, eles sempre serão especificados no caminho absoluto?

— Tim

Sim, neste exemplo, mover / foo / baz como um todo funcionará. Sua afirmação sobre caminhos relativos versus caminhos absolutos geralmente é verdadeira, mas aposto que, se olhávamos bastante, poderíamos encontrar algum programa em algum lugar que fizesse algo completamente estranho. Freqüentemente, a única maneira de ter certeza é fazer a mudança e, em seguida, usando ldd, strace, comportamento quebrado, verifique se tudo está funcionando corretamente.

— BDK

0

No Linux (e UNIX em geral), a maioria dos executáveis pode ser movimentada livremente. Eles normalmente encontram suas dependências automaticamente ... algumas vezes usando ~ /.* ("arquivos de ponto") ... convencionalmente nomeados como ~ /. rc (onde 'rc' significava originalmente "comando de execução", mas pode ser considerado como configurações de "recurso / configuração"). Às vezes (cada vez mais) pacotes UNIX / Linux criam um ~ /. diretório (como ~ / .gnome /, ~ / .firefox / e assim por diante).

Geralmente, um aplicativo verifica se há um arquivo ~ /.* e depois procura um arquivo / etc / configuration. Pode procurar em outros lugares (como / opt / etc / ou / usr / local / etc).

Também é bastante comum que esses programas respeitem uma configuração de ambiente ... para que você export(conchas da família Bourne) ou setenv(csh / tcsh) seja uma configuração de configuração apropriada para eles. É claro que também é comum que eles usem uma opção de linha de comando para apontar para qualquer arquivo ou recurso de configuração.

Geralmente, é melhor consultar a documentação de um programa para descobrir os arquivos e as configurações do ambiente. Normalmente, um programa permite que um comutador da linha de comando substitua qualquer configuração do ambiente, substituindo qualquer configuração ~ /.*, que substitua qualquer configuração / etc / * que possa substituir qualquer configuração compilada. No entanto, isso é apenas uma convenção pouco seguida. Verifique os documentos!

Em geral, os programas UNIX / Linux são muito menos frágeis que os programas MS Windows ou MacOS mais antigos no gerenciamento de seus locais de recursos. Geralmente, não existe um "registro" opaco ou "garfos de recursos" para ocultar essas coisas.

— Jim Dennis
fonte