Script com variável no caminho

0

Não sei bem onde perguntar ou como formular essa pergunta com a terminologia correta.

Eu tenho script aqui para gerenciar um servidor de jogo (minecraft) para o usuário (bukkit). Eu cortei algumas variáveis e eu quero saber por que isso não está funcionando e uma possível solução .

#!/bin/bash
# /etc/init.d/bukkit

USERNAME='bukkit'
MCROOT='/home/$USERNAME' 
MCPATH='/home/$USERNAME/Server'
BACKUPPATH='/home/$USERNAME/backups'
SCRIPTLOG='/home/$USERNAME/script.log'
LOGPATH='/home/$USERNAME/Server/logs'

(line 50) cd $MCPATH

(Eu também gosto de ter $ MCROOT nos caminhos seguidos por ele.)

A execução do script fornece:

/bin/bukkit: line 50: cd: /home/$USERNAME/Server: No such file or directory
-su: line 0: cd: /home//Server: No such file or directory

O ponto é ter USERNAME diferente em arquivos diferentes e eu pensei em economizar tempo editando todos os caminhos substituindo tudo com uma variável normalmente no resto do código. Então meu outro arquivo chamado "ftb" tem USERNAME='ftb'

"/bin/bukkit" is a symbolic link to "/etc/init.d/bukkit"

Tenha um bom dia!

    
por OskyEdz Snakehult 16.12.2015 / 00:09

1 resposta

1

As variáveis não são expandidas dentro de aspas simples, portanto o sistema está procurando literal /home/$USERNAME/Server em vez de /home/bukkit/Server .

Seu código deve funcionar se você usar aspas duplas, por exemplo,

MCPATH="/home/$USERNAME/Server"

Há uma discussão mais detalhada em Qual é o significado de aspas simples e duplas em variáveis de ambiente?

    
por 16.12.2015 / 02:19
O script qstnhdr ___ init.d não fornece saída padrão ______ qstntxt ___

Estou usando o Debian Jessie e quando estou tentando usar algum script do init.d (iniciar, parar, reiniciar). Existem funções %code% %code% %code% que devem dar algo na saída padrão, mas isso não acontece. Na versão mais antiga do Debian eu lembro que funciona normalmente. Mesmo se estiver tentando usar um script com falha, ele sempre obterá a mesma saída:

%bl0ck_qu0te%     
______ azszpr250997 ___
%bl0ck_qu0te%

Não execute scripts em %code% diretamente.

Em sistemas operacionais systemd, não há garantia de que esses scripts existam, e muito menos que eles estejam especificando seu serviço. Mesmo no Debian 7, havia unidades systemd suplantando o System 5 %code% scripts; e isto é mais no Debian 8. Os comandos corretos para usar são:

  • %code% com seus subcomandos %code% , %code% , %code% , %code% e %code%
  • %code%
  • %code% e %code% , mas apenas se você for um script do mantenedor de pacotes

Isso é exatamente o que está acontecendo com você. Sua invocação direta do script está sendo substituída, através de um gancho dentro de uma biblioteca Debian amplamente utilizada de funções de script, com uma invocação de (neste caso particular)

%pre%

Você pode até ver isso na saída à sua frente. É o que o %code% significa. E claramente, longe de falhar, é sucesso em dizer ao systemd para reiniciar o serviço.

Os sinos e assobios interativos dentro do script %code% , incluindo mensagens coloridas, não são mais eficazes. Seu serviço não é executado como um processo filho de %code% . Ele é executado como um processo filho de %code% e possui conexão zero com o terminal no qual você está executando comandos interativamente.

Todo esse %code% scaffolding e geração de mensagens de log é totalmente desnecessário com o systemd, de qualquer forma. O systemd fornece mecanismos de serviço cruzado para habilitar e desabilitar serviços e para reiniciá-los automaticamente. Registra quando inicia e interrompe serviços, sem necessidade dos serviços para fazer isso. Pela minha conta, esse script %code% é simplesmente substituível por 16 unidades %code% comuns, uma para cada serviço. Veja como ficaria:

%pre%

Ligue para %code% , execute %code% e…

  • … há informações de status disponíveis com %code% .
  • … você o habilita para executar no bootstrap com %code% .
  • … você pode ver as entradas de log do systemd para iniciar e pará-lo com %code% .

É muito fácil para os outros 15.

Leitura adicional

___ Problema de inicialização após tentar iniciar o dual fedora 23 e o windows 8.1