shell-script-pt
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [shell-script] Re: Construção de CASE Complexa


From: Julio C. Neves
Subject: Re: [shell-script] Re: Construção de CASE Complexa
Date: Mon, 11 Jul 2016 11:02:05 -0300

Rodrigo,
Qdo o e-mail com a dúvida é muito grande e meu tempo muito pequeno, só leio o que interessa. Agora, conseguindo ler um pouco mais do assunto, estou vendo que o case não me parece ser o mais aconselhável. Dá uma olhadinha nisso aqui [1] e veja se não lhe interessa.

[1] - http://wiki.softwarelivre.org/TWikiBar/TWikiBarPapo010#Comando_getopts

Abcs,
Julio
@juliobash

P
róximos cursos de Shell
Cidade         Local Período
São Paulo 4Linux 25
-29/07
Dou treinamento de Shell em qualquer cidade.
Para mais detalhes, me mande um e-mail.


Em 11 de julho de 2016 00:09, Rodrigo Amorim Ferreira | CODECOMMUNITY address@hidden [shell-script] <address@hidden> escreveu:
 

Oi Pessoal,

Acho que consegui uma forma de resolver o meu problema e manter o código
o mais "fácil" e "legível" possível para esse SCMS por linha de comando
que estou tentando criar.

O problema é que essa ideia pode parecer insana (ou mesmo herética), já
que eu não resolvi o problema do identificador de parâmetros (para saber
como o programa vai agir) utilizando o CASE, mas sim com o IF (ELIF)n
ELSE :D

Dessa forma posso expandir todas as opções de linha de comando do
programa, das que tem menor quantidade de parâmetros até as que contêm
maior quantidade de parâmetros, tudo no mesmo nível, sem precisar
aninhar nada.

NOTA: Peço que, antes de jogarem pedras (ou me atirarem na fogueira)
deem uma olhada no exemplo ilustrativo abaixo e teçam seus comentários
(e me deem tempo para me esconder...):

#!/bin/bash

# SCMS (ainda sem nome)
#
# - Inicia pelos comandos com menor quantidade de parâmetros, até os
# que possuem maior quantidade de parâmetros (apenas por questão de
# lógica e organização do código).
#
# - Força o usuário a digitar as opções na ordem correta no intuito
# de pensar em [projetos > subprojetos > arquivos] como uma forma de
# superconjunto.
#
# - A título de explicação para esse exemplo simples, a especificação
# de cada comando está na saída (echo) de cada condição.
#
# - Exemplo apenas ilustrativo para avaliação da proposta de uso do
# IF (ELIF)n ELSE ao invés de CASE para identificar todos os
# parâmetros e suas respectivas ordens digitadas na linha de
# comando.
#

if [[ "${1}" == "-p" ]] || [[ "${1}" == "--project" ]] && [[ -z "${2}"
]]
then
echo "OPÇÃO: Lista informações sobre todos os projetos existentes"
echo "FORMA: <programa> -p, --project"
echo "DIGITADO: $(basename ${0}) $1"
elif [[ "${1}" == "-p" ]] || [[ "${1}" == "--project" ]] && [[ ! -z
"${2}" ]] && [[ ${3} == "-s" ]] || [[ "${3}" == "--subproject" ]] &&
[[ ! -z "${4}" ]] && [[ -z "${5}" ]]
then
echo "OPÇÃO: Lista informações sobre o subprojeto $4"
echo "FORMA: <programa> -p, --project PROJECT -s, --subproject
SUBPROJECT"
echo "DIGITADO: $(basename ${0}) $1 $2 $3 $4"
elif [[ "${1}" == "-p" ]] || [[ "${1}" == "--project" ]] && [[ ! -z
"${2}" ]] && [[ ${3} == "-s" ]] || [[ "${3}" == "--subproject" ]] &&
[[ ! -z "${4}" ]] && [[ "${5}" == "-F" ]] || [[ "${5}" == "--Framework"
]] && [[ ! -z "${6}" ]]
then
echo "OPÇÃO: Associa o Framework $6 ao Subprojeto $4"
echo "FORMA: <programa> -p, --project PROJECT -s, --subproject
SUBPROJECT -F, --Framework FRAMEWORK"
echo "DIGITADO: $(basename ${0}) $1 $2 $3 $4 $5 $6"
else
echo "RTFM :D"
fi

PERGUNTAS

- O que acharam?
- Vale a pena continuar dessa forma, ou essa não seria a maneira mais
adequada de resolver esse problema?
- E, se é "errado" (leia-se: amador) fazer as coisas desse jeito, qual
seria a forma mais interessante de resolver esse problema mantendo um
nível igual ou maior de legibilidade de código (inclusive para
manutenção)?

NOTA: Tenham em mente que a quantidade de possibilidades de comandos
para esse projeto é (possivelmente) enorme.

Realmente, quero tentar fazer esse programa da melhor forma possível e
sei que vocês tem ótimas opiniões e ideias sobre o assunto.

Desde já agradeço a ajuda.

Um abraço.

Rodrigo

On Sat, 2016-07-09 at 20:25 -0300, Rodrigo Amorim Ferreira |
CODECOMMUNITY wrote:
> OI Itamar,
>
> Não se preocupe. Na minha opinião nunca é crítica, e esse tipo de
> retorno sempre será bem vindo.
>
> E, Não! Não visitei esse site ainda. Mas, Sim! Antes de decidir (tentar)
> fazer um SCMS por minha própria conta, andei avaliando diversos outros
> projetos que encontrei "Internet à fora" :D (mas nem de longe todos,
> apenas os que mais se destacavam na comunidade).
>
> Eu também estava restrito a um número fixo de linguagens de programação
> utilizadas para o desenvolvimento dessas ferramentas e sabia que não
> poderia querer mexer em qualquer coisa, em qualquer linguagem. As
> linguagens de programação em que eu "me garanto" são bem poucas, o que
> torna o universo de escolha bastante limitado...
>
> E dos poucos que eu encontrei, eu achei que o trabalho que iria dar para
> alterá-los para as minhas necessidades seria (aparentemente) maior do
> que um construído do zero (nem que seja em
> prestações-a-perder-de-vista).
>
> PONTOS (POSSIVELMENTE) NEGATIVOS
>
> [Geração de Código]
>
> Muito do que me importa em um SCMS é a maneira que ele constrói as
> páginas, como ele monta o código HTML e suas diversas opções, seu grau
> de refinamento, o que é difícil de encontrar em muitos projetos.
>
> [Construção de Código]
>
> Outro ponto que me afasta é o "mexer em código alheio". É raro você
> encontrar código "semelhante" a sua maneira de construir programas, a
> sua maneira de pensar como programar, a sua maneira de trabalhar (o que
> você está tentando automatizar) e, rezar para que o mesmo seja o mínimo
> possível de "macarrônico", e que possua o uso adequado de endentação e
> comentários no código, fornecimento de documentação mínima, histórico de
> modificações, bugs conhecidos, e assim por diante.
>
> Ainda nesse ponto, se o programa que você quer modificar - além de ter
> uma abordagem diferente - estiver abaixo (ou, principalmente, acima) de
> seu nível de programação, só irá complicar as coisas. Claro que é sempre
> um desafio, mas... o tempo disponível também conta. E acredito que fazer
> um fork e levar ele a sério também é muito trabalho.
>
> É importante destacar também que nesta vida já troquei muitas vezes de
> ferramenta por problemas de customização, limitações, etc.
>
> [Projeto de Código]
>
> Outra coisa que sinto falta é da modularidade na construção dos projetos
> de software, que permitam desenvolvimento e expansão contínuo sem muito
> refactoring. Não necessariamente vemos isso nas opções de software
> disponíveis.
>
> NOTA: Não estou querendo afirmar que sou um especialista em programação.
> Longe disso! Acredito saber bem menos que muitos programadores mundo
> afora, mas me preocupo desde o início com o código, no que se refere ao
> crescimento do projeto e, principalmente, a quem vai colocar a mão nele
> depois (seja um newbie ou um hacker).
>
> Por sinal, os livros do Aurélio (regexp e "shell avançado") e do Julio
> (shell e "graphic shell") eu tenho ao meu lado para consulta a todo
> momento :D Nem de longe estou com as versões atualizadas dessas
> publicações, mas ainda sim são uma mão-na-roda por aqui. E como ultimo
> recurso eu tenho a Internet e depois a lista de discussão :D
>
> PONTOS (POSSIVELMENTE) POSITIVOS
>
> [Nova Abordagem]
>
> Eu sei que por mais que a gente avalie um projeto e ache que ele será
> "simples" de desenvolver, ele nunca será realmente simples. Eu também
> sei que (possivelmente) terei muitas dores de cabeça - antes, durante e
> depois de cada marco do projeto alcançado. Mas eu acredito que (para
> esse projeto) tenho algumas ideias que tornarão o processamento de
> automatização de sites algo muito mais simples e com possibilidades
> muito maiores de expansão e refinamento que as alternativas disponíveis
> (ou pelo menos do que eu consegui avaliar delas).
>
> Antes de mais nada quero deixar claro que isso não é pretensão de minha
> parte. Vamos dizer apenas que me empolguei com algumas ideias que tive e
> quero colocar elas para funcionar o quanto antes. Se der certo, ficarei
> feliz. Mas é claro que posso estar redondamente enganado
> (probabilisticamente falando, a chance é sempre maior para esse caso),
> mas se isso for verdade só descobrirei mais para frente :D
>
> [Compressão de Conhecimento]
>
> Outra vantagem de se criar um projeto do zero é a carga de aprendizado,
> comprimida, que adentra seu cérebro a cada hora de seu desenvolvimento.
> Não somente código, mas também referente ao gerenciamento do projeto
> como um todo. Ninguém em sã consciência sai programando do início ao fim
> como se fosse uma corrida de bits. Um projeto precisa ser (muito bem)
> planejado, antes, durante e depois do seu desenvolvimento (baseando-se
> em marcos e versões).
>
> E quanto mais vezes você repete esse processo em projetos começados do
> zero, mais bagagem você acumula simultaneamente em gerenciamento e em
> programação.
>
> [Meu Caminho, Minha Velocidade]
>
> Uma outra vantagem é que, como (aparentemente) de início, esse projeto
> só terá utilidade para minha pessoa, eu posso ir desenvolvendo minha
> ideia aos poucos, sempre priorizando a automatização das funcionalidades
> mais importantes para minhas necessidades emergenciais, e com o tempo ir
> implementando as demais características consideradas não-críticas.
>
> Assim, eu tento dividir o meu processo de desenvolvimento (atualmente
> manual) de SCMSs ao máximo, chegando a um possível módulo funcional
> mínimo, e tento criar ferramentas de automatização dessas pequenas
> etapas, de forma que seja possível uma futura interação entre esses
> módulos dependendo da combinação utilizada.
>
> Espero que eu consiga... torça por mim! :D
>
> Um abraço.
>
> Rodrigo
>
> On Sat, 2016-07-09 at 13:36 -0700, address@hidden [shell-script]
> wrote:
> >
> > Caro Rodrigo
> >
> > É muito interessante o seu projeto e a disposição em produzir um
> > "Gerenciador de Sites Estáticos".
> >
> > Quanto ao escopo da lista acho que se encaixa sim, visto que pediu
> > dicas de Shell Script e é bom saber que há um projeto assim em
> > andamento com esse enfoque ou ao menos com um uso intenso.
> >
> > Mas sem querer criticar, apenas no objetivo de te dar uma nova
> > perspectica já consultou algum CMS listado em StaticGen
> >
> >
> >
> > image
> >
> > StaticGen
> > StaticGen
> > is a
> > leaderboard
> > of the top
> > open-source
> > static site
> > generators.
> > Promoting a
> > static
> > approach to
> > building
> > websites.
> >
> > Visualizar
> > em
> > www.staticgen...
> > Visualização pelo Yahoo
> >
> >
> >
> >
> > Ou consultar o Axe em :
> > Axe CMS
> >
> >
> > image
> >
> > Axe CMS
> > Gerenciador
> > de conteúdo
> > estático
> >
> > Visualizar
> > em
> > augustocampo...
> > Visualização pelo Yahoo
> >
> >
> >
> >
> > https://github.com/augustocc/axe
> >
> >
> > São apenas sugestões que podem servir ou fornecer alguma idéia
> > adicional ao seu projeto
> >
> > []'s
> > Itamar
> >
> >
> >
>
>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]