Menu
▾
▴
linuxcall-list — Lista de discussão do projeto LinuxCall
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(132) |
Oct
(228) |
Nov
(108) |
Dec
(69) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(52) |
Feb
(27) |
Mar
(3) |
Apr
(1) |
May
(2) |
Jun
|
Jul
|
Aug
(1) |
Sep
(1) |
Oct
(4) |
Nov
|
Dec
|
|
From: C. <al...@br...> - 2000-10-11 03:35:59
|
Alex Borro wrote: > > Seria um otima ideia, ia facilitar bastante pros programadores em C pq > eu já tenho todas as expressoes regulares prontinha.. Ai a > compatibilidade com os scripts seria 10! Puts... cara, ia ajudar um monte!!! > > A propósito, alguém poderia documentar o funcionamento dos scripts, isto > > é, listar todos os arquivos que estão sendo usados e a função de cada um > > deles? Seria legal descrever com um pouco mais de cuidado o funcionamento > > dos scripts mais importantes. > > OK, pode deixar que eu mando.... Beleza... valeu Alex... ajudou bastaaaannnteee! []'s -- André Casteliano Analista de Sistemas - al...@br... +---------------------------------------------+ | Linux User: # 178853 Machine: # 79923 | | Linux Heavy User - Powered by Slackware 7.1 | | http://www.geocities.com/andre_casteliano/ | +---------------------------------------------+ | LinuxCall - The Linux Dialer | | http://linuxcall.sourceforge.net | +---------------------------------------------+ |
|
From: C. <al...@br...> - 2000-10-11 03:33:25
|
Djames Suhanko wrote: > > Olá pessoal ! Opa. Beleza Djames... > Como havia anteriormente comentado com o André, haveria eu de fazer > um modelo de "logotipo" ( não confundir com "logomarca", que é o caso da > Coca-Cola(R).) hehhehe... pois é mano... minha idéia (que eu até comentei contigo), é um logo que seja "marcante"! Um logo que as minas olhem e digam: - Oh! Que gracinha... :PPP Algo como o 'wilbur'... o lobinho do GIMP... hehehe > Dificil fazer isso, heing? Tendo em mente que se trata de um É... deve ser bem difícil mesmo... hehehe Pessoal, quem tiver sugestões manda pro Djames... Eu já mandei minha sugestão... que tal algo mais.... mais.... 3D! ??? :-) []'s -- André Casteliano Analista de Sistemas - al...@br... +---------------------------------------------+ | Linux User: # 178853 Machine: # 79923 | | Linux Heavy User - Powered by Slackware 7.1 | | http://www.geocities.com/andre_casteliano/ | +---------------------------------------------+ | LinuxCall - The Linux Dialer | | http://linuxcall.sourceforge.net | +---------------------------------------------+ |
|
From: C. <al...@br...> - 2000-10-11 03:29:33
|
AAl...@am... wrote: > > Bom Nelson, cê pego o bonde andando. O negócio é o seguinte, o André fez > algumas funções que atuam em cima do arquivo de configuração, o meu > questionamento é que essas funções devem estar num módulo separado ou serem > colocadas numa função única para que tenhamos facilidades de manutenção no > futuro. Opa... tou aterrisando agora tb... :) Bom, Amauri e demais coders... a idéia DESDE O INÍCIO era essa!!! Modularização. Essa é a palavra chave! Se vcs repararem no mail que mandei há alguns dias, notarão que lá já estava definido assim... O arquivo que contém as funções de acesso ao arq. de config. se chama 'get_conf.c'. Provavelmente o arquivo de gravação do arq. de config. se chamará 'put_conf.c' e assim por diante... Em programas maiores que 500 linhas a modularização já é necessária... :PPP > Concordo com a idéia de se poder usar expressões regulares, mas caimos no > mesmo problema, se não tivermos funções agrupadas num mesmo local, depois > teremos que garimpar o código para mudarmos as mesmas. Hum... expressões regulares ??? Desculpem a ignorância mais não entendi muito bem... Usar Expressões regulares no acesso ao arq. de config. ??? > André, sei que posso até estar enchendo o saco, mas acho que assim fica mais > fácil de termos um código modular e enchuto. Que enchendo o saco que nada! Eu gosto de discutir... :))) E olha que engraçado: Estamos defendendo os mesmos pontos... como podemos discutir... hehehehe > Coders, aguardo sugestões a favor e também contra, as discussões são legais. Com certeza!!! Todo mundo opinando por favor.,... :PPP []'s -- André Casteliano Analista de Sistemas - al...@br... +---------------------------------------------+ | Linux User: # 178853 Machine: # 79923 | | Linux Heavy User - Powered by Slackware 7.1 | | http://www.geocities.com/andre_casteliano/ | +---------------------------------------------+ | LinuxCall - The Linux Dialer | | http://linuxcall.sourceforge.net | +---------------------------------------------+ |
|
From: C. <al...@br...> - 2000-10-11 03:20:27
|
Eae pessoal, beleza ? Olha aí pessoal, um mail que eu recebi hj... Dá o que pensar... será que o LinuxCall tá tão user-friendly assim ??? []'s -- André Casteliano Analista de Sistemas - al...@br... +---------------------------------------------+ | Linux User: # 178853 Machine: # 79923 | | Linux Heavy User - Powered by Slackware 7.1 | | http://www.geocities.com/andre_casteliano/ | +---------------------------------------------+ | LinuxCall - The Linux Dialer | | http://linuxcall.sourceforge.net | +---------------------------------------------+ |
|
From: Marcelo B. <md...@ma...> - 2000-10-11 02:19:25
|
---[ printf("Em ter, 10 out 2000, AAl...@am... escreveu"); ]---
// Bom Nelson, cê pego o bonde andando. O negócio é o seguinte, o André fez
// algumas funções que atuam em cima do arquivo de configuração, o meu
// questionamento é que essas funções devem estar num módulo separado ou serem
// colocadas numa função única para que tenhamos facilidades de manutenção no
// futuro.
//
// Concordo com a idéia de se poder usar expressões regulares, mas caimos no
// mesmo problema, se não tivermos funções agrupadas num mesmo local, depois
// teremos que garimpar o código para mudarmos as mesmas.
// André, sei que posso até estar enchendo o saco, mas acho que assim fica mais
// fácil de termos um código modular e enchuto.
//
// Coders, aguardo sugestões a favor e também contra, as discussões são legais.
//
Sou totalmente a favor da modularização! Modularização já!
Isso facilita tudo, o trabalho em paralelo, o cvs, o reaproveitamento
de código, e tudo o mais.
Prefiro várias funções menores agrupadas em um módulo em separado do
que baitas super funções inseridas em um único .c
Trabalhar com um único .c num projeto desse tipo é totalmente
inviável.
[]s
--
Marcelo D. Beckmann - Linux User #173935
md...@ma... - UIN 53189692
http://marcelobeckmann.cjb.net
.~. 233MMX 32MB 8.4+3.2GB Quantum Fireball
/V\ OPL3SAx TGUI9680 2MB 33600 CL5 2.2.14 + Slack7 2.2.13
/(.)\ "Estamos de volta aos tempos em que os homens eram homens
^`~´^ e programavam seus próprios drivers de dispositivo." L.T.
"Se casamento fosse que nem estrada, eu andaria sempre pelo
acostamento..."
|
|
From: Marcelo B. <md...@ma...> - 2000-10-11 02:19:19
|
---[ printf("Em ter, 10 out 2000, Nelson Correa de Toledo Ferraz escreveu"); ]---
// Pessoal,
//
// > Coders, eu concordo com o André quanto a performance, mas a diferença entre
// > uma função genérica e outras menores em termos de processamento é muito
// > pequena.
//
// Até que ponto a performance é um fator importante para um dialer? Se não
// for tão crítico, vale mais a pena encarar o programa como um "meio de
// comunicação entre humanos", e não somente entre homem-máquina.
Isso me traz à lembrança aquela vez em que estavamos discutindo e
debugando junto as primeiras implementações em XStep junto com o
André. Eu mesmo cheguei a comentar sobre o uso de listas encadeadas,
mas essas listas são um sac* e vimos que não precisávamos de tanta
complicação, e então foi adotada uma forma mais simples e
'entendível' de implementação.
O processo de discagem já é algo considerávelmente lento em
comparação a um possível ganho de performance que pudesse ser obtido
em virtude de uma forma de implementação ou outra.
// > Uma outra solução poderia ser manter as pequenas funções, mas num
// > arquivo separado (módulo) de maneira que quando precisarmos mudar o formato
// > do arq. de configuração isso ficar fácil. Não é necessário fazer uma super
// > função, mas o que fizermos deve ser de fácil manutenção, já que amanhã pode
// > não sermos que estará dando manutenção ao código. Entre performance e
// > facilidade de manutenção fico com a segunda.
Exatamente. Eu sou totalmente a favor da modularização do projeto. É
muito viável reunir grupos de funções com finalidades específicas em
arquivos .c separados, e mesmo os includes dependendo do caso.
Eu antes me embananava todo pra trabalhar dessa forma, com vários
arquivos separados e coisa e tal. Mas uma vez que se pegue o costume,
basta partir de um makefile inicial e seguir atualizando-o que tudo
vai sem problemas.
Principalmente num projeto como esse, feito a várias mãos, isso é
importantíssimo, pois facilita em muito o desenvolvimento e
administração do código.
// Eu peguei a discussão no meio, mas se eu entendi a questão envolve o uso
// de arquivos em formato texto. Porque não usar uma biblioteca em C que
// permita usar expressões regulares (tipo Perl)?
Opa, idéia interessante.
Eu não trabalhei com isso ainda. Nelson, você conhece alguma
biblioteca em C desse tipo? Se você puder comentar algo mais a
respeito seria muito bom.
// > Coders, mandem suas opiniões, o projeto é grande e tem um futuro enorme se
// > sair bem feito e isso depende da gente.
//
// A minha idéia de fazer uma interface baseada no Mozilla/XUL ainda está de
// pé, só falta eu arranjar algum tempo. :-)
O linux e suas infinitas possibilidades, isso é sensacional.
LinuxCall em bash script, C, XStep, GTK, Mozilla/XUL...
Quanto a falta de tempo, putz, é fogo...
Às vezes eu me pergunto por que o comando
$ grep DIA tempo.h
retorna...
#define DIA 24*HORA
Ah se eu pudesse mudar isso... :)
// A propósito, alguém poderia documentar o funcionamento dos
scripts, isto // é, listar todos os arquivos que estão sendo usados
e a função de cada um // deles? Seria legal descrever com um pouco
mais de cuidado o funcionamento // dos scripts mais importantes.
Taí uma coisa que tem que ser feita mesmo...
Recentemente andei lendo alguma coisa sobre sed e no trampo vou ter
que começar a mexer muito com scripts, então unindo o útero ao
agradável, seria interessante para mim aprender mais de sed, e como
os scripts do Alex estão recheados dele (sed é powered!) talvez eu
possa dar uma mão nesse sentido.
Infelizmente ando meio ruinzão de saúde ultimamente, os últimos 5
dias foi só chegar em casa e cair na cama por que não tava guentando
mesmo. Eu já queria estar com umas funções de tratamento de modem
prontas pra mandar pra vocês mas infelizmente não deu. Mas assim que
eu melhorar boto isso no ar. Aproveitando o embalo,
relacionem ai o que vocês precisam relacionado a isso, ok? Por
enquanto, já estou prevendo as seguintes funcionalidades:
* Enviar string de reset e/ou inicialização para o modem;
* Envio dos ATI's e tratamento do retorno dos mesmos;
* Função para varrer as seriais em busca de um possível modem; Nesse
caso em específico, a busca de modens 'de verdade' nas portas padrões
(ttyS0 a ttyS3) me parece sem problemas, mas eu nunca usei winmodens,
então se vocês tiverem algo a comentar sobre isso, possíveis
diferenças, portas utilizadas, etc, seria bom.
Bom, por enquanto é isso ai.
Um grande abraço a todos,
--
Marcelo D. Beckmann - Linux User #173935
md...@ma... - UIN 53189692
http://marcelobeckmann.cjb.net
.~. 233MMX 32MB 8.4+3.2GB Quantum Fireball
/V\ OPL3SAx TGUI9680 2MB 33600 CL5 2.2.14 + Slack7 2.2.13
/(.)\ "Estamos de volta aos tempos em que os homens eram homens
^`~´^ e programavam seus próprios drivers de dispositivo." L.T.
|
|
From: C. <al...@br...> - 2000-10-11 02:02:59
|
Fala pessoal, beleza ? Eae, coders, todo mundo no gás ??? Bom, seguindo ainda as sugestões do Amauri, e me baseando na função que ele mandou por último, escrevi pequenas funções que acessam a 'super-função' e obtém dela os valores necessários a cada situação. Tou mandando tb a função principal (super-função) que recebeu pequenas modificações... Essas funções não foram testadas... devem haver pequenos bugs e/ou pequenos erros de lógica... mas ilustram bem a idéia... E vamos nessa!!! []'s -- André Casteliano Analista de Sistemas - al...@br... +---------------------------------------------+ | Linux User: # 178853 Machine: # 79923 | | Linux Heavy User - Powered by Slackware 7.1 | | http://www.geocities.com/andre_casteliano/ | +---------------------------------------------+ | LinuxCall - The Linux Dialer | | http://linuxcall.sourceforge.net | +---------------------------------------------+ |
|
From: Alex B. <ne...@za...> - 2000-10-11 01:54:35
|
Gostei da ideia e do logo.. Só precisa redesenhar para o phone deixar de parecer uma cartola, mas ta valendo... ;-) té mais... Djames Suhanko wrote: > > Olá pessoal ! > Como havia anteriormente comentado com o André, haveria eu de fazer > um modelo de "logotipo" ( não confundir com "logomarca", que é o caso da > Coca-Cola(R).) > Dificil fazer isso, heing? Tendo em mente que se trata de um discador > pra Linux (pelo menos de principio, nao vi comentarios de te-lo rodando > em outra plataforma), o que vem a cabeça? > a- Um pinguim. > b- Um telefone. > c- Os dois > Bem, o C seria o mais provavel, portanto, baseado nos já citados > elementos, juntamente ao fato de que estamos vivendo na época que os > produtos são representados por "signos" , somado à décima terceira > teoria de Newton (que diz que todo o pão cai com a manteiga para baixo), > cheguei ao primeiro elemento dessa extressante tentativa de criar um > logotipo agradável aos olhos. Não é tão complexo quanto este texto, mas > pelo menos não é tão feio quanto o logo da GNU ( Deus me perdoe pelo > comentário). > No logo, pode-se ver um penguim ao lado de um phone, ( que também > causa a impressão de ser um pinguim pondo a cartola no cabide do > Alcapone). O único problema que encontrei foi o tamanho, já que para > colocar no discador penso que não ficaria beeeeem definido. > Para concluir, se ao menos o logo chegou a agradar ou a idéia tomou um > rumo que lhes causou interesse, retruquem a esse mail. Em anexo, o logo > + o logo na janela de about do discador. > > Abraços !!! > > -- > ¨°¨ ¨°¨ ¨°¨ > * Linux User 158760 * > http://djames.suhanko.vila.bol.com.br/ > ¨°¨ > <<<°>>> > > ------------------------------------------------------------------------ > [Image] [Image] -- /------------------------------ \ ____ | Alex Borro - Neo-Linux_Inside | \ \ | Faculdade de Engenharia | |\ >>\ \> | Mecatrônica - UNICAMP |----| \_____\ \_______ >-------------------------------< | L I N U X \ | Powered By LINUX SLACKWARE 7.1|----|________ _______/ | Kernel 2.2.16 User: 164956 | / / | e-mail: ne...@ya... | >>/ /> \-------------------------------/ /___/ The box said "Requeries Windows 9x, Windows NT 4, or better", so I installed Linux. |
|
From: Alex B. <ne...@za...> - 2000-10-11 01:51:39
|
Nelson Correa de Toledo Ferraz wrote: > Eu peguei a discussão no meio, mas se eu entendi a questão envolve o uso > de arquivos em formato texto. Porque não usar uma biblioteca em C que > permita usar expressões regulares (tipo Perl)? Seria um otima ideia, ia facilitar bastante pros programadores em C pq eu já tenho todas as expressoes regulares prontinha.. Ai a compatibilidade com os scripts seria 10! > A propósito, alguém poderia documentar o funcionamento dos scripts, isto > é, listar todos os arquivos que estão sendo usados e a função de cada um > deles? Seria legal descrever com um pouco mais de cuidado o funcionamento > dos scripts mais importantes. OK, pode deixar que eu mando.... -- /------------------------------ \ ____ | Alex Borro - Neo-Linux_Inside | \ \ | Faculdade de Engenharia | |\ >>\ \> | Mecatrônica - UNICAMP |----| \_____\ \_______ >-------------------------------< | L I N U X \ | Powered By LINUX SLACKWARE 7.1|----|________ _______/ | Kernel 2.2.16 User: 164956 | / / | e-mail: ne...@ya... | >>/ /> \-------------------------------/ /___/ The box said "Requeries Windows 9x, Windows NT 4, or better", so I installed Linux. |
|
From: Djames S. <su...@uo...> - 2000-10-11 00:12:28
|
Olá pessoal ! Como havia anteriormente comentado com o André, haveria eu de fazer um modelo de "logotipo" ( não confundir com "logomarca", que é o caso da Coca-Cola(R).) Dificil fazer isso, heing? Tendo em mente que se trata de um discador pra Linux (pelo menos de principio, nao vi comentarios de te-lo rodando em outra plataforma), o que vem a cabeça? a- Um pinguim. b- Um telefone. c- Os dois Bem, o C seria o mais provavel, portanto, baseado nos já citados elementos, juntamente ao fato de que estamos vivendo na época que os produtos são representados por "signos" , somado à décima terceira teoria de Newton (que diz que todo o pão cai com a manteiga para baixo), cheguei ao primeiro elemento dessa extressante tentativa de criar um logotipo agradável aos olhos. Não é tão complexo quanto este texto, mas pelo menos não é tão feio quanto o logo da GNU ( Deus me perdoe pelo comentário). No logo, pode-se ver um penguim ao lado de um phone, ( que também causa a impressão de ser um pinguim pondo a cartola no cabide do Alcapone). O único problema que encontrei foi o tamanho, já que para colocar no discador penso que não ficaria beeeeem definido. Para concluir, se ao menos o logo chegou a agradar ou a idéia tomou um rumo que lhes causou interesse, retruquem a esse mail. Em anexo, o logo + o logo na janela de about do discador. Abraços !!! -- ¨°¨ ¨°¨ ¨°¨ * Linux User 158760 * http://djames.suhanko.vila.bol.com.br/ ¨°¨ <<<°>>> |
|
From: <AAl...@am...> - 2000-10-10 23:07:15
|
Bom Nelson, cê pego o bonde andando. O negócio é o seguinte, o André fez algumas funções que atuam em cima do arquivo de configuração, o meu questionamento é que essas funções devem estar num módulo separado ou serem colocadas numa função única para que tenhamos facilidades de manutenção no futuro. Concordo com a idéia de se poder usar expressões regulares, mas caimos no mesmo problema, se não tivermos funções agrupadas num mesmo local, depois teremos que garimpar o código para mudarmos as mesmas. André, sei que posso até estar enchendo o saco, mas acho que assim fica mais fácil de termos um código modular e enchuto. Coders, aguardo sugestões a favor e também contra, as discussões são legais. []s Amauri Albuquerque Engenheiro de Telecomunicações Centro de Supervisão e Controle de Rede - CSCR Americel 329-6811 > ----- Mensagem original ----- > De: Nelson Correa de Toledo Ferraz [SMTP:nf...@in...] > Enviada em: Terça-feira, 10 de Outubro de 2000 18:52 > Para: lin...@li... > Assunto: [Linuxcall] Re: [Linuxcall] Código... > > > Pessoal, > > > Coders, eu concordo com o André quanto a performance, mas a diferença > entre > > uma função genérica e outras menores em termos de processamento é muito > > pequena. > > Até que ponto a performance é um fator importante para um dialer? Se não > for tão crítico, vale mais a pena encarar o programa como um "meio de > comunicação entre humanos", e não somente entre homem-máquina. > > > Uma outra solução poderia ser manter as pequenas funções, mas num > > arquivo separado (módulo) de maneira que quando precisarmos mudar o > formato > > do arq. de configuração isso ficar fácil. Não é necessário fazer uma > super > > função, mas o que fizermos deve ser de fácil manutenção, já que amanhã > pode > > não sermos que estará dando manutenção ao código. Entre performance e > > facilidade de manutenção fico com a segunda. > > Eu peguei a discussão no meio, mas se eu entendi a questão envolve o uso > de arquivos em formato texto. Porque não usar uma biblioteca em C que > permita usar expressões regulares (tipo Perl)? > > > Coders, mandem suas opiniões, o projeto é grande e tem um futuro enorme > se > > sair bem feito e isso depende da gente. > > A minha idéia de fazer uma interface baseada no Mozilla/XUL ainda está de > pé, só falta eu arranjar algum tempo. :-) > > A propósito, alguém poderia documentar o funcionamento dos scripts, isto > é, listar todos os arquivos que estão sendo usados e a função de cada um > deles? Seria legal descrever com um pouco mais de cuidado o funcionamento > dos scripts mais importantes. > > []s > > Nelson > > __________________________________________________________________ > Nelson Ferraz Insite - Solucoes Internet > e-mail: nf...@in... http://www.insite.com.br/ > > _______________________________________________ > Linuxcall-list mailing list > Lin...@li... > http://lists.sourceforge.net/mailman/listinfo/linuxcall-list > Canal IRC: irc.wnet.com.br #linuxcall > HomePage: http://linuxcall.sourceforge.net |
|
From: Nelson C. de T. F. <nf...@in...> - 2000-10-10 21:52:27
|
Pessoal, > Coders, eu concordo com o André quanto a performance, mas a diferença entre > uma função genérica e outras menores em termos de processamento é muito > pequena. Até que ponto a performance é um fator importante para um dialer? Se não for tão crítico, vale mais a pena encarar o programa como um "meio de comunicação entre humanos", e não somente entre homem-máquina. > Uma outra solução poderia ser manter as pequenas funções, mas num > arquivo separado (módulo) de maneira que quando precisarmos mudar o formato > do arq. de configuração isso ficar fácil. Não é necessário fazer uma super > função, mas o que fizermos deve ser de fácil manutenção, já que amanhã pode > não sermos que estará dando manutenção ao código. Entre performance e > facilidade de manutenção fico com a segunda. Eu peguei a discussão no meio, mas se eu entendi a questão envolve o uso de arquivos em formato texto. Porque não usar uma biblioteca em C que permita usar expressões regulares (tipo Perl)? > Coders, mandem suas opiniões, o projeto é grande e tem um futuro enorme se > sair bem feito e isso depende da gente. A minha idéia de fazer uma interface baseada no Mozilla/XUL ainda está de pé, só falta eu arranjar algum tempo. :-) A propósito, alguém poderia documentar o funcionamento dos scripts, isto é, listar todos os arquivos que estão sendo usados e a função de cada um deles? Seria legal descrever com um pouco mais de cuidado o funcionamento dos scripts mais importantes. []s Nelson __________________________________________________________________ Nelson Ferraz Insite - Solucoes Internet e-mail: nf...@in... http://www.insite.com.br/ |
|
From: <AAl...@am...> - 2000-10-10 18:30:13
|
Coders, eu concordo com o André quanto a performance, mas a diferença entre uma função genérica e outras menores em termos de processamento é muito pequena. Uma outra solução poderia ser manter as pequenas funções, mas num arquivo separado (módulo) de maneira que quando precisarmos mudar o formato do arq. de configuração isso ficar fácil. Não é necessário fazer uma super função, mas o que fizermos deve ser de fácil manutenção, já que amanhã pode não sermos que estará dando manutenção ao código. Entre performance e facilidade de manutenção fico com a segunda. Coders, mandem suas opiniões, o projeto é grande e tem um futuro enorme se sair bem feito e isso depende da gente. []s Amauri Albuquerque Engenheiro de Telecomunicações Centro de Supervisão e Controle de Rede - CSCR Americel 329-6811 > ----- Mensagem original ----- > De: André Casteliano [SMTP:al...@br...] > Enviada em: Segunda-feira, 9 de Outubro de 2000 22:15 > Para: Lista LinuxCall > Assunto: [Linuxcall] Código... > > Olá pessoal, > > a coisa apertou aki... tou bastante ocupado mas arrumei um tempinho prá > dar uma olhada naquele código que o Amauri mandou... > > Bom, ainda não sei realmente se é a melhor solução (aguardo a opinião > dos demais coders...)... eu tenho a impressão de que funções menores e > mais específicas seriam mais interessantes do que super-funções... acho > que o programa se torna mais modular... > > Uma super-função, acabaria sendo genérica demais... dei uma revisada > naquele código que o Amauri mandou, corrigi uns pequenos bugs, otimizei > um pouquinho e tou mandando ele agora, em anexo. > > Amauri, eu entendi sua idéia cara. Uma função maior, genérica, e funções > menores, que chamassem essa função maior e retornassem dados > específicos. Só não sei se é a melhor solução... > > As funções menores, que mandei da outra vez, podem até ter as mesmas > rotinas, mas elas seriam usadas em partes diferentes do programa, de > forma que, acredito eu, aumentaria a performance, mas também aumentaria > o número de linhas de código a serem revisadas, caso mudássemos o > formato do arquivo, por exemplo, como vc falou. > > O melhor mesmo é discutirmos isso de forma que a melhor solução seja > implementada. Afinal, o nosso objetivo é fazer do LinuxCall o MELHOR > discador que existe (até mesmo se comparado ao de outras plataformas). > > É isso aí... vamos ver a opinião do pessoal, > > []'s > > -- > André Casteliano > Analista de Sistemas - al...@br... > +---------------------------------------------+ > | Linux User: # 178853 Machine: # 79923 | > | Linux Heavy User - Powered by Slackware 7.1 | > | http://www.geocities.com/andre_casteliano/ | > +---------------------------------------------+ > | LinuxCall - The Linux Dialer | > | http://linuxcall.sourceforge.net | > +---------------------------------------------+ << Arquivo: super.c >> |
|
From: C. <al...@br...> - 2000-10-10 02:10:08
|
Olá pessoal, a coisa apertou aki... tou bastante ocupado mas arrumei um tempinho prá dar uma olhada naquele código que o Amauri mandou... Bom, ainda não sei realmente se é a melhor solução (aguardo a opinião dos demais coders...)... eu tenho a impressão de que funções menores e mais específicas seriam mais interessantes do que super-funções... acho que o programa se torna mais modular... Uma super-função, acabaria sendo genérica demais... dei uma revisada naquele código que o Amauri mandou, corrigi uns pequenos bugs, otimizei um pouquinho e tou mandando ele agora, em anexo. Amauri, eu entendi sua idéia cara. Uma função maior, genérica, e funções menores, que chamassem essa função maior e retornassem dados específicos. Só não sei se é a melhor solução... As funções menores, que mandei da outra vez, podem até ter as mesmas rotinas, mas elas seriam usadas em partes diferentes do programa, de forma que, acredito eu, aumentaria a performance, mas também aumentaria o número de linhas de código a serem revisadas, caso mudássemos o formato do arquivo, por exemplo, como vc falou. O melhor mesmo é discutirmos isso de forma que a melhor solução seja implementada. Afinal, o nosso objetivo é fazer do LinuxCall o MELHOR discador que existe (até mesmo se comparado ao de outras plataformas). É isso aí... vamos ver a opinião do pessoal, []'s -- André Casteliano Analista de Sistemas - al...@br... +---------------------------------------------+ | Linux User: # 178853 Machine: # 79923 | | Linux Heavy User - Powered by Slackware 7.1 | | http://www.geocities.com/andre_casteliano/ | +---------------------------------------------+ | LinuxCall - The Linux Dialer | | http://linuxcall.sourceforge.net | +---------------------------------------------+ |
|
From: C. <al...@br...> - 2000-10-10 02:10:03
|
Marcelo Beckmann wrote: > > Lá vai o meu: eu acho melhor manter a máxima compatibilidade possível > com a versão em scripts. Creio que seja interessante manter isso > compatível, pois o cara pode usar uma ou outra versão sem ter dois > configs diferentes. Ok. Concordo com você. Só teremos um pequeno problema: Os scripts usam vários arquivos de configuração, e a versão em C deverá usar apenas 1. Minha idéia é incluir na seção "GLOBAL" desse arquivo de config, os parâmetros (nem sei se serão necessários) dos demais arquivos de configuração. O script simplesmente ignora esses parâmetros, o que não afeta o seu funcionamento. Aguardo a opinião de vocês, > "Não tenho tudo que quero, mas..." > mas foda-se, hehehehe "Não tenho tudo que quero, mas..." um muambeiro ficou de me arrumar, hehehehe []'s -- André Casteliano Analista de Sistemas - al...@br... +---------------------------------------------+ | Linux User: # 178853 Machine: # 79923 | | Linux Heavy User - Powered by Slackware 7.1 | | http://www.geocities.com/andre_casteliano/ | +---------------------------------------------+ | LinuxCall - The Linux Dialer | | http://linuxcall.sourceforge.net | +---------------------------------------------+ |
|
From: Davi F. <da...@li...> - 2000-10-09 12:50:18
|
On sáb, 07 out 2000 18:27:05 André Casteliano wrote: > Marcelo Beckmann wrote: > > > > André, > > > > Eu vi o seu texto, valeu ai, mas acho que dá pra melhorar. > > Bom, SEMPRE dá prá melhorar... :P > > > Como o Alex falou, existem formas de configurar o sudo para executar > > apenas determinados comandos sem a utilização de senha. > > Eu sei cara!!! O f*da é que se for ensinar pro cara todas as > configurações possíveis com o sudo é melhor escrever um HOWTO... > hehehehe Mas essa não era a idéia? A gente colocar ums HowTOs na página? Ia ser legal porque ia tirar a dúvida dos usuários e ainda ia colaborar com um HowTO em português sobre o SUDO! Na minha opinião, devia ter uma resposta básica no FAQ, ensinando ele a se conectar, sem muitos detalhes. E um HowTO completo sobre o SUDO. Abraços, -- Davi Ferreira |
|
From: <AAl...@am...> - 2000-10-09 10:15:50
|
Vamos manter a compatibilidade !!!!
Vou fazer as alterações. Pera aí, o André mudou as funções para fazer o que
a gente precisa. Dá uma olhada no e-mail dele.
[]s
Amauri Albuquerque
Engenheiro de Telecomunicações
Centro de Supervisão e Controle de Rede - CSCR
Americel
329-6811
> ----- Mensagem original -----
> De: Marcelo Beckmann [SMTP:md...@ma...]
> Enviada em: Domingo, 8 de Outubro de 2000 15:54
> Para: lin...@li...
> Assunto: Re: [Linuxcall] Fedeu...
>
> ---[ printf("Em sáb, 07 out 2000, André Casteliano escreveu"); ]---
> // Fala pessoal,
> //
> // Amauri, agora que eu fui testar as funcs de acesso ao arquivo de
> // configuração que eu percebi cara. Ele não é no estilo do arquivo do
> // samba por exemplo:
> //
> // campo = valor
> //
> // É assim:
> //
> // campo valor...
> //
> // Será que dá prá mudar ??? Ou então podemos deixar do jeito que tá
> // mesmo... só que aí peremos compatibilidade com a versão em scripts...
> // puts, é f*da...
> //
> // Aguardo comentários dos coders...
>
> Lá vai o meu: eu acho melhor manter a máxima compatibilidade possível
> com a versão em scripts. Creio que seja interessante manter isso
> compatível, pois o cara pode usar uma ou outra versão sem ter dois
> configs diferentes.
>
> E pro meu lado fedeu também... Esses dias, não sei por que, ando
> meio malzão, tipo meio ruim do estomago e já faz uns 4 dias que ando
> com uma dor de cabeça da porra. Eu planejava já estar mandando uma
> versão do configurador do modem pra vocês, mas infelizmente não deu
> ainda, não consegui cara. Lamento muito, mas é que tá 1/2 foda
> mesmo... Primeiro foi o micro que deu pau, agora sou eu que to
> baleado, ôôô vida....
>
> Desculpem ai pelo palavreado, mas assim que eu tiver melhor eu boto
> gaz na coisa de novo.
>
> Um abração ai.
>
>
> --
> Marcelo D. Beckmann - Linux User #173935
> md...@ma... - UIN 53189692
> http://marcelobeckmann.cjb.net
> .~. 233MMX 32MB 8.4+3.2GB Quantum Fireball
> /V\ OPL3SAx TGUI9680 2MB 33600 CL5 2.2.14 + Slack7 2.2.13
> /(.)\ "Estamos de volta aos tempos em que os homens eram homens
> ^`~´^ e programavam seus próprios drivers de dispositivo." L.T.
>
> "Não tenho tudo que quero, mas..."
> mas foda-se, hehehehe
>
> _______________________________________________
> Linuxcall-list mailing list
> Lin...@li...
> http://lists.sourceforge.net/mailman/listinfo/linuxcall-list
> Canal IRC: irc.wnet.com.br #linuxcall
> HomePage: http://linuxcall.sourceforge.net
|
|
From: Marcelo B. <md...@ma...> - 2000-10-08 18:03:28
|
---[ printf("Em sáb, 07 out 2000, André Casteliano escreveu"); ]---
// Fala pessoal,
//
// Amauri, agora que eu fui testar as funcs de acesso ao arquivo de
// configuração que eu percebi cara. Ele não é no estilo do arquivo do
// samba por exemplo:
//
// campo = valor
//
// É assim:
//
// campo valor...
//
// Será que dá prá mudar ??? Ou então podemos deixar do jeito que tá
// mesmo... só que aí peremos compatibilidade com a versão em scripts...
// puts, é f*da...
//
// Aguardo comentários dos coders...
Lá vai o meu: eu acho melhor manter a máxima compatibilidade possível
com a versão em scripts. Creio que seja interessante manter isso
compatível, pois o cara pode usar uma ou outra versão sem ter dois
configs diferentes.
E pro meu lado fedeu também... Esses dias, não sei por que, ando
meio malzão, tipo meio ruim do estomago e já faz uns 4 dias que ando
com uma dor de cabeça da porra. Eu planejava já estar mandando uma
versão do configurador do modem pra vocês, mas infelizmente não deu
ainda, não consegui cara. Lamento muito, mas é que tá 1/2 foda
mesmo... Primeiro foi o micro que deu pau, agora sou eu que to
baleado, ôôô vida....
Desculpem ai pelo palavreado, mas assim que eu tiver melhor eu boto
gaz na coisa de novo.
Um abração ai.
--
Marcelo D. Beckmann - Linux User #173935
md...@ma... - UIN 53189692
http://marcelobeckmann.cjb.net
.~. 233MMX 32MB 8.4+3.2GB Quantum Fireball
/V\ OPL3SAx TGUI9680 2MB 33600 CL5 2.2.14 + Slack7 2.2.13
/(.)\ "Estamos de volta aos tempos em que os homens eram homens
^`~´^ e programavam seus próprios drivers de dispositivo." L.T.
"Não tenho tudo que quero, mas..."
mas foda-se, hehehehe
|
|
From: <AAl...@am...> - 2000-10-08 05:33:01
|
Aquilo que você fez está certo. O que acontece é que você realiza a mesma
rotina nas três funções. A idéia que tenho é mudar a get_token para não
procurar o "=" e sim retornar o conteudo total das seções e então usar a
get_token para fazer o trabalho. Ou também mudar uma das funções que você
fez e torná-la genérica e as outras chamam ela.
Da maneira como está feito podemos ter problemas no futuro. Vamos dizer que
por uma fatalidade temos que mudar o formato do arquivo de configuração, ao
invés de usarmos "[" vamos usar "{" por exemplo. Dessa forma teremos que
mudar todas as ocorrências de "[" para "{" em todas as funções que fazem
acesso ao arq configuracao. A idéia da função generica é facilitar a
manutenção no futuro. O exemplo abaixo encapsula as três funções numa só, o
exemplo é meio ruim (tem erros de sintaxe e de variáveis e precisa ser
otimizado) mas ilustra a idéia.
#include <stdio.h>
#include <string.h>
/*#include "lc.h" */
/* Verifica se o provedor especificado em 'isp' está cadastrado no arquivo
'filename' */
int generic_check(char *filename, char *isp,char *token,int option /*qual
operação deve fazer*/,int* retorno /*retorno de check_isp*/)
{
FILE *conf;
char fstemp[200];
short int flag;
char *sigual;
char value[1000];
char *list[];
char *fstemp[200];
unsigned short count = 0, k = 0;
/* Abre o arquivo de configuração */
conf = fopen(filename, "r");
if (!conf) return -1; /* Se der falha na abertura do arquivo retorna
-1 */
/* procura a seção */
while (!feof(conf))
{
fscanf(conf, "%s", fstemp);
if ((strchr(fstemp, '[')) && (strchr(fstemp, ']')))
{
switch (option)
case 0:/*get_conf*/
if (strstr(stemp, isp))
{
/*procura o campo até encontrar o
final do arquivo ou até a proxima seção*/
while ((!feof(conf)) ||
((strchr(fstemp,'[')) && (strchr(fstemp,']'))))
{
fscanf(conf, "%s", fstemp);
if (strstr(fstemp, token))
{
sigual =
strchr(fstemp, '=');
sigual++;
strcpy(value,
sigual);
break;
}
}
}
break;
case 1:/*check_isp*/
if (strstr(stemp, isp))
flag = 0;
else flag = 1;
break;
case 2:/*list_isp*/
if ((strchr(fstemp, '[')) && (strchr(fstemp,
']')))
{
for (count = 0; count <
strlen(fstemp); count++)
{
if ((fstemp[count] == '[')
|| (fstemp[count] == ']'))
{
fstemp[count] =
NULL;
count++;
}
}
/* Verifica se é ou não a seção
'global' */
if (!strcmp(fstemp, "GLOBAL")
{
list[k] = (char *)
malloc(sizeof(fstemp));
strcpy(list[k], fstemp);
k++; /* Atualiza o contador
*/
}
}
break;
}
}
/* Fecha o arquivo de configurações */
fclose(conf);
switch (option)
{
case 0:
return &value;
break;
case 1:
if (flag == 0)
{
*retorno=1;
return null;
}
else
{
*retono=0;
return null;
}
break;
case 2:
return list;
break;
}
}
Amauri Albuquerque
Engenheiro de Telecomunicações
Centro de Supervisão e Controle de Rede - CSCR
Americel
329-6811
> ----- Mensagem original -----
> De: André Casteliano [SMTP:al...@br...]
> Enviada em: Sábado, 7 de Outubro de 2000 17:42
> Para: lin...@li...
> Assunto: Re: [Linuxcall] RES: [Linuxcall] Funções de acesso
> aoarq. de config.
>
> AAl...@am... wrote:
> >
> > André me manda um arquivo de configurção seu, acho que as funções podem
> > ficar mais simples se a gente usar a get_token.
>
> O arquivo tá indo em anexo... só tem hum provedor cadastrado...
>
> Como assim mais simples Amauri ???
>
> Eu tou pensando em criar funções menores cara... mais específicas... eu
> acho melhor do que uma super-função cheia de recursos... :-)
>
> Explica melhor isso aí... :-)
>
> []'s
>
> --
> André Casteliano
> Analista de Sistemas - al...@br...
> +---------------------------------------------+
> | Linux User: # 178853 Machine: # 79923 |
> | Linux Heavy User - Powered by Slackware 7.1 |
> | http://www.geocities.com/andre_casteliano/ |
> +---------------------------------------------+
> | LinuxCall - The Linux Dialer |
> | http://linuxcall.sourceforge.net |
> +---------------------------------------------+ << Arquivo: isp.conf >>
|
|
From: <AAl...@am...> - 2000-10-08 05:06:03
|
A=ED vai as fun=E7=F5es. Bom divertimento.
<<utils.c>> <<utils.h>>=20
Amauri Albuquerque
Engenheiro de Telecomunica=E7=F5es
Centro de Supervis=E3o e Controle de Rede - CSCR
Americel
329-6811
> ----- Mensagem original -----
> De: Marcelo Beckmann [SMTP:md...@ma...]
> Enviada em: Sexta-feira, 6 de Outubro de 2000 22:58
> Para: lin...@li...
> Assunto: Re: [Linuxcall] Fun=E7=F5es de acesso ao arq. de config.
>=20
> ---[ printf("Em sex, 06 out 2000, Andr=E9 Casteliano escreveu"); ]---
> // =20
> // Ol=E1 pessoal, beleza ?
> // =20
> // Essa =E9 para os programadores do projeto.
> // =20
> // Bom, baseado na fun=E7=E3o 'get_token()' que o Amauri mandou, =
criei
> pequenas
> // fun=E7=F5es que executam tarefas espec=EDficas:
>=20
> Aeeee
>=20
> Amauri &&|| Andr=E9....
>=20
> Poderia(m) mandar pra lista as fun=E7=F5es originais que o Amauri =
mandou?
>=20
>=20
> Ah, outra coisa, indenta=E7=E3o e 'estilo' do c=F3digo.
>=20
> Tipo, em vez de assim:
>=20
> while (!feof(conf))
> {
> fscanf(conf, "%s", fstemp);
>=20
> if ((strchr(fstemp, '[')) && (strchr(fstemp, ']')) &&
> (strstr(stemp, isp)))
> {
> flag =3D 0;
> break;
> }
> else flag =3D 1;
>=20
> }
>=20
>=20
>=20
> Eu prefiro assado, a la Kernighan & Ritchie:
>=20
>=20
> while (!feof(conf)) {
> fscanf(conf, "%s", fstemp);
>=20
> if ((strchr(fstemp, '[')) && (strchr(fstemp, ']'))=20
> && (strstr(stemp, isp))) {
> flag =3D 0;
> break;
> }
> else flag =3D 1;
> }
>=20
>=20
>=20
> E, para ficar mais f=E1cil, experimente(m) rodar ai:
>=20
> $ indent -kr -ts8 -i8 get_conf.c -o get_conf_kr.c
>=20
> man indent
> ---8<---
> -kr, --k-and-r-style
> Use Kernighan & Ritchie coding style.
>=20
> -tsn, --tab-sizen
> Set tab size to n spaces.
>=20
> -in, --indent-leveln
> Set indentation level to n spaces.
> ---8<--
> indent is powered.
> VI is wysiwyg.
>=20
> []s
>=20
> --=20
> Marcelo D. Beckmann - Linux User #173935
> md...@ma... - UIN 53189692
> http://marcelobeckmann.cjb.net
> .~. 233MMX 32MB 8.4+3.2GB Quantum Fireball
> /V\ OPL3SAx TGUI9680 2MB 33600 CL5 2.2.14 + Slack7 2.2.13
> /(.)\ "Estamos de volta aos tempos em que os homens eram homens
> ^`~=B4^ e programavam seus pr=F3prios drivers de dispositivo." L.T.
>=20
> Se voc=EA acha o VI complicado...
> =C9 por que nunca tentou rodar o emacs no console... sem mouse....
>=20
> emacs: n=E3o tente enviar um email com ele. voce pode se arrepender.
>=20
> (n=E3o acredito que escrevi isso, mas l=E1 VaI... heehehhe :)
> _______________________________________________
> Linuxcall-list mailing list
> Lin...@li...
> http://lists.sourceforge.net/mailman/listinfo/linuxcall-list
> Canal IRC: irc.wnet.com.br #linuxcall
> HomePage: http://linuxcall.sourceforge.net
|
|
From: C. <al...@br...> - 2000-10-07 23:33:59
|
Fala pessoal, Amauri, agora que eu fui testar as funcs de acesso ao arquivo de configuração que eu percebi cara. Ele não é no estilo do arquivo do samba por exemplo: campo = valor É assim: campo valor... Será que dá prá mudar ??? Ou então podemos deixar do jeito que tá mesmo... só que aí peremos compatibilidade com a versão em scripts... puts, é f*da... Aguardo comentários dos coders... []'s -- André Casteliano Analista de Sistemas - al...@br... +---------------------------------------------+ | Linux User: # 178853 Machine: # 79923 | | Linux Heavy User - Powered by Slackware 7.1 | | http://www.geocities.com/andre_casteliano/ | +---------------------------------------------+ | LinuxCall - The Linux Dialer | | http://linuxcall.sourceforge.net | +---------------------------------------------+ |
|
From: C. <al...@br...> - 2000-10-07 23:33:54
|
AAl...@am... wrote: > > André me manda um arquivo de configurção seu, acho que as funções podem > ficar mais simples se a gente usar a get_token. O arquivo tá indo em anexo... só tem hum provedor cadastrado... Como assim mais simples Amauri ??? Eu tou pensando em criar funções menores cara... mais específicas... eu acho melhor do que uma super-função cheia de recursos... :-) Explica melhor isso aí... :-) []'s -- André Casteliano Analista de Sistemas - al...@br... +---------------------------------------------+ | Linux User: # 178853 Machine: # 79923 | | Linux Heavy User - Powered by Slackware 7.1 | | http://www.geocities.com/andre_casteliano/ | +---------------------------------------------+ | LinuxCall - The Linux Dialer | | http://linuxcall.sourceforge.net | +---------------------------------------------+ |
|
From: C. <al...@br...> - 2000-10-07 23:33:48
|
Marcelo Beckmann wrote: > > André, > > Eu vi o seu texto, valeu ai, mas acho que dá pra melhorar. Bom, SEMPRE dá prá melhorar... :P > Como o Alex falou, existem formas de configurar o sudo para executar > apenas determinados comandos sem a utilização de senha. Eu sei cara!!! O f*da é que se for ensinar pro cara todas as configurações possíveis com o sudo é melhor escrever um HOWTO... hehehehe Tipo, dá prá melhorar o que tá lá... mas sem aprofundar muito... acho que devíamos ensinar o cara simplesmente a configurar o sudo dessas duas formas: * Executar qqer comando (com ou sem senha) * Executar APENAS o LinuxCall (com ou sem senha) > Eu tinha uma configuração dessas aqui, mas no último crash das > memórias foi tudo pro saco :( Puts... é f*da... perdeu um monte de coisa né ? > Mesmo assim, prepararei um exemplo na sequencia ensinando a > configurar o sudo apenas para uso com o linuxcall. Beleza, lê o que eu falei mais acima... :-) > Outra coisa: existe uma forma de se definir qual vai ser o editor > do sudo, dessa forma, não necessariamente o VI. Não lembro de cabeça > agora, mas já vi isso numa lista... É isso que eu tou querendo dizer cara... naum adianta aprofundar muito... afinal o objetivo é apenas explicar ao cara como executar o LinuxCall sem ter de se logar como root... No final, infome onde ele pode obter mais informações sobre o sudo: * manpage do sudo * manpage do sudoers > A vantagem do VISUDO é que ele muda automaticamente a permissão do > /etc/sudoers antes da edição, e restaura-a após a edição, dispensando > os chmod's... No VI eu simplesmente uso um ! na hora de salvar... ehehehehe > Além do que, I Like VI, hehehehhehehhehhe Me too... VI is powered!!! []'s -- André Casteliano Analista de Sistemas - al...@br... +---------------------------------------------+ | Linux User: # 178853 Machine: # 79923 | | Linux Heavy User - Powered by Slackware 7.1 | | http://www.geocities.com/andre_casteliano/ | +---------------------------------------------+ | LinuxCall - The Linux Dialer | | http://linuxcall.sourceforge.net | +---------------------------------------------+ |
|
From: C. <al...@br...> - 2000-10-07 23:33:44
|
Marcelo Beckmann wrote:
>
> Aeeee
>
> Amauri &&|| André....
>
> Poderia(m) mandar pra lista as funções originais que o Amauri mandou?
Ok. Tão indo em anexo...
> Ah, outra coisa, indentação e 'estilo' do código.
>
> Tipo, em vez de assim:
>
> while (!feof(conf))
> {
> fscanf(conf, "%s", fstemp);
>
> if ((strchr(fstemp, '[')) && (strchr(fstemp, ']')) && (strstr(stemp, isp)))
> {
> flag = 0;
> break;
> }
> else flag = 1;
>
> }
>
> Eu prefiro assado, a la Kernighan & Ritchie:
>
> while (!feof(conf)) {
> fscanf(conf, "%s", fstemp);
>
> if ((strchr(fstemp, '[')) && (strchr(fstemp, ']'))
> && (strstr(stemp, isp))) {
> flag = 0;
> break;
> }
> else flag = 1;
> }
>
> E, para ficar mais fácil, experimente(m) rodar ai:
>
> $ indent -kr -ts8 -i8 get_conf.c -o get_conf_kr.c
--------------->8================[corta]
cara, eu prefiro o MEU estilo... hehehehe
Sem brincadeira... eu acho mais fácil de ler o código daquele jeito que
eu mandei... tipow, com mais espaços entre as linhas... sem falar que
fica melhor para inserir comentários...
Só vou mudar o número de espaços que corresponde a um <TAB>... prá naum
ficar tão largo o código...
> VI is wysiwyg.
VI: What You See Is What You Get!!! I see Text. I get Text. :-)
[]'s
--
André Casteliano
Analista de Sistemas - al...@br...
+---------------------------------------------+
| Linux User: # 178853 Machine: # 79923 |
| Linux Heavy User - Powered by Slackware 7.1 |
| http://www.geocities.com/andre_casteliano/ |
+---------------------------------------------+
| LinuxCall - The Linux Dialer |
| http://linuxcall.sourceforge.net |
+---------------------------------------------+ |
|
From: Alex B. <ne...@za...> - 2000-10-07 06:08:52
|
Marcelo Beckmann wrote: > bom, se o erro fosse expansão do parametro pelo bash, ou coisa assim, > tudo bem... > o que eu não entendo é: > como é que o grep está pegando com parâmetro o que eu digitei??? Simples meu caro amigo... O alias funciona literalmente como um apelido. O bash substitui o alias pelo comando em si, nada mais. no seu caso: alias lsd='l $1 | grep /' lsd ~/ o ultimo comando é a mesma coisa que: l $1 | grep / ~/ Sacou ?? ele substitui a palavra lsd pelo comando armazenado e joga as opções depois... No caso, a variavel $1 só funciona pra scripts.. nesse caso ela vai ser vazia e o seu comando se torna: l | grep / ~/ que vai gerar aquele erro... Acho que a melhor saida ai seria fazer um scriptzinho em vez do alias e colocar no seu path... pronto... té mais... > > -- > Marcelo D. Beckmann - Linux User #173935 > md...@ma... - UIN 53189692 > http://marcelobeckmann.cjb.net > .~. 233MMX 32MB 8.4+3.2GB Quantum Fireball > /V\ OPL3SAx TGUI9680 2MB 33600 CL5 2.2.14 + Slack7 2.2.13 > /(.)\ "Estamos de volta aos tempos em que os homens eram homens > ^`~´^ e programavam seus próprios drivers de dispositivo." L.T. > _______________________________________________ > Linuxcall-list mailing list > Lin...@li... > http://lists.sourceforge.net/mailman/listinfo/linuxcall-list > Canal IRC: irc.wnet.com.br #linuxcall > HomePage: http://linuxcall.sourceforge.net -- /------------------------------ \ ____ | Alex Borro - Neo-Linux_Inside | \ \ | Faculdade de Engenharia | |\ >>\ \> | Mecatrônica - UNICAMP |----| \_____\ \_______ >-------------------------------< | L I N U X \ | Powered By LINUX SLACKWARE 7.1|----|________ _______/ | Kernel 2.2.16 User: 164956 | / / | e-mail: ne...@ya... | >>/ /> \-------------------------------/ /___/ The box said "Requeries Windows 9x, Windows NT 4, or better", so I installed Linux. |
