Wait, am I on the wrong mailing list? Since when was this Fans of BSD
and Linux Talk about why Plan 9 Sucks Donkey Shit?
(I use FreeBSD and Linux. OTOH, I'm not on freebsd-general@ and centos
mailing lists talking about how our private namespaces and 9p are so
much shinier than VFS)
> >> i know of many thousands of plan 9 systems in production right
> >> now.
>
> Erik, you might want to know how many *million* people use Linux ;)
> Won't you?
the criticisim of plan 9 that i was respnding to was that
plan 9 was not used for anything serious or capable of
being used in product
On 04/10/2009 05:08 AM, Eris Discordia wrote:
>> this is the "space-shuttle dichotomy." it's a false one. it's a
>> continuum. its ends are dangerous.
>
> So somewhere in the middle is the golden mean? I have no objections to
> that. *BSD systems very well represent a silver, if not a golden,
>
No, bash's completion system is what's responsible for line numbers in
the thousands.
How? Is bash's completion on your system different than on my system? I'd
like you to substantiate that statement and will thank you for a proper
response.
--On Friday, April 10, 2009 3:33 PM -0400 "J.R. Ma
On Thu, Apr 9, 2009 at 6:34 PM, Eris Discordia wrote:
>> this is the "space-shuttle dichotomy." it's a false one. it's a
>> continuum. its ends are dangerous.
>
> So somewhere in the middle is the golden mean? I have no objections to that.
> *BSD systems very well represent a silver, if not a go
On Thu, Apr 9, 2009 at 6:09 PM, Eris Discordia wrote:
>> It only starts to balloon once you begin customizing bash.
>
> Have you customized your bash by aliases as long as tens or hundreds of
> lines? Now is it bash's fault you have defined an alias for something that
> ought to be a script/progra
Eris Discordia wrote:
> And I haven't really ever used Plan 9 or "been into it." The
> no-herpes indicator is that strong.
New, from 9fans Cinemas, the long-awaited summer blockbuster:
"An Unsurprising Truth", starring Eris Discordia
And don't forget the upcoming sequel, "Why The Hell Are You Ev
this is the "space-shuttle dichotomy." it's a false one. it's a
continuum. its ends are dangerous.
So somewhere in the middle is the golden mean? I have no objections to
that. *BSD systems very well represent a silver, if not a golden,
mean--just my idea, of course.
it is interesting to m
It only starts to balloon once you begin customizing bash.
Have you customized your bash by aliases as long as tens or hundreds of
lines? Now is it bash's fault you have defined an alias for something that
ought to be a script/program in its own right?
--On Thursday, April 09, 2009 3:34 PM -
Seems Charles Forsyth's bash (or wc -l) works very differently.
[r...@host ~/]# set | wc -l
49
[r...@host ~/]#
37 out of 49 are just environment variables (as contrasted to shell
variables). So the shell is using 12 variables in addition to the
environment. A 'set | wc -c' gives 2133 o
2009/4/9 Bakul Shah :
> On Thu, 09 Apr 2009 15:28:58 EDT "Devon H. O'Dell"
> wrote:
>> $ set | wc -l
>> 64
>>
>> I don't quite get that locally.
>
> This must be on FreeBSD!
>
> % bash
> $ echo $BASH_VERSION
> 4.0.10(2)-release
> $ set|wc
> 72 1062107
It is actually CentOS 5 (work)
> $ echo $BASH_VERSION
> 4.0.10(2)-release
> $ set|wc
> 72 1062107
if this is the criteria, plan 9 loses:
; printenv|wc
73 2102417
- erik
p.s.
; cat /bin/printenv
#!/bin/rc
rfork en
cd /env
for(i in *){
if(! test -s $i)
echo $i ^ '=()'
>
> I prefer the cadillac of shells (zsh) & the vw bug (rc).
>
I like this.
On Thu, 09 Apr 2009 15:28:58 EDT "Devon H. O'Dell"
wrote:
> $ set | wc -l
> 64
>
> I don't quite get that locally.
This must be on FreeBSD!
% bash
$ echo $BASH_VERSION
4.0.10(2)-release
$ set|wc
72 1062107
I prefer the cadillac of shells (zsh) & the vw bug (rc).
> No, it's very likely bigger. wc -l is lines of course
Silly me, I was (optimistically) confusing it with wc -c.
> $ set | wc -l
> 64
>
> I don't quite get that locally.
please upgrade your distribution.
- erik
> No, it's very likely bigger. wc -l is lines of course, and I'm
> guessing each line is more than 1 character. However,
>
> $ set | wc -l
> 64
>
> I don't quite get that locally.
It only starts to balloon once you begin customizing bash. I'm not
sure how rc handles functions, but the nice thing a
2009/4/9 Richard Miller <9f...@hamnavoe.com>:
>> set | wc -l
>> 8047
>> well.
>
> This is nearly as big as the shell itself in the (ahem) good old days.
>
> term% tar tzvf interdata_v6.tar.gz bin/sh
> --rwxr-xr-x 8316 Nov 13 15:48 1978 bin/sh
No, it's very likely bigger. wc -l is lines of co
> set | wc -l
> 8047
> well.
This is nearly as big as the shell itself in the (ahem) good old days.
term% tar tzvf interdata_v6.tar.gz bin/sh
--rwxr-xr-x 8316 Nov 13 15:48 1978 bin/sh
set | wc -l
8047
well.
certainly if you leave bash or even dash set as the shell,
a terminal or 9term window takes ages on ubuntu. set the shell to p9p rc,
9term starts straight away and you're a better person for it.
On Thu, Apr 9, 2009 at 9:44 AM, Eris Discordia wrote:
>> Try env | wc -l in bash. Now tell me why that value is so big.
>
>> [r...@host ~]# env | wc -l
>> 37
>> [r...@host ~]#
>
> Is that very high? I don't even know if it is or how it would mean anything
> bad (or good for that matter) ass
On Thu Apr 9 10:48:08 EDT 2009, eris.discor...@gmail.com wrote:
> Most of it in the 19 lines for one TERMCAP variable. Strictly a relic of
> the past kept with all good intentions: backward compatibility, and heeding
[...]
> Quite a considerable portion of UNIX-like systems, FreeBSD in this ca
Try env | wc -l in bash. Now tell me why that value is so big.
[r...@host ~]# env | wc -l
37
[r...@host ~]#
Is that very high? I don't even know if it is or how it would mean anything
bad (or good for that matter) assuming it were high. Not to mention, it's a
very bad metric. Becaus
On Tue, Apr 7, 2009 at 9:48 PM, Eris Discordia wrote:
>> The man page *does* say it's too big and slow. So does the bash
>> manpage. And getting readline to do anything sane is about as fun as
>> screwing around with a terminfo file.
>
> A bad implementation is not a bad design. And, in fact, the
> A bad implementation is not a bad design.
neither is stink an outhouse, but often they keep company.
- erik
The man page *does* say it's too big and slow. So does the bash
manpage. And getting readline to do anything sane is about as fun as
screwing around with a terminfo file.
A bad implementation is not a bad design. And, in fact, the badness of the
implementation is even questionable in the light
> Well someone's gotta tell these prepubescents ...
>
> "Because the V6 shell did it, that's why.".
ooh. ooh. i know what you're going to say next:
if should be an external program.
- erik
Exactly, and the end user can choose to have a re or glob expansion
program, rather than having to muck up the shell code with different
flags or whatever.
somebody is going to jump in very soon and tell us why this is
funny :-)
i promised i wouldn't,
Well someone's gotta tell these prepu
On Tue, Apr 7, 2009 at 2:21 PM, Eris Discordia wrote:
> I see. But seriously, readline does handle bindings and line editing for
> bash. Except it's a function instead of a program and you think it's a bad
> idea.
The man page *does* say it's too big and slow. So does the bash
manpage. And gettin
I see. But seriously, readline does handle bindings and line editing for
bash. Except it's a function instead of a program and you think it's a bad
idea.
--On Tuesday, April 07, 2009 10:31 PM +0800 sqweek wrote:
2009/4/7 Eris Discordia :
Keyboard
bindings for example; why couldn't they be h
> > Exactly, and the end user can choose to have a re or glob expansion
> > program, rather than having to muck up the shell code with different
> > flags or whatever.
>
> somebody is going to jump in very soon and tell us why this is funny :-)
i promised i wouldn't,
- erik
On Tue, Apr 7, 2009 at 9:05 AM, Corey wrote:
> On Tue, 2009-04-07 at 08:08 -0700, ron minnich wrote:
>> you could break out re expansion into a separate program :-)
>>
>> ron
>>
>
> Exactly, and the end user can choose to have a re or glob expansion
> program, rather than having to muck up the she
On Tue, 2009-04-07 at 08:08 -0700, ron minnich wrote:
> you could break out re expansion into a separate program :-)
>
> ron
>
Exactly, and the end user can choose to have a re or glob expansion
program, rather than having to muck up the shell code with different
flags or whatever.
you could break out re expansion into a separate program :-)
ron
On Tue, Apr 7, 2009 at 12:28 AM, Eris Discordia
wrote:
>
> Like... readline(3)?
one hopes not.
ron
2009/4/7 Eris Discordia :
>>> Keyboard
>>> bindings for example; why couldn't they be handled by a program that
>>> just does keyboard bindings + line editing, and writes finalized lines
>>> to the shell.
>
> Like... readline(3)?
No.
-sqweek
Keyboard
bindings for example; why couldn't they be handled by a program that
just does keyboard bindings + line editing, and writes finalized lines
to the shell.
Like... readline(3)?
SEE ALSO
The Gnu Readline Library, Brian Fox and Chet Ramey
The Gnu History Library, Brian Fox a
2009/4/7 Corey :
> Keyboard
> bindings for example; why couldn't they be handled by a program that
> just does keyboard bindings + line editing, and writes finalized lines
> to the shell.
Congratulations, you've perceived the difference between shell and
terminal. A lot of people stuck in modern
> Would there be any merit to breaking the shell apart into a number of
> smaller programs? Looking at GNU bash as an example (though I know GNU
> is probably one of the worst places to look for "Unix style"), It is my
> understanding that one program handles many things, such as keyboard
> binding
Not exactly related to Plan 9, but I don't know any other place full of
people much smarter than myself who put value in the "Unix philosophy",
and this idea is partially inspired by something I read about rio/rc.
Would there be any merit to breaking the shell apart into a number of
smaller progra
40 matches
Mail list logo