Linux – Página 4

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.

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. 🙂

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). 🙂

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:

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.

Comecei 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):

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:

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:

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

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):

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.