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,
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 production.
i
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)
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.
On Thu, Apr 9, 2009 at 6:09 PM, Eris Discordia eris.discor...@gmail.com 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
On Thu, Apr 9, 2009 at 6:34 PM, Eris Discordia eris.discor...@gmail.com 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
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.
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
On Thu, Apr 9, 2009 at 9:44 AM, Eris Discordia eris.discor...@gmail.com 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
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.
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 course, and
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 about
No, it's very likely bigger. wc -l is lines of course
Silly me, I was (optimistically) confusing it with wc -c.
I prefer the cadillac of shells (zsh) the vw bug (rc).
I like this.
$ 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 ^ '=()'
if
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
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 me
2009/4/7 Corey co...@comfortstore.net:
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
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
2009/4/7 Eris Discordia eris.discor...@gmail.com:
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
On Tue, Apr 7, 2009 at 12:28 AM, Eris Discordia
eris.discor...@gmail.com wrote:
Like... readline(3)?
one hopes not.
ron
you could break out re expansion into a separate program :-)
ron
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.
On Tue, Apr 7, 2009 at 9:05 AM, Corey co...@comfortstore.net 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
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 sqw...@gmail.com wrote:
2009/4/7 Eris Discordia eris.discor...@gmail.com:
Keyboard
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 2:21 PM, Eris Discordia eris.discor...@gmail.com 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
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
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
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
A bad implementation is not a bad design.
neither is stink an outhouse, but often they keep company.
- erik
On Tue, Apr 7, 2009 at 9:48 PM, Eris Discordia eris.discor...@gmail.com 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.
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
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
bindings
34 matches
Mail list logo
