[9fans] a bit OT, programming style question

[9fans] a bit OT, programming style question

[Corey]

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 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 (which I believe in turn requires bash to read in cbreak or raw
or whatever and do it's own line editing), glob expansion, aliases,
history, syntax parsing, command execution, job control, etc. etc.

IMO this results in a more complex program than necessary. 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. This in turn could also allow bindings to be more easily
customized (such as binding autocomplete to Ctrl+F instead of tab)
depending on its implementation.

Does this make sense? Is it more work than it's worth? Has it already
been done (I know filename completion is handled by rio rather than rc
for example)? Sorry if this is too off-topic for 9fans.

Re: [9fans] a bit OT, programming style question

[erik quanstrom]

> 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 (which I believe in turn requires bash to read in cbreak or raw
> or whatever and do it's own line editing), glob expansion, aliases,
> history, syntax parsing, command execution, job control, etc. etc.
>
> IMO this results in a more complex program than necessary. 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. This in turn could also allow bindings to be more easily
> customized (such as binding autocomplete to Ctrl+F instead of tab)
> depending on its implementation.

fwiw, plan 9 handles key bindings in #κ.  the shell hasn't a clue.
rio (or acme) handles the editing.  again, the shell hasn't a clue.
and autocomplete?  yup.  same story.  hapless rc hasn't a clue.

rc is proof that ignorance is bliss.

- erik

Re: [9fans] a bit OT, programming style question

[sqweek]

2009/4/7 Corey <corey@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 people stuck in modern unix fail to notice this
one... which is not that surprising considering the state of modern
unix terminals (9term excepted - quiet Anothy :P).
-sqweek

Re: [9fans] a bit OT, programming style question

[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)?

> SEE ALSO
>        The Gnu Readline Library, Brian Fox and Chet Ramey
>        The Gnu History Library, Brian Fox and Chet Ramey
>        bash(1)

-- man readline

--On Tuesday, April 07, 2009 3:53 PM +0800 sqweek <sqweek@gmail.com> wrote:

> 2009/4/7 Corey <corey@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 people stuck in modern unix fail to notice this
> one... which is not that surprising considering the state of modern
> unix terminals (9term excepted - quiet Anothy :P).
> -sqweek
>

Re: [9fans] a bit OT, programming style question

[sqweek]

2009/4/7 Eris Discordia <eris.discordia@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

Re: [9fans] a bit OT, programming style question

[ron minnich]

On Tue, Apr 7, 2009 at 12:28 AM, Eris Discordia
<eris.discordia@gmail.com> wrote:

>
> Like... readline(3)?

one hopes not.

ron

Re: [9fans] a bit OT, programming style question

[Eris Discordia]

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 <sqweek@gmail.com> wrote:

> 2009/4/7 Eris Discordia <eris.discordia@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 Tuesday, April 07, 2009 8:09 AM -0700 ron minnich <rminnich@gmail.com>
wrote:

> On Tue, Apr 7, 2009 at 12:28 AM, Eris Discordia
> <eris.discordia@gmail.com> wrote:
>
>>
>> Like... readline(3)?
>
> one hopes not.
>
> ron
>

Re: [9fans] a bit OT, programming style question

[J.R. Mauro]

On Tue, Apr 7, 2009 at 2:21 PM, Eris Discordia <eris.discordia@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 bash
manpage. And getting readline to do anything sane is about as fun as
screwing around with a terminfo file.

>
> --On Tuesday, April 07, 2009 10:31 PM +0800 sqweek <sqweek@gmail.com> wrote:
>
>> 2009/4/7 Eris Discordia <eris.discordia@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 Tuesday, April 07, 2009 8:09 AM -0700 ron minnich <rminnich@gmail.com>
> wrote:
>
>> On Tue, Apr 7, 2009 at 12:28 AM, Eris Discordia
>> <eris.discordia@gmail.com> wrote:
>>
>>>
>>> Like... readline(3)?
>>
>> one hopes not.
>>
>> ron
>>
>
>
>
>
>
>

Re: [9fans] a bit OT, programming style question

[Eris Discordia]

> 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 of bash's normal behavior 
or the working .inputrc files I've been using for some time.

Anyway, thanks for the info.

--On Tuesday, April 07, 2009 3:57 PM -0400 "J.R. Mauro" <jrm8005@gmail.com> 
wrote:

> On Tue, Apr 7, 2009 at 2:21 PM, Eris Discordia <eris.discordia@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 bash
> manpage. And getting readline to do anything sane is about as fun as
> screwing around with a terminfo file.
>
>>
>> --On Tuesday, April 07, 2009 10:31 PM +0800 sqweek <sqweek@gmail.com>
>> wrote:
>>
>>> 2009/4/7 Eris Discordia <eris.discordia@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 Tuesday, April 07, 2009 8:09 AM -0700 ron minnich
>> <rminnich@gmail.com> wrote:
>>
>>> On Tue, Apr 7, 2009 at 12:28 AM, Eris Discordia
>>> <eris.discordia@gmail.com> wrote:
>>>
>>>>
>>>> Like... readline(3)?
>>>
>>> one hopes not.
>>>
>>> ron
>>>
>>
>>
>>
>>
>>
>>
>

Re: [9fans] a bit OT, programming style question

[erik quanstrom]

> A bad implementation is not a bad design.

neither is stink an outhouse, but often they keep company.

- erik

Re: [9fans] a bit OT, programming style question

[J.R. Mauro]

On Tue, Apr 7, 2009 at 9:48 PM, Eris Discordia <eris.discordia@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. And, in fact, the badness of the
> implementation is even questionable in the light of bash's normal behavior
> or the working .inputrc files I've been using for some time.

Behavior is not indicative of good design. It just means that the
bandaids heaped upon bash (and X11, and...) make it work acceptably.

Try env | wc -l in bash. Now tell me why that value is so big.

>
> Anyway, thanks for the info.
>
> --On Tuesday, April 07, 2009 3:57 PM -0400 "J.R. Mauro" <jrm8005@gmail.com>
> wrote:
>
>> On Tue, Apr 7, 2009 at 2:21 PM, Eris Discordia <eris.discordia@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 bash
>> manpage. And getting readline to do anything sane is about as fun as
>> screwing around with a terminfo file.
>>
>>>
>>> --On Tuesday, April 07, 2009 10:31 PM +0800 sqweek <sqweek@gmail.com>
>>> wrote:
>>>
>>>> 2009/4/7 Eris Discordia <eris.discordia@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 Tuesday, April 07, 2009 8:09 AM -0700 ron minnich
>>> <rminnich@gmail.com> wrote:
>>>
>>>> On Tue, Apr 7, 2009 at 12:28 AM, Eris Discordia
>>>> <eris.discordia@gmail.com> wrote:
>>>>
>>>>>
>>>>> Like... readline(3)?
>>>>
>>>> one hopes not.
>>>>
>>>> ron
>>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>
>
>
>
>
>

Re: [9fans] a bit OT, programming style question

[Eris Discordia]

> Try env | wc -l in bash. Now tell me why that value is so big.

> [root@host ~]# env | wc -l
> 	37
> [root@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. Because:

> [root@host ~]# env | wc -c
> 	1404
> [root@host ~]#

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 
the diversity of hardware and configuration that still exists out there. 5 
of the other 18 lines are completely specific to my installation. That 
leaves us with 13 short lines.

Quite a considerable portion of UNIX-like systems, FreeBSD in this case, is 
the way it is not because the developers are stupid, rather because they 
have a "constituency" to tend to. They aren't carefree researchers with 
high ambitions.

--On Tuesday, April 07, 2009 11:04 PM -0400 "J.R. Mauro" 
<jrm8005@gmail.com> wrote:

> On Tue, Apr 7, 2009 at 9:48 PM, Eris Discordia <eris.discordia@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. And, in fact, the badness of
>> the implementation is even questionable in the light of bash's normal
>> behavior or the working .inputrc files I've been using for some time.
>
> Behavior is not indicative of good design. It just means that the
> bandaids heaped upon bash (and X11, and...) make it work acceptably.
>
> Try env | wc -l in bash. Now tell me why that value is so big.
>
>>
>> Anyway, thanks for the info.
>>
>> --On Tuesday, April 07, 2009 3:57 PM -0400 "J.R. Mauro"
>> <jrm8005@gmail.com> wrote:
>>
>>> On Tue, Apr 7, 2009 at 2:21 PM, Eris Discordia
>>> <eris.discordia@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 bash
>>> manpage. And getting readline to do anything sane is about as fun as
>>> screwing around with a terminfo file.
>>>
>>>>
>>>> --On Tuesday, April 07, 2009 10:31 PM +0800 sqweek <sqweek@gmail.com>
>>>> wrote:
>>>>
>>>>> 2009/4/7 Eris Discordia <eris.discordia@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 Tuesday, April 07, 2009 8:09 AM -0700 ron minnich
>>>> <rminnich@gmail.com> wrote:
>>>>
>>>>> On Tue, Apr 7, 2009 at 12:28 AM, Eris Discordia
>>>>> <eris.discordia@gmail.com> wrote:
>>>>>
>>>>>>
>>>>>> Like... readline(3)?
>>>>>
>>>>> one hopes not.
>>>>>
>>>>> ron
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>>
>>
>>
>>
>

Re: [9fans] a bit OT, programming style question

[erik quanstrom]

On Thu Apr  9 10:48:08 EDT 2009, eris.discordia@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 case, is
> the way it is not because the developers are stupid, rather because they
> have a "constituency" to tend to. They aren't carefree researchers with
> high ambitions.

this is the "space-shuttle dichotomy."  it's a false one.  it's a continuum.
its ends are dangerous.

on the one hand, if you change things, the new things are likely
to be buggy.  on the space shuttle, this is bad.  people die.

on the other hand, systems are not perfect.  and if the problems
are not addressed, eventually the system will need to much fixing
and will be abandoned.

yet bringing a new system on line is an even bigger risk.  everything
is new simultaneously.

it is interesting to me that some software manages to run off both
ends of this continuum at the same time.  in linux your termcap
from 1981 will still work, but software written to access /sys last
year is likely out-of-date.

your insinuation that *bsd is a real serious system and plan 9 is
a research system doesn't make any historical sense to me.  they
both started as research systems.  i am not aware of any law that
prevents a system that started as a research project from becoming
a serious production system.

i know of many thousands of plan 9 systems in production right
now.

- erik

Re: [9fans] a bit OT, programming style question

[Eris Discordia]

> 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 that some software manages to run off both
> ends of this continuum at the same time.  in linux your termcap
> from 1981 will still work, but software written to access /sys last
> year is likely out-of-date.

While I won't vouch for Linux as a good OS (user-land and kernel combined)
I understand what you see as its eccentricity is merely a side-effect of
openness. Tighten the development up and you get a BSD-style system
(committer/contributor/maintainer/grunt/user highest-to-lowest ranking,
with a demiurge position for Theo de Raadt). Tighten it even further up
with in-ken shared among a core group of old-timers and thoroughbreds
transmitted only to serious researchers and you get Plan 9.

You are right, after all. It all lies on a continuum. Actually, more
tightly regulated Linux distros such as Slackware readily demonstrate that;
they easily beat all-out all-open distros like Fedora (whose existence is
probably perceived at Red Hat as a big brainstorming project).

> your insinuation that *bsd is a real serious system and plan 9 is
> a research system doesn't make any historical sense to me.  they
> both started as research systems.  i am not aware of any law that
> prevents a system that started as a research project from becoming
> a serious production system.

What I am insinuating is more like this: any serious system will sooner or
later have to grow warts and/or contract herpes. That's an unavoidable
consequence of social life. If you do insist that Plan 9 has no warts, or
far less warts than the average, or that it has never seen a cold sore on
its upper lip then I'll happily conclude it has never lived socially. And I
haven't really ever used Plan 9 or "been into it." The no-herpes indicator
is that strong.

> i know of many thousands of plan 9 systems in production right
> now.

Good for you. Honestly.

--On Thursday, April 09, 2009 11:06 AM -0400 erik quanstrom
<quanstro@quanstro.net> wrote:

> On Thu Apr  9 10:48:08 EDT 2009, eris.discordia@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 case,
>> is  the way it is not because the developers are stupid, rather because
>> they  have a "constituency" to tend to. They aren't carefree researchers
>> with  high ambitions.
>
> this is the "space-shuttle dichotomy."  it's a false one.  it's a
> continuum. its ends are dangerous.
>
> on the one hand, if you change things, the new things are likely
> to be buggy.  on the space shuttle, this is bad.  people die.
>
> on the other hand, systems are not perfect.  and if the problems
> are not addressed, eventually the system will need to much fixing
> and will be abandoned.
>
> yet bringing a new system on line is an even bigger risk.  everything
> is new simultaneously.
>
> it is interesting to me that some software manages to run off both
> ends of this continuum at the same time.  in linux your termcap
> from 1981 will still work, but software written to access /sys last
> year is likely out-of-date.
>
> your insinuation that *bsd is a real serious system and plan 9 is
> a research system doesn't make any historical sense to me.  they
> both started as research systems.  i am not aware of any law that
> prevents a system that started as a research project from becoming
> a serious production system.
>
> i know of many thousands of plan 9 systems in production right
> now.
>
> - erik
>

Re: [9fans] a bit OT, programming style question

[john]

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 Even On
This List", with a cast of thousands, three hundred dancing rabbits, and
a world-class score (if you have a compatible audio device)!



John

Re: [9fans] a bit OT, programming style question

[Balwinder S Dheeman]

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,
> mean--just my idea, of course.
>
>> it is interesting to me that some software manages to run off both
>> ends of this continuum at the same time.  in linux your termcap
>> from 1981 will still work, but software written to access /sys last
>> year is likely out-of-date.
>
> While I won't vouch for Linux as a good OS (user-land and kernel
> combined) I understand what you see as its eccentricity is merely a
> side-effect of openness. Tighten the development up and you get a
> BSD-style system (committer/contributor/maintainer/grunt/user
> highest-to-lowest ranking, with a demiurge position for Theo de Raadt).
> Tighten it even further up with in-ken shared among a core group of
> old-timers and thoroughbreds transmitted only to serious researchers and
> you get Plan 9.
>
> You are right, after all. It all lies on a continuum. Actually, more
> tightly regulated Linux distros such as Slackware readily demonstrate
> that; they easily beat all-out all-open distros like Fedora (whose
> existence is probably perceived at Red Hat as a big brainstorming project).
>
>> your insinuation that *bsd is a real serious system and plan 9 is
>> a research system doesn't make any historical sense to me.  they
>> both started as research systems.  i am not aware of any law that
>> prevents a system that started as a research project from becoming
>> a serious production system.
>
> What I am insinuating is more like this: any serious system will sooner
> or later have to grow warts and/or contract herpes. That's an
> unavoidable consequence of social life. If you do insist that Plan 9 has
> no warts, or far less warts than the average, or that it has never seen
> a cold sore on its upper lip then I'll happily conclude it has never
> lived socially. And I haven't really ever used Plan 9 or "been into it."
> The no-herpes indicator is that strong.

I for one could not resist adding that no doubt, Plan9 and *BSD are
quite clean and well maintained systems, but these IMHO, have but only a
little use for an average user, because of a noticeable scarcity of
hardware drivers and real applications. Hence, who cares a cow gone dry.

Years ago, in an article, 'Program design in UNIX environment', Rob Pike
and Brain W. Kernighan discussed UNIX programming environment, program
design, tools and some problems introduced by the users, after UNIX
commercially became a success. Have, they mentioned and, or do they know
who indeed is behind that success?

>> 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?

--
Dr Balwinder S "bsd" Dheeman          Registered Linux User: #229709
Anu'z Linux@HOME (Unix Shoppe)        Machines: #168573, 170593, 259192
Chandigarh, UT, 160062, India         Plan9, T2, Arch/Debian/FreeBSD/XP
Home: http://cto.homelinux.net/~bsd/  Visit: http://counter.li.org/

Re: [9fans] a bit OT, programming style question

[erik quanstrom]

> >> 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 was specificly *not* making an appeal to the majority.

maybe you misunderstood, but from where i sit your
argument consists of putting words in my mouth and
a logical fallacy.

- erik

Re: [9fans] a bit OT, programming style question

[Devon H. O'Dell]

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)

Re: [9fans] a bit OT, programming style question

[J.R. Mauro]

On Thu, Apr 9, 2009 at 6:34 PM, Eris Discordia <eris.discordia@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 silver, if not a golden, mean--just my
> idea, of course.
>
>> it is interesting to me that some software manages to run off both
>> ends of this continuum at the same time.  in linux your termcap
>> from 1981 will still work, but software written to access /sys last
>> year is likely out-of-date.
>
> While I won't vouch for Linux as a good OS (user-land and kernel combined) I
> understand what you see as its eccentricity is merely a side-effect of
> openness. Tighten the development up and you get a BSD-style system
> (committer/contributor/maintainer/grunt/user highest-to-lowest ranking, with
> a demiurge position for Theo de Raadt). Tighten it even further up with
> in-ken shared among a core group of old-timers and thoroughbreds transmitted
> only to serious researchers and you get Plan 9.
>
> You are right, after all. It all lies on a continuum. Actually, more tightly
> regulated Linux distros such as Slackware readily demonstrate that; they
> easily beat all-out all-open distros like Fedora (whose existence is
> probably perceived at Red Hat as a big brainstorming project).
>
>> your insinuation that *bsd is a real serious system and plan 9 is
>> a research system doesn't make any historical sense to me.  they
>> both started as research systems.  i am not aware of any law that
>> prevents a system that started as a research project from becoming
>> a serious production system.
>
> What I am insinuating is more like this: any serious system will sooner or
> later have to grow warts and/or contract herpes. That's an unavoidable
> consequence of social life. If you do insist that Plan 9 has no warts, or
> far less warts than the average, or that it has never seen a cold sore on
> its upper lip then I'll happily conclude it has never lived socially. And I
> haven't really ever used Plan 9 or "been into it." The no-herpes indicator
> is that strong.

So you're saying that I don't have a social life since I've never gotten herpes?

I suppose from your demeanor that we can compare you to, say, Windows ME?

>
>> i know of many thousands of plan 9 systems in production right
>> now.
>
> Good for you. Honestly.
>
> --On Thursday, April 09, 2009 11:06 AM -0400 erik quanstrom
> <quanstro@quanstro.net> wrote:
>
>> On Thu Apr  9 10:48:08 EDT 2009, eris.discordia@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 case,
>>> is  the way it is not because the developers are stupid, rather because
>>> they  have a "constituency" to tend to. They aren't carefree researchers
>>> with  high ambitions.
>>
>> this is the "space-shuttle dichotomy."  it's a false one.  it's a
>> continuum. its ends are dangerous.
>>
>> on the one hand, if you change things, the new things are likely
>> to be buggy.  on the space shuttle, this is bad.  people die.
>>
>> on the other hand, systems are not perfect.  and if the problems
>> are not addressed, eventually the system will need to much fixing
>> and will be abandoned.
>>
>> yet bringing a new system on line is an even bigger risk.  everything
>> is new simultaneously.
>>
>> it is interesting to me that some software manages to run off both
>> ends of this continuum at the same time.  in linux your termcap
>> from 1981 will still work, but software written to access /sys last
>> year is likely out-of-date.
>>
>> your insinuation that *bsd is a real serious system and plan 9 is
>> a research system doesn't make any historical sense to me.  they
>> both started as research systems.  i am not aware of any law that
>> prevents a system that started as a research project from becoming
>> a serious production system.
>>
>> i know of many thousands of plan 9 systems in production right
>> now.
>>
>> - erik
>>
>
>

Re: [9fans] a bit OT, programming style question

[J.R. Mauro]

On Thu, Apr 9, 2009 at 9:44 AM, Eris Discordia <eris.discordia@gmail.com> wrote:
>> Try env | wc -l in bash. Now tell me why that value is so big.
>
>> [root@host ~]# env | wc -l
>>        37
>> [root@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. Because:
>
>> [root@host ~]# env | wc -c
>>        1404
>> [root@host ~]#
>
> 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 the
> diversity of hardware and configuration that still exists out there. 5 of
> the other 18 lines are completely specific to my installation. That leaves
> us with 13 short lines.

Grumble... s/env/set

And then you see the guts of bash spill out.

>
> Quite a considerable portion of UNIX-like systems, FreeBSD in this case, is
> the way it is not because the developers are stupid, rather because they
> have a "constituency" to tend to. They aren't carefree researchers with high
> ambitions.

I leveled no claims against *BSD or Linux. I'm simply trying to point
out that bash is utter garbage, as its own man page indicates.

>
> --On Tuesday, April 07, 2009 11:04 PM -0400 "J.R. Mauro" <jrm8005@gmail.com>
> wrote:
>
>> On Tue, Apr 7, 2009 at 9:48 PM, Eris Discordia <eris.discordia@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. And, in fact, the badness of
>>> the implementation is even questionable in the light of bash's normal
>>> behavior or the working .inputrc files I've been using for some time.
>>
>> Behavior is not indicative of good design. It just means that the
>> bandaids heaped upon bash (and X11, and...) make it work acceptably.
>>
>> Try env | wc -l in bash. Now tell me why that value is so big.
>>
>>>
>>> Anyway, thanks for the info.
>>>
>>> --On Tuesday, April 07, 2009 3:57 PM -0400 "J.R. Mauro"
>>> <jrm8005@gmail.com> wrote:
>>>
>>>> On Tue, Apr 7, 2009 at 2:21 PM, Eris Discordia
>>>> <eris.discordia@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 bash
>>>> manpage. And getting readline to do anything sane is about as fun as
>>>> screwing around with a terminfo file.
>>>>
>>>>>
>>>>> --On Tuesday, April 07, 2009 10:31 PM +0800 sqweek <sqweek@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> 2009/4/7 Eris Discordia <eris.discordia@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 Tuesday, April 07, 2009 8:09 AM -0700 ron minnich
>>>>> <rminnich@gmail.com> wrote:
>>>>>
>>>>>> On Tue, Apr 7, 2009 at 12:28 AM, Eris Discordia
>>>>>> <eris.discordia@gmail.com> wrote:
>>>>>>
>>>>>>>
>>>>>>> Like... readline(3)?
>>>>>>
>>>>>> one hopes not.
>>>>>>
>>>>>> ron
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>
>

Re: [9fans] a bit OT, programming style question

[Charles Forsyth]

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.

Re: [9fans] a bit OT, programming style question

[Richard Miller]

> 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

Re: [9fans] a bit OT, programming style question

[Devon H. O'Dell]

2009/4/9 Richard Miller <9fans@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 I'm
guessing each line is more than 1 character. However,

$ set | wc -l
64

I don't quite get that locally.

--dho

Re: [9fans] a bit OT, programming style question

[erik quanstrom]

> $ set | wc -l
> 64
>
> I don't quite get that locally.

please upgrade your distribution.

- erik

Re: [9fans] a bit OT, programming style question

[J.R. Mauro]

> 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 zsh is that it
compiles them to bytecode instead of this insanity that bash employs.

Re: [9fans] a bit OT, programming style question

[Eris Discordia]

> 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 -0400 "J.R. Mauro"
<jrm8005@gmail.com> wrote:

>> 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 zsh is that it
> compiles them to bytecode instead of this insanity that bash employs.
>

Re: [9fans] a bit OT, programming style question

[J.R. Mauro]

On Thu, Apr 9, 2009 at 6:09 PM, Eris Discordia <eris.discordia@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 be a script/program in its own right?

No, bash's completion system is what's responsible for line numbers in
the thousands.

>
> --On Thursday, April 09, 2009 3:34 PM -0400 "J.R. Mauro" <jrm8005@gmail.com>
> wrote:
>
>>> 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 zsh is that it
>> compiles them to bytecode instead of this insanity that bash employs.
>>
>
>
>
>
>
>

Re: [9fans] a bit OT, programming style question

[Eris Discordia]

> 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. Mauro" <jrm8005@gmail.com>
wrote:

> On Thu, Apr 9, 2009 at 6:09 PM, Eris Discordia <eris.discordia@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 be a script/program in its own right?
>
> No, bash's completion system is what's responsible for line numbers in
> the thousands.
>
>>
>> --On Thursday, April 09, 2009 3:34 PM -0400 "J.R. Mauro"
>> <jrm8005@gmail.com> wrote:
>>
>>>> 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 zsh is that it
>>> compiles them to bytecode instead of this insanity that bash employs.
>>>
>>
>>
>>
>>
>>
>>
>

Re: [9fans] a bit OT, programming style question

[Richard Miller]

> No, it's very likely bigger. wc -l is lines of course

Silly me, I was (optimistically) confusing it with wc -c.

Re: [9fans] a bit OT, programming style question

[Bakul Shah]

On Thu, 09 Apr 2009 15:28:58 EDT "Devon H. O'Dell" <devon.odell@gmail.com>  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     106    2107

I prefer the cadillac of shells (zsh) & the vw bug (rc).

Re: [9fans] a bit OT, programming style question

[J.R. Mauro]

>
> I prefer the cadillac of shells (zsh) & the vw bug (rc).
>

I like this.

Re: [9fans] a bit OT, programming style question

[erik quanstrom]

> $ echo $BASH_VERSION
> 4.0.10(2)-release
> $ set|wc
>       72     106    2107

if this is the criteria, plan 9 loses:

; printenv|wc
     73     210    2417

- erik

p.s.

; cat /bin/printenv
#!/bin/rc
rfork en
cd /env
for(i in *){
	if(! test -s $i)
		echo $i ^ '=()'
	if not{
		if(~ $i 'fn#'*) {
			ifs='#' i = `{echo -n $i}
			i = $i(2);
		}
		whatis $i
	}
}

Re: [9fans] a bit OT, programming style question

[Devon H. O'Dell]

2009/4/9 Bakul Shah <bakul+plan9@bitblocks.com>:
> On Thu, 09 Apr 2009 15:28:58 EDT "Devon H. O'Dell" <devon.odell@gmail.com>  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     106    2107

It is actually CentOS 5 (work) with p9p.

--dho

Re: [9fans] a bit OT, programming style question

[Eris Discordia]

Seems Charles Forsyth's bash (or wc -l) works very differently.

> [root@host ~/]# set | wc -l
>       49
> [root@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 over half of which are from the 
environment, 972 of them in TERMCAP.

--On Thursday, April 09, 2009 3:28 PM -0400 "Devon H. O'Dell" 
<devon.odell@gmail.com> wrote:

> 2009/4/9 Richard Miller <9fans@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 I'm
> guessing each line is more than 1 character. However,
>
> $ set | wc -l
> 64
>
> I don't quite get that locally.
>
> --dho
>

Re: [9fans] a bit OT, programming style question

[ron minnich]

you could break out re expansion into a separate program :-)

ron

Re: [9fans] a bit OT, programming style question

[Corey]

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.

Re: [9fans] a bit OT, programming style question

[ron minnich]

On Tue, Apr 7, 2009 at 9:05 AM, Corey <corey@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 up the shell code with different
> flags or whatever.

somebody is going to jump in very soon and tell us why this is funny :-)

ron

Re: [9fans] a bit OT, programming style question

[erik quanstrom]

> > 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

Re: [9fans] a bit OT, programming style question

[dave.l]

>>> 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 prepubescents ...

"Because the V6 shell did it, that's why.".

Re: [9fans] a bit OT, programming style question

[erik quanstrom]

> 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