Obter listagem de todos os comandos em Linux

Será algo com pouco interesse para os utilizadores habituais e mais experientes, mas é uma dúvida de poderá surgir a novos utilizadores: como poderei saber todos os comandos disponíveis na linha de comandos do Linux (ou GNU/Linux)?

Num sistema Linux, todos os comandos disponíveis acabam por ser as aplicações instaladas e os comandos internos do interpretador de comandos usado, que comummente será a bash.

Uma forma simples de obter está listagem será no terminal carregar na tecla TAB duas vezes e responder ‘(s)im/(y)es’ quando for pedido se pretendemos que sejam listados os comandos.

tab-tab.png

Não é algo que se descubra à partida, mas a tecla TAB é usada para completar elementos introduzidos na linha de comando (comandos, nomes dos ficheiros, opções dos comandos, etc), ou mostrar sugestões para essa completação.

Para se saber mais sobre um comando (para comandos que tenham página de manual) pode-se sempre aceder ao manual do comando com o comando ‘man’. Basta executar ‘man nome_do_comando’. Se existir uma página de manual para esse comando ela será exibida. Para sair dessa visualização basta carregar na tecla ‘q’.

Para comandos internos da bash pode-se sempre fazer man bash e procurar por eles para saber o que fazem.

Os comandos a que se tem acesso e que não sejam comandos internos da bash, estão nos directórios indicados numa variável de sistema: $PATH.

Uma forma de listar os ficheiros que estão nesses directórios poderá ser a seguinte:

$ ls `echo $PATH|sed -e s/:/\ /g` | less

E como a listagem é passada para o paginador less, podemos navegar na lista à vontade e sair com a tecla ‘q’ como no comando man.

Muitas vezes não é possível saber à partida o que faz cada comando só pelo nome, e se o comando não tiver uma página de manual, numa distribuição baseada em Debian podemos sempre saber a que pacote pertence e que funcionalidade esse pacote pretende fornecer com:

$ dpkg -S `which comando`

E depois saber mais informação com:

$ apt-cache show pacote

Por exemplo (parte menos relevante cortada):

$ dpkg -S `which gimp`
gimp: /usr/bin/gimp

$ apt-cache show gimp
Package: gimp
Section: graphics
Description: The GNU Image Manipulation Program
The GIMP lets you draw, paint, edit images, and much more! GIMP includes the functionality and plug-ins of other famous image
editing and processing programs.

Mixing barato em Linux – 3

Claro que uma solução ainda melhor, e explicada de forma satisfatória neste artigo no Viva Linux, é conjugar o XMMS com o dbmix.

Ganha-se um interface simples e eficaz com controlo de volume, pitch, suporte de sampling e N canais distintos e também controlo de playlists unificado. Está em banho maria desde 2002, mas funciona. Portar isto para gtk2 e rejuvenescer o interface não era mal pensado… 🙂

Também tem suporte para cueing numa placa de som independente.

No meu setup não funciona bem ao nível do hardware. Mas calculo que seja uma conjugação de factores, ter uma placa no bus USB, mau suporte da placa onboard e da USB, problemas de latência, etc.

Será que a libertação da versão em condições do OSS vai mudar o panorama actual?

Mixing barato em Linux – 2

Melhor que usar o XMMS para este fim, talvez seja usar o Audacious. Baseado no XMMS tem um feeling mais actualizado e parece-me que o desenvolvimento continua. As notícias no site do XMMS parecem ser actualmente anúncios cheios de sarcasmo quando uma distribuição qualquer deixa de ter o XMMS nos repositórios… 😛

Podemos usar o truque que usei para o XMMS de redefinir a variável de ambiente $HOME para ter configurações independentes para cada player, mas no Audacious não é assim tão simples, porque algumas coisas ficam na directoria principal de configuração, como as presets de equalização, mas isso não é algo negativo, já que basta definirmos as que pretendemos usar e ficam disponíveis nos dois players e no player principal.

Além disso não existe opção de várias instâncias nas configurações do Audacious, mas podemos editar o ficheiro de configuração para obter essa funcionalidade.

As minhas configurações estão disponíveis aqui.

O mais certo é ser necessário reconfigurar a posição de cada janela, etc, depois de correr o script de arranque das duas instâncias.
Da próxima vez que o script for lançado estará tudo como ficou, inclusive as posições das janelas.

Quanto a equalização as principais presets serão o corte das frequências agudas, graves e médias (vozes e idênticos). Eu estou a usar este ficheiro que pode ser copiado para $HOME/.audacious/eq.preset.

Mixing no Linux com Python, GTK2 e GStreamer

Graças ao esforço do Jono em incentivar quem pegue nesta matéria, estive a brincar com os exemplos dele, no Eclipse+PyDev (entretanto fartei-me das manias do Eclipse e passei a usar o PyPe) e no Glade.

Fiz um simples player com controlo de pitch, ganho de volume e bending. 🙂

screenshot-pydj.png

O código foleiro em Python está aqui, e o interface glade, aqui.

Entretanto refiz o GUI e estou a tentar fazer alguma coisa de jeito e usável (o código actual está aqui). 🙂

screenshot-pydjpy.png

Com o poder que os pipelines do GStreamer permitem, talvez consiga aquilo que pretendo, um player simples com controlo de pitch e possibilidade de definir as opções do sink para poder usar duas placas de som independentes. Até os kill switches devem ser simples de implementar (adicionando um bpwsinc ao pipeline ou algo do género), só não sei como será a latência… 😛

Alteração ao GUI para os kill switches:

screenshot-pydjpy-1.png

Muito obrigado Jono!

Mixing barato em Linux – 1

Este será o primeiro do acompanhar de uma ideia que andava há vários meses para experimentar, usar placas de som baratas USB para misturar música.

usb_audio.pngComecei por adquirir um par de placas USB baratas. Em Linux funcionam na perfeição, são do mais simples possível, uma saída e uma entrada. Tive alguns problemas de latência se usar ambas num hub USB, mas este hub não tem alimentação, nem tenho a certeza que suporte a versão 2.0 do protocolo USB, mas poderá ser que o tráfego no barramento USB seja demasiado para duas placas em simultâneo. 🙂

Tenho para aqui uma mesa de mistura com a minha idade, mas que já tem crossfader, dado que a equalização será feita por software também é desprezável o facto de não haver equalização por canal na mesa.

Para já testei ambas as placas a funcionar com o xmms e corre tudo sem problemas, dado que as ligue a portas USB independentes sem passar pelo hub. A minha ideia era usar o mixxx, mas ainda não suporta várias placas de som… por isso vou para já fazer uns testes com o mais que testado xmms.:)

Para poder ter duas instâncias de xmms sem partilha de definições, configurei o xmms como queria (activei o suporte para múltiplas instâncias):

screenshot-preferences.png

Depois criei uma pasta onde vou guardar as definições de cada instância, chamei-lhe xmms. O xmms recorre apenas à variável $HOME para saber onde está o directório onde guardará as suas definições, daí podermos mudá-lo a nosso favor.

Criei o seguinte script bastante simples para gerir o arranque das duas instâncias e no meu caso chamei-lhe launch_xmms:

#! /bin/bash
# Player 1
export HOME=$PWD/player1
xmms&

# Player 2
export HOME=$PWD/player2
xmms&

Dei-lhe permissões de execução com

chmod +x launch_xmms

Depois criei dois directórios, player1 e player2, para onde copiei a configuração original do xmms:

cp -r $HOME/.xmms player1 && cp -r $HOME/.xmms player2

Agora posso correr o script de arranque e tenho duas instâncias do xmms com definições independentes entre si e do xmms normal:

./launch_xmms

Agora em cada instância defino a placa de saída, hw:1,0 e hw:2,0:

screenshot-alsa-driver-configuration.png

Agora falta apenas ligar as placas à mesa e testar. Com o suporte de filtros LADSPA do xmms posso usar os filtros disponíveis para esta framework no xmms, inclusive controlo de pitch, além de haver um plugin também para esse fim.

Nos próximos posts pretendo documentar melhor todo o processo com mais imagens e fotografias e talvez alguns samples do resultado.

Aspecto exemplificativo:

screenshot.png

Correr initscripts em distribuições de Linux baseadas em Debian

Para quem já usa as facilidades do bash_completion, eis mais uma.

Quando é necessário parar, iniciar ou reiniciar serviços, o usual é correr directamente o script:

$ sudo /etc/init.d/script [stop|start|restart|…]

Para facilitar este processo, existe um script em /usr/sbin/invoke-rc.d para correr os initscripts pelo nome, tornando o anterior em:

$ sudo invoke-rc.d script [stop|start|restart|…]

Ora isto é praticamente a mesma coisa, mas tem a vantagem de com o sistema de sugestão podermos completar/listar os scripts disponíveis usando a amiga TAB, bem como completar/listar todas as acções que esse script disponibiliza, seja start, stop, restart, etc.

$ sudo invoke-rc.d [TAB TAB]
acpid etc-setserial openvpn skeleton
acpi-support festival pcmciautils spamassassin
alsa-utils fetchmail postfix ssh
anacron –force postgresql-8.1 stop-bootlogd
apmd gdm powernowd stop-bootlogd-single
apport halt powernowd.early stop-readahead
atd hddtemp pppd-dns stunnel4
avahi-daemon hdparm –query sysklogd
binfmt-support –help –quiet –try-anyway
bluetooth hotkey-setup rc udev
bootclean hplip rc.local umountfs
bootlogd keyboard-setup rcS umountroot
brltty killprocs readahead urandom
console-setup klogd readahead-desktop usplash
courier-authdaemon laptop-mode reboot vbesave
courier-imap linux-restricted-modules-common rmnologin wacom-tools
courier-imap-ssl loopback rsync webfs
cron makedev samba wpa-ifupdown
cupsys module-init-tools screen x11-common
dbus networking sendsigs xserver-xorg-input-wacom
–disclose-deny –no-fallback setserial
dns-clean nvidia-kernel single

$ sudo invoke-rc.d fetchmail [TAB TAB]
awaken debug-run force-reload restart start stop

🙂

ssh + bash + bash_completion

O Ubuntu traz por omissão o cliente de ssh configurado para guardar uma hash da informação de ligação, em vez de guardar o endereço IP e o host.
Isto deve-se a questões de segurança e privacidade. Se por algum motivo a máquina for comprometida, é difícil saber a que outras máquinas o utilizador estabelecia ligações e onde quiçá tinha acesso por chave sem password.
Isto é importante, porém infelizmente retira uma funcionalidade interessante para quem precisa de estabelecer certas ligações com alguma frequência e para quem o TAB é tal vício que já se usa em todo o lado. 🙂
Para quem estiver seguro que esta informação é irrelevante, quer pela facilidade de ser descoberta por outros meios, quer pela segurança da rede em que está inserido e pretenda facilitar o dia a dia, poderá adicionar ao ficheiro de configuração $HOME/.ssh/config a linha:

HashKnownHosts no

Desta forma no ficheiro $HOME/.ssh/known_hosts passará a constar o IP e o hostname das máquinas para onde são feitas ligações, permitindo à funcionalidade acrescida do bash_completion completar os nomes dos hosts como é comum com outros comandos na bash.

As funcionalidade dos scripts de sugestão avançada também não estão activos de raiz, sendo necessário tirar o # das linhas finais do ficheiro $HOME/.bashrc para que se leia:

if [ -f /etc/bash_completion ]; then
. /etc/bash_completion
fi

GIMP – Sugestão de arrumação do interface

Acho que é do senso comum que o GIMP precisa de uma volta no interface inicial, na arrumação das ferramentas, sei lá. Não é apelativo à partida. Eu uso-o com frequência e há tantos anos que me é indiferente (não sou um utilizador avançado, mas nem era necessário referir isso ehehe 😛 ), mas verifico que há todo um potencial não reconhecido dado o modo menos… arrumado do interface.

Ao acompanhar o video blog de Bert Monroy sobre técnicas de desenho onde usa o Photoshop (ou o Ilustrator), para ver se aprendo alguma coisa (a ferramenta é irrelevante, interessam-me as técnicas e teoria, gostava de encontrar mais oferta deste género, “straight to the point” e clara), verifico que o GIMP tem muitas ferramentas análogas às mostradas no Photoshop. As que possam faltar talvez se possam atingir com conjugações das disponíveis. Não quero de forma alguma comparar directamente as duas aplicações, até porque nem é essa a ideia deste post. 🙂

O que pretendo expor é um ensaio no arranjo do interface do GIMP para optimizar o espaço e disponibilizar o máximo das funcionalidades do GIMP, por vezes escondidas em diálogos não activos na configuração inicial.

Ferramentas na janela principal (todas as disponíveis activas):
gimp-janela-princial.png

Janelas extra, com todos os diálogos disponíveis activos (parte clara da imagem) e facilmente acessíveis, como o motor dos pincéis por exemplo (importante e escondido na configuração inicial):
gimp-janelas-extra.png

Assim tendo ambas as janelas a um canto, fica mais espaço disponível para a imagem do que usando as duas janelas verticais do início e ficam mais funcionalidades expostas.