Mateusz Piotrowski's questions

Gostaria de entender por que chamar chill()um bloco de ação do DTrace aumenta a timestampvariável, mas não vtimestampe walltimestamp.

Aqui está um exemplo mostrando timestampo aumento após uma chamada para chill():

# dtrace -w -c true -n 'pid$target:::entry {self->t = $1; chill(1); printf("%d\n", $1 - self->t);}' timestamp
dtrace: description 'pid$target:::entry ' matched 3082 probes
dtrace: allowing destructive actions
dtrace: pid 6734 has exited
CPU     ID                    FUNCTION:NAME
  5  83475          _r_debug_postinit:entry 11258

  5  85771                     atexit:entry 2218

  5  86468              __libc_atexit:entry 491

  5  86428                       exit:entry 441

  5  85397    __cxa_thread_call_dtors:entry 441

  5  86213             __cxa_finalize:entry 447

  5  86213             __cxa_finalize:entry 565

  5  83470            _rtld_addr_phdr:entry 454

  5  86213             __cxa_finalize:entry 431

  5  83470            _rtld_addr_phdr:entry 1645

  5  84405                      _exit:entry 432

Se rodarmos o mesmo script mas usarmos walltimestamp(ou vtimestamp), veremos que o contador não aumentou:

# dtrace -w -c true -n 'pid$target:::entry {self->t = $1; chill(1); printf("%d\n", $1 - self->t);}' walltimestamp
dtrace: description 'pid$target:::entry ' matched 3082 probes
dtrace: allowing destructive actions
dtrace: pid 6707 has exited
CPU     ID                    FUNCTION:NAME
  4  83475          _r_debug_postinit:entry 0

  4  85771                     atexit:entry 0

  4  86468              __libc_atexit:entry 0

  4  86428                       exit:entry 0

  4  85397    __cxa_thread_call_dtors:entry 0

  4  86213             __cxa_finalize:entry 0

  4  86213             __cxa_finalize:entry 0

  4  83470            _rtld_addr_phdr:entry 0

  4  86213             __cxa_finalize:entry 0

  4  83470            _rtld_addr_phdr:entry 0

  4  84405                      _exit:entry 0

Isso é compreensível para vtimestamp, pois não aumenta ao executar o código DTrace, mas não entendo o walltimestampcomportamento de s aqui.

Estou executando o FreeBSD 13.1-RELEASE-p1 aqui no amd64.

Eu gostaria de criar uma nova localidade no FreeBSD. Eu pensei que poderia simplesmente copiar um dos existentes, /usr/share/localemas aparentemente não é tão simples.

Em primeiro lugar, apenas crio uma cópia do en_US.UTF-8locale.

$ sudo cp -R /usr/share/locale/en_US.UTF-8 /usr/share/locale/en_DK.UTF-8

Estou testando minha configuração com mosh, então com o padrão en_US.UTF-8está tudo bem:

$ LC_ALL=en_US.UTF-8 PATH_LOCALE=/usr/share/locale mosh xyz.example.org

No entanto, se eu tentar usar a en_DK.UTF-8localidade recém-criada, recebo os seguintes erros:

$ LC_ALL=en_DK.UTF-8 PATH_LOCALE=/usr/share/locale mosh xyz.example.org
The locale requested by LC_ALL=en_DK.UTF-8 isn't available here.
Running `locale-gen en_DK.UTF-8' may be necessary.

mosh-server needs a UTF-8 native locale to run.

Unfortunately, the local environment ([no charset variables]) specifies
the character set "US-ASCII",

The client-supplied environment (LC_ALL=en_DK.UTF-8) specifies
the character set "US-ASCII".

sh: warning: setlocale: LC_ALL: cannot change locale (en_DK.UTF-8)
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
LANG=en_DK.UTF-8
LC_CTYPE="en_DK.UTF-8"
LC_NUMERIC="en_DK.UTF-8"
LC_TIME="en_DK.UTF-8"
LC_COLLATE="en_DK.UTF-8"
LC_MONETARY="en_DK.UTF-8"
LC_MESSAGES="en_DK.UTF-8"
LC_PAPER="en_DK.UTF-8"
LC_NAME="en_DK.UTF-8"
LC_ADDRESS="en_DK.UTF-8"
LC_TELEPHONE="en_DK.UTF-8"
LC_MEASUREMENT="en_DK.UTF-8"
LC_IDENTIFICATION="en_DK.UTF-8"
LC_ALL=en_DK.UTF-8
Connection to xyz.example.org closed.
/usr/local/bin/mosh: Did not find mosh server startup message. (Have you installed mosh on your server?)

Gostaria de saber se existe uma ferramenta que me permita verificar se cometi algum erro de sintaxe no wpa_supplicant.conf(5) .

Eu estou procurando um utilitário para wpa_supplicant(8) que sirva ao mesmo propósito que o --checksinalizador de visudo(8) do sudo(8) suite.

A única solução que encontrei até agora é executar

wpa_supplicant -c wpa_supplicant.conf -iNonexistentInterface`

mas está abaixo do ideal. Parcialmente porque o código de retorno é sempre 255 devido ao nome de interface inválido.

Idealmente, eu gostaria que o utilitário fosse executado no FreeBSD.

Temos env(1) para modificar o ambiente do comando que queremos executar (por exemplo env MANPAGER=more man dtrace). Existe algo semelhante, mas para modificar o diretório em que o comando será iniciado?

O ideal seria que ficasse assim:

theMagicCommand /new/cwd myProgram

Dessa forma, ele pode ser "encadeado" com outros comandos do tipo env(1), por exemplo,

daemon -p /tmp/pid env VAR=value theMagicCommand /new/cwd myProgram

Até agora posso pensar na seguinte solução, que infelizmente não tem a mesma interface que env(1):

cd /new/cwd && myProgram

Além disso, posso criar um script de shell simples como este:

#! /bin/sh -
cd "${1:?Missing the new working directory}" || exit 1
shift
exec "${@:?Missing the command to run}"

mas estou procurando algo que já existe (pelo menos no macOS e FreeBSD).

myProgramnão é necessariamente um aplicativo de desktop (nesse caso eu poderia usar apenas a tecla Path em um arquivo .desktop ).

É possível rolar além do fundo em menos?

Idealmente, gostaria de poder ver a última linha do arquivo que estou visualizando na parte superior da janela do meu terminal (o restante da tela pode ser preenchido com tils ( ~), o que significa linha vazia/nada para ver aqui em menos).