Eu uso o ambiente de servidor compartilhado CentOS com Bash.

ll "$HOME"/public_html/cron_daily/

traz:

./
../
-rwxr-xr-x 1 user group 181 Jul 11 11:32 wp_cli.sh*

Não sei por que o nome do arquivo tem um asterisco no final. Não me lembro de adicioná-lo e, quando tentei alterá-lo, obtive esta saída:

[~/public_html]# mv cron_daily/wp_cli.sh* cron_daily/wp_cli.sh
+ mv cron_daily/wp_cli.sh cron_daily/wp_cli.sh
mv: `cron_daily/wp_cli.sh' and `cron_daily/wp_cli.sh' are the same file

Este erro pode indicar por que meu cronjob do Cpanel falhou:

Fiz algo errado ao alterar o arquivo ou ao executar o comando Cpanel cron? Porque ambas as operações parecem falhar.

Tentei executar os seguintes comandos semelhantes no CentOS (12.x):

printf "\nhello" "$HOME"/.bashrc
printf "\nhello" ${HOME}/.bashrc

Após a execução eu exponho o conteúdo do .bashrcarquivo e não vejo nada de novo.

set -xtraz uma linha vazia de saída para ambos, então meu comando provavelmente está errado.

Eu tive um problema semelhante com a echosintaxe (editar: é provável que me lembre mal, mas lembrei que poderia anexar conteúdo echosem operador de apêndice como >>).

O que você vê de errado?

Desejo combinar todos os arquivos que terminam com uma determinada extensão com um glob de shell.

Nesse caso, desejo direcionar todos os arquivos que terminam com a .shextensão, que são arquivos bourne que executo com o shell Bash depois de colocar um "shebang" (como #!/bin/bash) em sua primeira linha.

Este é, por exemplo, um comando cron que tenho:

0 0 * * * "$HOME"/public_html/cron_daily/myfile.sh 2>/dev/null

Em vez de myfile.sh, preciso direcionar todos os arquivos nesse diretório, terminando com uma .shextensão.

O código a seguir está correto?

0 0 * * * "$HOME"/public_html/cron_daily/*$.sh 2>/dev/null

Atualizar

Eu acho que isso é bom ao usar um glob:

*.{sh}

Por favor, revise estes códigos que visam fazer basicamente a mesma tarefa (encontrar o principal .htaccessdo site e alterá-lo):

for dir in "$HOME"/public_html/*.{com,co.il}/; do 
  if pushd "$dir"; then 
    chmod 644 .htaccess 
    popd 
  fi 
done 2>/dev/null 

e:

find "$HOME"/public_html/*.{com,co.il} -name ".htaccess" -exec chmod 644 {} \;

Isso também deve afetar os .htaccessarquivos em subdiretórios de cada diretório em public_html?

Neste post , a resposta de Stephen exibe este código:

cat <<-"EOF1" >> myPath/myFile.append
if ! grep -F -q -f myPath/myFile{.append,}; then
    cat myPath/myFile.append >> myPath/myFile
fi

Como é que não há delimitador para o documento aqui?

Qual código de saída grep inteiro retorna quando não corresponde a uma string?

Eu sei que ele retorna 0 quando corresponde e presumo que retorna 1 quando não corresponde.

Isso é correto?

Eu tenho um arquivo ao qual quero anexar algum conteúdo (incluindo o primeiro, segundo e terceiro espaços vazios visíveis no meu código abaixo):

### Eu sou o texto 1

### Eu sou o texto 2

_{(O texto real que anexo é muito maior do que essas 5 linhas).}

Para simplesmente anexar conteúdo a um arquivo, eu faço:

cat <<-"EOF" >> myPath/myFile
    content...
EOF

Mas como eu poderia garantir que o heredocument acrescentaria o conteúdo apenas se o conteúdo ainda não existir em um arquivo e que, caso contrário, a operação seria abortada?

Se apenas parte do conteúdo do bloco já existir no arquivo, toda a operação também deve ser abortada.

Eu preciso de uma maneira de direcionar todos os subdiretórios sob os public_htmlquais termina com .comou outros TLDs como .bizou .co.ilque eu possa listar, em um documento aqui .

Este meu hereoducmnet dentro de uma instrução pushd-popd- if-fianinhada dentro de um forloop:

for dir in "$HOME"/public_html/*/; do
    if pushd "$dir"; then
        cat <<-"EOF" >> "$HOME"/public_html/ALL_DOT_COM|ALL_DOT_BIZ/.htaccess

           Apache_directive_set_1

           Apache_directive_set_2

           popd
        EOF
    fi
done 2>myErrors.txt

Existe uma maneira de combinar regex para conseguir isso, diretamente dentro da linha de redirecionamento/anexação do documento here (onde ALL_DOT_COM|ALL_DOT_BIZestá)?

Criei alguns ambientes de servidor com Ubuntu e Bash, em provedores de hospedagem "shell autogerenciados" como DigitialOcean, nos quais executei aplicativos Drupal/WordPress.

Durante todo esse tempo não tive a necessidade de usar o que se chama de " substituição de comando ".

Eu pergunto, qual será um problema, um "padrão" no qual um programador Bash teria que usar esse conceito? Por favor, dê um exemplo?

Eu tenho o seguinte conjunto de comandos usado para atualizar todos os meus sites WordPress em minha partição de hospedagem compartilhada CentOs na plataforma do meu provedor de hospedagem (via cron diário).

Os wpcomandos dentro do pushd-popdconjunto são do programa WP-CLI , que é uma extensão Bash usada para várias ações em nível de shell em sites WordPress.

for dir in public_html/*/; do
    if pushd "$dir"; then
        wp plugin update --all
        wp core update
        wp language core update
        wp theme update --all
        popd
    fi
done

O diretório public_htmlé o diretório no qual todos os diretórios do site estão localizados (cada site geralmente possui um banco de dados e um diretório de arquivos principal).

Dado que public_htmltem alguns diretórios que não são diretórios do site WordPress, o WP-CLI retornaria erros relacionados a eles.

Para evitar esses erros, suponho que poderia fazer:

for dir in public_html/*/; do
    if pushd "$dir"; then
        wp plugin update --all 2>myErrors.txt
        wp core update 2>myErrors.txt
        wp language core update 2>myErrors.txt
        wp theme update --all 2>myErrors.txt
        popd
    fi
done

Em vez de escrever 2>myErrors.txtquatro vezes (ou mais), existe uma maneira de garantir que todos os erros, de todos os comandos, irão para o mesmo arquivo, em uma linha?

Estou usando o Ubuntu 16.04 com Bash e tentei ler na Wikipedia , aqui e aqui , mas não consegui entender o significado de "substituição de comando" em scripts de shell em geral e em Bash em particular, como em:

$(command)

ou

`command`

Qual é o significado deste termo?

Editar: Quando publiquei esta pergunta pela primeira vez, já conhecia o conceito puro de substituição e também o conceito Linux de substituição de variável (substituir uma variável por seu valor por execução), mas ainda perdi o objetivo desse recurso de shell da documentação para qualquer coisa razão ou grupo de razões.

Minha resposta após a pergunta bloqueada

A substituição de comandos é uma operação com sintaxe dedicada tanto para executar um comando quanto para manter a saída desse comando (armazenada) por uma variável para uso posterior.

Um exemplo com date:

thedate="$(date)"

Podemos então imprimir o resultado usando o comando printf:

printf 'The date is %s\n' "$thedate"

1. A sintaxe de substituição do comando é $().
2. O comando em si é date.
3. Combinando ambos obtemos $(date), seu valor é o resultado da substituição (que poderíamos obter após a execução ).
4. Salvamos esse valor em uma variável, $thedate, para uso posterior.
5. Exibimos o valor de saída mantido pela variável com printf, conforme o comando acima.

Nota: \nin printfé uma quebra de linha.

Na terceira edição de "Learning the Bash shell" de Newham e Rosenblatt, a página 19 menciona a descompactação de um arquivo chamado gcc.tar.Z.

Digite uncompress gcc.tar &(você pode omitir o Z).

Por que os autores dizem "você pode omitir o Z"? Por que não apenas mantê-lo? ...

No man uncompressUbuntu 16.04, cheguei ao manual do Gunzip ("Gzip") que diz:

Se o nome do arquivo compactado for muito longo para seu sistema de arquivos, o gzip o truncará. Gzip tenta truncar apenas as partes do nome do arquivo com mais de 3 caracteres.

O gunzip obtém uma lista de arquivos em sua linha de comando e substitui cada arquivo cujo nome termina com .gz, -gz, .z, -z ou _z (ignorando maiúsculas e minúsculas) e que começa com o número mágico correto por um arquivo descompactado sem o extensão original. O gunzip também reconhece as extensões especiais .tgz e .taz como atalhos para .tar.gz e .tar.Z, respectivamente. Ao compactar, o gzip usa a extensão .tgz, se necessário, em vez de truncar um arquivo com uma extensão .tar.

O gunzip às vezes é capaz de detectar um arquivo .Z ruim

Admito que não está totalmente claro para mim por que o programa tem o comportamento mencionado acima.

Na terceira edição de "Learning the Bash shell" de Newham e Rosenblatt está escrito na página 15 como um comentário:

se um determinado utilitário UNIX não aceitar a entrada padrão quando você deixar de fora o argumento do nome do arquivo, tente usar um traço (0) como argumento. Alguns sistemas NIX fornecem entrada padrão como um arquivo para que você possa tentar fornecer o arquivo /dev/stdin como o arquivo de entrada argumnet.

A última frase não está clara para mim - qual é o significado de "fornecer entrada padrão como um arquivo"?

Não é perigoso criar "repetidamente" arquivos nomeados /dev/stdinem um sistema (eu pessoalmente uso o Ubuntu 16.04).

BTW me deparei com um caso semelhante neste post .

Costumo confundir globs de shell do Bash 3.x:

?      # Match any single character.
*      # Match any string of characters (up until the asterisk).
[set]  # Match any character in set (but not the entire set itself).
[!set] # Match any character not in set.

com regex (especialmente PCRE ).

Minha pergunta é por que não vê-los como "Bash regex" (assim como temos "JavaScript regex" por exemplo)?

Por que não vê-los apenas como outro "dialeto" do regex?

Claro que seria pouco ortodoxo, mas não tenho certeza de que não haja nenhuma razão lógica formal para não fazê-lo.

Ao praticar regex no Bash, tentei combinar todo o conjunto/padrão de pesquisa dentro dos colchetes.

Em vez disso, combinei apenas cada caractere neles.

Por exemplo, com

cd
touch a.c a.h a.o a.cho
ls *.[cho]

O lscombinado:

a.c
a.h
a.o 

mas não correspondeu ao conjunto inteiro como em a.cho.

Por que não combinei todo o conjunto também e como é possível fazer isso?

Em "Learning the Bash Shell" de O'reilly (terceira edição), está escrito na página 7:

lp -d lp1 -h myfiletem duas opções e um argumento.

Por quê?

Vejo o que considero duas opções, cada uma com um argumento:

-d lp1
-h myfile

Notas

lpimprime um arquivo (concretamente, através de uma impressora, e não no terminal).

Algumas vezes eu confundi bash -vou bash --vrepresentei bash --versiono que eles não fazem, a partir de Bash 4.3.48(1).

De man bash, bash -vé equivalente a bash --verbose; embora retorne uma saída grande (supostamente alguns bashrcarquivos, talvez mais); Acho que apenas inicia uma sessão infantil.

bash --vproduz muito menos, principalmente bash: --v: invalid option.

Eu planejei perguntar se algum dos dois poderia ser problemático em um bash totalmente padrão, mas não vejo nenhuma evidência para isso e suponho que os novatos do Bash não devam se estressar com isso.

Minha pergunta

Eu entendi mal de man bash, qual é o significado de bash -v varname.

Qual é o significado de iniciar uma nova sessão bash com uma variável aparentemente indefinida, ou significa iniciá-la também imprimindo o valor de uma variável exportada [1]?

Notas para os recém-chegados:

1. Uma variável exportada é qualquer variável herdada de uma sessão shell para outra (digamos, da sessão 0 para a sessão 1).

Eu uso o Ubuntu 16.04 (xenial) com Bash 4.3.48(1) e zip3.0.

Em um arquivo contendo um script bash ( #!/bin/bash) com várias funções diferentes, também tenho essa função usada para criar um backup completo do banco de dados + backup raiz do documento em um arquivo zip :

imb() {
    drt="/var/www/html"
    date="$(date +%F-%T)"
    mysqldump -u root -p --all-databases | zip "$drt/db-$date.zip" - # Note the hyphen before this comment;
    zip -r "all_zipped-$date.zip" "$drt"/ -x "*/cache/*"
    rm -f "$drt/db-$date.zip"
}

Eu criei o arquivo acima mencionado ( source ~/function.sh) e executei imbno modo de depuração ( set -x):

A senha do banco de dados foi solicitada e, em seguida, algum tempo se passou (indicando o backup do banco de dados criado). Além disso, um zip detalhado apareceu (muito longo para colar ou rastrear no terminal) indicando que tudo na raiz do documento foi compactado.

No entanto, nenhum backup aparece em /var/www/html/.

Minha pergunta

Devido a um comentário, sinto que devo fazer duas perguntas, que achei semelhantes, mas na verdade diferentes:

1. Onde o zip colocou meus arquivos (supondo que não seja uma "criação de arquivo" no sentido de criação manual como com touch, por exemplo)? Claro, os arquivos criados e localizados em algum lugar por um processo não devem necessariamente pertencer ao meu usuário.

2. Como eu poderia descobrir onde estava localizado o último arquivo criado pelo meu usuário atual ?

Eu esperava que estivesse localizado em /var/www/html/:

zip -r "all_zipped-$date.zip" "$drt"/ -x "*/cache/*"

mas não foi. Não conheço uma maneira eficiente de saber onde foi criado sem executar toda a árvore de arquivos do meu sistema a partir da raiz ( /), pois isso pode levar horas naquela máquina.

Atualizar

Ao escrever esta pergunta, visitei meu diretório inicial ( $HOME/), lá encontrei o arquivo, mas não sei por que ele foi criado lá na raiz do documento.

Eu uso o Ubuntu 16.04 (xenial) com o Bash 4.3.48(1).

Com base na resposta de Stephen Kitt nesta sessão , tentei executar o seguinte comando como parte de uma função chamada imb():

mysqldump -u root -p --all-databases | zip "$drt/db-$date.zip" -

Eu criei o arquivo no qual a imb()função se encontra:

source ~/functions.sh

A função

imb() {
    drt="/var/www/html"
    date="$(date +\%F-\%T)"
    mysqldump -u root -p --all-databases | zip "$drt/db-$date.zip" - # Note the hyphen before this comment;
    zip -r "all_zipped-$date.zip" "$drt"/ -x "*/cache/*"
    rm -f "$drt/db-$date.zip"
}

Meu problema

Chamar a função falha com o ziperro:

zip error: Nothing to do! (/var/www/html/db-2018-04-13-22:27:47.zip)

Isso parece acontecer porque o hífen foi ignorado de alguma forma; Eu suponho que de uma olhada em:

type -a imb

quais saídas:

imb is a function

imb () {
    date="$(date +\%F-\%T)";
    mysqldump -u root -p --all-databases | zip "$drt/db-$date.zip";
    zip -r "all_zipped-$date.zip" "$drt"/ -x "*/cache/*";
    rm -f "$drt/db-$date.zip" 
}

Notei a falta de hífen aqui.

Minha pergunta

Por que a função falha / por que o Bash supostamente ignora o hífen?

Qual é a principal diferença entre um arquivo temporário ("tempfile") e um arquivo normal no Linux?

A única diferença principal que reconheço entre esses dois inodes é que, em geral, um "arquivo temporário" tem um ciclo de vida muito mais curto do que um "arquivo normal", por qualquer motivo, enquanto ambos são, por princípio, praticamente temporários (pelo menos do fato de que este universo está caminhando para uma morte total por calor ).

Referências:

1. Como um pipe difere de um arquivo temporário?

2. Como um FIFO (pipe nomeado) difere de um tubo regular (pipe sem nome)?