StoneThrow's questions

Tenho aprendido sobre gerenciamento de pacotes Linux recentemente ( https://superuser.com/questions/393681/how-to-find-out-what-versions-of-a-package-can-i-install-on-apt , https://askubuntu.com/questions/340530/how-can-i-check-the-available-version-of-a-package-in-the-repositories , Por que diferentes distros Linux têm diferentes formatos de pacote (e gerenciadores de pacotes)? , https://itsfoss.com/ubuntu-repository-mechanism/ , https://itsfoss.com/sources-list-ubuntu/ )

Se bem entendi, /etc/apt/sources.list(e .list/ .sourcesarquivos em /etc/apt/sources.list.d/) controla apt-getde onde (e utilitários relacionados) obtêm pacotes/código-fonte.

Como minha versão atual está congestionada, tenho entradas sources.listcomo as seguintes:

deb http://archive.ubuntu.com/ubuntu/ jammy main restricted
deb-src http://archive.ubuntu.com/ubuntu/ jammy main restricted

... o que eu acho que significa que (depois running apt-file update) apt-cache policy libuv1procurará todas as versões disponíveis libuv1em http://archive.ubuntu.com/ubuntu/dists/jammy/main/

$ apt-cache policy libuv1
libuv1:
  Installed: 1.43.0-1
  Candidate: 1.43.0-1
  Version table:
 *** 1.43.0-1 500
        500 http://archive.ubuntu.com/ubuntu jammy/main amd64 Packages
        100 /var/lib/dpkg/status
$
$ apt-cache madison libuv1
    libuv1 |   1.43.0-1 | http://archive.ubuntu.com/ubuntu jammy/main amd64 Packages
    libuv1 |   1.43.0-1 | http://archive.ubuntu.com/ubuntu jammy/main Sources
$

Minha pergunta é: existe uma maneira de consultar versões disponíveis do libuv1pacote para versões diferentes do Jammy sem edição sources.list?

A partir da saída acima apt-cache, parece que 1.43.0-1 é a única versão disponível - tanto como pacote quanto como fonte. Mas eu sei que os autores do libuv têm versões mais recentes . Gostaria de saber se posso consultar repositórios de pacotes não bloqueados quanto à disponibilidade de libuv1pacotes ou fontes mais recentes. Por excesso de cautela, estou nervoso em adicionar entradas como deb-src http://archive.ubuntu.com/ubuntu/ mantic main restrictedporque sources.listtenho medo de esquecer e depois executar descuidadamente apt-get upgrade- isso não correria o risco de criar um FrankenDebian ?

Eu só quero descobrir - mesmo que apenas por curiosidade - se existem versões mais recentes de libuv1fontes/pacotes em versões diferentes da minha atual, sem os riscos incorridos pela edição sources.list- existe uma maneira? Dito de outra forma: é necessário editar sources.listtanto para consultar a disponibilidade quanto para instalar os pacotes, ou é possível consultar a disponibilidade do pacote sem editar o arquivo?

Estou confuso sobre qual deve ser o valor da coluna 3 ("suite" ou "release" ou "distribution") no arquivo /etc/apt/sources.list.

De man sources.list(editado para relevância):

O formato para duas entradas de estilo de uma linha usando os tipos deb e deb-src é:

deb [opção1=valor1 opção2=valor2] uri suite [component1] [component2] [...]
deb-src [opção1=valor1 opção2=valor2] uri suite [component1] [component2] [...]

suite pode especificar um caminho exato, caso em que os componentes devem ser omitidos e suite deve terminar com uma barra...Se suite não especificar um caminho exato, pelo menos um componente deve estar presente.

suite também pode conter uma variável, $(ARCH) que se expande para a arquitetura Debian (como amd64 ou armel) usada no sistema.

Em https://wiki.debian.org/SourcesList (onde a coluna 3 parece ser chamada de "distribuição"):

A 'distribuição' pode ser o nome/alias do código de lançamento ( stretch, buster, bullseye, bookworm, sid) ou a classe de lançamento (oldoldstable, oldstable, stable, testing, instável), respectivamente. Se você pretende rastrear uma classe de lançamento, use o nome da classe.

De https://help.ubuntu.com/community/Repositories/CommandLine (editado para relevância):

Normalmente.../etc/apt/sources.list se parece com isto:

deb http://ch.archive.ubuntu.com/ubuntu/ saucy main restricted
deb-src http://ch.archive.ubuntu.com/ubuntu/ saucy main restricted

...
atrevido é o nome do lançamento ou versão da sua distribuição.
...
Para outras versões do Ubuntu, você substituiria o 'picante' pela versão atual que você instalou ('preciso', 'quantal', 'raring', 'picante', 'confiável', ...) Digite lsb_release -sc para descobrir sua libertação.

De acordo com lsb_release -sc, minha suíte/lançamento/distribuição é "jammy":

$ lsb_release -sc
jammy
$

Minha pergunta é: dado que meu conjunto/lançamento/distribuição é "jammy", que aparentemente é o valor que deve ser usado na coluna 3, por que algumas entradas no /etc/apt.sources.listarquivo têm valores na coluna 3 de jammy-securitye ?jammy-updatesjammy-backports

$ cat /etc/apt/sources.list
# See http://help.ubuntu.com/community/UpgradeNotes for how to upgrade to
# newer versions of the distribution.
deb http://archive.ubuntu.com/ubuntu/ jammy main restricted
# deb-src http://archive.ubuntu.com/ubuntu/ jammy main restricted

## Major bug fix updates produced after the final release of the
## distribution.
deb http://archive.ubuntu.com/ubuntu/ jammy-updates main restricted
# deb-src http://archive.ubuntu.com/ubuntu/ jammy-updates main restricted

## N.B. software from this repository is ENTIRELY UNSUPPORTED by the Ubuntu
## team. Also, please note that software in universe WILL NOT receive any
## review or updates from the Ubuntu security team.
deb http://archive.ubuntu.com/ubuntu/ jammy universe
# deb-src http://archive.ubuntu.com/ubuntu/ jammy universe
deb http://archive.ubuntu.com/ubuntu/ jammy-updates universe
# deb-src http://archive.ubuntu.com/ubuntu/ jammy-updates universe

## N.B. software from this repository is ENTIRELY UNSUPPORTED by the Ubuntu
## team, and may not be under a free licence. Please satisfy yourself as to
## your rights to use the software. Also, please note that software in
## multiverse WILL NOT receive any review or updates from the Ubuntu
## security team.
deb http://archive.ubuntu.com/ubuntu/ jammy multiverse
# deb-src http://archive.ubuntu.com/ubuntu/ jammy multiverse
deb http://archive.ubuntu.com/ubuntu/ jammy-updates multiverse
# deb-src http://archive.ubuntu.com/ubuntu/ jammy-updates multiverse

## N.B. software from this repository may not have been tested as
## extensively as that contained in the main release, although it includes
## newer versions of some applications which may provide useful features.
## Also, please note that software in backports WILL NOT receive any review
## or updates from the Ubuntu security team.
deb http://archive.ubuntu.com/ubuntu/ jammy-backports main restricted universe multiverse
# deb-src http://archive.ubuntu.com/ubuntu/ jammy-backports main restricted universe multiverse

deb http://security.ubuntu.com/ubuntu/ jammy-security main restricted
# deb-src http://security.ubuntu.com/ubuntu/ jammy-security main restricted
deb http://security.ubuntu.com/ubuntu/ jammy-security universe
# deb-src http://security.ubuntu.com/ubuntu/ jammy-security universe
deb http://security.ubuntu.com/ubuntu/ jammy-security multiverse
# deb-src http://security.ubuntu.com/ubuntu/ jammy-security multiverse

Os valores da coluna 3 em meu sources.listnão parecem ser um caminho exato, nem têm uma variável, e não parecem ser uma classe de lançamento, então acho que essas respectivas seções do man sources.listwiki do Debian não se aplicam. Mas não vejo nenhuma descrição nos "sufixos" de suíte/lançamento/distribuição (por não saber como chamá-los) como "-updates", "-security" ou "-backports".

Se relacionado: explique se os termos "suite", "distribuição" e "lançamento" são usados ​​indistintamente neste contexto ou se há uma diferença significativa entre eles. Pelas respostas a esta pergunta , pensei ter chegado ao entendimento de que "distribuição" significava Ubuntu vs. Debian vs. Fedora, etc., então seu uso neste contexto (especificamente, o wiki do Debian) turvou o entendimento que pensei Eu tinha alcançado.

Gostaria de instalar o libuv em uma instância WSL do Ubuntu e preciso especificamente da versão 1.45.0 ou posterior.

Meu entendimento (a partir deste artigo tutorial ) é que o comando para descobrir quais versões de um pacote estão disponíveis para instalação é apt list | grep:

$ apt list | grep libuv

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

libuv1-dev/jammy,now 1.43.0-1 amd64 [installed]
libuv1/jammy,now 1.43.0-1 amd64 [installed,automatic]
libuvc-dev/jammy 0.0.6-1.1 amd64
libuvc-doc/jammy 0.0.6-1.1 all
libuvc0/jammy 0.0.6-1.1 amd64

... o que me leva a pensar que apenas 1.43.0-1 está disponível para instalação por apt-gete que já está instalado.

Mas o site GitHub da libuv indica que existem versões mais recentes.

Como posso obter o libuv v1.45.0 (ou posterior) na minha instância do Ubuntu com apt-get?

Embora minha necessidade imediata seja específica do libuv, na verdade quero aprender sobre este aspecto do ecossistema Unix/Linux em geral: qual é a relação entre drivers/pacotes/etc. que parecem ser "lançados" (por exemplo, de acordo com suas páginas do GitHub) versus o que está "disponível" para gerenciadores de pacotes, como apt-get? O que os usuários devem fazer se quiserem uma versão mais recente de um pacote que não está disponível no gerenciador de pacotes? Eles deveriam baixar o código-fonte e compilar localmente?

Atualização : Por que preciso do 1.45.0, ou seja, por que preciso de uma versão mais avançada do que a disponível no meu gerenciador de pacotes?

Minha máquina Linux é um ambiente de desenvolvimento, onde preciso compilar para hospedar (ou seja, podemos desconsiderar a compilação cruzada para o contexto desta questão). O aplicativo que preciso compilar (não escrito por mim) depende de uv_timespec64_t, que aparentemente foi introduzido na libuv v1.45.0 por este git merge/diff ).

Portanto, essa é a premissa desta questão: preciso compilar (para o host) um aplicativo que depende de um recurso de uma versão mais recente do libuv do que o gerenciador de pacotes da minha distribuição Linux oferece.

Atualização: Esta questão tem uma pergunta de acompanhamento relacionada aqui: Por que diferentes distros Linux têm diferentes formatos de pacotes (e gerenciadores de pacotes)?

Quero usar pkg-configmeu Makefile para encontrar o caminho do link para libspa-0.2 .

Observo que pkg-config --libs libspa-0.2não retorna nada.

Para simplificar, demonstrarei o problema executando pkg-configdiretamente do shell, ou seja, não de dentro do meu Makefile .

$ uname -a
Linux MY_LINUX_PC 5.15.133.1-microsoft-standard-WSL2 #1 SMP Thu Oct 5 21:02:42 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
$
$ sudo apt-get install -y libspa-0.2-dev
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following package was automatically installed and is no longer required:
  libwebrtc-audio-processing1
Use 'sudo apt autoremove' to remove it.
Suggested packages:
  pipewire-doc
The following NEW packages will be installed:
  libspa-0.2-dev
0 upgraded, 1 newly installed, 0 to remove and 3 not upgraded.
Need to get 0 B/81.7 kB of archives.
After this operation, 625 kB of additional disk space will be used.
Selecting previously unselected package libspa-0.2-dev:amd64.
(Reading database ... 34966 files and directories currently installed.)
Preparing to unpack .../libspa-0.2-dev_0.3.48-1ubuntu3_amd64.deb ...
Unpacking libspa-0.2-dev:amd64 (0.3.48-1ubuntu3) ...
Setting up libspa-0.2-dev:amd64 (0.3.48-1ubuntu3) ...
$
$ pkg-config --libs libspa-0.2

$

Estranhamente, pkg-configele se comporta conforme esperado quando solicitado a reportar os cflags de libspa-0.2 :

$ pkg-config --cflags libspa-0.2
-D_REENTRANT -I/usr/include/spa-0.2
$

Este é o conteúdo de libspa-0.2.pc :

$ cat /usr/lib/x86_64-linux-gnu/pkgconfig/libspa-0.2.pc
prefix=/usr
libdir=${prefix}/lib/x86_64-linux-gnu
includedir=${prefix}/include

plugindir=${libdir}/spa-0.2

Name: libspa
Description: Simple Plugin API
Version: 0.2
Cflags: -I${includedir}/spa-0.2 -D_REENTRANT
$

... então eu esperava pkg-config --libs libspa-0.2retornar algo parecido com /usr/lib/x86_64-linux-gnu.

Por que pkg-config --libs libspa-0.2retorna uma string vazia?

Ficaria grato se um respondente experiente pudesse descrever um pouco sobre a relação entre pkg-config, apt-gete o conteúdo dos respectivos .pcarquivos.

Eu gostaria de entender o problema/comportamento observado especificamente em relação a libspa-0.2-dev , mas se houver uma generalização, gostaria de aprender isso também.

Atualização : isso é estranho - parece que pkg-configestá fazendo alguma formatação/remoção (inteligente) de conteúdo para os caminhos de link da biblioteca. Este é o conteúdo do zlib.pc - algo pré-instalado (o que deve descartar minha bagunça):

$ cat /usr/lib/x86_64-linux-gnu/pkgconfig/zlib.pc
prefix=/usr
exec_prefix=${prefix}
libdir=${prefix}/lib/x86_64-linux-gnu
sharedlibdir=${libdir}
includedir=${prefix}/include

Name: zlib
Description: zlib compression library
Version: 1.2.11

Requires:
Libs: -L${libdir} -L${sharedlibdir} -lz
Cflags: -I${includedir}
$

... e isto é o que pkg-configinforma os caminhos de link da biblioteca:

$ pkg-config --libs zlib
-lz
$

...ou seja, parece estar retirando a -L${libdir} -L${sharedlibdir}peça.

Pelo menos o comportamento é consistente... o que talvez implique que este não é um "problema", mas um comportamento definido pkg-config. Mas não consigo entender a razão pela qual ele está se comportando dessa maneira: quando e por que ele elimina os caminhos dos links da biblioteca, ou seja, o -Lconteúdo?

Gostaria de saber como systemdinicia os serviços, especificamente com qual usuário o serviço é iniciado e gostaria de usar o Jenkins em execução no meu PC com Linux como exemplo.

Eu sei que inité pid 1, a mãe de todos os processos no Linux e, no meu caso, pid 1pertence a systemd, que posso ver executando top:

$ top
Tasks: 646 total,   1 running, 645 sleeping,   0 stopped,   0 zombie
%Cpu(s):  1.0 us,  0.6 sy,  0.0 ni, 97.0 id,  1.3 wa,  0.0 hi,  0.1 si,  0.0 st
MiB Mem : 257826.8 total, 198695.4 free,  28529.6 used,  30601.7 buff/cache
MiB Swap: 262012.0 total, 262012.0 free,      0.0 used. 227579.3 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
    1 root      20   0  171284  11196   7904 S   0.3   0.0  31:49.54 systemd

Eu presumi ingenuamente que, porque systemdé executado como root, todos os serviços executados por ele seriam executados como root.
Mas acho que Jenkins está rodando como adminno meu PC.
Tentei usar systemctlpara determinar qual usuário Jenkins estava executando, mas não vi nenhuma informação do usuário no stdout:

user@linux_box:~$ systemctl status jenkins
● jenkins.service - LSB: Start Jenkins at boot time
   Loaded: loaded (/etc/init.d/jenkins; generated)
   Active: active (exited) since Fri 2023-05-05 11:50:06 PDT; 3 days ago
     Docs: man:systemd-sysv-generator(8)
    Tasks: 0 (limit: 4915)
   Memory: 0B
   CGroup: /system.slice/jenkins.service

Warning: Journal has been rotated since unit was started. Log output is incomplete or unavailable.
user@linux_box:~$

... então eu tentei ps aux:

user@linux_box:~$ ps aux | grep jenkins
admin  2042  0.0  0.0  14164   196 ?        S    May05   0:00 /usr/bin/daemon --name=admin --inherit --env=JENKINS_HOME=/home/admin/jenkins --output=/var/log/jenkins/jenkins.log --pidfile=/var/run/admin/admin.pid -- /usr/bin/java -Djava.awt.headless=true -jar /home/admin/jenkins/jenkins.war --webroot=/var/cache/jenkins/war --httpPort=8080
admin  2043  1.7  5.3 48146100 14118144 ?   Sl   May05  83:41 /usr/bin/java -Djava.awt.headless=true -jar /home/admin/jenkins/jenkins.war --webroot=/var/cache/jenkins/war --httpPort=8080
admin 29932  0.0  0.0   6204   892 pts/1    S+   20:37   0:00 grep jenkins

...Acho que a coluna mais à esquerda está dizendo que Jenkins está sendo executado como admin, não?

Alguém pode explicar a relação entre systemd, o usuário que o executa e o usuário que executa os serviços? Seria ótimo se a resposta pudesse vincular isso ao que está acontecendo especificamente com o Jenkins neste PC com Linux.

Tentando aprender sobre UIDs e GIDs.
Várias leituras online me levaram a acreditar que meu UID está salvo em /etc/passwd, mas isso não parece ser o caso em um servidor em que trabalho:

$ whoami
user1
$ cat /etc/passwd | grep user1
$

Existe um (outro) arquivo além do /etc/passwdque poderia conter meu UID?

(Estou assumindo que o UID é semelhante ao GID, pois há um arquivo em algum lugar que o contém. Encontrei o GID no qual estou interessado no arquivo /etc/group)

Eu sei que posso obter meu UID com o comando id -u, mas para esta pergunta, estou especificamente interessado em saber se existe um arquivo que o contém.

Esta questão decorre desta recomendação e de uma de suas respostas para ler Linuxtopia - Capítulo 20. Subshells .

Estou um pouco confuso com esta declaração no site Linuxtopia:

subshells permitem que o script faça o processamento paralelo, executando várias subtarefas simultaneamente.
_{https://www.linuxtopia.org/online_books/advanced_bash_scripting_guide/subshells.html}

Isso significa que os subshells, executados a partir de um script, são sempre executados em paralelo ao script original? Experimentalmente, isso não parece ser o caso, mas ficaria grato pela confirmação de especialistas de uma forma ou de outra.

#! /usr/bin/bash

# This script reliably prints:
# hello
# world
# 0
# ...implying that the the subshell is not run in parallel with this script.

(echo hello;
echo world)

echo $?

.

#! /usr/bin/bash

# This script prints:
# 0
# hello
# world
# ...implying that the the subshell is run in parallel with this script.

(echo hello;
echo world) &

echo $?

É o uso do &que o site Linuxtopia pode ter significado por " [deixar] o script fazer processamento paralelo "?

Nota: Estou familiarizado com o conceito de comandos com sufixo &no bash... ele executa o referido comando como um processo em segundo plano. Portanto, minha pergunta é mais sobre se os comandos executados em um subshell são executados como processo em segundo plano/paralelo por padrão ou se a adição do &aqui também é o que causa a execução em segundo plano/paralelo. A redação do artigo Linuxtopia, para mim, implicava o primeiro, que não parece corresponder à observação.

Da minha caixa Windows, eu me conecto à minha caixa Linux usando VNCo visualizador/servidor.

Na caixa do Linux, quando minha sessão expira e depois que a tela de bloqueio é ativada, se eu tentar desbloquear usando o gui, pelo VNC, pareço estar permanentemente "bloqueado" sem a capacidade de inserir qualquer texto no solicitação de senha. Mais especificamente, parece que algum fluxo de Entercaracteres está sendo constantemente transmitido pelo VNC, acionando o prompt de login para pensar que o usuário está digitando constantemente uma senha de comprimento 0: observe a instrução "Erro de autenticação" na captura de tela anexa, revelando que o tela de login pensa que algo foi inserido. Além disso, se eu fizer um teste de estresse aqui, digitando rapidamente, um ou dois dos símbolos de "caractere oculto" aparecerão antes de desaparecer rapidamente novamente. O tempo todo, o "erro de autenticação"

A solução que encontrei para essa situação é fazer login diretamente na caixa do Linux e executar este script:

$ while true; do loginctl unlock-session 2 > /dev/null 2>&1; sleep 1; done

...onde esse número, 2, é meu "id de sessão". O script tem o efeito de descartar a tela de bloqueio (dentro de um segundo) sempre que ela aparecer - não exatamente a melhor solução, mas melhor do que um bloqueio perpétuo com a incapacidade de inserir uma senha.

Por que isso é necessário? Alguém pode explicar o que está acontecendo com o VNCvisualizador/servidor, ou a tela de bloqueio na caixa do Linux, ou qualquer outro software relacionado, e por que aparece um fluxo constante de Enterser enviado VNCespecificamente para a tela de login do Linux (ou qualquer outra coisa que esteja acontecendo fazer com que a tela de bloqueio relate continuamente "Erro de autenticação" como se uma senha incorreta fosse fornecida)?

Observe que quando estou passando a tela de bloqueio, em um bashshell, não parece haver nenhum pressionamento de tecla indesejado enviado - ou seja, posso digitar, executar comandos, etc. sem interferência de nenhum pressionamento de tecla não intencional.

Pergunta relacionada(?): Se isso não estiver atrapalhando o assunto: observe que o script que executo está em primeiro plano, ou seja:

$ while true; do loginctl unlock-session 2 > /dev/null 2>&1; sleep 1; done

...não...

$ while true; do loginctl unlock-session 2 > /dev/null 2>&1; sleep 1; done &

... se eu tentar a versão em segundo plano do script, ela tem um efeito único, ou seja, a tela de bloqueio é descartada apenas na primeira execução, mas nunca depois, versus a versão em primeiro plano do script, que parece manter a tela de bloqueio fora perpetuamente. Por que faz diferença, nesse contexto, se o script de solução alternativa está em segundo plano ou em primeiro plano?

Detalhes do ambiente:

$ uname -a
Linux linuxbox 5.3.11-100.fc29.x86_64 #1 SMP Tue Nov 12 20:41:25 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

.

$ vncserver -list

TigerVNC server sessions:

X DISPLAY # PROCESS ID
:1  2958

.

$ loginctl list-sessions
SESSION   UID USER    SEAT   TTY
      2  1000 user    seat0  tty2

1 sessions listed.

Eu quero escrever um script que ecoe na stdoutíntegra $@, incluindo quaisquer aspas duplas em potencial, sem uma nova linha.

O que eu tentei:

> cat ./script1    
#! /usr/bin/bash
printf "%s %s" $0 $@
echo -n $0 $@
echo -n "$0 $@"
> 
> ./script1 a "bc d"
./script1 abc d./script1 a bc d./script1 a bc d>

Eu gostaria que meu script fosse executado da seguinte forma:

> ./script1 a "bc d"
./script1 a "bc d">

Existe uma maneira de fazer isso?

O comando openssl passwd calcula o hash de uma senha digitada em tempo de execução ou o hash de cada senha em uma lista. A lista de senhas é obtida do arquivo nomeado para a opção -in file, de stdin para a opção -stdin e, caso contrário, da linha de comando. O algoritmo padrão do UNIX crypt e o algoritmo 1 de senha BSD baseado em MD5 e sua variante Apache apr1 estão disponíveis.

Entendo que o termo "hash" significa " transformar uma entrada em uma saída da qual é difícil/impossível derivar a entrada original ". Mais especificamente, a relação entrada:saída após o hash é N:M, onde M<=N (ou seja, a colisão de hash é possível).

Por que a saída de " openssl passwd" é diferente executada sucessivamente com a mesma entrada?

> openssl passwd
Password:
Verifying - Password:
ZTGgaZkFnC6Pg
> openssl passwd
Password:
Verifying - Password:
wCfi4i2Bnj3FU
> openssl passwd -1 "a"
$1$OKgLCmVl$d02jECa4DXn/oXX0R.MoQ/
> openssl passwd -1 "a"
$1$JhSBpnWc$oiu2qHyr5p.ir0NrseQes1

Não devo entender o objetivo dessa função, porque parece que executar o mesmo algoritmo de hash na mesma entrada produz várias saídas exclusivas . Acho que estou confuso com essa aparente relação de entrada:saída N:M, em que M>N.

Eu quero criar um .tgz a partir do conteúdo de um diretório. Eu também quero remover o " ./" inicial do conteúdo com tar.
Eu tinha feito isso da seguinte forma:

cd /path/to/files/ && find . -type f | cut -c 3- | xargs czf /path/to/tgz/myTgz.tgz

Aprendi recentemente que usar xargspode não ser a melhor maneira de fazer isso porque xargspode invocar tarvárias vezes se a lista cmdline arg ficar muito longa, e fui aconselhado a usar tara capacidade de ler uma lista de arquivos de entrada de stdin. Acabei encontrando este artigo sobre como fazer isso. No entanto, acho que a recomendação ...

cd /path/to/files/ && find . -type f | cut -c 3- | tar czf foo.tgz -T -

... parece não ser portátil. Ele funciona bem no meu dev PC, mas em um destino do busybox, recebo o seguinte erro ao executar o mesmo comando:

tar: can't open '-': No such file or directory

Então, minha pergunta : existe uma maneira verdadeiramente portátil / global de invocar tarpara criar um .tgzalimentando arquivos de entrada de stdin (em oposição aos argumentos cmdline)?

(Não é uma opção disponível para mim instalar alternativas tarcomo gnutar/ bsdtar/etc.)

(Pergunta secundária: Por que o -T -argumento " " para tardenotar " lê arquivos destdin "? Na tarpágina man, tudo o que pude encontrar foi que " -T" significa:

obter nomes para extrair ou criar de FILE

... mas não consegui ver nenhuma referência a um simples " -")

O sistema de arquivos Linux parece ter camadas e camadas de sutileza que eu tropeço caso a caso:

Estou interessado em editar este arquivo:

[user@box ~]$ ls -l /a/b/c/foo.bar
-rw-rwxr-x    1 user   user      144529 Jan 26  2018 /a/b/c/foo.bar

Parece que deve ser gravável pelo usuário user- verdade? Mas quando tento editar o arquivo no vim, recebo um W10: Warning: Changing a readonly fileaviso " ".

Eu sei que a capacidade de gravação do arquivo depende das permissões da pasta que o contém. Eu acho que a pasta que contém precisa ter permissão de execução - verdade? Presumo que a permissão de diretório necessária também se estenda até /- true?

Parece-me que a árvore de pastas que contém o arquivo observado tem permissões de execução:

[user@box ~]$ ls -ld /a/b/c/                                                                                    
drwxrwxrwx    2 user   user       36864 Mar  5 17:50 /a/b/c/
[user@box ~]$ ls -ld /a/b/           
drwxrwxr-x    4 user   user        4096 Sep 22  2017 /a/b/
[user@box ~]$ ls -ld /a/                
drwxrwxr-x    9 user   user        4096 Sep 15  2017 /a/
[user@box ~]$ ls -ld /     
drwxr-xr-x   24 root   root           0 Aug 24 10:48 /
[user@box ~]$ whoami
user

Tanto quanto eu posso dizer acima, cada diretório na árvore relevante tem permissões de execução. No começo, desconfiei se tinha a ver com /ser de propriedade de root, mas tem permissão de execução para "outros". Além disso, se houvesse problemas relacionados à /propriedade de root, imagino que teria problemas para gravar arquivos em qualquer lugar do sistema de arquivos como um usuário diferente de root, mas esse não é o caso.

Alguém pode pensar/identificar outras razões pelas quais o arquivo observado é considerado somente leitura?

Quando eu executo este script, destinado a ser executado até ser morto ...

# foo.sh

while true; do sleep 1; done

...Não consigo encontrá-lo usando ps ax:

>./foo.sh

// In a separate shell:
>ps ax | grep foo.sh
21110 pts/3    S+     0:00 grep --color=auto foo.sh

...mas se eu apenas adicionar o #!cabeçalho " " comum ao script...

#! /usr/bin/bash
# foo.sh

while true; do sleep 1; done

...então o script se torna localizável pelo mesmo pscomando...

>./foo.sh

// In a separate shell:
>ps ax | grep foo.sh
21319 pts/43   S+     0:00 /usr/bin/bash ./foo.sh
21324 pts/3    S+     0:00 grep --color=auto foo.sh

Porque isto é assim?
Esta pode ser uma pergunta relacionada: eu pensei que " #" era apenas um prefixo de comentário e, nesse caso, " #! /usr/bin/bash" não é nada mais do que um comentário. Mas " #!" carrega algum significado maior do que apenas um comentário?

Um cpparquivo com o qual estou trabalhando cria um diretório, ou seja mkdir( path, ... ), onde path vem de uma variável de ambiente (por exemplo, getenv( "FOO" );).

Por exemplo, digamos que $FOOseja /foo, e path, criado acima, seja `/foo/newPath/'.

Para o meu cenário de pergunta, é possível que /foo/oldPath/exista e tenha conteúdo (suponha que não haja mais subdiretórios), caso em que desejo mover arquivos de /foo/oldPath/para /foo/newPath.

Minha pergunta é: porque /foo/newPath/é criado como um subdiretório de $FOO, ou seja, /foo/newPath/e /foo/oldPath/tem o mesmo diretório pai, é garantido que ambos os diretórios estejam no mesmo "sistema de arquivos montado"? Meu entendimento de pontos de montagem e sistemas de arquivos no Linux é, na melhor das hipóteses, tênue.

O contexto por trás dessa pergunta é: se /foo/newPath/e tiver /foo/oldPath/a garantia de estar no mesmo sistema de arquivos montado, posso usar rename()para executar a movimentação de arquivos com mais facilidade do que outras alternativas. A página de manual da função diz que ela falhará se oldPathe newPathnão estiver no mesmo "sistema de arquivos montado".

Quando executo um executável (como a.out) de um shell Bash, esse executável é executado em algum tipo de "sub" shell, ou seja, diferente do shell no qual estou digitando?

Vou tentar ilustrar minha pergunta com um exemplo. O programa a seguir obtém e imprime o valor de uma variável de ambiente, altera-o e, em seguida, obtém e imprime novamente:

#include <iostream>
#include <string>
#include <cstdlib>
int main( int argc, char* argv[] )
{
  std::string str( getenv( "FOO" ) );
  std::cout << str << std::endl;
  setenv( "FOO", "bar", 1 );
  str = getenv( "FOO" );
  std::cout << str << std::endl;
  return 0;
}

Agora, observe a saída quando executo o seguinte no meu prompt do Bash:

>unset FOO && export FOO=foo && printf "$FOO\n" && ./a.out && printf "$FOO\n"
foo
foo
bar
foo
>
>unset FOO && export FOO=baz && printf "$FOO\n" && ./a.out && printf "$FOO\n"
baz
baz
bar
baz

Portanto, estou exportando FOOpara que seja obtido a partir do executável - entendo isso. E a saída do executável mostra o envvar sendo alterado.

Mas o final printf "$FOO\n"imprime o valor pré-executável. Isso ocorre porque o executável é executado em um "ambiente diferente" daquele em que digito comandos?

O que é isto???

/\[*\]/ {
      inFoo = ($1 == "["foo"]")
      next
    }

Parece uma função por causa dos colchetes, mas o que diabos é isso antes do colchete de abertura??? Algum tipo de nome de função regex'ed? Nunca fui bom em scripts Bash, mas isso é totalmente indecifrável.

Existe um semelhante, mas seu corpo é muito grande (e potencialmente sensível) para eu postar:

/.*/ {
    ...
    }