No Chrome OS, o Bash não executará meu script. Como obtenho o Bash para executar meu script?

16

Eu tenho um arquivo foo.sh no meu diretório atual. Se eu tentar executar ./foo.sh , obtenho:

-bash: ./foo.sh: /bin/sh: bad interpreter: Permission denied

Mas se eu executar /bin/sh ./foo.sh , ele será executado corretamente.

Como posso corrigir isso para que eu possa executar ./foo.sh e ele seja executado automaticamente com / bin / sh?

Editar: Ok, este é o Chrome OS e essa pasta específica é montada com noexec . Aparentemente, isso anula a capacidade de executar apenas ./foo.sh ; mas por quê? Por que ainda posso executar sh foo.sh para conseguir exatamente a mesma coisa? Que segurança, então, o noexec dá?

    
por Ricket 02.02.2011 / 22:54

5 respostas

21

O sinalizador noexec será aplicado adequadamente aos scripts, porque esse seria o comportamento "esperado".

No entanto, definir noexec apenas impede que as pessoas não saibam o suficiente sobre o que estão fazendo. Quando você executa sh foo.sh , na verdade você está executando sh de seu local padrão (provavelmente /bin ), o que não está em um sistema de arquivos montado com noexec .

Você pode até mesmo obter noexec para arquivos binários regulares invocando ld diretamente.

cp /bin/bash $HOME
/lib/ld-2.7.so $HOME/bash

Isso executará o bash, independentemente de estar ou não em um sistema de arquivos montado com noexec .

    
por 02.02.2011 / 23:19
5

Você também pode obter esse erro (ou uma mensagem muito, muito semelhante) se tentar executar um arquivo com terminações de linha de 2 bytes do MS-DOS (retorno de linha de carro).

Vim é tão esperto hoje em dia, que não lhe mostra necessariamente os retornos de carro como '^ M'. Assim, você pode ser enganado se não verificar o que o Vim acha que é o "formato de arquivo" e confiar apenas na aparência da tela.

Neste caso, o "#! / bin / sh ^ M" faz com que o kernel tente encontrar "/ bin / sh ^ M", o que não é possível. Intérprete ruim, de fato.

    
por 03.02.2011 / 00:05
2

Se você tiver a opção de executar o script ou o programa a partir de um pen drive USB (ou outra mídia removível), tente desmontar e montá-lo manualmente:

  1. Conecte o stick USB

  2. Encontre dispositivo de pendrive com $ mount

  3. Tome nota disso; vamos supor que seja /dev/sdb1

  4. Desmontar o stick USB:

    $ cd /media/removable
    
    $ sudo umount mountpoint
    

Por fim, monte novamente o stick USB:

$ sudo mount /dev/sdb1 mountpoint

Com o ponto de montagem, o nome de montagem do dispositivo USB

    
por 25.07.2014 / 01:12
0

Eu tive a mesma pergunta. Meu problema foi com o cartão SD. Isso funcionou para mim e é muito mais simples do que as outras respostas aqui. Aprendi com edição Crouton # 928 .

$ sudo mount -o remount,exec /media/removable/SD\ Card

Note que você tem que usar o ponto de montagem, não o dispositivo (/ dev / mmcblk1p1). Mesma coisa para USB (/ dev / sdb1) no seu caso. Apenas o ponto de montagem é diferente:

$ sudo mount -o remount,exec /media/removable/USB\ Drive

Você saberá que teve o efeito desejado porque "noexec" desaparecerá das opções de montagem quando você consultar.

    
por 06.03.2017 / 01:02
-1

Por motivos de segurança do sistema no Chrome OS / ChromiumOS, determinadas pastas estão marcadas com noexec e você precisa remontar com o comando abaixo ou usar um caminho alternativo que não tenha noexec definido, como o segundo exemplo. / p>

Esses comandos presumem que você esteja pelo menos no modo de desenvolvedor e tenha acesso ao shell com chronos@localhost / $ e não apenas ao crosh> e saiba a senha do sudo.

sudo mount -i -o remount,exec /home/chronos/user/

O método mais sustentável que deve sobreviver a uma atualização porque o Google reserva a maior parte de /usr/local para desenvolvedores:

sudo mkdir -p /usr/local/bin/ && sudo chown -R chronos: /usr/local/bin/
cp ${HOME}/Downloads/foo.sh /usr/local/bin/

O benefício adicional de colocar as coisas aqui é que ele já está no $PATH (tente echo $PATH para confirmar isso) para que você não precise usar o caminho completo para executar scripts ou binários que estão em /usr/local/bin e tiveram chmod +x executado neles.

    
por 23.07.2018 / 15:29