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!
1
Respostas:
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.
fonte
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.
fonte
Então, aqui está o truque:
Funcionará, você verá o seu novo ícone quando copiar / mover da próxima vez.
fonte
usualmente. Se houver bibliotecas compartilhadas, elas também precisarão ser movidas ou um conjunto de caminhos para encontrá-las, dependendo do sistema operacional.
fonte
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.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.
fonte
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) ousetenv(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.
fonte