Um nome de arquivo tem um asterisco por algum motivo - ele não será alterado e o conteúdo não será executado

Question

Eu uso o ambiente de servidor compartilhado do CentOS com o Bash.

ll "$HOME"/public_html/cron_daily/

traz:

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

Eu não sei porque o nome do arquivo tem um asterisco no final. Não me lembro de adicioná-lo e, quando tentei alterá-lo, recebi 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 porque meu cronjob do Cpanel falhou:

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

    

Answer 1

O asterisco não faz parte do nome do arquivo. Você está vendo isso porque o arquivo é executável e seu alias para ll inclui o -F flag:

-F

Display a slash ('/') immediately after each pathname that is a directory, an asterisk ('*') after each that is executable, an at sign ('@') after each symbolic link, an equals sign ('=') after each socket, a percent sign ('%') after each whiteout, and a vertical bar ('|') after each that is a FIFO.

Como Kusalananda mencionou, você não pode globar todos os scripts em um diretório com cron assim. Com as partes de execução, você pode chamar "$HOME"/public_html/cron_daily/ para executar todos os scripts no diretório (não apenas .sh) ou percorrê-los conforme mencionado em este post .

    

Answer 2

Jesse_b já respondeu à pergunta, mas acho que vale a pena abordar alguns possíveis equívocos.

O shell tem caracteres que possuem um significado especial sob algumas condições específicas. Por exemplo: | é usado em pipelines, > em redirecionamentos, \ para caracteres de escape, etc. Esses caracteres não são interpretados literalmente pelo shell, e é por isso que quando você faz echo foo>bar , foo>bar won não será impresso no seu terminal, mas foo será redirecionado para o arquivo bar .

Felizmente, o shell também possui um mecanismo que faz com que esses caracteres percam seu significado especial: citando. Em shells POSIX, existem 3 mecanismos de cotação :

• Barra invertida \ : preserva o valor literal do caractere seguinte, com exceção de <newline> .
• As aspas duplas "..." : preservam o valor literal de todos os caracteres entre aspas duplas, com exceção dos caracteres ' , $ e \ .
• As aspas simples '...' : preservam o valor literal de cada caractere entre aspas simples, sem exceções.

Então, seguindo o exemplo anterior, se quiséssemos imprimir foo>bar literalmente, poderíamos ter feito:

• echo foo\>bar
• echo "foo>bar"
• echo 'foo>bar'

O asterisco * é um desses caracteres especiais, faz parte da correspondência de padrões notação e é usada para expansão de nome de arquivo . Em outras palavras, comandos como echo *.txt substituirão o padrão pelos arquivos que o padrão corresponde.

No seu caso, cron_daily/wp_cli.sh* corresponde apenas a cron_daily/wp_cli.sh , por isso mv vê dois argumentos idênticos e reclama. Tudo bem, porque não há arquivo cron_daily/wp_cli.sh* . Mas se você tivesse um arquivo cron_daily/wp_cli.sh* real e mais arquivos que pudessem ser correspondidos pelo padrão, mv teria falhas.

Considere o seguinte cenário:

$ ls -l
total 0
-rw-rw-r-- 1 user group 0 jul 14 12:00 file*
-rw-rw-r-- 1 user group 0 jul 14 12:00 file1
-rw-rw-r-- 1 user group 0 jul 14 12:00 file2
-rw-rw-r-- 1 user group 0 jul 14 12:00 file3

Se eu tentar renomear file* sem usar aspas:

$ mv file* new_file
mv: target 'new_file' is not a directory

Isso porque esses são os argumentos que mv recebe, portanto new_file deve ser um diretório:

$ printf '[%s]\n' file* new_file
[file*]
[file1]
[file2]
[file3]
[new_file]

Para renomear com sucesso file* , preciso citar esse argumento:

$ mv 'file*' new_file
$ ls -l
total 0
-rw-rw-r-- 1 user group 0 jul 14 12:00 file1
-rw-rw-r-- 1 user group 0 jul 14 12:00 file2
-rw-rw-r-- 1 user group 0 jul 14 12:00 file3
-rw-rw-r-- 1 user group 0 jul 14 12:00 new_file