Sergiy Kolodyazhnyy's questions

TL; DR : Por que o grupo de chaves POSIX precisa de espaços após a {palavra reservada, mas o subshell não após a palavra reservada (?

A gramática do shell POSIX define o grupo de chaves e o subshell da seguinte maneira

brace_group      : Lbrace compound_list Rbrace

subshell         : '(' compound_list ')'

Agora, se estivermos lendo isso literalmente, os espaços são significativos. Isso significaria que deve haver espaço delimitando abertura e fechamento de chave e parênteses como em

{ echo hello world; }

( echo hello world )

Isso também se alinharia com as definições do Comando Composto :

Cada um desses comandos compostos tem uma palavra reservada ou operador de controle no início e uma palavra reservada ou operador de terminação correspondente no final.

No entanto, o que não faz sentido é porque (list)e ( list )funciona bem (esse espaço depois (não é necessário), no entanto, a expansão do brace tem que ter um espaço à esquerda, ou seja {echo hello;}, não funcionaria.

É claro que a palavra reservada sendo tratada como palavra shell faria sentido precisar de um espaço depois para se alinhar ao conceito de divisão de campo , no entanto, a própria definição não faz menção a espaços. Além disso, se {e (ambos são considerados palavras reservadas pela definição POSIX do comando composto, por que eles são tratados de maneira diferente em relação ao caractere de espaço após essas palavras reservadas? Agora, o manual do ksh(1) declara:

As palavras, que são sequências de caracteres, são delimitadas por caracteres de espaço em branco sem aspas (espaço, tabulação e nova linha) ou metacaracteres (<, >, |, ;, &, ( e ))

Em outras palavras, faz sentido que o ksh reconheça (como delimitador de palavras, onde a primeira palavra seria um comando ou atribuição de variável. POSIX, no entanto, não parece ser mencionado (como meta-caractere. A única explicação possível que encontrei no que diz respeito à gramática POSIX é que {é considerado um "token", onde as (não é listado como um.

/* These are reserved words, not operator tokens, and are
   recognized when reserved words are recognized. */


%token  Lbrace    Rbrace    Bang
/*      '{'       '}'       '!'   */

Então, qual seria o raciocínio preciso para essa discrepância?

Notas de resposta aceitas:

• Movida a marca de seleção aceita para a resposta de Isaac, pois fornece uma citação do próprio padrão que aborda diretamente minha pergunta:

  Por exemplo, '(' e ')' são operadores de controle, de modo que não <space>é necessário em (lista). No entanto, '{' e '}' são palavras reservadas em { list;}, de modo que, neste caso, o e principal <space>e <semicolon>são obrigatórios.

• Aceitando a resposta de Kusalananda . A resposta de Kusalananda atende ao que eu precisava, embora principalmente do ponto de vista informal e intuitivo; aponta {é uma palavra reservada e (é operador. Michael Homer também observou o mesmo nos comentários - que a definição do Comando Composto afirma (ênfase adicionada):

  Cada um desses comandos compostos tem uma palavra reservada ou operador de controle no início

• {são definidos como palavras reservadas, semelhantes a forou while, listadas na Shell Grammar (veja o último bloco de código na pergunta)

• A seção 2.9 declara (ênfase adicionada):

  Em particular, as representações incluem espaçamento entre tokens em alguns lugares onde <blank>s não seria necessário (quando um dos tokens é um operador).

• Enquanto o padrão não define explicitamente (como um operador, (é referido como operador; especificamente, a seção 2.9.2 diz

  Se o pipeline começar com a palavra reservada ! e command1 é um comando de subshell, o aplicativo deve garantir que o operador ( no início de command1 seja separado do ! por um ou mais caracteres. O comportamento da palavra reservada ! imediatamente seguido pelo operador ( não é especificado.

• A pergunta sobre o Stack Overflow por Digital Trauma aponta a Seção 2.4 sobre Palavras Reservadas:

  Este reconhecimento só ocorrerá quando nenhum dos caracteres for citado e quando a palavra for utilizada como:

  -A primeira palavra de um comando

• Como mencionado na resposta de Kusalananda "Os espaços mostrados na gramática POSIX não são espaços que precisam estar lá nos dados de entrada do shell, mas apenas uma maneira de exibir a própria gramática. É o fato de as chaves serem palavras reservadas que implica que eles precisam ser cercados por espaços em branco" Como mencionado por Michael Homer nos comentários: "Se os espaços fossem significativos por si só, eles precisariam ser listados na produção "

Caso encerrado.

Ao tentar obter o último parâmetro posicional definido em /bin/dash, tentei echo ${$#}. Surpreendentemente, isso não resultou em erro, mas no PID, que é o mesmo que o $$conteúdo da variável. Pergunta, é por que essa sintaxe funcionou? Qual é a regra de sintaxe que o shell aplicou aqui?

Basicamente, o que eu fiz foi

$ set 1 2 3 4 5
$ echo ${$#}
13819
$ echo $$
13819

Aparentemente, %o personagem também é ignorado em tal construção

$ echo ${$%}
13819

Mas *e @resulta em erro de substituição ruim:

$ echo ${$*}
sh: 10: Bad substitution
$ echo ${$@}
sh: 11: Bad substitution

Fechar aviso de votação : enquanto a duplicata vinculada faz a mesma pergunta, os comentários e a única resposta não fornecem uma resposta que seja extraída de uma fonte autorizada. A resposta à minha pergunta por Thomas Dickey , de fato fornece a resposta que eu estava procurando. Assim, a duplicata proposta não é útil, no entanto, a resposta de Thomas aqui é adequada.

De acordo com a resposta do G-Man na pergunta do superusuário e na conta pessoal neste comentário do PerlDuck , os diretórios que possuem grande quantidade de entradas chegam a um tamanho superior a 4096 bytes (o que pode ser visto com a ls -lsaída), mas uma vez que as entradas são removidas - o número nunca diminui.

A pergunta é "por que"? É devido à forma como o ext4sistema de arquivos está configurado para reter os metadados do diretório? Obviamente, remover o diretório e recriá-lo não é uma solução, pois exclui o inode original e cria um novo. O que pode ser feito para diminuir o número manualmente?

Nas Definições do POSIX existe a seção específica 3.424 , Banco de Dados do Usuário, que define quais informações devem ser relacionadas a cada ID de usuário. No entanto, ao longo do documento, não consegui encontrar (pelo menos não via simples Ctrl+ fpesquisa) menção a rootnenhum dos nomes de usuário típicos do sistema, como syslog, bin, daemon, nobody, sys. Também não parece haver menção a isso nas definições do utilitário newgrp , às quais o 3.424 se refere.

Isso levanta a questão: o POSIX requer a existência de determinados nomes de usuário ou UIDs no nível do sistema? O rootusuário precisa ser root, ou é teoricamente possível ter um sistema compatível com POSIX onde a conta do sistema mais poderosa não é chamada rootou tem UID diferente de zero?

Observe esta passagem de man bash (ênfase minha):

Coprocessos

Um coprocesso é um comando shell precedido pela palavra reservada coproc. Um coprocesso é executado de forma assíncrona em um subshell, como se o comando tivesse sido finalizado com o operador & control, com um canal bidirecional estabelecido entre o shell em execução e o coprocesso.

Agora, como sabemos, ao contrário de outros sistemas *nix, os pipes do Linux são unidirecionais (também ref man pipe(7) , seção Portabilidade). Então, como o bash coproces alcança o "tubo de duas vias" sem um existente no Linux?

Eu tenho o Ubuntu 18.04 Server no Virtual Box e, uma vez que fiquei sem 10 GB de espaço alocado no disco virtual, aumentei o tamanho do disco virtual para 17 GB e redimensionei a partição raiz com partedo resizepart comando ' (e fiz isso enquanto a partição está em uso, e sim, eu sei que é uma prática ruim, mas é uma máquina virtual para desenvolvimento, todo o código comprometido com o github e eu tenho um clone da máquina por precaução).

Tudo parece ter funcionado: lsblke udisksctlrelatar corretamente o novo tamanho, mas dfainda está preso em relatar os antigos 10 GB e 100% de uso (mesmo após a reinicialização). Por que é assim e o que posso fazer sobre dfo comportamento desse estranho?

Considere /var/run/acpid.socket. A qualquer momento eu posso me conectar a ele e me desconectar dele. Compare isso com nc:

$ nc -l -U ./myunixsocket.sock
Ncat: bind to ./myunixsocket.sock: Address already in use. QUITTING.

ncaparentemente permite apenas soquetes de uso único. A questão é então, como faço para criar um socket análogo ao /var/run/acpid.socket, para uso múltiplo e reutilização ?

TL;DR : Eu sei que um programa cria e exclui arquivos em /tmp. Como posso interceptá-los para exame?

Contexto :

Há um .jararquivo específico, no qual não confio; por algum motivo, seu código-fonte contém um método ftm e tem capacidade para fazer conexões, o que é evidente em syscalls relacionadas à rede na saída de strace(e quando quero dizer conexão, não quero dizer soquetes de domínio unix, é AF_INET6). Eu examinei com o Wireshark e não vi conexões TCP ou UDP de saída durante o uso.

No entanto, ainda não confio muito nele. A partir da saída de straceeu vi que está criando arquivos temporários /tmpe depois os exclui. Existe uma maneira de interceptar esses arquivos para examinar seu conteúdo?

Considere o seguinte (com shser /bin/dash):

$ strace -e trace=process sh -c 'grep "^Pid:" /proc/self/status /proc/$$/status'
execve("/bin/sh", ["sh", "-c", "grep \"^Pid:\" /proc/self/status /"...], [/* 47 vars */]) = 0
arch_prctl(ARCH_SET_FS, 0x7fcc8b661540) = 0
clone(child_stack=NULL, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7fcc8b661810) = 24865
wait4(-1, /proc/self/status:Pid:    24865
/proc/24864/status:Pid: 24864
[{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0, NULL) = 24865
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=24865, si_uid=1000, si_status=0, si_utime=0, si_stime=0} ---
exit_group(0)                           = ?
+++ exited with 0 +++

Não há nada incomum, grepsubstituiu um processo bifurcado (aqui feito via clone()) do processo principal do shell. Até agora tudo bem.

Agora com o bash 4.4:

$ strace -e trace=process bash -c 'grep "^Pid:" /proc/self/status /proc/$$/status'
execve("/bin/bash", ["bash", "-c", "grep \"^Pid:\" /proc/self/status /"...], [/* 47 vars */]) = 0
arch_prctl(ARCH_SET_FS, 0x7f8416b88740) = 0
execve("/bin/grep", ["grep", "^Pid:", "/proc/self/status", "/proc/25798/status"], [/* 47 vars */]) = 0
arch_prctl(ARCH_SET_FS, 0x7f8113358b80) = 0
/proc/self/status:Pid:  25798
/proc/25798/status:Pid: 25798
exit_group(0)                           = ?
+++ exited with 0 +++

Aqui o que fica aparente é que grepassume pid do processo shell e não aparente fork()ou clone()call. A questão é, então, como bashconseguir tais acrobacias sem nenhuma das chamadas?

Observe, no entanto, que clone()syscalls aparece se o comando contiver redirecionamento de shell, comodf > /dev/null

Enquanto procurava pela /proc/[PID]/fd/pasta de vários processos, encontrei uma entrada curiosa paradbus

lrwx------ 1 root root 64 Aug 20 05:46 4 -> anon_inode:[eventpoll]

Daí a pergunta, o que são anon_inodes? Eles são semelhantes aos pipes anônimos?

Contexto para a pergunta: De acordo com as especificações do POSIX , ARG_MAX é o comprimento máximo dos argumentos de linha de comando para a exec()família de funções. O que me leva a acreditar que esse é o número real de argumentos, no entanto, isso claramente não funcionou:

$ ulimit -s
8192
$ touch {1..18000}.jpg
$ rm *.jpg
$ 

Claramente, isso funciona bem, apesar de ter mais de 8192 itens. De acordo com a resposta do DW , o 8192tamanho é supostamente em kB. Então, claramente, a suposição anterior estava errada.

É aqui que entra a questão real: Como descubro a quantidade de itens que realmente ficarão acima do limite de 8192 kB? Em outras palavras, que tipo de computação devo realizar para garantir que esse *.jpgtipo de glob resultará em Argument list too longerro?

Observe que isso não é uma duplicata de O que define o tamanho máximo do argumento de comando único . Conheço getconf ARG_MAXe ulimit -svalores, essa não é a minha pergunta. Eu preciso saber como gerar argumentos suficientes em tamanho que estarão acima do limite . Em outras palavras, preciso encontrar uma maneira de obter o erro, não evitá-lo.