O statcomando oferece, ou bashoferece, uma maneira direta de verificar se se FILENAMErefere a um arquivo em vez de, digamos, a um diretório?
Usando bashand stat, aqui está minha solução feia:
if RESPONSE="$(LC_ALL=C stat -c%F FILENAME)"\
&& [ "$RESPONSE" = 'regular file'\
-o "$RESPONSE" = 'regular empty file' ]
then
# do something ...
fi
Veja também esta questão relacionada.
Meu sistema GNU/Linux transmite dados pela Internet, quer eu peça ou não. Como posso fazê-lo parar?
Por exemplo, sem perguntar, o software Firefox do meu sistema evidentemente entra em contato com o Mozilla.org em segundo plano. Da mesma forma, sem perguntar, o software GNOME do meu sistema solicita notificações de alguém pela rede. (Estes são apenas exemplos. Não estou perguntando como configurar o Firefox ou o GNOME especificamente. Em vez disso, estou perguntando como parar transmissões automáticas não autorizadas em geral.)
quero meu sistema
Como posso fazer meu sistema parar de balbuciar?
(Para informações, minha distribuição é Debian. No entanto, usuários Debian, Fedora e Arch são igualmente bem-vindos para responder.)
No meu sistema Debian GNU/Linux 9, quando um binário é executado,
Por quê?
Presumo que a inicialização zero promova a segurança, mas, se para o heap, por que não também para a pilha? A pilha também não precisa de segurança?
Minha pergunta não é específica para o Debian até onde eu sei.
Exemplo de código C:
#include <stddef.h>
#include <stdlib.h>
#include <stdio.h>
const size_t n = 8;
// --------------------------------------------------------------------
// UNINTERESTING CODE
// --------------------------------------------------------------------
static void print_array(
const int *const p, const size_t size, const char *const name
)
{
printf("%s at %p: ", name, p);
for (size_t i = 0; i < size; ++i) printf("%d ", p[i]);
printf("\n");
}
// --------------------------------------------------------------------
// INTERESTING CODE
// --------------------------------------------------------------------
int main()
{
int a[n];
int *const b = malloc(n*sizeof(int));
print_array(a, n, "a");
print_array(b, n, "b");
free(b);
return 0;
}
Resultado:
a at 0x7ffe118997e0: 194 0 294230047 32766 294230046 32766 -550453275 32713
b at 0x561d4bbfe010: 0 0 0 0 0 0 0 0
O padrão C não pede malloc()para limpar a memória antes de alocá-la, é claro, mas meu programa C é meramente ilustrativo. A pergunta não é sobre C ou sobre a biblioteca padrão de C. Em vez disso, a pergunta é sobre por que o kernel e/ou o carregador de tempo de execução estão zerando o heap, mas não a pilha.
OUTRO EXPERIMENTO
Minha pergunta diz respeito ao comportamento GNU/Linux observável em vez dos requisitos dos documentos de padrões. Se não tiver certeza do que quero dizer, tente este código, que invoca mais comportamento indefinido ( indefinido, ou seja, no que diz respeito ao padrão C) para ilustrar o ponto:
#include <stddef.h>
#include <stdlib.h>
#include <stdio.h>
const size_t n = 4;
int main()
{
for (size_t i = n; i; --i) {
int *const p = malloc(sizeof(int));
printf("%p %d ", p, *p);
++*p;
printf("%d\n", *p);
free(p);
}
return 0;
}
Saída da minha máquina:
0x555e86696010 0 1
0x555e86696010 0 1
0x555e86696010 0 1
0x555e86696010 0 1
No que diz respeito ao padrão C, o comportamento é indefinido, então minha pergunta não diz respeito ao padrão C. Uma chamada para malloc()não precisa retornar o mesmo endereço todas as vezes, mas, como essa chamada para de malloc()fato retorna o mesmo endereço todas as vezes, é interessante notar que a memória, que está no heap, é zerada a cada vez.
A pilha, por outro lado, não parecia estar zerada.
Não sei o que o último código fará em sua máquina, pois não sei qual camada do sistema GNU/Linux está causando o comportamento observado. Você pode, mas tente.
ATUALIZAR
@Kusalananda observou nos comentários:
Para o que vale a pena, seu código mais recente retorna diferentes endereços e (ocasionalmente) dados não inicializados (diferentes de zero) quando executados no OpenBSD. Isso obviamente não diz nada sobre o comportamento que você está testemunhando no Linux.
Que meu resultado difere do resultado no OpenBSD é realmente interessante. Aparentemente, meus experimentos estavam descobrindo não um protocolo de segurança do kernel (ou linker), como eu pensava, mas um mero artefato de implementação.
Diante disso, acredito que, juntas, as respostas abaixo de @mosvy, @StephenKitt e @AndreasGrapentin resolvem minha dúvida.
Veja também no Stack Overflow: Por que o malloc inicializa os valores como 0 no gcc? (crédito: @bta).
Meu laptop é uma máquina normal e desinteressante com duas GPUs padrão não multiplexadas e uma instalação comum do Debian. A GPU secundária (uma Radeon) geralmente é desligada, mas posso ativá-la e usá-la (por exemplo) DRI_PRIME=1 glxgears. O arquivo fonte do Mesa src/loader/loader.c o gerencia.
Está DRI_PRIMEindocumentado?
Desejo ler a documentação, mas não consigo encontrá-la. Curiosamente, não está aqui. Além disso, o Google não pode localizá-lo. Se você souber onde está a documentação, você diria?
Alternar GPUs é uma função de sistema bastante importante. Alguém poderia pensar que o mecanismo que faz isso seria completamente documentado, mas tudo o que posso encontrar são algumas entradas oblíquas do changelog e algumas tradições online como esta.
INFORMAÇÃO ADICIONAL
Você não precisará do Debian para responder à minha pergunta. Qualquer Linux deve fazer.
Caso um leitor que deseja começar a aprender sobre comutação de GPU tropeçar aqui, ele pode tentar sudo cat /sys/kernel/debug/vgaswitcheroo/switchler html/newstyle/gpu/vga-switcheroo.html na fonte do kernel Linux. Também, man 8 lspci. Levei duas horas para descobrir isso, então menciono aqui para economizar tempo do leitor.
Enquanto isso, onde está a documentação adequada das variáveis de ambiente do Mesa como DRI_PRIME, por favor?