O que acontece se o limite de 4 bilhões de arquivos for excedido em uma partição ext4, com uma transferência de 5 bilhões de arquivos por exemplo?
meu raspberry pi 3 modelo B, executando o Arch, tem um problema com o bluetooth. Em primeiro lugar:
- O Bluetooth funcionou perfeitamente anteriormente
- pi-bluetooth do AUR está atualizado
- bluez e bluez-utils estão atualizados
- O sistema também está atualizado (apenas executei pacman -Syu)
Ainda assim, quando tento usar a interface bluetooth, não funciona.
bluetoothctl (como root), quando eu executo "scan on", me diz
Failed to start discovery: org.bluez.Error.NotReady
wminput não consegue encontrar a interface bluetooth:
No Bluetooth interface found
unable to connect
"systemctl status bluetooth" tem a seguinte saída:
● bluetooth.service - Bluetooth service
Loaded: loaded (/usr/lib/systemd/system/bluetooth.service; enabled; vendor preset: disabled)
Active: active (running) since Sat 2019-03-23 21:32:47 CET; 9min ago
Docs: man:bluetoothd(8)
Main PID: 2005 (bluetoothd)
Status: "Running"
Tasks: 1 (limit: 1404)
CGroup: /system.slice/bluetooth.service
└─2005 /usr/lib/bluetooth/bluetoothd
Mar 23 21:32:47 media.lan systemd[1]: Starting Bluetooth service...
Mar 23 21:32:47 media.lan bluetoothd[2005]: Bluetooth daemon 5.50
Mar 23 21:32:47 media.lan systemd[1]: Started Bluetooth service.
Mar 23 21:32:47 media.lan bluetoothd[2005]: Starting SDP server
Mar 23 21:32:47 media.lan bluetoothd[2005]: Bluetooth management interface 1.14 initialized
Estou no meu juízo final aqui, tudo parece estar bem, mas nada funciona. O que está acontecendo aqui?
Eu tenho duas máquinas diferentes (casa e trabalho) executando o Ubuntu 18.04. Ontem à noite vimcongelou em casa. Eu estava no modo insert e digitando e fui salvar ( esc :w) e nada aconteceu. A barra de status ainda lê -- INSERT --, o cursor ainda está piscando onde estava. Eu estava travado. Não consegui encontrar uma saída. Eu não conseguia digitar (nada acontecia quando eu digitava), não conseguia me mover (as setas para cima e para baixo não faziam nada). Ele estava preso no modo de inserção com o cursor piscando onde estava.
Eu estava definitivamente multitarefa e provavelmente apertei algumas outras teclas lá, mas não sei quais teclas. No entanto, já era tarde, então fechei a janela do terminal e tentei novamente (estava digitando uma mensagem de confirmação do git). Aconteceu novamente no meio da minha digitação, então mudei para git commit -m "don't need an editor for this". E então eu desliguei meu computador e parei de funcionar.
Achei que estava apenas cansado, mas aconteceu comigo hoje no trabalho em um laptop completamente diferente. Mais uma vez eu estava multitarefa e não posso jurar que não digitei nenhuma sequência de teclas bizarra, mas se o fiz foi acidental. E outras guias no mesmo terminal não estão congeladas.
Estou acostumado a ficar preso no visualmodo vim. Isso é um truque que aprendi. Mas preso no modo de inserção? Alguma idéia sobre o que eu poderia ter feito e como sair disso?
Por uma sugestão de comentário, tentei olhar, .viminfomas o único .viminfoque vejo é de propriedade exclusiva roote só parece mostrar coisas com as quais eu teria editado sudo:
# Input Line History (newest to oldest):
# Debug Line History (newest to oldest):
# Registers:
# File marks:
'0 1 0 /etc/neomuttrc
|4,48,1,0,1531789956,"/etc/neomuttrc"
'1 1 66 /etc/apt/sources.list.d/signal-bionic.list
|4,49,1,66,1530816565,"/etc/apt/sources.list.d/signal-bionic.list"
'2 51 0 /etc/apt/sources.list
|4,50,51,0,1530816531,"/etc/apt/sources.list"
# Jumplist (newest first):
-' 1 0 /etc/neomuttrc
|4,39,1,0,1531789956,"/etc/neomuttrc"
-' 1 66 /etc/apt/sources.list.d/signal-bionic.list
|4,39,1,66,1530816565,"/etc/apt/sources.list.d/signal-bionic.list"
-' 1 66 /etc/apt/sources.list.d/signal-bionic.list
|4,39,1,66,1530816565,"/etc/apt/sources.list.d/signal-bionic.list"
-' 51 0 /etc/apt/sources.list
|4,39,51,0,1530816531,"/etc/apt/sources.list"
-' 51 0 /etc/apt/sources.list
|4,39,51,0,1530816531,"/etc/apt/sources.list"
-' 51 0 /etc/apt/sources.list
|4,39,51,0,1530816531,"/etc/apt/sources.list"
-' 51 0 /etc/apt/sources.list
|4,39,51,0,1530816531,"/etc/apt/sources.list"
-' 1 0 /etc/apt/sources.list
|4,39,1,0,1530816447,"/etc/apt/sources.list"
-' 1 0 /etc/apt/sources.list
|4,39,1,0,1530816447,"/etc/apt/sources.list"
-' 1 0 /etc/apt/sources.list
|4,39,1,0,1530816447,"/etc/apt/sources.list"
-' 1 0 /etc/apt/sources.list
|4,39,1,0,1530816447,"/etc/apt/sources.list"
# History of marks within files (newest to oldest):
> /etc/neomuttrc
* 1531789952 0
" 1 0
> /etc/apt/sources.list.d/signal-bionic.list
* 1530816564 0
" 1 66
^ 1 67
. 1 66
+ 1 66
> /etc/apt/sources.list
* 1530816454 0
" 51 0
Parece estranho que eu não tivesse um sem privilégios .viminfo, mas eu tive sudo udpatedbe locate .viminfoainda não apareceu mais do que um arquivo de propriedade do root.
Não consigo encontrar a maneira correta de executar alguns scripts locais (ou comandos muito locais) no systemd, já sei que não devo criar um serviço (no systemd uma unidade) para esse tipo de script (ou devo?)....
A solução que encontrei é criar rc.local e dar a ele permissões de execução.
printf '#!/bin/bash \n\nexit 0' >/etc/rc.local
chmod +x /etc/rc.local
Por exemplo, se eu pegar um servidor legado com um rc.local simples configurado por você, saberei o que você fez e o quanto vai doer atualizar ou instalar algo novo na distro, já que o rc.local era respeitado por externos pacotes, mas por outro lado se eu instalar um servidor e criar uma unidade systemd ou duas ou três (ou até serviços sysvinit), apenas por fazer uma tarefa simples, isso às vezes pode dificultar sua vida, e muito mais do que isso minhas unidades nomes podem algum dia entrar em conflito com os nomes dos novos serviços criados pelo desenvolvimento da distribuição, e talvez instalados em uma atualização, causando problemas para meus scripts!
Eu vejo outra pergunta perguntando sobre onde está o rc.local e a resposta foi criá-lo e dar permissões de execução, acho que minha pergunta não é realmente uma duplicata , pois não quero saber onde está - acredite, só quero aceitar que está obsoleto , mas não consigo encontrar a maneira correta de fazer esse tipo de coisa, devo realmente criar uma unidade apenas para algo simples assim?
Então, apaguei minha pasta pessoal (ou, mais precisamente, todos os arquivos aos quais eu tinha acesso de gravação). O que aconteceu é que eu tinha
build="build"
...
rm -rf "${build}/"*
...
<do other things with $build>
em um script bash e, depois de não precisar mais $build, removendo a declaração e todos os seus usos - mas o rm. Bash felizmente se expande para rm -rf /*. Sim.
Eu me senti estúpido, instalei o backup, refiz o trabalho que perdi. Tentando superar a vergonha.
Agora, eu me pergunto: quais são as técnicas para escrever scripts bash para que tais erros não aconteçam, ou pelo menos sejam menos prováveis? Por exemplo, se eu tivesse escrito
FileUtils.rm_rf("#{build}/*")
em um script Ruby, o intérprete teria reclamado por buildnão ter sido declarado, então aí a linguagem me protege.
O que considerei no bash, além de encurralar rm(o que, como muitas respostas em perguntas relacionadas mencionam, não é isento de problemas):
rm -rf "./${build}/"*
Isso teria matado meu trabalho atual (um repositório Git), mas nada mais.- Uma variante/parametrização
rmdisso requer interação ao atuar fora do diretório atual. (Não foi possível encontrar nenhum.) Efeito semelhante.
É isso ou existem outras maneiras de escrever scripts bash que são "robustos" nesse sentido?
Como a maioria de vocês já fez muitas vezes, é conveniente visualizar o texto longo usando less:
some_command | less
Agora seu stdin está conectado a um pipe (FIFO). Como ele ainda pode ler comandos como up/down/quit?
Em include/x86_64-linux-gnu/asm/unistd_64.h, vejo uma chamada de sistema chamada tuxcall,
#define __NR_tuxcall 184
Não há nada sobre isso, man tuxcallexceto para dizer que é uma chamada de sistema não implementada . O que isso fez? Nunca foi implementado ou fez algo na antiguidade?
Estou tentando encontrar um arquivo que não existe no meu diretório inicial e em todos os subdiretórios.
find ~/ -name "bogus"me dá essa informação depois de alguns segundos, mas o gerenciador de arquivos do KDEdolphin precisou de quase 3 minutos para fazer o mesmo. Isso corresponde à minha experiência anterior com o GNOMEbeagle .
Como findconsegue fazer o mesmo muito rápido enquanto a pesquisa gráfica (que é mais intuitiva de usar do que os parâmetros da linha de comando) fica para trás?
Suponha que eu estivesse usando sha1passpara gerar um hash de alguma senha confidencial na linha de comando. Posso usar sha1pass mysecretpara gerar um hash de mysecretmas isso tem a desvantagem que mysecretagora está no histórico do bash. Existe uma maneira de atingir o objetivo final deste comando, evitando a revelação mysecretem texto simples, talvez usando um passwdprompt -style?
Também estou interessado em uma maneira generalizada de fazer isso para passar dados confidenciais para qualquer comando. O método mudaria quando os dados confidenciais fossem passados como um argumento (como em sha1pass) ou em STDIN para algum comando.
Existe uma maneira de conseguir isso?
Edit : Esta questão atraiu muita atenção e várias boas respostas foram oferecidas abaixo. Um resumo é:
- De acordo com a resposta de @Kusalananda , idealmente, nunca seria necessário fornecer uma senha ou segredo como argumento de linha de comando para um utilitário. Isso é vulnerável de várias maneiras, conforme descrito por ele, e deve-se usar um utilitário melhor projetado que seja capaz de receber a entrada secreta no STDIN
- A resposta de @vfbsilva descreve como impedir que as coisas sejam armazenadas no histórico do bash
- A resposta de @Jonathan descreve um método perfeitamente bom para fazer isso, desde que o programa possa obter seus dados secretos no STDIN. Como tal, decidi aceitar esta resposta.
sha1passno meu OP foi apenas um exemplo, mas a discussão estabeleceu que existem ferramentas melhores que coletam dados no STDIN. - como @R.. observa em sua resposta , o uso de expansão de comando em uma variável não é seguro.
Portanto, em resumo, aceitei a resposta de @Jonathan, pois é a melhor solução, pois você tem um programa bem projetado e bem-comportado para trabalhar. Embora passar uma senha ou segredo como um argumento de linha de comando seja fundamentalmente inseguro, as outras respostas fornecem maneiras de mitigar as preocupações simples de segurança.
Estou familiarizado com "jq" para analisar json.
Eu trabalho com um serviço que produz uma resposta json onde uma das propriedades é uma string json. Como converto esse valor citado em uma string json válida para que eu possa processá-la com jq?
Por exemplo, se eu apenas visualizar o json simples e bem impresso de "jq .", aqui está um pequeno trecho da saída:
"someJsonString": "{\"date\":\"2018-01-08\", ...
Posso usar jq para obter o valor dessa propriedade, mas preciso converter a string entre aspas em json válido, "removendo-a".
Suponho que poderia canalizá-lo para sed, removendo as aspas duplas de abertura e finalização e removendo todas as barras invertidas (" sed -e 's/^"//' -e 's/"$//' -e 's/\\//g'"). Isso parece funcionar, mas não parece ser a solução mais robusta.
Atualização :
Apenas para ser um pouco mais claro sobre o que estou fazendo, aqui estão algumas amostras omitidas que mostram o que tentei:
% curl -s -q -L 'http://.../1524.json' | jq '.results[0].someJsonString' | jq .
"{\"date\":\"2018-01-08\",...
% echo $(curl -s -q -L 'http:/.../1524.json' | jq '.results[0].someJsonString') | jq .
"{\"date\":\"2018-01-08\",...
Atualização :
Aqui está um exemplo completamente autônomo:
% cat stuff.json | jq .
{
"stuff": "{\"date\":\"2018-01-08\"}"
}
% cat stuff.json | jq '.stuff'
"{\"date\":\"2018-01-08\"}"
% cat stuff.json | jq '.stuff' | jq .
"{\"date\":\"2018-01-08\"}"
Atualização :
Se eu tentar processar a última saída com uma expressão jq real, ele fará algo assim:
% cat stuff.json | jq '.stuff' | jq '.date'
assertion "cb == jq_util_input_next_input_cb" failed: file "/usr/src/ports/jq/jq-1.5-3.x86_64/src/jq-1.5/util.c", line 371, function: jq_util_input_get_position
Aborted (core dumped)