On 2012-04-19, at 23:03, Kurt H Maier wrote:
> On Thu, Apr 19, 2012 at 10:27:04PM +0200, Truls Becken wrote:
>>
>> So for the user they seem to have the same effect.
>> Perhaps 2) is partly the reason they do 1), by the way.
>
> Let's not make the fantastically naive mistake of assuming this use
Greetings.
On Fri, 20 Apr 2012 07:38:40 +0200 Kai Hendry wrote:
> I know this is very lazy of me, though it would be good if you could
> have hints how to integrate it say with a typical Archlinux system and
> its /etc/network.d
> https://wiki.archlinux.org/index.php/Netcfg
Netcfg is hardwire
Greetings.
On Fri, 20 Apr 2012 07:27:13 +0200 "Galos, David"
wrote:
> I've written a simple (~500 lines) dhcp client, using the plan9 client
> as reference. It compiles statically to between 8 and 30K depending
> on libc, and gets me onto all the networks I've thrown at it, but
> that's a terri
On Thu, Apr 19, 2012 at 05:40:31PM -0500, Galos, David wrote:
> I've written a simple (~500 lines) dhcp client, using the plan9 client
> as reference. It compiles statically to between 8 and 30K depending
> on libc, and gets me onto all the networks I've thrown at it, but
> that's a terribly small
> I'll gladly test this out on my netbook on different networks. I'll report
> back in a weekish : )
Thanks a lot! I'm looking forward to it.
On Fri, Apr 20, 2012 at 09:59:05AM +0800, Kai Hendry wrote:
> I know this is very lazy of me, though it would be good if you could
> have hints how to integrate it say with a typical Archlinux system and
> its /etc/network.d
> https://wiki.archlinux.org/index.php/Netcfg
>
for the love of christ,
I know this is very lazy of me, though it would be good if you could
have hints how to integrate it say with a typical Archlinux system and
its /etc/network.d
https://wiki.archlinux.org/index.php/Netcfg
I'll gladly test this out on my netbook on different networks. I'll report
back in a weekish : )
On Thu, Apr 19, 2012 at 6:40 PM, Galos, David
wrote:
> I've written a simple (~500 lines) dhcp client, using the plan9 client
> as reference. It compiles statically to between 8 and 30K depending
> on
On 20 April 2012 03:37, Nico Golde wrote:
> Hi,
> * Ivan Kanakarakis [2012-04-20 01:54]:
> > On 20 April 2012 02:24, Connor Lane Smith wrote:
> > > On 19 April 2012 23:51, Connor Lane Smith wrote:
> [...]
> > however if one wants to connect to more than one server
> > and has a different passw
Hi,
* Ivan Kanakarakis [2012-04-20 01:54]:
> On 20 April 2012 02:24, Connor Lane Smith wrote:
> > On 19 April 2012 23:51, Connor Lane Smith wrote:
[...]
> however if one wants to connect to more than one server
> and has a different password for that other server then
> the env var doesn't help
On 20 April 2012 02:24, Connor Lane Smith wrote:
> On 19 April 2012 23:51, Connor Lane Smith wrote:
> > In my opinion the -h flag
> > should be made mandatory, with no default host.
>
> Sorry, it's -h in sic, -s in ii (which is confusing, too.)
>
> On 20 April 2012 00:19, Nico Golde wrote:
> >
On 19 April 2012 23:51, Connor Lane Smith wrote:
> In my opinion the -h flag
> should be made mandatory, with no default host.
Sorry, it's -h in sic, -s in ii (which is confusing, too.)
On 20 April 2012 00:19, Nico Golde wrote:
> I don't really like putting that in a file.
Well, in bash you co
Hi,
* Connor Lane Smith [2012-04-19 18:51]:
> On 19 April 2012 17:24, Ivan Kanakarakis wrote:
> > I was thinking in having -k with no argument to go search for a file
> > like oftc.passwd and grab the password from there.
>
> How about making 'ii -k -' read the password from stdin? Flags with
>
On 19 April 2012 19:12, Strake wrote:
> Worse yet are flags whose semantics vary by argument.
> k flag takes literal password, not file name.
> If we want such a feature we ought to add a new flag, as in attached patch.
I understand your position, but I think we should have just one PASS
flag, no
I've written a simple (~500 lines) dhcp client, using the plan9 client
as reference. It compiles statically to between 8 and 30K depending
on libc, and gets me onto all the networks I've thrown at it, but
that's a terribly small list.
I thought it might be of use to the people here. The source is
On 19/04/2012, Ivan Kanakarakis wrote:
> I tried the second one, I see the check for '-' in the code, but I get
>
> $ ii -n fooo -j -
> -: No such file or directory
>
> seems the check is faulty
>
> if (keyfile != NULL || stat(argv[i], &s) != 0) {
>
> does it work there ?
Ahhh. *facepal
Personally (not that anyone asked) I have a script that will remove
all stale fifos before starting ii, then wait for fifos to appear
before writing commands to them (with an extra optional wait on the
end). I also have ii exit(2) if it times out, and run each ii in a
loop in the background so it w
On Thu, Apr 19, 2012 at 10:27:04PM +0200, Truls Becken wrote:
>
> So for the user they seem to have the same effect.
> Perhaps 2) is partly the reason they do 1), by the way.
Let's not make the fantastically naive mistake of assuming this userbase
is sufficiently large to comprise a statistical u
Anyhow the correct way to connect to a server and
register/auth to the services is two different things.
you need PASS to connect to servers that need it
you need "/j nickserv identify .." to register/auth
no matter if popular servers seem to "merge" this
that's the way it should be, there're not
On Thu, Apr 19, 2012 at 21:21, Kurt H Maier wrote:
> PASS has nothing to do with nickserv.
> nickserv has nothing to do with PASS.
>
> any server that uses data from the PASS string to do shit with nickserv
> is doing that on its own.
>
> Why is this not filtering into anyone's skull?
Because:
1
On 19 April 2012 22:21, Kurt H Maier wrote:
> On Thu, Apr 19, 2012 at 08:41:14PM +0200, Truls Becken wrote:
> >
> > True, PASS is cleaner because of the delay necessary with the nickserv
> > message. Key as argument sucks quite a bit, though.
> >
>
> for those following along at home, PASS has AB
On Thu, Apr 19, 2012 at 08:41:14PM +0200, Truls Becken wrote:
>
> True, PASS is cleaner because of the delay necessary with the nickserv
> message. Key as argument sucks quite a bit, though.
>
for those following along at home, PASS has ABSOLUTELY NOTHING to do
with nickserv or any of this other
Greetings.
On Thu, 19 Apr 2012 21:03:45 +0200 "Galos, David"
wrote:
> > Your proposed changes are applied.
> Glad I could help!
>
> > I still have to insist on checking
> > the right side of »end« to be checked for length.
> > % seq 5 -1 1.
> > should show four digits to thr righ
On Thu, Apr 19, 2012 at 20:05, Ivan Kanakarakis wrote:
> I think PASS is good, having it removed wouldn't really gain
> us much, nothing important in terms of loc and would have
> to replace that functionality, that the irc protocol provides
> with a delayed "/j nickserv identify ..." message.
> w
On Thu, Apr 19, 2012 at 09:05:07PM +0300, Ivan Kanakarakis wrote:
> what's the difference between PASS and identify ?
> both are used to register the user to the server.
> afaict PASS is sent by the client before the nick/user is set
> so when the user connects he's already registered.
> afaik irss
Oops, forgot case "-".
pwfile.patch
Description: Binary data
On 19/04/2012, Connor Lane Smith wrote:
> How about making 'ii -k -' read the password from stdin? Flags with
> optional arguments are bad, imo.
Worse yet are flags whose semantics vary by argument.
k flag takes literal password, not file name.
If we want such a feature we ought to add a new fl
On 19 April 2012 19:48, Connor Lane Smith wrote:
> Hey,
>
> On 19 April 2012 17:34, Truls Becken wrote:
> > $ ii &
> > $ cat ~/irc/freenode_login_script > ~/irc/irc.freenode.net/in
> >
>
I suppose freenode_login_script is something like
/j nickserv identify mypasswd
/j #channel-foo
/j #c
Hey,
On 19 April 2012 17:34, Truls Becken wrote:
> $ ii &
> $ cat ~/irc/freenode_login_script > ~/irc/irc.freenode.net/in
>
> No need for the program to implement password support at all really.
'ii -k' sends the server a PASS message, which must be done before
NICK or USER. This is unrelated to
On 2012-04-19, at 17:54, Ivan Kanakarakis wrote:
> I guess some possible workarounds would be
> - reading the passwd from an environmental var (is that any safer?)
> - reading the passwd from a file (overkill ?)
> - ?
>
> what do you people think ?
> should this be 'fixed' in ii ?
$ ii &
$ cat ~
On 19 April 2012 19:07, Strake wrote:
> On 19/04/2012, Ivan Kanakarakis wrote:
> > because ii takes as an argument
> > the password/-k,
> > the password is exposed to anyone that can see what processes are running
> > (top/htop).
> >
> > As no process can hide its arguments, how should one go ar
On 19/04/2012, Ivan Kanakarakis wrote:
> because ii takes as an argument
> the password/-k,
> the password is exposed to anyone that can see what processes are running
> (top/htop).
>
> As no process can hide its arguments, how should one go around this ?
>
> - reading the passwd from a file (over
Hi all,
I'm using ii lately as my irc client (written a simple frontend too -- will
post on another mail)
What I noticed (and is expected) is that because ii takes as an argument
the password/-k,
the password is exposed to anyone that can see what processes are running
(top/htop).
try running ii w
> Your proposed changes are applied.
Glad I could help!
> I still have to insist on checking
> the right side of »end« to be checked for length.
> % seq 5 -1 1.
> should show four digits to thr right.
I agree that this is sensible behavior. GNU seq doesn't do that,
but since when h
Updating on this. I did some extra digging and it looks like the menu should
be set to hold a max of 32 chars as that's the input limit. I re-adjusted my
patch and now it takes the font width * 32 and uses that as the width
measurement. With this I removed the custom size option and just all
35 matches
Mail list logo
