linuxcall-list

[Linuxcall] GLOBAL section...

[C. <dig...@us...>]

Eae pessoal, tudo beleza ?

Tava aki implementando os trecos da nova interface e da futura versão em
C do LinuxCall quando me ocorreu o seguinte: unificação dos arkivos de
configuração.

Não sei se vocês já repararam, mas na versão em Bash script feita pelo
Alex, faz-se uso de vários arkivos de configuração... um pros paths,
etc, outro pros provedores, exemplos do options e dos ifup...

Poderíamos colocar todas as informações que hoje estão em arkivos
separados na seção 'GLOBAL' desse arkivo unificado. E no programa,
poderíamos criar uma struct personalizada prá essa seção.

Bom, sugiro que passemos a utilizar um _único_ arquivo de configuração,
a ser localizado em ~/.linuxcallrc, ou seja, no home do usuário... isso
nos leva de volta à velha discussão sobre o programa ser multiusuário ou
monousuário. 

Gostaria da opinião de vocês a respeito.

E mesmo que decidamos pelo programa monousuário, ainda assim sugiro a
unificação dos arkivos de configuração, que passaria a ficar localizado
em /etc/linuxcall.conf, como é padrão do sistema.

O que acham ?

[]'s

-- 
André Casteliano
Analista de Sistemas

+-=-=[ dig...@us...]=-=-+
[ 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       ]
+-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+

Re: [Linuxcall] GLOBAL section...

[shellbh <sh...@br...>]

oi
acho que ele pode ser "mono e multi" ao mesmo tempo
tipo que tenha um arquivo em /etc/linuxcall.conf onde teria todas as
configuracoes, mas se determinado usuario quisse ter um configuracao
opcional ele bastaria criar um arquivo .linuxcallrc no seu home
pois isso é feito por muitos programas, um deles que me vem a cabeca é o
wget
tem o arquivo /etc/wgetrc e ~/.wgetrc

t+
leoserra

X-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-X
|    Linux Conectiva Edicao Servidor 5.1    |
|Kernel 2.2.16                   User 172791|
|              UIN: 45066512                |
X-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-X


On Mon, 6 Nov 2000, André Casteliano wrote:

> Date: Mon, 06 Nov 2000 22:32:53 -0200
> From: André Casteliano <dig...@us...>
> Reply-To: lin...@li...
> To: Lista LinuxCall <lin...@li...>
> Subject: [Linuxcall] GLOBAL section...
> 
> Eae pessoal, tudo beleza ?
> 
> Tava aki implementando os trecos da nova interface e da futura versão em
> C do LinuxCall quando me ocorreu o seguinte: unificação dos arkivos de
> configuração.
> 
> Não sei se vocês já repararam, mas na versão em Bash script feita pelo
> Alex, faz-se uso de vários arkivos de configuração... um pros paths,
> etc, outro pros provedores, exemplos do options e dos ifup...
> 
> Poderíamos colocar todas as informações que hoje estão em arkivos
> separados na seção 'GLOBAL' desse arkivo unificado. E no programa,
> poderíamos criar uma struct personalizada prá essa seção.
> 
> Bom, sugiro que passemos a utilizar um _único_ arquivo de configuração,
> a ser localizado em ~/.linuxcallrc, ou seja, no home do usuário... isso
> nos leva de volta à velha discussão sobre o programa ser multiusuário ou
> monousuário. 
> 
> Gostaria da opinião de vocês a respeito.
> 
> E mesmo que decidamos pelo programa monousuário, ainda assim sugiro a
> unificação dos arkivos de configuração, que passaria a ficar localizado
> em /etc/linuxcall.conf, como é padrão do sistema.
> 
> O que acham ?
> 
> []'s
> 
> -- 
> André Casteliano
> Analista de Sistemas
> 
> +-=-=[ dig...@us...]=-=-+
> [ 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       ]
> +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+
> 
> 
> _______________________________________________
> 
> Linuxcall-list mailing list
> 
> Lin...@li...
> 
> http://lists.sourceforge.net/mailman/listinfo/linuxcall-list
> 
> Canais IRC: irc.wnet.com.br  #linuxcall
>             irc.matrix.com.br  #linuxcall
> HomePage: http://linuxcall.sourceforge.net
> 

Re: [Linuxcall] GLOBAL section...

[Alex B. <ne...@za...>]

sim, é uma otima ideia...

shellbh wrote:
> 
> oi
> acho que ele pode ser "mono e multi" ao mesmo tempo
> tipo que tenha um arquivo em /etc/linuxcall.conf onde teria todas as
> configuracoes, mas se determinado usuario quisse ter um configuracao
> opcional ele bastaria criar um arquivo .linuxcallrc no seu home
> pois isso é feito por muitos programas, um deles que me vem a cabeca é o
> wget
> tem o arquivo /etc/wgetrc e ~/.wgetrc
> 
> t+
> leoserra
> 
> X-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-X
> |    Linux Conectiva Edicao Servidor 5.1    |
> |Kernel 2.2.16                   User 172791|
> |              UIN: 45066512                |
> X-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-X
> 
> On Mon, 6 Nov 2000, André Casteliano wrote:
> 
> > Date: Mon, 06 Nov 2000 22:32:53 -0200
> > From: André Casteliano <dig...@us...>
> > Reply-To: lin...@li...
> > To: Lista LinuxCall <lin...@li...>
> > Subject: [Linuxcall] GLOBAL section...
> >
> > Eae pessoal, tudo beleza ?
> >
> > Tava aki implementando os trecos da nova interface e da futura versão em
> > C do LinuxCall quando me ocorreu o seguinte: unificação dos arkivos de
> > configuração.
> >
> > Não sei se vocês já repararam, mas na versão em Bash script feita pelo
> > Alex, faz-se uso de vários arkivos de configuração... um pros paths,
> > etc, outro pros provedores, exemplos do options e dos ifup...
> >
> > Poderíamos colocar todas as informações que hoje estão em arkivos
> > separados na seção 'GLOBAL' desse arkivo unificado. E no programa,
> > poderíamos criar uma struct personalizada prá essa seção.
> >
> > Bom, sugiro que passemos a utilizar um _único_ arquivo de configuração,
> > a ser localizado em ~/.linuxcallrc, ou seja, no home do usuário... isso
> > nos leva de volta à velha discussão sobre o programa ser multiusuário ou
> > monousuário.
> >
> > Gostaria da opinião de vocês a respeito.
> >
> > E mesmo que decidamos pelo programa monousuário, ainda assim sugiro a
> > unificação dos arkivos de configuração, que passaria a ficar localizado
> > em /etc/linuxcall.conf, como é padrão do sistema.
> >
> > O que acham ?
> >
> > []'s
> >
> > --
> > André Casteliano
> > Analista de Sistemas
> >
> > +-=-=[ dig...@us...]=-=-+
> > [ 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       ]
> > +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+
> >
> >
> > _______________________________________________
> >
> > Linuxcall-list mailing list
> >
> > Lin...@li...
> >
> > http://lists.sourceforge.net/mailman/listinfo/linuxcall-list
> >
> > Canais IRC: irc.wnet.com.br  #linuxcall
> >             irc.matrix.com.br  #linuxcall
> > HomePage: http://linuxcall.sourceforge.net
> >
> 
> _______________________________________________
> 
> Linuxcall-list mailing list
> 
> Lin...@li...
> 
> http://lists.sourceforge.net/mailman/listinfo/linuxcall-list
> 
> Canais IRC: irc.wnet.com.br  #linuxcall
>             irc.matrix.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.

Re: [Linuxcall] GLOBAL section...

[Alex B. <ne...@za...>]

Eu acho que não pode ser multi-usuários, pois usuário comuns (não-root)
não podem efetuar conexões sem a permissão do root. Por isso só o root
configuraria os provedores para os quais o sistema pode discar. Olhem o
pppd e vejam como ele trata esse assunto.... é bem restrito. Exatamente
para reforçar a segurança do sistema.
Bom, essa é minha opnião..

té mais...


André Casteliano wrote:
> 
> Eae pessoal, tudo beleza ?
> 
> Tava aki implementando os trecos da nova interface e da futura versão em
> C do LinuxCall quando me ocorreu o seguinte: unificação dos arkivos de
> configuração.
> 
> Não sei se vocês já repararam, mas na versão em Bash script feita pelo
> Alex, faz-se uso de vários arkivos de configuração... um pros paths,
> etc, outro pros provedores, exemplos do options e dos ifup...
> 
> Poderíamos colocar todas as informações que hoje estão em arkivos
> separados na seção 'GLOBAL' desse arkivo unificado. E no programa,
> poderíamos criar uma struct personalizada prá essa seção.
> 
> Bom, sugiro que passemos a utilizar um _único_ arquivo de configuração,
> a ser localizado em ~/.linuxcallrc, ou seja, no home do usuário... isso
> nos leva de volta à velha discussão sobre o programa ser multiusuário ou
> monousuário.
> 
> Gostaria da opinião de vocês a respeito.
> 
> E mesmo que decidamos pelo programa monousuário, ainda assim sugiro a
> unificação dos arkivos de configuração, que passaria a ficar localizado
> em /etc/linuxcall.conf, como é padrão do sistema.
> 
> O que acham ?
> 
> []'s
> 
> --
> André Casteliano
> Analista de Sistemas
> 
> +-=-=[ dig...@us...]=-=-+
> [ 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       ]
> +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+
> 
> _______________________________________________
> 
> Linuxcall-list mailing list
> 
> Lin...@li...
> 
> http://lists.sourceforge.net/mailman/listinfo/linuxcall-list
> 
> Canais IRC: irc.wnet.com.br  #linuxcall
>             irc.matrix.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.

Re: [Linuxcall] GLOBAL section...

[Marcelo B. <md...@ma...>]

---[ printf("Em qua, 08 nov 2000, Alex Borro escreveu"); ]---
# Eu acho que não pode ser multi-usuários, pois usuário comuns (não-root)
# não podem efetuar conexões sem a permissão do root. Por isso só o root
# configuraria os provedores para os quais o sistema pode discar. Olhem o
# pppd e vejam como ele trata esse assunto.... é bem restrito. Exatamente
# para reforçar a segurança do sistema.
# Bom, essa é minha opnião..
# 
# té mais...
# 
# 

Alex, voce esta me parecendo meio contraditorio, pois num email
anterior seu, respondendo ao leoserra, voce parecia concordar com
isso:

------------8<-------------------
sim, é uma otima ideia...

shellbh wrote:
> 
> oi
> acho que ele pode ser "mono e multi" ao mesmo tempo
> tipo que tenha um arquivo em /etc/linuxcall.conf onde teria todas as
> configuracoes, mas se determinado usuario quisse ter um configuracao
> opcional ele bastaria criar um arquivo .linuxcallrc no seu home
> pois isso é feito por muitos programas, um deles que me vem a cabeca é o
> wget
> tem o arquivo /etc/wgetrc e ~/.wgetrc
--------------8<-------------------

Acho que devemos sempre alertar quanto a questão de segurança, mas a
escolha final de como proceder deve ser do usuário. Um exemplo disso
é o kppp, que permite que o usuário comum faça as suas configurações.

Para rodar o programa, o usuário pode escolher entre bit SUID, sudo,
su, logar como root, etc, de acordo como melhor lhe convier.

No kppp existe também um esquema de fork, que eu com o Andre já
conversamos bastante ha algum tempo. Tipo, o kppp starta como root,
e faz um fork. Dessa forma, ele roda apenas o que for necessário como
root (pppd, edição do resolv.conf...), e as demais partes (interface
gráfica e etc) rodam com poderes de usuário comum.

Eu particularmente acho desagradável ter que rodar todo o X com
poderes de root, ou ter que abrir excessivamente o xhost para poder
rodar um programa em X como root.

Claro, segurança é segurança, mas podemos pensar tb em dar
flexibilidade e _informação_ sobre as várias alternativas possíveis
de se rodar o programa e suas respectivas implicações quanto a
segurança, cabendo a escolha final ao usuário.

É apenas um ponto de vista sobre o assunto. Eu posso estar errado, e
até por isso mesmo gostaria de discutir mais sobre isso, a nível de
implementação do código, junto com vocês, para que possamos adotar a
melhor solução.

Abraços,

-- 
#=-=[  ser...@us...  ]=-=+=#=--------------=#
|  Marcelo D. Beckmann  --user[]="#173935"--  | |     CL5 2.2.14
| md...@ma...     UIN [53189692]----+ | Slack 7 2.2.13
#  - =-#--=[ http://marcelobeckmann.cjb.net ]=--#-==-==-==-==-==-#
+ .~.  |                  233MMX 32MB 8.4+3.2GB Quantum Fireball ]
  /V\  #------------------466.94----[ OPL3SAx TGUI9680 2MB 33600 ]
 /(.)\ "Estamos de volta aos tempos em que os homens eram homens ]
 ^`~´^  e programavam seus próprios drivers de dispositivo."L.T. ]
#-====-#----=[ serialcoder ]=- + -=[ http://wm.themes.org ]=-----'
RTS-[CTS]-DLE-STX-17-39-35-CRC-F6-66-DLE-ETX-/RTS-[/CTS-RTS]-CTS-[ACK]

Re: [Linuxcall] GLOBAL section...

[C. <dig...@us...>]

Marcelo Beckmann wrote:
> 
> Acho que devemos sempre alertar quanto a questão de segurança, mas a
> escolha final de como proceder deve ser do usuário. Um exemplo disso
> é o kppp, que permite que o usuário comum faça as suas configurações.

Quanto mais opções o usuário tiver, melhor...

> Para rodar o programa, o usuário pode escolher entre bit SUID, sudo,
> su, logar como root, etc, de acordo como melhor lhe convier.

Exatamente...

> No kppp existe também um esquema de fork, que eu com o Andre já
> conversamos bastante ha algum tempo. Tipo, o kppp starta como root,
> e faz um fork. Dessa forma, ele roda apenas o que for necessário como
> root (pppd, edição do resolv.conf...), e as demais partes (interface
> gráfica e etc) rodam com poderes de usuário comum.

Boa lembrar disso cara, estive pesquisando mais um pouco os fontes do
kppp... :) Eles têm algumas rotinas interessantes... mando depois prá
lista com comentários... :)

> Eu particularmente acho desagradável ter que rodar todo o X com
> poderes de root, ou ter que abrir excessivamente o xhost para poder
> rodar um programa em X como root.

Isso é horrível... detesto o xhost...

> Claro, segurança é segurança, mas podemos pensar tb em dar
> flexibilidade e _informação_ sobre as várias alternativas possíveis
> de se rodar o programa e suas respectivas implicações quanto a
> segurança, cabendo a escolha final ao usuário.

Parece que vc leu meus pensamentos... hehehe

Estou elaborando um esquema interessante prá versão em pure C que será
exatamente assim... Uma espécie de menu "Advanced" onde inclusive o
usuário poderá setar localização de arquivos, e coisas mais "baixo
nível" como formas de acesso ao kernel... (eu naum estou brincando... )
:P

> É apenas um ponto de vista sobre o assunto. Eu posso estar errado, e
> até por isso mesmo gostaria de discutir mais sobre isso, a nível de
> implementação do código, junto com vocês, para que possamos adotar a
> melhor solução.

Ok. Se não me engano, já mandei um mail prá lista dizendo isso... :)
Tipo, precisamos de alguém que conheça o pppd, o chat, os modems, e não
exatamente de programação... 

A parte de implementação (código) é relativamente fácil de fazer, temos
exemplos tb, etc... O que tá pesando é a lógica, talvez até por isso eu
ainda naum tenha conseguido concluir um BETA da versão em pure C...

Precisamos de alguém que manje dos parâmetros do pppd, seus retornos,
etc, para podermos implementar esse front-end (exatamente, nosso
programa é um front-end pro pppd, assim como o kppp).

Agora vem a melhor parte: Nós JÁ temos uma pessoa assim! O Alex... 
Alex, precisamos de um doc explicando o básico do básico prá podermos
começar a implementação dessa versão em pure C...

Tipo, de onde vem akeles retornos (NO CARRIER, BUSY, NODIALTONE, etc)
??? Do pppd ??? Do chat ??? do modem ??? :P

O chat é usado prá autenticação ??? Como implementar conexão chat, além
da PAP, etc... espero que esteja me entendendo... :)

Andei dando uma olhada nos scripts, e infelizmente não está muito bem
documentado internamente... :)

Se for possível prá vc agilizar isso ae... :)

[]'s

-- 
André Casteliano
Analista de Sistemas

+-=-=[ dig...@us...]=-=-+
[ 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       ]
+-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+

Re: [Linuxcall] GLOBAL section...

[Marcelo B. <md...@ma...>]

---[ printf("Em qui, 09 nov 2000, André Casteliano escreveu"); ]---
# Estou elaborando um esquema interessante prá versão em pure C que será
# exatamente assim... Uma espécie de menu "Advanced" onde inclusive o
# usuário poderá setar localização de arquivos, e coisas mais "baixo
# nível" como formas de acesso ao kernel... (eu naum estou brincando... )
# :P

E eu vou lá achar que você está brincando? mas nem de longe, eu te
conheço, coder do jeito que é, vai logo se empolgando em abrir
fontes e cair no núcleo do código :)

Volta e meia eu ando pensando na versão "Pure C" pra console do
LinuxCall. Há uns tempos atrás tive contato com ncurses. No momento,
lá no trampo, estou mexendo com newt, e em casa, baixei a uconio
(Unix conio, um porte pra unix da lib conio do DOS). Acho que essas
experiências que estou tendo serão válidas pra implementação Pure C,
então, oportunamente, estarei escrevendo um artigo massa sobre tudo
isso. 

Hum... agora mesmo acabou de me bater uma idéia....  Tipo, no
site do projeto tem uma seção desenvolvedores...  Que tal a gente
começar a povoar esse espaço com artigos sobre programação, links,
experiências nossas, papos do irc que rolaram (e ainda vão rolar)
sobre o desenvolvimento do projeto? Acho que uma seção desse tipo
seria massa, e, de quebra, o site do projeto poderia ganhar com isso
um grande diferencial, de não apenas hospedar o programa LinuxCall,
mas sim, ser referencia para coisas ligadas a programação,
aspectos relacionados a conexão com internet, relatos e impressões
pessoais sobre a experiencia do desenvolvimento de um projeto open
source gpl como o nosso, enfim, como diz o André, agitarrrrr, fazer
algo diferente, inovador, revolucionário, wow, me empolguei mesmo....

Nossa, me lembrei agora daquela madrugada de sexta pra sabado, em que
eu o André e o Amauri ficamos das 3 da madruga até as 10 da manha em
conferencia telefonica, estavamos rodando as primeiras versões do
script do Alex (a tal da imcompatibilidade entre as versões do bash,
conectiva x slackware, heheheeh) , debugando a primeira implementação
da interface que o André tinha feito em XStep... aquilo foi muito
massa...  depois daquele dia, as coisas assumiram uma nova dimensão...

ôôô lugar, ôôô saudosismo...


# A parte de implementação (código) é relativamente fácil de fazer, temos
# exemplos tb, etc... O que tá pesando é a lógica, talvez até por isso eu
# ainda naum tenha conseguido concluir um BETA da versão em pure C...

Até por que há um tempo atrás a gente conversava muito pela net sobre
isso....  putz, existem infinitas formas de implementação, a cada
conversa pintam novas idéias. A gente tem visto fontes do kppp e do
wvdial, tentando ver o que já foi implementado, o que é bom, o que se
deve evitar...

# Precisamos de alguém que manje dos parâmetros do pppd, seus retornos,
# etc, para podermos implementar esse front-end (exatamente, nosso
# programa é um front-end pro pppd, assim como o kppp).
# 
# Agora vem a melhor parte: Nós JÁ temos uma pessoa assim! O Alex... 
# Alex, precisamos de um doc explicando o básico do básico prá podermos
# começar a implementação dessa versão em pure C...

Alex, se você puder dar uma força ai seria uma ótima...

Tipo, você manja bastante disso, eu de pppd e chat já li bastante,
entendo como funciona, mas nunca cheguei a brincar mais
profundamente com a coisa.

# Tipo, de onde vem akeles retornos (NO CARRIER, BUSY, NODIALTONE, etc)
# ??? Do pppd ??? Do chat ??? do modem ??? :P

Creio que vem primeiramente do modem. Quem cuida da discagem e
tratamento das coisas nesse processo é o chat, que por sua vez é
chamado pelo pppd. Confere? Ou falei m*rda? hehehhehe 

Agora, interfacear tudo isso com C, ai é outro papo...

Existem tantas alternativas, forks, pipes, execve's, system's... 
Qual o rumo a tomar? Quais as vantagens e desvantagens? eis uma boa
pergunta...

# O chat é usado prá autenticação ??? Como implementar conexão chat, além
# da PAP, etc... espero que esteja me entendendo... :)

Tai, bem lembrado...  até agora só pensei em PAP, mas existem outras
formas de autenticação...   hum...   vamos ter que correr atras.

# Andei dando uma olhada nos scripts, e infelizmente não está muito bem
# documentado internamente... :)

Documentação: as vezes sacal, mas necessária. Se precisar de ajuda,
e puder guentar +- uma semana, tou nessa.

Abração ai companheiros,

-- 
#=-=[  ser...@us...  ]=-=+=#=--------------=#
|  Marcelo D. Beckmann  --user[]="#173935"--  | |     CL5 2.2.14
| md...@ma...     UIN [53189692]----+ | Slack 7 2.2.13
#  - =-#--=[ http://marcelobeckmann.cjb.net ]=--#-==-==-==-==-==-#
+ .~.  |                  233MMX 32MB 8.4+3.2GB Quantum Fireball ]
  /V\  #------------------466.94----[ OPL3SAx TGUI9680 2MB 33600 ]
 /(.)\ "Estamos de volta aos tempos em que os homens eram homens ]
 ^`~´^  e programavam seus próprios drivers de dispositivo."L.T. ]
#-====-#----=[ serialcoder ]=- + -=[ http://wm.themes.org ]=-----'
RTS-[CTS]-DLE-STX-17-39-35-CRC-F6-66-DLE-ETX-/RTS-[/CTS-RTS]-CTS-[ACK]

Re: [Linuxcall] GLOBAL section...

[C. <dig...@us...>]

Marcelo Beckmann wrote:
> 
> Volta e meia eu ando pensando na versão "Pure C" pra console do
> LinuxCall. Há uns tempos atrás tive contato com ncurses. No momento,
> lá no trampo, estou mexendo com newt, e em casa, baixei a uconio
> (Unix conio, um porte pra unix da lib conio do DOS). Acho que essas
> experiências que estou tendo serão válidas pra implementação Pure C,
> então, oportunamente, estarei escrevendo um artigo massa sobre tudo
> isso.

Cara, eu já fiz umas experiências com essa UNIX Conio... prá te falar a
verdade, não gostei... 
A versão que eu peguei não acessava diretamente a tela, como o ncurses
ou newt. Ele era um front-end para a ncurses e deu muito pau aki...
Andei lendo novamente akelas xerox que o Amauri mandou, e mais alguns
trecos sobre curses... curses é fácil mano! Dá prá fazer sem
problemas... e como vc tá mexendo com newt no teu trampo, porque não
fazemos em newt então ???

> Hum... agora mesmo acabou de me bater uma idéia....  Tipo, no
> site do projeto tem uma seção desenvolvedores...  Que tal a gente
> começar a povoar esse espaço com artigos sobre programação, links,
> experiências nossas, papos do irc que rolaram (e ainda vão rolar)
> sobre o desenvolvimento do projeto? Acho que uma seção desse tipo
> seria massa, e, de quebra, o site do projeto poderia ganhar com isso
> um grande diferencial, de não apenas hospedar o programa LinuxCall,
> mas sim, ser referencia para coisas ligadas a programação,
> aspectos relacionados a conexão com internet, relatos e impressões
> pessoais sobre a experiencia do desenvolvimento de um projeto open
> source gpl como o nosso, enfim, como diz o André, agitarrrrr, fazer
> algo diferente, inovador, revolucionário, wow, me empolguei mesmo....

Essa é uma ótima idéia... se não me engano eu já havia dado uma sugestão
dessas há algum teeemmpoooooo..... :)

Fazer da page um local onde a pessoa visite frequentemente, não só pra
saber se tem nova versão do programa, mas tb prá ver as novidades,
documentação, ver o FAQ... cês tão entendendo ? ;-)

Tenho bastante documentação aki sobre IPC em UNIX, CVS, etc... vou
procurar os links aki prá por como referência e na sequência mando pro
Davi por na page... seção 'Colaborador' ou seção 'Documentação' ???

> # A parte de implementação (código) é relativamente fácil de fazer, temos
> # exemplos tb, etc... O que tá pesando é a lógica, talvez até por isso eu
> # ainda naum tenha conseguido concluir um BETA da versão em pure C...
> 
> Até por que há um tempo atrás a gente conversava muito pela net sobre
> isso....  putz, existem infinitas formas de implementação, a cada
> conversa pintam novas idéias. A gente tem visto fontes do kppp e do
> wvdial, tentando ver o que já foi implementado, o que é bom, o que se
> deve evitar...

Pois é mano, tem algumas coisas que eu vi nos fontes do kppp e tal que
eu não gostei... :)

A gente melhora as rotinas no LinuxCall... ;-)

> # Precisamos de alguém que manje dos parâmetros do pppd, seus retornos,
> # etc, para podermos implementar esse front-end (exatamente, nosso
> # programa é um front-end pro pppd, assim como o kppp).
> #
> # Agora vem a melhor parte: Nós JÁ temos uma pessoa assim! O Alex...
> # Alex, precisamos de um doc explicando o básico do básico prá podermos
> # começar a implementação dessa versão em pure C...
> 
> Alex, se você puder dar uma força ai seria uma ótima...
> 
> Tipo, você manja bastante disso, eu de pppd e chat já li bastante,
> entendo como funciona, mas nunca cheguei a brincar mais
> profundamente com a coisa.

É isso que tá pegando pro meu lado... Pq acesso ao modem é contigo,
"encapsulação" do pppd, fork, etc, pode deixar que eu faço... :)

Vou dar uma lida no PPP-HowTo... :P

> # Tipo, de onde vem akeles retornos (NO CARRIER, BUSY, NODIALTONE, etc)
> # ??? Do pppd ??? Do chat ??? do modem ??? :P
> 
> Creio que vem primeiramente do modem. Quem cuida da discagem e
> tratamento das coisas nesse processo é o chat, que por sua vez é
> chamado pelo pppd. Confere? Ou falei m*rda? hehehhehe

Puts, eu achava o seguinte: que o pppd fazia a discagem, e usava o chat
prá autenticar, etc... mas agora, percebo que o pppd faz às vezes com o
kernel, roteamento e tal... hum... interessante!!! 

Tou no aguardo de mais informações do Alex a respeito... :P

> Agora, interfacear tudo isso com C, ai é outro papo...
> 
> Existem tantas alternativas, forks, pipes, execve's, system's...
> Qual o rumo a tomar? Quais as vantagens e desvantagens? eis uma boa
> pergunta...

Calma mano... cê tá pensando muito lá prá frente... heheheh

Tipo, concentre-se no problema atual: arkivo. Resolva e parta pro
próximo... :)

Fazendo dessa forma já consegui implementar algumas coisas por aki... no
teu caso, seria interessante se vc fizesse as rotinas de
tratamento/localização do modem... :)

Rotinas essas que poderiam ser usadas tb nessa versão da interface
atual... porque não ?

> # O chat é usado prá autenticação ??? Como implementar conexão chat, além
> # da PAP, etc... espero que esteja me entendendo... :)
> 
> Tai, bem lembrado...  até agora só pensei em PAP, mas existem outras
> formas de autenticação...   hum...   vamos ter que correr atras.

É... a gente tem que ver tudo isso... heeheheheheh

> # Andei dando uma olhada nos scripts, e infelizmente não está muito bem
> # documentado internamente... :)
> 
> Documentação: as vezes sacal, mas necessária. Se precisar de ajuda,
> e puder guentar +- uma semana, tou nessa.

Com certeza... enquanto isso vou aki me virando com as listas
encadeadas, acesso a arkivos e muitos ponteiros bêbados.... hehehehe

Falous pessoal, vamos lá... tá ficando muito massa... hehehehe

[]'s

-- 
André Casteliano
Analista de Sistemas

+-=-=[ dig...@us...]=-=-+
[ 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       ]
+-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+

[Linuxcall] =?ISO-8859-1?Q?Documenta=E7=E3o_e_CVS?=

[Nelson C. de T. F. <nf...@in...>]

> # Andei dando uma olhada nos scripts, e infelizmente não está muito bem
> # documentado internamente... :)
> 
> Documentação: as vezes sacal, mas necessária. Se precisar de ajuda,
> e puder guentar +- uma semana, tou nessa.

Só como curiosidade, alguém já ouviu falar de "literate programming"? É um
método interessante, no qual a documentação e o código do programa são
intercalados... quem quiser saber mais pode dar uma olhada no links:

http://www-cs-faculty.stanford.edu/~knuth/cweb.html
http://shelob.ce.ttu.edu/daves/lpfaq/faq.html

Por outro lado, seria interessante começarmos a usar o CVS do SourceForge
para armazenar todo o histórico do projeto, consolidando as mudanças
realizadas por todos os desenvolvedores automaticamente.

[]s

Nelson

__________________________________________________________________
Nelson Ferraz                           Insite - Solucoes Internet
e-mail: nf...@in...           http://www.insite.com.br/

Re: [Linuxcall] =?ISO-8859-1?Q?Documenta=E7=E3o_e_CVS?=

[Nelson C. de T. F. <nf...@in...>]

> Só como curiosidade, alguém já ouviu falar de "literate programming"? É um
> método interessante, no qual a documentação e o código do programa são
> intercalados... quem quiser saber mais pode dar uma olhada no links:
> 
> http://www-cs-faculty.stanford.edu/~knuth/cweb.html
> http://shelob.ce.ttu.edu/daves/lpfaq/faq.html

Aqui vai mais um link sobre Literate Programming:

http://www.literateprogramming.com/

Entre outras coisas interessantes, vocês encontrarão uma versão do antigo
jogo "Adventure", de 1975, em formato PDF. Just for fun. :-)

[]s

Nelson

__________________________________________________________________
Nelson Ferraz                           Insite - Solucoes Internet
e-mail: nf...@in...           http://www.insite.com.br/

Re: [Linuxcall] Documentação e CVS

[Marcelo B. <md...@ma...>]

---[ printf("Em sex, 10 nov 2000, Nelson Correa de Toledo Ferraz escreveu"); ]---
# Só como curiosidade, alguém já ouviu falar de "literate programming"? É um
# método interessante, no qual a documentação e o código do programa são
# intercalados... quem quiser saber mais pode dar uma olhada no links:

Seria algo como inserir a documentação em forma de comentários no
meio do código? Se for isso, legal, acho que isso quebra um galhão.

# http://www-cs-faculty.stanford.edu/~knuth/cweb.html
# http://shelob.ce.ttu.edu/daves/lpfaq/faq.html

Vou dar uma olhada na sequencia, valeu ai pela indicação dos links.

# Por outro lado, seria interessante começarmos a usar o CVS do SourceForge
# para armazenar todo o histórico do projeto, consolidando as mudanças
# realizadas por todos os desenvolvedores automaticamente.

Olha Nelson, é isso mesmo. Teve uma época que bateu o maior gaz sobre
isso, mas acabou pintando outras coisas no meio do caminho e acabamos
não botando em prática. Mas que isso é importantíssimo isso é com
certeza. O CVS ajuda muito a organizar as coisas. Já passou da hora
da gente começar a usar ele, vamos tentar dar um gaz de novo nisso ai.

Forte abraço ai,



-- 
#=-=[  ser...@us...  ]=-=+=#=--------------=#
|  Marcelo D. Beckmann  --user[]="#173935"--  | |     CL5 2.2.14
| md...@ma...     UIN [53189692]----+ | Slack 7 2.2.13
#  - =-#--=[ http://marcelobeckmann.cjb.net ]=--#-==-==-==-==-==-#
+ .~.  |                  233MMX 32MB 8.4+3.2GB Quantum Fireball ]
  /V\  #------------------466.94----[ OPL3SAx TGUI9680 2MB 33600 ]
 /(.)\ "Estamos de volta aos tempos em que os homens eram homens ]
 ^`~´^  e programavam seus próprios drivers de dispositivo."L.T. ]
#-====-#----=[ serialcoder ]=- + -=[ http://wm.themes.org ]=-----'
RTS-[CTS]-DLE-STX-17-39-35-CRC-F6-66-DLE-ETX-/RTS-[/CTS-RTS]-CTS-[ACK]

gcc: vitamina C pura!

[Linuxcall] =?ISO-8859-1?Q?Re=3A_=5BLinuxcall=5D_Documenta=E7=E3o_e_CVS?=

[Nelson C. de T. F. <nf...@in...>]

> # Só como curiosidade, alguém já ouviu falar de "literate programming"? É um
> # método interessante, no qual a documentação e o código do programa são
> # intercalados... quem quiser saber mais pode dar uma olhada no links:
> 
> Seria algo como inserir a documentação em forma de comentários no
> meio do código? Se for isso, legal, acho que isso quebra um galhão.

Eh isso e muito mais. A ideia eh que voce organize o programa como se
estivesse escrevendo um artigo, misturando texto e codigo, de modo que 
voce nao precisa ordenar o programa segundo a logica do computador.

> O CVS ajuda muito a organizar as coisas. Já passou da hora
> da gente começar a usar ele, vamos tentar dar um gaz de novo nisso ai.

Legal. O primeiro passo eh verificar quem tem a versao mais atualizada do
LinuxCall, e mandar para o repositorio com o comando cvs import.

[]s

Nelson

__________________________________________________________________
Nelson Ferraz                           Insite - Solucoes Internet
e-mail: nf...@in...           http://www.insite.com.br/

Re: [Linuxcall] Re: [Linuxcall] =?iso-8859-1?Q?Documenta=E7=E3o?= e CVS

[C. <dig...@us...>]

Nelson Correa de Toledo Ferraz wrote:
> 
> > # Só como curiosidade, alguém já ouviu falar de "literate programming"? É um
> > # método interessante, no qual a documentação e o código do programa são
> > # intercalados... quem quiser saber mais pode dar uma olhada no links:
> >
> > Seria algo como inserir a documentação em forma de comentários no
> > meio do código? Se for isso, legal, acho que isso quebra um galhão.
> 
> Eh isso e muito mais. A ideia eh que voce organize o programa como se
> estivesse escrevendo um artigo, misturando texto e codigo, de modo que
> voce nao precisa ordenar o programa segundo a logica do computador.

Interessante mesmo... 
Eu ainda não li os links que vc passou prá aprender mais sobre isso e
poder opinar, mas, parece interessante. Apesar de que eu _no momento_
apóie a idéia do CVS antigão... explico:

Pelo que eu já li/fiz experiências com cvs, manteríamos os arquivos
(fontes) normalmente, mas teríamos um arquivo ChangeLog onde a cada
update, import, commit, o desenvolvedor iria fazer um pequeno resumo do
que ele fez... :)

Mas seria legal se vc pudesse dar uma explicação melhor sobre isso aí...
de preferência estilo 'receita de bolo'... bem mastigadinho... :PPP

> > O CVS ajuda muito a organizar as coisas. Já passou da hora
> > da gente começar a usar ele, vamos tentar dar um gaz de novo nisso ai.
> 
> Legal. O primeiro passo eh verificar quem tem a versao mais atualizada do
> LinuxCall, e mandar para o repositorio com o comando cvs import.

Pode deixar !!!

Eu _provavelmente_ sou o que tem mais fontes relacionados ao LinuxCall,
então já estou me organizando nesse sentido e ainda nesse fim de semana,
se tudo der certo, estaremos com o CVS no ar, ok ?

Falous pessoal, té +

[]'s

-- 
André Casteliano
Analista de Sistemas

+-=-=[ dig...@us...]=-=-+
[ 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       ]
+-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+

[Linuxcall] Literate Programming

[Nelson C. de T. F. <nf...@in...>]

> > > Seria algo como inserir a documentação em forma de comentários no
> > > meio do código? Se for isso, legal, acho que isso quebra um galhão.
> > 
> > Eh isso e muito mais. A ideia eh que voce organize o programa como se
> > estivesse escrevendo um artigo, misturando texto e codigo, de modo que
> > voce nao precisa ordenar o programa segundo a logica do computador.
> 
> Interessante mesmo... 
> Eu ainda não li os links que vc passou prá aprender mais sobre isso e
> poder opinar, mas, parece interessante. Apesar de que eu _no momento_
> apóie a idéia do CVS antigão... 

Na verdade, Literate Programming não está diretamente relacionada com o
uso ou não de CVS; aliás, seria ótimo usar os dois simultaneamente!

Aqui vão alguns trechos de um artigo de Mark Jason Dominus, que explica
porque o método de documentação de Perl, chamado POD, não é Literate
Programming:

---

The first idea is that good program documentation shouldn't be squeezed
into little `comments'. It should be structured more like a technical
article for a journal, and it should have all the support that a journal
article usually gets, including good typesetting. The programmer should
have the opportunity to annotate each section of the code with as much
explanation as is necessary and appropriate.

So far this sounds just like POD. Where POD comes up short is in the
other important idea.

Knuth's other idea was that the best order to explain the parts of the
program in a journal article is not going to be the same as the order that
the computer needs to see the code. When you write a computer program, you
have to present the code to the computer in a certain order, or else it
doesn't work. This order might not be a good order for explaining the way
the program works.

For example, you might have

unless (open(F, "< $file")) {
           # 55 lines of error handling here ...        
        }

$line = <F>;

When you're explaining the program to someone else, you want to talk about
opening the file and reading a line. You don't want to have to interrupt
yourself with a huge digression about the error handling just because the
computer language you're using requires that you put the error handling in
between the open and the read; you'd might prefer to talk about the main
logic first, and return to discuss the error-handling part much later.

For the same reason, having the error handling code in the middle there is
no just an impediment to you when you try to explain the code, it's also
an impediment to another programmer trying to understand the code. One
frequent criticism of C is that it's too hard to follow the flow of logic
because it is visually dominated by block after block of error handling
code.

---

Para maiores detalhes, leiam o artigo!

"POD is Not Literate Programming"
http://www.perl.com/pub/tchrist/litprog.html

[]s

Nelson

__________________________________________________________________
Nelson Ferraz                           Insite - Solucoes Internet
e-mail: nf...@in...           http://www.insite.com.br/

Re: [Linuxcall] GLOBAL section...

[Alex B. <ne...@za...>]

Marcelo Beckmann wrote:
> 
> ---[ printf("Em qui, 09 nov 2000, André Casteliano escreveu"); ]---
> # Precisamos de alguém que manje dos parâmetros do pppd, seus retornos,
> # etc, para podermos implementar esse front-end (exatamente, nosso
> # programa é um front-end pro pppd, assim como o kppp).
> #
> # Agora vem a melhor parte: Nós JÁ temos uma pessoa assim! O Alex...
> # Alex, precisamos de um doc explicando o básico do básico prá podermos
> # começar a implementação dessa versão em pure C...
> 
> Alex, se você puder dar uma força ai seria uma ótima...

Claro que posso !!!
 
> Tipo, você manja bastante disso, eu de pppd e chat já li bastante,
> entendo como funciona, mas nunca cheguei a brincar mais
> profundamente com a coisa.

Cara, passei literalmente meses mexendo com isso...
 
> # Tipo, de onde vem akeles retornos (NO CARRIER, BUSY, NODIALTONE, etc)
> # ??? Do pppd ??? Do chat ??? do modem ??? :P

Quando o chat termina, ele retorna um codigo.. esse codigo representa,
entre outras coisas, o status que o modem devolveu...
 
> # O chat é usado prá autenticação ??? Como implementar conexão chat, além
> # da PAP, etc... espero que esteja me entendendo... :)
> 
> Tai, bem lembrado...  até agora só pensei em PAP, mas existem outras
> formas de autenticação...   hum...   vamos ter que correr atras.

Cara, acho que a gente não precisa se preocupar com CHAP, pq ele não é
mais usado, pelo menos em desktop. A diferença entre PAP e CHAP, é que
no PAP só o usuário se autentica no provedor. Já no CHAP, o provedor tb
tem que se autenticar no seu sistema, ou seja, ele tem que ter uma conta
e senha na sua maquina, do mesmo jeito que vc tem no sistema deles... vc
já ouviu falar disso aqui no Brasil ?? eu não.. nem no exterior...Esse
tipo de autenticação que o PPPD aceita é para sistemas que não trabalhem
com internet, ou seja, uma conexão PPP entre dois micros... eu acho..
;-)
 
> # Andei dando uma olhada nos scripts, e infelizmente não está muito bem
> # documentado internamente... :)

realmente, a documentação está horrivel... Por isso que me disponho a
esclarecer qualquer dúvida sobre o sistema de discagem, pppd, chat, etc.

Alias, me digam uma coisa, vcs estão complicando o linuxcall em C, não
estão ?? Eu estava pensando em algumas coisas aqui... com o pouco de C
que eu estou aprendendo, já dava pra fazer uma versão em Puro C, sem
complicações...

té mais...

-- 
 /------------------------------ \          ____ 
 | 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.

Re: [Linuxcall] GLOBAL section...

[C. <dig...@us...>]

Alex Borro wrote:
> 
> Marcelo Beckmann wrote:
> >
> > Alex, se você puder dar uma força ai seria uma ótima...
> 
> Claro que posso !!!

Opa... beleza... hehehehe

> > Tipo, você manja bastante disso, eu de pppd e chat já li bastante,
> > entendo como funciona, mas nunca cheguei a brincar mais
> > profundamente com a coisa.
> 
> Cara, passei literalmente meses mexendo com isso...

Então manja mesmo... hehehe ainda bem.

> Alias, me digam uma coisa, vcs estão complicando o linuxcall em C, não
> estão ?? Eu estava pensando em algumas coisas aqui... com o pouco de C
> que eu estou aprendendo, já dava pra fazer uma versão em Puro C, sem
> complicações...

Sem complicações ??? Alex, tem certeza ?

Temos que invocar o pppd, receber os retornos dele, analisar, tratar
tudo isso... sem falar no IPC, já que o pppd roda de dentro do
processo-filho...

Temos que ver ainda o lance do fork como root, etc, etc, etc...

Não é nenhum bicho de sete cabeças, mas tb não é assim tão fácil...

O nosso maior problema não é o código (desconhecimento do C) e sim a
lógica, como funfa o pppd, o chat, etc... manja ?

Mas é bom vc estar interessado em C tb... podemos trocar idéias. :)

[]'s

-- 
André Casteliano
Analista de Sistemas

+-=-=[ dig...@us...]=-=-+
[ 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       ]
+-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+

Re: [Linuxcall] GLOBAL section...

[serialcoder <md...@ma...>]

---[ printf("Em sex, 10 nov 2000, André Casteliano escreveu"); ]---
# Cara, eu já fiz umas experiências com essa UNIX Conio... prá te falar a
# verdade, não gostei... 
# A versão que eu peguei não acessava diretamente a tela, como o ncurses
# ou newt. Ele era um front-end para a ncurses e deu muito pau aki...

Hum...  Estranho...  pelo que eu vi, essa conio, para "controlar" a
tela, se baseia em sequencias de escape ANSI. Pelo que vi nos fontes
dela não seria um front-end pra curses... será?

# Andei lendo novamente akelas xerox que o Amauri mandou, e mais
alguns # trecos sobre curses... curses é fácil mano! Dá prá fazer sem
# problemas... e como vc tá mexendo com newt no teu trampo, porque não
# fazemos em newt então ???

O que eu vi é o seguinte: tudo depende da finalidade.
Por exemplo: se voce precisa apenas de um gotoxy() e coisinhas
simples, a uconio é legal.
Se for pra fazer telas de configuradores, estilo instalador do Red
Hat, ou coisas parecidas com dialog, newt é a pedida, newt é muito
legal pra isso.
Curses pode servir pra tudo isso, mas, conforme o caso, é matar um
passarinho com um canhão. Curses é muito poder de fogo, é massa
mesmo, e na verdade não é dificil, ainda mais quando se tem uma
documentação legal como aqueles xerox que o Amauri mandou.
Mas pra fazer coisas tipo configuradores e instaladores, prefiro
newt, é sob medida para isso.
Bom, deixa sobrar um tempinho por aqui que eu vou escrever algo a
respeito. Até André, já que você andou mexendo com curses tb, vamos
trocar umas idéias sobre isso tb.


# Fazer da page um local onde a pessoa visite frequentemente, não só pra
# saber se tem nova versão do programa, mas tb prá ver as novidades,
# documentação, ver o FAQ... cês tão entendendo ? ;-)
# 
# Tenho bastante documentação aki sobre IPC em UNIX, CVS, etc... vou
# procurar os links aki prá por como referência e na sequência mando pro
# Davi por na page... seção 'Colaborador' ou seção 'Documentação' ???

Acho que na 'Documentação' caberiam coisas relacionadas mais
diretamente ao linuxcall em si. Na 'Colaborador' (ou 'desenvolvedor',
sei lá :), iriam as coisas "extras".

De qualquer modo, a idéia é muito boa, creio que temos material de
montão pra botar lá, seria mais uma questão de tempo pra organizar as
coisas e ir botando no ar.

# Calma mano... cê tá pensando muito lá prá frente... heheheh

hehe, esse é um problema meu as vezes, eu fico pensando muito adiante
mesmo....

# Tipo, concentre-se no problema atual: arkivo. Resolva e parta pro
# próximo... :)

Ou seja, vamos por partes :)  legal.

# Fazendo dessa forma já consegui implementar algumas coisas por aki... no
# teu caso, seria interessante se vc fizesse as rotinas de
# tratamento/localização do modem... :)
# 
# Rotinas essas que poderiam ser usadas tb nessa versão da interface
# atual... porque não ?

Mas claro! Eu só dei um tempo nelas por que tava atolado com os
trecos aqui, mas agora pode rolar sim. 
De qualquer modo, como já estamos com uma visão de modularização do
código, as rotinas poderão ser aproveitadas tanto pelas versões
atuais (script + xstep) quanto na versão texto pure C, tranquilo.
Falar nisso, se você (André) e o Alex já tiverem algumas necessidades
em mente ai, tipo "função pra resetar modem", "função pra ler ATI's
do modem", me passem ai o que voces precisam quanto a parametros de
entrada e saida, coisa e tal, que ai já vou caminhando nesse sentido.

Ok man's, vamos tocando esse barco e trocando idéias.

Abração a todos,

-- 
#=-=[  ser...@us...  ]=-=+=#=--------------=#
|  Marcelo D. Beckmann  --user[]="#173935"--  | |     CL5 2.2.14
| md...@ma...     UIN [53189692]----+ | Slack 7 2.2.13
#  - =-#--=[ http://marcelobeckmann.cjb.net ]=--#-==-==-==-==-==-#
+ .~.  |                  233MMX 32MB 8.4+3.2GB Quantum Fireball ]
  /V\  #------------------466.94----[ OPL3SAx TGUI9680 2MB 33600 ]
 /(.)\ "Estamos de volta aos tempos em que os homens eram homens ]
 ^`~´^  e programavam seus próprios drivers de dispositivo."L.T. ]
#-====-#----=[ serialcoder ]=- + -=[ http://wm.themes.org ]=-----'
RTS-[CTS]-DLE-STX-17-39-35-CRC-F6-66-DLE-ETX-/RTS-[/CTS-RTS]-CTS-[ACK]

Re: [Linuxcall] GLOBAL section...

[C. <dig...@us...>]

serialcoder wrote:
> 
> Hum...  Estranho...  pelo que eu vi, essa conio, para "controlar" a
> tela, se baseia em sequencias de escape ANSI. Pelo que vi nos fontes
> dela não seria um front-end pra curses... será?

Deve ter "evoluído" agora... mas a versão que eu peguei era um
'front-end'... hehehe

Dava uns paus malucos na libncurses.so.5 ...

> O que eu vi é o seguinte: tudo depende da finalidade.
> Por exemplo: se voce precisa apenas de um gotoxy() e coisinhas
> simples, a uconio é legal.
> Se for pra fazer telas de configuradores, estilo instalador do Red
> Hat, ou coisas parecidas com dialog, newt é a pedida, newt é muito
> legal pra isso.
> Curses pode servir pra tudo isso, mas, conforme o caso, é matar um
> passarinho com um canhão. Curses é muito poder de fogo, é massa
> mesmo, e na verdade não é dificil, ainda mais quando se tem uma
> documentação legal como aqueles xerox que o Amauri mandou.
> Mas pra fazer coisas tipo configuradores e instaladores, prefiro
> newt, é sob medida para isso.
> Bom, deixa sobrar um tempinho por aqui que eu vou escrever algo a
> respeito. Até André, já que você andou mexendo com curses tb, vamos
> trocar umas idéias sobre isso tb.

Bom, a idéia realmente é fazer uma interface modo texto, ou seja, um
configurador, no estilo dos configuradores da RedHat, ou do Slack, etc..

Agora seria interessante se pudéssemos mudar as cores... hehehe Tipo,
akele vermelho com azul já tá enjoando... :)

> # Fazer da page um local onde a pessoa visite frequentemente, não só pra
> # saber se tem nova versão do programa, mas tb prá ver as novidades,
> # documentação, ver o FAQ... cês tão entendendo ? ;-)
> #
> # Tenho bastante documentação aki sobre IPC em UNIX, CVS, etc... vou
> # procurar os links aki prá por como referência e na sequência mando pro
> # Davi por na page... seção 'Colaborador' ou seção 'Documentação' ???
> 
> Acho que na 'Documentação' caberiam coisas relacionadas mais
> diretamente ao linuxcall em si. Na 'Colaborador' (ou 'desenvolvedor',
> sei lá :), iriam as coisas "extras".

Eu acho assim: Na seção 'Colaborador' deveriam estar os docs,
comentários a respeito do LinuxCall... e na seção 'Documentação',
podíamos por os textos que nos ajudaram, os tais dos artigos com as
"Impressões pessoais no desenvolvimento de software livre", etc...
Exatamente o contrário.... :P

> De qualquer modo, a idéia é muito boa, creio que temos material de
> montão pra botar lá, seria mais uma questão de tempo pra organizar as
> coisas e ir botando no ar.

Pois é... o tal do tempo... realmente anda curto, hehehehe

Tipo, tou me organizando aki, no sentido de por o CVS no ar, mas logo em
seguida mando os trecos procês... :)

> # teu caso, seria interessante se vc fizesse as rotinas de
> # tratamento/localização do modem... :)
> #
> # Rotinas essas que poderiam ser usadas tb nessa versão da interface
> # atual... porque não ?
> 
> Mas claro! Eu só dei um tempo nelas por que tava atolado com os
> trecos aqui, mas agora pode rolar sim.
> De qualquer modo, como já estamos com uma visão de modularização do
> código, as rotinas poderão ser aproveitadas tanto pelas versões
> atuais (script + xstep) quanto na versão texto pure C, tranquilo.
> Falar nisso, se você (André) e o Alex já tiverem algumas necessidades
> em mente ai, tipo "função pra resetar modem", "função pra ler ATI's
> do modem", me passem ai o que voces precisam quanto a parametros de
> entrada e saida, coisa e tal, que ai já vou caminhando nesse sentido.

Hum... preciso:

	* Seek AND Destroy do modem... :)
	* Reset
	* Leitura das ATI's

Acho que é só... :)

> Ok man's, vamos tocando esse barco e trocando idéias.

Falous pessoal,

[]'s

-- 
André Casteliano
Analista de Sistemas

+-=-=[ dig...@us...]=-=-+
[ 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       ]
+-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+

Re: [Linuxcall] GLOBAL section...

[C. <dig...@us...>]

serialcoder wrote:
> 
> Falar nisso, se você (André) e o Alex já tiverem algumas necessidades
> em mente ai, tipo "função pra resetar modem", "função pra ler ATI's
> do modem", me passem ai o que voces precisam quanto a parametros de
> entrada e saida, coisa e tal, que ai já vou caminhando nesse sentido.

Hum... que tal:

int modem_found(void)

Retorna verdadeiro (1) ou falso (0). Se achou o modem retorna
verdadeiro, se não achou retorna falso...

char *device(void)

Essa a gente só usaria caso a func acima retornasse verdadeiro, ou seja,
indicando que tem um modem instalado. Aí a gente usa essa prá saber em
qual ttyS* esse modem está...

char **modem_ati(char *device)

A gente passa como parâmetro a saída da função anterior e recebe um
vetor com as ATI's do modem...

Retorna um ponteiro prá ponteiro (um vetor char de duas dimensões), com
os retornos do modem.

Ou algo mais específico:

char *ati(char *device, int ati)

Vc passa como parâmetro além do device do modem, também a ati que vc
quer como resposta (ati 1, ati 2, etc). E a func retorna... se vc
especificar um ati inválido, a função retorna NULL...

------------------------- [corta]

Agora se vc tiver com mais tempo e paciência, pode aprofundar mais... :)

char *speed(char *device)

Retorna a velocidade do modem.

char *model(char *device)

Retorna o modelo do modem (USR 33.6, etc, etc, etc)

int reset_modem(char *device)

Retorna verdadeiro caso tenha resetado com sucesso o modem e falso caso
contrário
------------------------ [corta]

É isso aí mano, se tiver mais alguma idéia ou os demais coders quiserem
complementar a minha, sintam-se à vontade... :)

[]'s
 
-- 
André Casteliano
Analista de Sistemas

+-=-=[ dig...@us...]=-=-+
[ 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       ]
+-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+

Re: [Linuxcall] GLOBAL section...

[Alex B. <ne...@za...>]

serialcoder wrote:
> Falar nisso, se você (André) e o Alex já tiverem algumas necessidades
> em mente ai, tipo "função pra resetar modem", "função pra ler ATI's
> do modem", me passem ai o que voces precisam quanto a parametros de
> entrada e saida, coisa e tal, que ai já vou caminhando nesse sentido.
>

Cara, eu quero uma que somente reseta o modem, independente do estado
atual dele.. se está discando, esperando, parado..etc.. se for possivel.
só isso...

té mais...

-- 
 /------------------------------ \          ____ 
 | 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.

[Linuxcall] Funções de acesso ao modem

[Marcelo B. <md...@ma...>]

---[ printf("Em seg, 13 nov 2000, André Casteliano escreveu"); ]---
# serialcoder wrote:
# > 
# > Falar nisso, se você (André) e o Alex já tiverem algumas necessidades
# > em mente ai, tipo "função pra resetar modem", "função pra ler ATI's
# > do modem", me passem ai o que voces precisam quanto a parametros de
# > entrada e saida, coisa e tal, que ai já vou caminhando nesse sentido.
# 
# Hum... que tal:
# 
# int modem_found(void)
# 
# Retorna verdadeiro (1) ou falso (0). Se achou o modem retorna
# verdadeiro, se não achou retorna falso...
# 
# char *device(void)
# 
# Essa a gente só usaria caso a func acima retornasse verdadeiro, ou seja,
# indicando que tem um modem instalado. Aí a gente usa essa prá saber em
# qual ttyS* esse modem está...

Ok André. Só queria colocar algumas considerações:
* no caso da int modem(void), você gostaria que procurasse modem em
quais portas? Apenas as padrões (ttyS0 a ttyS3) ? Ou seria
interessante procurar em outras? Eu nunca usei winmodens, e não sei
bem como eles se comportam, já vi por ai que alguns winmodens usam
ttyS15, por exemplo. Alguma informação nesse sentido poderia me ser
útil.

* Valores de retorno: poderia ser feito da seguinte forma:
0 = achou modem
1 = não conseguiu abrir porta
2 = abriu porta, mas estourou timeout pra receber resposta
Acha válido isso, ou não?

Poderia também ser feito da seguinte forma:
int modem_found(char *ttyS)

Além de retornar se achou modem ou não, poderia retornar em ttyS qual
das seriais foi encontrado o modem. A passagem do parâmetro 'ttyS'
evitaria o uso de alguma variável global.


# char **modem_ati(char *device)
# 
# A gente passa como parâmetro a saída da função anterior e recebe um
# vetor com as ATI's do modem...

Exatamente, o parâmetro anterior seria retornado como parâmetro, sem
o uso de uma variável global. A partir daí, faço a leitura dos ATI's
e escrevo a resposta no vetor, retornando o ponteiro pro mesmo.

# char *ati(char *device, int ati)
# 
# Vc passa como parâmetro além do device do modem, também a ati que vc
# quer como resposta (ati 1, ati 2, etc). E a func retorna... se vc
# especificar um ati inválido, a função retorna NULL...

Ok, tranquilo. Nesse caso, ati pode ser um char, que já dá conta do
recado.

 
# ------------------------- [corta]
# 
# Agora se vc tiver com mais tempo e paciência, pode aprofundar mais... :)
# 
# char *speed(char *device)
# 
# Retorna a velocidade do modem.
#
# char *model(char *device)
# 
# Retorna o modelo do modem (USR 33.6, etc, etc, etc)

A velocidade e o modelo, se não me engano, estão em um dos ATI's. Vou
dar uma consultada nos comandos de modem, e ver se tem mais alguma
característica interessante que possa ser usada.

# int reset_modem(char *device)
# 
# Retorna verdadeiro caso tenha resetado com sucesso o modem e falso caso
# contrário

Tranquilo de ser implementado tb.

# ------------------------ [corta]
# 
# É isso aí mano, se tiver mais alguma idéia ou os demais coders quiserem
# complementar a minha, sintam-se à vontade... :)

Beleza, vamos nessa.

[]s

-- 
#=-=[  ser...@us...  ]=-=+=#=--------------=#
|  Marcelo D. Beckmann  --user[]="#173935"--  | |     CL5 2.2.14
| md...@ma...     UIN [53189692]----+ | Slack 7 2.2.13
#  - =-#--=[ http://marcelobeckmann.cjb.net ]=--#-==-==-==-==-==-#
+ .~.  |                  233MMX 32MB 8.4+3.2GB Quantum Fireball ]
  /V\  #------------------466.94----[ OPL3SAx TGUI9680 2MB 33600 ]
 /(.)\ "Estamos de volta aos tempos em que os homens eram homens ]
 ^`~´^  e programavam seus próprios drivers de dispositivo."L.T. ]
#-====-#----=[ serialcoder ]=- + -=[ http://wm.themes.org ]=-----'
RTS-[CTS]-DLE-STX-17-39-35-CRC-F6-66-DLE-ETX-/RTS-[/CTS-RTS]-CTS-[ACK]