Como posso executar um arquivo sem permissões de execução?

Question

Como posso executar um arquivo sem me dar permissões de execução (com chmod u+x ) para ele?

Se eu tentar marcar a marca de seleção "Permitir execução do arquivo como programa", a marca de verificação será removida imediatamente.

    

Answer 1

Verifique a propriedade do arquivo

Por favor, faça isso antes de mais nada (a menos que você tenha certeza de que é o proprietário do arquivo).

Verifique se você possui o arquivo que está tentando executar com um dos métodos a seguir.

Gráfica

1. Clique com o botão direito no arquivo.
2. Clique em "Propriedades".
3. Clique na guia "Permissões".
4. Verifique se o campo "Proprietário" informa seu nome de usuário. Se não aparecer "Alterar a propriedade do arquivo" abaixo

Linha de Comando

1. Execute este comando em um terminal

   [ ! -O "/path/to/file" ] && echo "You don't own the file"
   

2. Se imprimir " You don't own the file ", consulte "Alterar a propriedade do arquivo" abaixo.

Alterar a propriedade do arquivo

Execute este comando em um terminal

sudo chown $USER:$(id -gn $USER) "/path/to/file"

Arquivos Executáveis

Uma resposta que encontrei de um comentário por Lekensteyn em um responder para uma pergunta sobre chmod em partições NTFS que eu acho que merece sua própria pergunta e resposta, completa crédito para Lekensteyn.

Use este comando para arquivos executáveis (substituindo /path/to/executable pelo caminho correto):

• arquivos executáveis de 64 bits:

  /lib64/ld-linux-x86-64.so.2 /path/to/executable
  

• arquivos executáveis de 32 bits:

  /lib/ld-linux.so.2 /path/to/executable
  

Se o acima não funcionar (ou gerar erros de arquivo não encontrado), tente usar isso antes do comando acima

cd "$(dirname /path/to/executable)"

Todos os comandos acima não funcionarão para scripts baseados em texto (Bash, Python, Perl, etc.), veja abaixo.

Verifique se um programa é de 64 ou 32 bits

Use este comando para descobrir se um executável é 32 ( x86 ) ou 64 ( x86-64 ) bit

objdump -f "$file" | grep '^architecture' | cut -d, -f1 | sed 's/architecture: //'

Se ele diz i386:x86-64 , então é 64 bits. Se ele diz i386 apenas, então é 32 bits.

Scripts

Para scripts baseados em texto (Bash, Python, Perl, etc.), você deve usar o comando especificado na primeira linha #! no arquivo.

Por exemplo, se a primeira linha do arquivo for

#!/usr/bin/env python3

execute estes comandos em um terminal (substituindo /path/to/file pelo caminho correto)

cd "$(dirname /path/to/file)"       # Not strictly necessary, see section below

# Replace '/usr/bin/env python3' with the first line without the front #!
/usr/bin/env python3 /path/to/file  # Use './file' if you want

Java .jar arquivos

Para jar do executável Java, você pode simplesmente usar esses comandos (substituindo /path/to/jar pelo caminho correto):

cd "$(dirname /path/to/jar)"   # Not strictly necessary, see section below
java -jar /path/to/jar

Quando você não precisa de cd "$(dirname /path/to/file)"

Estas são possíveis circunstâncias em que você não precisará usar cd "$(dirname /path/to/file)" antes de executar o programa com qualquer método: Se pelo menos um for verdadeiro, você não precisará do cd primeiro.

• O programa não executa operações de arquivo em si (exemplo: ele usa apenas apt-get )
• O programa usa cd (ou equivalente) para alterar para um caminho absoluto antes de executar qualquer operação de arquivo (exemplo: cd "$(dirname "$0")" )
• O programa não faz referência a nenhum caminho relativo (caminhos começando com ./ ou iniciando sem barra)

Se não tiver certeza, adicione cd "$(dirname "$0")" (ou equivalente) à parte superior do script (se aplicável) ou use cd "$(dirname /path/to/file)" mesmo assim.

    

Answer 2

Se for um script de shell, você poderá "fonte" de outro script de shell, por exemplo:

#!/bin/bash
# This script runs another script indirectly, by sucking in its contents and evaluating inline:

source /path/to/script/which/lost/its/exec/flag "$@"

O "$ @" acrescenta os parâmetros da linha de comando, se necessário.

Dito isto, esta provavelmente não é a melhor solução para o problema subjacente, mas não sabemos o suficiente sobre esse problema para oferecer alternativas.