Oi Luciano,
Em 14 de novembro de 2011 11:38, Luciano de Souza<[email protected]>escreveu:
lua lacuna.lua
env lua lacuna.lua
Sim, ambos os comandos funcionavam. NO entanto, não podia chamar
./lacuna.lua.
#!/usr/bin/lua - interpretador inválido.
#!/usr/bin/env lua - interpretador inválido.
O que poderia ser? O mistério se desfez quando, ao invés de reutilizar o
mesmo arquivo, criei um completamente novo.
Por que havia falha? Porque o último caracter era uma quebra linha
Windows. Aquele script foi criado durante as férias, na casa de minha mãe.
E por lá, a máquina é Windows.
Para estar certo de que o problema era mesmo esse, voltei ao lacuna.lua e
o salvei, mudando a quebra de linha de Windows para Unix. Pronto, tudo está
resolvido.
Use unix2dos e dos2unix para fazer a conversão entre os sistemas
Mas que coisa extraordinária. Não seria mal que o Linux reconhecesse como
válida as duas quebras e pouparia um bocado de dor de cabeça.
Na verdade isso é uma "limitação" do C: \n é uma quebra de linha em C, a
linguagem base que foi construído o Linux e, por compatibilidade
retroativa, tudo foi criado a partir disso.
Observe-se que, independentemente da quebra de linha, o script é executado
normalmente em um ou outro caso quando a linha de comando é "lua
lacuna.lua". A quebra de linha só fez diferença quando tentei executar o
script diretamente pelo Bash.
Quando a estrutura de pastas do Linux, confesso que ainda me atrapalho um
pouco. Segundo entendo, em /usr/bin, guardo executáveis binários. Em
/usr/share, guardo executáveis do tipo script. Em /usr/lib, guardo binários
do tipo biblioteca. Temos a mesma estrutura reproduzida em /usr/local. A
bem dizer, pensava que este "local" referia-se a coisinhas produzidas pelo
próprio usuário.
Vamos em partes:
/bin - binários do sistema
/boot - binários para startup do sistema (e.g. initramfs, vmlinuz, grub
etc.)
/etc - configurações globais do sistema
/dev - acesso aos dispositivos de hardware do sistema
/home - os arquivos dos usuários
/lib - as bibliotecas do sistema
/opt - programas de terceiros, isto é, que não são instalados via .deb ou
façam parte da distribuição
/proc - é o acesso aos dados do processador e funções do kernel
/usr - é a mesma hierarquia acima, mas para a distribuição, assim:
/usr/share - dados compartilhados (geralmente não há binários aqui)
/usr/lib - bibliotecas da distro
/usr/bin - binários da distro
etc.
Então se você está a instalar programas que não são da distro o ideal é em
/opt.
Note que há uma outra hierarquia para programas de terceiros: /usr/local
Em /usr/local há a mesma hierarquia acima (bin, share, lib, etc.) para
instalações (e.g. compiladas) pelo usuário, mas de acesso global ao sistema.
Uma outra hierarquia de pastas, em geral para desenvolvimento, pode ser
criada dentro da pasta do usuário, assim:
$HOME/bin - os binários
$HOME/lib - as bibliotecas compartillhadas
$HOME/src - os fontes
$HOME/share - os arquivos compartilhados, em geral ícones, recursos, etc.
Os scripts são arquivos executáveis e são tratados como binários.
O PATH do sistema é uma variável que define as buscas no bash para a
execução de arquivos executáveis (binários e scripts).
Há muito mais detalhes aqui, mas por hora o e-mail já está gigante, então
fico por aqui.
Detalhes em: http://wiki.debian.org/FilesystemHierarchyStandard
Só que está em inglês.
Windows e Linux tem filosofias diferentes. . NO Windows, em geral, os
programas criam uma pasta em que binários, scripts, documentação e tudo
mais são colocados.
Não, na verdade a filosofia é a mesma: bibliotecas vão para
C:\windows\system ou c:\windows|system32 e os programas vão para c:\program
files e os compartilhados vão para c:\program files\commoms. A diferença é
que, no windows, não há "distribuição", então todos os programas, inclusive
os da microsoft são tratados como de terceiros (seria equivalente a ter-se
somente o /opt).
Para o seu caso, colocaria tudo em $HOME/scritps e um link simbólico em
$HOME/bin
Abraços
