Documentação<Anterior | Conteúdo | Próxima>
IFS
Normalmente, o shell executa a divisão de palavras na entrada fornecida para ler. Como vimos, isso significa que várias palavras separadas por um ou mais espaços tornam-se itens separados na linha de entrada e são atribuídas a variáveis separadas por ler. Este comportamento é configurado por uma variável de shell chamada IFS (para separador de campo interno). O valor padrão de IFS contém um espaço, uma guia e um caractere de nova linha, cada um dos quais separará os itens uns dos outros.
Podemos ajustar o valor de IFS para controlar a separação de campos de entrada para ler. Por exemplo, o / Etc / passwd arquivo contém linhas de dados que usam o caractere dois-pontos como um separador de campo. Alterando o valor de IFS para um único dois pontos, podemos usar ler para inserir o conteúdo de / Etc / passwd e separar com sucesso os campos em diferentes variáveis. Aqui temos um script que faz exatamente isso:
#! / Bin / bash
# read-ifs: lê os campos de um arquivo FILE = / etc / passwd
#! / Bin / bash
# read-ifs: lê os campos de um arquivo FILE = / etc / passwd
read -p "Digite um nome de usuário>" user_name file_info = $ (grep "^ $ user_name:" $ FILE) if [-n "$ file_info"]; então
IFS = ":" ler usuário pw uid gid nome shell home <<< "$ file_info" echo "User = '$ user'"
echo "UID = '$ uid'"
echo "GID = '$ gid'" echo "Full Name = '$ name'" echo "Home Dir. = '$ home'" echo "Shell = '$ shell'"
outro
echo "Não existe tal usuário '$ user_name'"> & 2 exit 1
fi
read -p "Digite um nome de usuário>" user_name file_info = $ (grep "^ $ user_name:" $ FILE) if [-n "$ file_info"]; então
IFS = ":" ler usuário pw uid gid nome shell home <<< "$ file_info" echo "User = '$ user'"
echo "UID = '$ uid'"
echo "GID = '$ gid'" echo "Full Name = '$ name'" echo "Home Dir. = '$ home'" echo "Shell = '$ shell'"
outro
echo "Não existe tal usuário '$ user_name'"> & 2 exit 1
fi
Este script solicita que o usuário insira o nome de usuário de uma conta no sistema e, em seguida, exibe os diferentes campos encontrados no registro do usuário no / Etc / passwd Arquivo. O script contém duas linhas interessantes. O primeiro é:
file_info = $ (grep "^ $ user_name:" $ FILE)
Esta linha atribui os resultados de um grep comando para a variável informações do arquivo. A expressão regular usada por grep garante que o nome de usuário corresponderá apenas a uma única linha no / Etc / passwd arquivo.
A segunda linha interessante é esta:
IFS = ":" ler usuário pw uid gid nome shell inicial <<< "$ file_info"
A linha consiste em três partes: uma atribuição de variável, um ler comando com uma lista de nomes de variáveis como argumentos e um novo operador de redirecionamento estranho. Veremos primeiro a atribuição da variável.
O shell permite que uma ou mais atribuições de variáveis ocorram imediatamente antes de um comando. Essas atribuições alteram o ambiente para o comando a seguir. O efeito da atribuição é temporário; apenas mudando o ambiente durante o comando. Em nosso caso, o valor de IFS é alterado para um caractere de dois pontos. Como alternativa, poderíamos ter codificado desta forma:
OLD_IFS = "$ IFS" IFS = ":"
ler usuário pw uid gid nome shell home <<< "$ file_info" IFS = "$ OLD_IFS"
onde armazenamos o valor de IFS, atribua um novo valor, execute o ler comando e, em seguida, restaure IFS ao seu valor original. Claramente, colocando a atribuição de variável na frente de
o comando é uma maneira mais concisa de fazer a mesma coisa.
O << operador indica um aqui corda. Uma string here é como um documento here, só que mais curta, consistindo em uma única string. Em nosso exemplo, a linha de dados do
O arquivo / etc / passwd é alimentado para a entrada padrão do comando de leitura. Podemos ganhar
der por que esse método um tanto oblíquo foi escolhido em vez de:
echo "$ file_info" | IFS = ":" ler usuário pw uid nome gid shell inicial
Bem, há uma razão ...
Você não pode ler o cachimbo
Enquanto o ler comando normalmente recebe a entrada da entrada padrão, você não pode fazer isso:
echo "foo" | leitura
Esperávamos que isso funcionasse, mas não funciona. O comando parecerá ter sucesso, mas o RESPOSTA variável sempre estará vazia. Por que é isso?
A explicação tem a ver com a maneira como o shell lida com pipelines. No bater (e outras conchas, como sh), pipelines criam subcamadas. Essas são cópias do shell e de seu ambiente, usadas para executar o comando no pipeline. Em nosso exemplo acima, ler é executado em um subshell.
Subshells em sistemas do tipo Unix criam cópias do ambiente para os processos usarem enquanto são executados. Quando o processo termina, a cópia do ambiente é destruída. Isso significa que um subshell nunca pode alterar o ambiente de seu processo pai. ler atribui variáveis, que passam a fazer parte do ambiente. No exemplo acima, ler atribui o valor “foo” à variável RESPONDER no ambiente de seu subshell, mas quando o comando sai, o subshell e seu ambiente são destruídos e o efeito da atribuição é perdido.
Usar strings aqui é uma maneira de contornar esse comportamento. Outro método é discutido no Capítulo 36.