[Ubuntu-BR] Execução de um script em /usr/local/share

[Luciano de Souza]

Guardei o link para consultas. Mas a bem dizer, sua explicação foi-me 
mais do que suficiente. Se eu criar um deb, utilizo /usr/local. Se não 
criar, utilizo /opt.

Agora tudo funciona magnificamente bem.

Em 14-11-2011 11:18, Andre Cavalcante escreveu:
> Oi Luciano,
>
> Em 14 de novembro de 2011 11:38, Luciano de Souza<luchyanus em gmail.com>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
>