[9fans] rc vs sh

[9fans] rc vs sh

[Rudolf Sykora]

Hello,

I am just curious...
Here
http://9fans.net/archive/2007/11/120

Russ Cox writes he uses bash as his default shell. Does anybody know
the reason? Is this for practicality within the linux environment? Or
has he found rc too limiting?

Ruda

Re: [9fans] rc vs sh

[hiro]

because he uses a mac.

Re: [9fans] rc vs sh

[dexen deVries]

On Tuesday 28 of August 2012 10:57:06 Rudolf Sykora wrote:
> Hello,
> 
> I am just curious...
> Here
> http://9fans.net/archive/2007/11/120
> 
> Russ Cox writes he uses bash as his default shell. Does anybody know
> the reason? Is this for practicality within the linux environment? Or
> has he found rc too limiting?

FWIW, i'm using bash as the interactive shell too, in `konsole' terminal  
emulator, because of bash' interactive line edition and command history. 9term 
doesn't fit me.

all  scripting -- both standalone and in mkfiles -- goes in rc, thou.


-- 
dexen deVries

[[[↓][→]]]

Re: [9fans] rc vs sh

[Rudolf Sykora]

On 28 August 2012 11:52, dexen deVries <dexen.devries@gmail.com> wrote:
> FWIW, i'm using bash as the interactive shell too, in `konsole' terminal
> emulator, because of bash' interactive line edition and command history. 9term
> doesn't fit me.

The thing is that he, according to the reference, switches off
the line edition provided by the readline library.
Hence, although I understand that the mentioned edition tools may be a reason
for using bash for somebody, it doesn't really seem to be Russ' reason.

Ruda

Re: [9fans] rc vs sh

[Lucio De Re]

> FWIW, i'm using bash as the interactive shell too, in `konsole' terminal
> emulator, because of bash' interactive line edition and command history. 9term
> doesn't fit me.
>
> all  scripting -- both standalone and in mkfiles -- goes in rc, thou.

Russ uses bash because it is uniformly crappy across all architectures
he has an interest in.  There's a similar conversation going on in the
go-nuts user group on google.  It is illuminating.

++L

Re: [9fans] rc vs sh

[Rudolf Sykora]

On 28 August 2012 15:07, Lucio De Re <lucio@proxima.alt.za> wrote:
> Russ uses bash because it is uniformly crappy across all architectures
> he has an interest in.  There's a similar conversation going on in the
> go-nuts user group on google.  It is illuminating.

I have been unable to locate the conversation...
Anyway, I do not understand how uniform crappiness can be advantageous...

Ruda

Re: [9fans] rc vs sh

[Lucio De Re]

> Anyway, I do not understand how uniform crappiness can be advantageous...

The issue raised on Go-Nuts is that Bash shouldn't be used for
installing Go, /bin/sh should be used instead.  The response is that
Bash is the most uniformly implemented of the /bin/sh's out there and
that none of the other shells (generally referred to as /bin/sh) can
be relied upon not to have incompatible foibles that would trip up a
complicated script headed #!/bin/sh.  Therefore, intentionally using
#!/bin/bash (or #!/usr/bin/env -c /bin/bash - from memory) is much
more likely to work without adjustments.

Hence, it makes sense to stick to bash in one's day-to-day work.

Of course, rc would be preferable, but the target platforms for Go are
not all adequately endowed, and Byron's rc proves the point: it is
slightly incompatible with Plan 9's rc.

++L

Re: [9fans] rc vs sh

[Kurt H Maier]

On Tue, Aug 28, 2012 at 04:10:39PM +0200, Lucio De Re wrote:
> > Anyway, I do not understand how uniform crappiness can be advantageous...
>
> The issue raised on Go-Nuts is that Bash shouldn't be used for
> installing Go, /bin/sh should be used instead.  The response is that
> Bash is the most uniformly implemented of the /bin/sh's out there and
> that none of the other shells (generally referred to as /bin/sh) can
> be relied upon not to have incompatible foibles that would trip up a
> complicated script headed #!/bin/sh.

Typical Go shit there.  If the scripts are so complicated that it's a
pain in the ass to find a way to run them, fix the stupid scripts.

Re: [9fans] rc vs sh

[Lucio De Re]

> ypical Go shit there.  If the scripts are so complicated that it's a
> pain in the ass to find a way to run them, fix the stupid scripts.

They did, by building the "go" command.

Do you think you can provide any guarantees that the subset of /bin/sh
features common to all current instances of /bin/sh is adequate to
build a moderately demanding open source package?

Or are you oriented towards kiloLOCs of test code to see which
features are implemented and provide compatability a la autoconf?

++L

Re: [9fans] rc vs sh

[Kurt H Maier]

On Tue, Aug 28, 2012 at 04:52:34PM +0200, Lucio De Re wrote:
>
> Or are you oriented towards kiloLOCs of test code to see which
> features are implemented and provide compatability a la autoconf?
>

Excellent example of a false dilemma.  I'm oriented towards exerting the
effort to make something that isn't shitty.  I'm at peace with the go
developers decision to avoid that effort.  Are you?

Anyway, bash uses autoconf as well.  So all you've done is push the mess
one step farther away from your code.  Why not just cut the cord?  I'm
hearing "shell scripting is easy" and I'm hearing "acceptance testing is
too hard."  Which is it?  I can write portable shell scripts, but the
idiots on golang-nuts have explicitly said they don't WANT portable
shell scripts.  They want to rely on bash, and all the GNU bullshit that
brings with it.

Re: [9fans] rc vs sh

[Dan Cross]

On Tue, Aug 28, 2012 at 8:35 PM, Kurt H Maier <khm-9@intma.in> wrote:
> On Tue, Aug 28, 2012 at 04:52:34PM +0200, Lucio De Re wrote:
>> Or are you oriented towards kiloLOCs of test code to see which
>> features are implemented and provide compatability a la autoconf?
>
> Excellent example of a false dilemma.  I'm oriented towards exerting the
> effort to make something that isn't shitty.

Wonderful!  Please point me to your new programming language so I can
have a look?

> I'm at peace with the go
> developers decision to avoid that effort.  Are you?

So are you saying that because they use bash to build the system, the
language is shitty?  Or just the build system is shitty?

> Anyway, bash uses autoconf as well.  So all you've done is push the mess
> one step farther away from your code.  Why not just cut the cord?  I'm
> hearing "shell scripting is easy" and I'm hearing "acceptance testing is
> too hard."  Which is it?  I can write portable shell scripts, but the
> idiots on golang-nuts have explicitly said they don't WANT portable
> shell scripts.  They want to rely on bash, and all the GNU bullshit that
> brings with it.

Writing a shell script is easy.  Writing a shell script to build a
non-trivial piece of software across $n$ different platforms is hard.

I can't speak for the Go team, but I suspect their decision is a
pragmatic compromise: should they spend their (limited) time creating
and maintaining a portable version of 'rc' that can be built (how,
exactly?  With a script that's just a straight run of commands or
something?) on a bunch of different platforms so that they can write
some beautiful script to build Go, or should they produce some lowest
common denominator shell script in the most common shell out there
that builds the system and then spend the time they save concentrating
on building a cool programming language?

I don't think the gain from the former approach is really worth the
cost to the latter.

To put it another way, why not cut the cord?  Because it takes time
away from doing something they consider more important.

More generally, if your impression of Go as a language ("Typical go
shit...") is based on what shell they chose for the build script, then
I'm not sure you have your priorities straight.

          - Dan C.

Re: [9fans] rc vs sh

[Kurt H Maier]

On Tue, Aug 28, 2012 at 08:48:39PM +0530, Dan Cross wrote:
>
> Wonderful!  Please point me to your new programming language so I can
> have a look?
>

I don't think it would do you any good, since you are apparently unable
to differentiate between programming languages and build systems.

>
> So are you saying that because they use bash to build the system, the
> language is shitty?  Or just the build system is shitty?
>

I have other issues with Go as a language, but the build system is
unmitigated shit.

>
> Writing a shell script is easy.  Writing a shell script to build a
> non-trivial piece of software across $n$ different platforms is hard.
>

And yet people do it all the time.

>
> To put it another way, why not cut the cord?  Because it takes time
> away from doing something they consider more important.
>

Incorrect.  There's a whole world of people out there; some of them
would be willing to build and maintain an elegant, portable shell
script.  That's the point of having an open development process, I
thought.  I understand the need for the core devs to focus on the task
at hand: language building.  It is idiotic not to delegate the build
system to someone willing and able to devote the time to it.

> More generally, if your impression of Go as a language ("Typical go
> shit...") is based on what shell they chose for the build script, then
> I'm not sure you have your priorities straight.

Fortunately, your assessment of my priorities is meaningless.  "Typical
Go shit" referred to the ceaseless lack of focus on quality endemic to a
schizophrenic community that was organized around a language without a
mission.  Go is still evolving in two separate directions; one camp sees
it as yet another language for web shit, and one camp sees it as a real
programming language for actual programs.  I long ago lost interest in
seeing who will eventually win, but in the meantime every bad decision
seems to have some chorus of supporters who take every piece of
criticism personally.  *Those* are the people who need to examine their
priorities.

Re: [9fans] rc vs sh

[Dan Cross]

On Tue, Aug 28, 2012 at 9:00 PM, Kurt H Maier <khm-9@intma.in> wrote:
> On Tue, Aug 28, 2012 at 08:48:39PM +0530, Dan Cross wrote:
>> Wonderful!  Please point me to your new programming language so I can
>> have a look?
>
> I don't think it would do you any good, since you are apparently unable
> to differentiate between programming languages and build systems.

Oh no, I can't.  Please, by all means, point me to whatever it is that
you have produced that demonstrates your prowess in this area so that
I can learn more.

>> So are you saying that because they use bash to build the system, the
>> language is shitty?  Or just the build system is shitty?
>
> I have other issues with Go as a language, but the build system is
> unmitigated shit.

Irrelevant.

>> Writing a shell script is easy.  Writing a shell script to build a
>> non-trivial piece of software across $n$ different platforms is hard.
>
> And yet people do it all the time.

Irrelevant.

>> To put it another way, why not cut the cord?  Because it takes time
>> away from doing something they consider more important.
>
> Incorrect.  There's a whole world of people out there; some of them
> would be willing to build and maintain an elegant, portable shell
> script.  That's the point of having an open development process, I
> thought.  I understand the need for the core devs to focus on the task
> at hand: language building.  It is idiotic not to delegate the build
> system to someone willing and able to devote the time to it.

Not the way that community is currently set up, so irrelevant.

>> More generally, if your impression of Go as a language ("Typical go
>> shit...") is based on what shell they chose for the build script, then
>> I'm not sure you have your priorities straight.
>
> Fortunately, your assessment of my priorities is meaningless.  "Typical
> Go shit" referred to the ceaseless lack of focus on quality endemic to a
> schizophrenic community that was organized around a language without a
> mission.  Go is still evolving in two separate directions; one camp sees
> it as yet another language for web shit, and one camp sees it as a real
> programming language for actual programs.  I long ago lost interest in
> seeing who will eventually win, but in the meantime every bad decision
> seems to have some chorus of supporters who take every piece of
> criticism personally.  *Those* are the people who need to examine their
> priorities.

And yet the produced the language, and people use it.  But you clearly
know better, so please, by all means, show me what you've produced
that's useful that I can learn something from.

        - Dan C.

Re: [9fans] rc vs sh

[Kurt H Maier]

On Tue, Aug 28, 2012 at 09:15:35PM +0530, Dan Cross wrote:
>
> Oh no, I can't.  Please, by all means, point me to whatever it is that
> you have produced that demonstrates your prowess in this area so that
> I can learn more.

you sound upset

>
> Irrelevant.
>

The topic at hand is not irrelevant to the topic at hand.

>
> Irrelevant.
>

The topic at hand is not irrelevant to the topic at hand.

>
> Not the way that community is currently set up, so irrelevant.
>

Hence "typical Go shit."

>
> And yet the produced the language, and people use it.  But you clearly
> know better, so please, by all means, show me what you've produced
> that's useful that I can learn something from.
>

I have no urges to prove myself to you.  They have produced a language,
yes.  They have not produced a worthwhile build system or development
community.

Re: [9fans] rc vs sh

[Dan Cross]

On Tue, Aug 28, 2012 at 11:13 PM, Kurt H Maier <khm-9@intma.in> wrote:
> On Tue, Aug 28, 2012 at 09:15:35PM +0530, Dan Cross wrote:
>> Oh no, I can't.  Please, by all means, point me to whatever it is that
>> you have produced that demonstrates your prowess in this area so that
>> I can learn more.
>
> you sound upset

Not at all.

> [...]
>> And yet the produced the language, and people use it.  But you clearly
>> know better, so please, by all means, show me what you've produced
>> that's useful that I can learn something from.
>
> I have no urges to prove myself to you.

I see no reason to take you your opinion any more seriously than
anyone else's.  You're entitled to it; that doesn't mean you are
right.

> They have produced a language, yes.
> They have not produced a worthwhile build system

You are conflating bootstrapping the language with the language's
build system.  The go command is actually quite nice.

The use of bash in Go is tiny.  Why fixate on it when you could go
build something useful, instead?

> or development community.

Evidence suggests otherwise.

Anyway, I have neither the time nor the inclination to get into a
pissing match with some random person on the Internet about Go's use
of bash.  If it's such a serious problem for you, well, I hope you
figure out a way to work around it.  If not, then I don't know what to
tell you.  In either case, good luck!

        - Dan C.

Re: [9fans] rc vs sh

[Kurt H Maier]

On Tue, Aug 28, 2012 at 11:50:27PM +0530, Dan Cross wrote:
>
> You are conflating bootstrapping the language with the language's
> build system.  The go command is actually quite nice.
>

Also, the go command is useless unless the bootstrap build system can
construct it.  I'm not conflating anything, I'm just not talking about
the build system you like.

> The use of bash in Go is tiny.  Why fixate on it when you could go
> build something useful, instead?

Because a corrected build system would be useful to me.  Is this a
complicated concept?

>
> Evidence suggests otherwise.
>

I have yet to see such.

> Anyway, I have neither the time nor the inclination to get into a
> pissing match with some random person on the Internet about Go's use
> of bash.  If it's such a serious problem for you, well, I hope you
> figure out a way to work around it.  If not, then I don't know what to
> tell you.  In either case, good luck!

I wish you would have ascertained you had nothing to tell me earlier in
the thread.  Thank you for your support.

Re: [9fans] rc vs sh

[Dan Cross]

One last thing:

On Tue, Aug 28, 2012 at 11:56 PM, Kurt H Maier <khm-9@intma.in> wrote:
> On Tue, Aug 28, 2012 at 11:50:27PM +0530, Dan Cross wrote:
>> You are conflating bootstrapping the language with the language's
>> build system.  The go command is actually quite nice.
>
> Also, the go command is useless unless the bootstrap build system can
> construct it.  I'm not conflating anything, I'm just not talking about
> the build system you like.

I don't *like* it, I just don't *hate* it.  Two very different concepts.

>> The use of bash in Go is tiny.  Why fixate on it when you could go
>> build something useful, instead?
>
> Because a corrected build system would be useful to me.

Well, if you could explain a) how it's currently broken, and b) how a
'corrected' version would be useful, others might be more sympathetic
to your concerns.  From most perspectives, it doesn't appear broken at
all; it works fine, it's just not what you would have done.

> Is this a complicated concept?

No.  But it's basic tact and consideration to fully explain oneself if
one expects a useful response.

>> Evidence suggests otherwise.
>
> I have yet to see such.

*shrug*  Don't know what to tell you, then.

>> Anyway, I have neither the time nor the inclination to get into a
>> pissing match with some random person on the Internet about Go's use
>> of bash.  If it's such a serious problem for you, well, I hope you
>> figure out a way to work around it.  If not, then I don't know what to
>> tell you.  In either case, good luck!
>
> I wish you would have ascertained you had nothing to tell me earlier in
> the thread.  Thank you for your support.

I somehow get the feeling that few people have anything to tell you
that you're willing to listen to.

        - Dan C.

Re: [9fans] rc vs sh

[Kurt H Maier]

On Wed, Aug 29, 2012 at 12:09:13AM +0530, Dan Cross wrote:
> Well, if you could explain a) how it's currently broken, and b) how a
> 'corrected' version would be useful, others might be more sympathetic
> to your concerns.  From most perspectives, it doesn't appear broken at
> all; it works fine, it's just not what you would have done.

Literally dozens of people have already explained why this would be
useful.  It's currently broken because it makes unnecessary assumptions
about target platforms in exchange for less up-front work on the part of
the devs.  These assumptions are often incorrect.

> *shrug*  Don't know what to tell you, then.

Thanks for your input.

> I somehow get the feeling that few people have anything to tell you
> that you're willing to listen to.

I'm enriched by this information.

Re: [9fans] rc vs sh

[Jeremy Jackins]

> Well, if you could explain a) how it's currently broken, and b) how a
> 'corrected' version would be useful, others might be more sympathetic
> to your concerns.  From most perspectives, it doesn't appear broken at
> all; it works fine, it's just not what you would have done.

Speak for yourself, please.

Re: [9fans] rc vs sh

[Dan Cross]

[-- Attachment #1: Type: text/plain, Size: 520 bytes --]

On Aug 29, 2012 2:14 AM, "Jeremy Jackins" <jeremyjackins@gmail.com> wrote:
> > Well, if you could explain a) how it's currently broken, and b) how a
> > 'corrected' version would be useful, others might be more sympathetic
> > to your concerns.  From most perspectives, it doesn't appear broken at
> > all; it works fine, it's just not what you would have done.
>
> Speak for yourself, please.

Which part?  One was a request to provide a substantive argument, the other
an objective fact.

        - Dan C.

[-- Attachment #2: Type: text/html, Size: 716 bytes --]

Re: [9fans] rc vs sh

[Uriel]

On Tue, Aug 28, 2012 at 5:30 PM, Kurt H Maier <khm-9@intma.in> wrote:
> On Tue, Aug 28, 2012 at 08:48:39PM +0530, Dan Cross wrote:
>
>> So are you saying that because they use bash to build the system, the
>> language is shitty?  Or just the build system is shitty?
>>
>
> I have other issues with Go as a language, but the build system is
> unmitigated shit.
>
>>
>> Writing a shell script is easy.  Writing a shell script to build a
>> non-trivial piece of software across $n$ different platforms is hard.
>>
>
> And yet people do it all the time.

Go currently builds out of the box on Linux, FreeBSD, OS X, Windows,
and Plan 9 (and probably more places), I don't know many build systems
that can do that.

The build system was basically replaced by Russ since you last looked at it.

The remaining few bash lines are there basically for historical
reasons, because Russ (or anyone else) could not be bothered to
replace them with Go or C code which is what is used in the rest of
the build system.

Which again, makes this whole thread even more ridiculous, as in the
time you people have spent whining about it you could have removed the
last remaining lines of bash from the Go build system. But guess what?
Nobody really cares.

This whole argument has turned into a typical bike shed, everyone has
an opinion because it is such a trivial matter that anyone can easily
argue about it for hours.

>>
>> To put it another way, why not cut the cord?  Because it takes time
>> away from doing something they consider more important.
>>
>
> Incorrect.  There's a whole world of people out there; some of them
> would be willing to build and maintain an elegant, portable shell
> script.  That's the point of having an open development process, I
> thought.  I understand the need for the core devs to focus on the task
> at hand: language building.  It is idiotic not to delegate the build
> system to someone willing and able to devote the time to it.

Nobody has volunteered to do it, so to blame Russ for actually solving
a problem nobody else has bothered to work on is very unfair.




>> More generally, if your impression of Go as a language ("Typical go
>> shit...") is based on what shell they chose for the build script, then
>> I'm not sure you have your priorities straight.
>
> Fortunately, your assessment of my priorities is meaningless.  "Typical
> Go shit" referred to the ceaseless lack of focus on quality endemic to a
> schizophrenic community that was organized around a language without a
> mission.  Go is still evolving in two separate directions; one camp sees
> it as yet another language for web shit, and one camp sees it as a real
> programming language for actual programs.  I long ago lost interest in
> seeing who will eventually win, but in the meantime every bad decision
> seems to have some chorus of supporters who take every piece of
> criticism personally.  *Those* are the people who need to examine their
> priorities.

Go is not "still evolving", Go 1 was released a while ago, and there
are absolutely no plans to change the language for the foreseeable
future.

Whatever it is used for "web shit" or "real programs" doesn't change
the language in any way.

And if you think ken can be persuaded to change the language based on
what people building "web shit" wants, then you really don't know ken
much.

Re: [9fans] rc vs sh

[Lucio De Re]

> On Tue, Aug 28, 2012 at 04:52:34PM +0200, Lucio De Re wrote:
>>
>> Or are you oriented towards kiloLOCs of test code to see which
>> features are implemented and provide compatability a la autoconf?
>>
>
> Excellent example of a false dilemma.  I'm oriented towards exerting the
> effort to make something that isn't shitty.  I'm at peace with the go
> developers decision to avoid that effort.  Are you?
>
Sure, feel free to make something that isn't shitty, there's plenty
out there that can be improved.  The machinery to install Go (from
sources) is hardly the most important amongst them.

And, yes, I am: I use Plan 9 as my development platform, /bin/ksh
(pdksh, I presume) as my Unix shell on NetBSD.  On Ubuntu I could not
give it a passing thought, my environment gets recycled way too often
to bother.

What the Go Team choose to use as the underlying shell isn't
important, unless it impacts their delivery of the Go code.  Arguing
that there are in fact portable /bin/sh scripts that can be written
does not actually write such scripts.  No one stops anyone from taking
the purportedly "bash" scripts, converting them to tidy, clean /bin/sh
scripts and submitting them to the Go Team for inclusion.  The Go
Team's reaction will still be: "How do you know that these scripts
will work under all possible instances of /bin/sh?"  Solution: replace
the #!/bin/sh with #!/usr/bin/env -c /bin/bash.  Why not?

> Anyway, bash uses autoconf as well.  So all you've done is push the mess
> one step farther away from your code.  Why not just cut the cord?  I'm
> hearing "shell scripting is easy" and I'm hearing "acceptance testing is
> too hard."  Which is it?  I can write portable shell scripts, but the
> idiots on golang-nuts have explicitly said they don't WANT portable
> shell scripts.  They want to rely on bash, and all the GNU bullshit that
> brings with it.

Bash using Autoconf is a straw man, there are almost certainly binary
releases of Bash out there for all Unix-y platforms on which the Go
development system is likely to work or be portable to.  I may
misremember, but before the Go tool was released, the Plan 9 release
managed to get itself compiled using ape/sh.  As far as I can tell,
the dependence isn't in Bash features as much as in the consistency
across Bash versions.

++L

Re: [9fans] rc vs sh

[Kurt H Maier]

On Tue, Aug 28, 2012 at 05:36:58PM +0200, Lucio De Re wrote:
>
> Sure, feel free to make something that isn't shitty, there's plenty
> out there that can be improved.  The machinery to install Go (from
> sources) is hardly the most important amongst them.
>

The Go team has already explicitly stated they are note interested in a
better build system.  I don't know if it's plain NIH or a secret bash
fetish, but they're not buying.  Improving software is not a zero-sum
game; Go development is not a closed system.  The build system can be
improved without impeding other progress.

> Solution: replace
> the #!/bin/sh with #!/usr/bin/env -c /bin/bash.  Why not?

Because there are plenty of systems out there without env or bash.

> I may
> misremember, but before the Go tool was released, the Plan 9 release
> managed to get itself compiled using ape/sh.  As far as I can tell,
> the dependence isn't in Bash features as much as in the consistency
> across Bash versions.
>

...which is another unproved assumption.

Re: [9fans] rc vs sh

[erik quanstrom]

> > Solution: replace
> > the #!/bin/sh with #!/usr/bin/env -c /bin/bash.  Why not?
>
> Because there are plenty of systems out there without env or bash.

so what's the reason for this argument on 9fans?  is it that it makes
building go on plan 9 harder?

- erik

Re: [9fans] rc vs sh

[Kurt H Maier]

On Tue, Aug 28, 2012 at 11:41:05AM -0400, erik quanstrom wrote:
>
> so what's the reason for this argument on 9fans?  is it that it makes
> building go on plan 9 harder?
>

I think it started out with rc users defending their purity of essence.
I'm just an Unattached Lensman with the Galactic Bullshit Patrol.

Re: [9fans] rc vs sh

[hiro]

great, it's becoming a pissing contest.

Re: [9fans] rc vs sh

[Lucio De Re]

>> Solution: replace
>> the #!/bin/sh with #!/usr/bin/env -c /bin/bash.  Why not?
>
> Because there are plenty of systems out there without env or bash.

Worth a try, though!  There is very little shell code left in the Go
release.  Maybe I'll give it a try on my pristine NetBSD machine.

But note that even if it does work, it is still not possible for the
Go Team to release the scripts as /bin/sh scripts because, as you have
clearly not yet grasped, not all /bin/sh instances out there can be
shown to be compatible with any one /bin/sh script, not matter how
"portable"!

Maybe the following illustration will help: Given Unix, Plan 9 and
Windows as target platforms, how does one go about releasing a single
build environment for all of them that on invocation automatically
produces the target package?  I didn't give it a lot of thought, but
it seems to me that the totally general build (bootstrap?) operation
for this purpose does not (and, it seems to me, cannot) exist.

++L

Re: [9fans] rc vs sh

[Kurt H Maier]

On Tue, Aug 28, 2012 at 06:05:04PM +0200, Lucio De Re wrote:
>
> But note that even if it does work, it is still not possible for the
> Go Team to release the scripts as /bin/sh scripts because, as you have
> clearly not yet grasped, not all /bin/sh instances out there can be
> shown to be compatible with any one /bin/sh script, not matter how
> "portable"!
>

This problem has been solved in myriad ways by myraid teams.  Requiring
bash is one of the solutions.  My only actual statement is that a better
solution would be de-shitting the build process so that it doesn't
require such a precise set of software to operate.  That's all.  Relax.

Re: [9fans] rc vs sh

[Lucio De Re]

> My only actual statement is that a better
> solution would be de-shitting the build process so that it doesn't
> require such a precise set of software to operate.

Does that translate into being able to supply an example of such a
"de-shitting" process the Go Team could and should have followed?  An
irresistible paragon of building prowess?  Something even the autoconf
people would be tempted to follow?

++L

Re: [9fans] rc vs sh

[Kurt H Maier]

On Tue, Aug 28, 2012 at 08:19:52PM +0200, Lucio De Re wrote:
>
> Does that translate into being able to supply an example of such a
> "de-shitting" process the Go Team could and should have followed?  An
> irresistible paragon of building prowess?  Something even the autoconf
> people would be tempted to follow?
>

You're still approaching this like it's some kind of pissing match.
Understand that "we did this because it was easy and it works so
whatever" is perfectly valid.  Understand as well that it's also a
non-optimal solution, and it's not been without its own problems.
The root of the problem isn't that some magical man has to swoop in with
all the answers all at once, it's that the core devs don't give a shit,
which (again) is their prerogative.

Re: [9fans] rc vs sh

[Uriel]

On Tue, Aug 28, 2012 at 5:35 PM, Kurt H Maier <khm-9@intma.in> wrote:
> On Tue, Aug 28, 2012 at 05:36:58PM +0200, Lucio De Re wrote:
>>
>> Sure, feel free to make something that isn't shitty, there's plenty
>> out there that can be improved.  The machinery to install Go (from
>> sources) is hardly the most important amongst them.
>>
>
> The Go team has already explicitly stated they are note interested in a
> better build system.  I don't know if it's plain NIH or a secret bash
> fetish, but they're not buying.  Improving software is not a zero-sum
> game; Go development is not a closed system.  The build system can be
> improved without impeding other progress.

Where did the Go team say explicitly they are not interested in a
better build system?

They just said they are not interested in replacing the last very few
remaining bits of bash unless there is certainty that it wont break
the build in some system.

The current build system already provides facilities to do this, just
nobody has bothered to replace the last remaining bits of (ba)sh.


>> Solution: replace
>> the #!/bin/sh with #!/usr/bin/env -c /bin/bash.  Why not?
>
> Because there are plenty of systems out there without env or bash.
>
>> I may
>> misremember, but before the Go tool was released, the Plan 9 release
>> managed to get itself compiled using ape/sh.  As far as I can tell,
>> the dependence isn't in Bash features as much as in the consistency
>> across Bash versions.
>>
>
> ...which is another unproved assumption.

What is the unproven assumption? One of the Go devs already pointed
out that the current shell scripts don't work for (who knows what
reason) FreeBSD's default shell, even when they make no use of any
bash-specific features as far as anyone knows.

Re: [9fans] rc vs sh

[Kurt H Maier]

Just for the record, nothing's changed:

On Tue, Aug 28, 2012 at 10:44:04PM +0200, Uriel wrote:
> Where did the Go team say explicitly they are not interested in a
> better build system?

http://goo.gl/AtBrC

Re: [9fans] rc vs sh

[Uriel]

On Sat, Sep 1, 2012 at 12:24 AM, Kurt H Maier <khm-9@intma.in> wrote:
>
> Just for the record, nothing's changed:
>
> On Tue, Aug 28, 2012 at 10:44:04PM +0200, Uriel wrote:
>> Where did the Go team say explicitly they are not interested in a
>> better build system?
>
> http://goo.gl/AtBrC
>

A lot has changed, the current build system has barely a handful of
lines of (ba)sh left in it.

Whatever I can convince Russ that it is OK to remove the little that
is left will depend on whatever other people make the case or just
give up and go away, because they can't be bothered to explain their
points to Russ.

Really, that of all the people in the world, I'm the one that has to
try to fight for consensus, communication and cooperation... maybe the
world is really hopeless. *sigh*

Uriel

Re: [9fans] rc vs sh

[hiro]

I think Russ is trolling you, uriel.

Re: [9fans] rc vs sh

[Matthew Veety]

[-- Attachment #1: Type: text/plain, Size: 135 bytes --]

On Aug 31, 2012 7:15 PM, "hiro" <23hiro@gmail.com> wrote:
>
> I think Russ is trolling you, uriel.
>
He is a pretty badass troll.

[-- Attachment #2: Type: text/html, Size: 233 bytes --]

Re: [9fans] rc vs sh

[suharik]

(haven't read the thread)
There's some things that rc cannot into:
- break/continue (well, perhabs I can do it a ugly way)
- sane user interface (rlwrap rc won't give you THE TRUE POWER OF AUTOCOMPLETE)
- *nix standarts (no one wants to install plan9port or even 9base only
for running a script)
That's all. Anyway, rc is still nice for script writing.

Re: [9fans] rc vs sh

[erik quanstrom]

On Sun Sep  2 11:21:53 EDT 2012, gleb.ax.sh@gmail.com wrote:
> (haven't read the thread)
> There's some things that rc cannot into:
> - break/continue (well, perhabs I can do it a ugly way)

works here:

; for(i in 1 2 3){echo $i;break}
1

it's a relatively simple change.  there's no reason continue couldn't be added
in the same way. i just didn't since without break you need condition variables.
but continue can be replaced by slightly rewriting your code.
	if(x)continue;block
can be replaced with
	if(! x)block
so it didn't seem worth the bother.

> - sane user interface (rlwrap rc won't give you THE TRUE POWER OF AUTOCOMPLETE)

lol.

- erik

Re: [9fans] rc vs sh

[suharik]

> works here:
> ; for(i in 1 2 3){echo $i;break}
> 1

Don't work for my 9base rc. Strange.
> continue can be replaced by slightly rewriting your code
Ok. Anyway, no one will write so huge and complicated code (like
sorcery from Source Mage GNU/Linux) in rc.

Re: [9fans] rc vs sh

[Rudolf Sykora]

On 2 September 2012 19:25, erik quanstrom <quanstro@quanstro.net> wrote:
> works here:
> ; for(i in 1 2 3){echo $i;break}

This change seems to have not got into the main plan9 source.
Should be there. Together with continue, since 'continue' may simplify
readability.

>
>> - sane user interface (rlwrap rc won't give you THE TRUE POWER OF AUTOCOMPLETE)
>
> lol.

I too believe that unless the mechanism of autocomplete is well-enough
resolved, rc won't work for many people. I understand the reasons why
readline is not in the shell, but on the other hand I often get angry
when I can't autocomplete.

Sometimes I just do not remember the exact name of a command,
sometimes I can't use variables in a path on the command line since I
do not exactly remember what should come next (like sam
$directory^/something; ctrl-f doesn't help), etc. Also the problem of
not being able to repeat last few commands so simply as can be done
elsewhere is disappointing (if there is a lot of error output from the
previous command, saying that one must look back, find the command,
change it, ...). Rsc's " and "" scripts help much, but still are not
so straightforward as an up-arrow. (Again, I understand that for the
latter-like behaviour one needs cursor addressing.)

Sometimes, perhaps, some complexity is useful.

Ruda

Re: [9fans] rc vs sh

[dexen deVries]

On Monday 03 of September 2012 09:31:12 Rudolf Sykora wrote:
> I too believe that unless the mechanism of autocomplete is well-enough
> resolved, rc won't work for many people. I understand the reasons why
> readline is not in the shell, but on the other hand I often get angry
> when I can't autocomplete.
> 
> Sometimes I just do not remember the exact name of a command,
> sometimes I can't use variables in a path on the command line since I
> do not exactly remember what should come next (like sam
> $directory^/something; ctrl-f doesn't help), etc. Also the problem of
> not being able to repeat last few commands so simply as can be done
> elsewhere is disappointing (if there is a lot of error output from the
> previous command, saying that one must look back, find the command,
> change it, ...). Rsc's " and "" scripts help much, but still are not
> so straightforward as an up-arrow. (Again, I understand that for the
> latter-like behaviour one needs cursor addressing.)


my use case: in acme, upon hitting ^F, before breaking up completion subject  
into directory/file part and passing it to complete(), do filter the 
completion subject through Rc to expand both variable names and wildcards.

somewhere around
/usr/local/plan9/src/cmd/acme/text.c:/^textcomplete


-- 
dexen deVries

[[[↓][→]]]

I'm sorry that this was such a long lett­er, but I didn't have time to write 
you a short one. -- Bla­ise Pasc­al

Re: [9fans] rc vs sh

[suharik]

2012/9/3 Rudolf Sykora <rudolf.sykora@gmail.com>:
> I too believe that unless the mechanism of autocomplete is well-enough
> resolved, rc won't work for many people. I understand the reasons why
> readline is not in the shell, but on the other hand I often get angry
> when I can't autocomplete.
Some users are lazy. They don't like to type this so looong commands,
they don't like to type so long paths, they like to type something
like ac[tab] /h/g/P/g[tab] (zsh style) or pk/i[tab] inf[tab] or even
hg ci -m 'TEH COMMIT'
Good user interface isn't "so cool graphics effects", it's neither
blurry film neither bells and whistles. Good user interface is a thing
providing to interact to computer most fast and effective way.
And good user interface is an another thing Plan 9 basically cannot into.

---
Plan 9 related: autocomplete doesn't work in the same namespace where
rc works. I consider, it will be never fixed.

Re: [9fans] rc vs sh

[hiro]

build your own ui then.

Re: [9fans] rc vs sh

[erik quanstrom]

> > I too believe that unless the mechanism of autocomplete is well-enough
> > resolved, rc won't work for many people. I understand the reasons why

there is no reason to put readline in the shell.  i know i've got at least one
readline implementation kicking around.

> And good user interface is an another thing Plan 9 basically cannot into.

i suppose that's a perfectly valid opinion, but p9p is pretty good evidence
that not everyone agrees.

- erik

Re: [9fans] rc vs sh

[erik quanstrom]

On Sun Sep  2 16:41:20 EDT 2012, gleb.ax.sh@gmail.com wrote:
> > works here:
> > ; for(i in 1 2 3){echo $i;break}
> > 1
>
> Don't work for my 9base rc. Strange.

it wasn't submitted to sources.

> > continue can be replaced by slightly rewriting your code
> Ok. Anyway, no one will write so huge and complicated code (like
> sorcery from Source Mage GNU/Linux) in rc.

that's a good thing, right?

- erik

Re: [9fans] rc vs sh

[Ethan Grammatikidis]

On Mon, 3 Sep 2012 09:46:58 -0400
erik quanstrom <quanstro@quanstro.net> wrote:

> On Sun Sep  2 16:41:20 EDT 2012, gleb.ax.sh@gmail.com wrote:
>
> > Ok. Anyway, no one will write so huge and complicated code (like
> > sorcery from Source Mage GNU/Linux) in rc.
>
> that's a good thing, right?
>
> - erik
>

sorcery is a nice package manager; the only one i've ever actually
liked, but yeah, it's a monster. a short time after i stopped using it
i was interested to see someone report he'd actually reduced the size
of his shell script by converting it from bash to ordinary sh; using
the proper tools instead of bashisms had shortened it. i wondered what
would happen to sorcery if so converted, but it was just idle
speculation.

--
This is obviously some strange usage of the word
"simple" that I was previously unaware of.

Re: [9fans] rc vs sh

[erik quanstrom]

> sorcery is a nice package manager; the only one i've ever actually
> liked, but yeah, it's a monster. a short time after i stopped using it
> i was interested to see someone report he'd actually reduced the size
> of his shell script by converting it from bash to ordinary sh; using
> the proper tools instead of bashisms had shortened it. i wondered what
> would happen to sorcery if so converted, but it was just idle
> speculation.

i have never seen a very large shell script that i found readable.
of course the waters have been polluted by gnu configure scripts,
but i still think the idea is invalid.  just as one makes every attempt
to keep a c function from exceeding a page or so, it follows that one
should keep the individual units in shell scripts small.  the individual
unit of scripting is imho ... a script, not a function.  this is because it
is too hard to do much isolation within a script.  even with functions.
patch/* is a good example of a structured set of scripts.

- erik

Re: [9fans] rc vs sh

[Balwinder S Dheeman]

On 09/01/2012 04:30 AM, Uriel wrote:
> On Sat, Sep 1, 2012 at 12:24 AM, Kurt H Maier <khm-9@intma.in> wrote:
>>
>> Just for the record, nothing's changed:
>>
>> On Tue, Aug 28, 2012 at 10:44:04PM +0200, Uriel wrote:
>>> Where did the Go team say explicitly they are not interested in a
>>> better build system?
>>
>> http://goo.gl/AtBrC
>>
>
> A lot has changed, the current build system has barely a handful of
> lines of (ba)sh left in it.

That's good news, but for me the Go is yet another bloatware and nothing
more than that :(

> Whatever I can convince Russ that it is OK to remove the little that
> is left will depend on whatever other people make the case or just
> give up and go away, because they can't be bothered to explain their
> points to Russ.

Or may be Russ is unable to grasp whatever the other volunteers suggest
or he is reluctant to accept patches.

> Really, that of all the people in the world, I'm the one that has to
> try to fight for consensus, communication and cooperation... maybe the
> world is really hopeless. *sigh*

The world is always live, hopeful and fair; and it shall remain so even
when we die.

--
Balwinder S "bdheeman" Dheeman
(http://werc.homelinux.net/contact/)

Re: [9fans] rc vs sh

[tlaronde]

On Tue, Aug 28, 2012 at 04:52:34PM +0200, Lucio De Re wrote:
>
> Do you think you can provide any guarantees that the subset of /bin/sh
> features common to all current instances of /bin/sh is adequate to
> build a moderately demanding open source package?
>

Yes. This is what is done by the R.I.S.K. framework used for building
KerGIS and kerTeX. The minimal being a subset of POSIX.2 for the tools,
since it is trivial to provide such subset for whatever environment (APE
on Plan9; this is what does Mingw for Windows; Cygwin is the overloaded
version; R.I.S.K. will probably provide one in the future).

--
        Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
                      http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

Re: [9fans] rc vs sh

[Aram Hăvărneanu]

> Yes. This is what is done by the R.I.S.K. framework used for building
> KerGIS and kerTeX.

I'm pretty sure that R.I.S.K has more than 2,250 lines of code. That's
the LOC count of \.(ba)?sh$ stuff in the Go tree. Also, nobody seemed
to mention that Go also ships with rc files to build on Plan 9...

-- 
Aram Hăvărneanu

Re: [9fans] rc vs sh

[tlaronde]

On Tue, Aug 28, 2012 at 07:12:15PM +0300, Aram H?v?rneanu wrote:
> > Yes. This is what is done by the R.I.S.K. framework used for building
> > KerGIS and kerTeX.
>
> I'm pretty sure that R.I.S.K has more than 2,250 lines of code. That's
> the LOC count of \.(ba)?sh$ stuff in the Go tree. Also, nobody seemed
> to mention that Go also ships with rc files to build on Plan 9...


$ wc -l rk*

     838 rkbuild
    1121 rkconfig
      60 rkguess
     247 rkinstall
     256 rkpkg
    2522 total

This is with comments of course. The rest are the trivial parameters
files for each system. (rkguess is used to sketch such a parameters file
on a new system.)

And this does what no other framework does: be able to remove
intermediary products, such that you can compile a resulting n
megabytes package with just slightly more than n megabytes of
space...

--
        Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
                      http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

Re: [9fans] rc vs sh

[tlaronde]

[Since the previous one did not reach the list (?), I send it once more]

On Tue, Aug 28, 2012 at 07:12:15PM +0300, Aram H?v?rneanu wrote:
> > Yes. This is what is done by the R.I.S.K. framework used for building
> > KerGIS and kerTeX.
>
> I'm pretty sure that R.I.S.K has more than 2,250 lines of code. That's
> the LOC count of \.(ba)?sh$ stuff in the Go tree. Also, nobody seemed
> to mention that Go also ships with rc files to build on Plan 9...


result of "wc -l rk*":

     838 rkbuild
    1121 rkconfig
      60 rkguess
     247 rkinstall
     256 rkpkg
    2522 total

This is with comments of course. The rest are the trivial parameters
files for each system. (rkguess is used to sketch such a parameters file
on a new system.)

And this does what no other framework does: be able to remove
intermediary products, such that you can compile a resulting n
megabytes package with just slightly more than n megabytes of
space...

To be clear: I'm answering the "there is not anything existing proving
this can be done differently". I'm not arguing about the choices
of the Go developers:  they do the work; they do as they see fit.
Period.

And as for KerGIS vs. GRASS; kerTeX vs. TexLive; it costed me less time
to do R.I.S.K. from scratch, knowing thus anything about how it works,
how to fix, how to improve, why it fails, than to try to use existing
monsters.

Sending to /dev/null is the developer's primary tool. (As well as for
the readers of my messages, probably...)

--
        Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
                      http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

Re: [9fans] rc vs sh

[Lucio De Re]

> The minimal being a subset of POSIX.2 for the tools,

Maybe I'm pushing too hard here, but even Posix isn't followed by all
implementations of /bin/sh (no, I'm not sure, but there is no proof
possible, as the future is also a factor).  Thing is, Bash is
well-defined, by a single implementation.

That's the original issue: why Bash over RC? Go is incidental, but a
data point in a big statistical set.  All Bashes are equal, all
instances of /bin/sh aren't: it's not better, it's singular.

++L

Re: [9fans] rc vs sh

[arnold]

Lucio De Re <lucio@proxima.alt.za> wrote:

> All Bashes are equal,

Even this isn't true. Bash is at 4.2 and people still report "issues"
with 3.x.  (Same with gawk; gawk is at 4.0.1, people still send it bug reports
about 3.1.3, which is 10 years old!)

I am not familiar with the use of Bash in Go; I suspect that they stick
to stuff that will work across Baash versions though.

Arnold

Re: [9fans] rc vs sh

[Lucio De Re]

> I am not familiar with the use of Bash in Go; I suspect that they stick
> to stuff that will work across Baash versions though.

The difficult bit for argumentative people to grasp is that the Go
Team use features that are portable across bourne-like shells, they
just refuse to commit to that level of compatibility.  On the one
hand, requiring Bash gives them a reliable grounding and on the other
if they slip up and use an advanced feature the entire castle doesn't
come tumbling down on their head.

Putting it another way, they use Bash specifically to minimise this
type of argumentative bike-shedding.

++L

Re: [9fans] rc vs sh

[tlaronde]

On Thu, Aug 30, 2012 at 09:41:14AM +0200, Lucio De Re wrote:
>
> The difficult bit for argumentative people to grasp is that the Go
> Team use features that are portable across bourne-like shells, they
> just refuse to commit to that level of compatibility.  On the one
> hand, requiring Bash gives them a reliable grounding and on the other
> if they slip up and use an advanced feature the entire castle doesn't
> come tumbling down on their head.
>

This is indeed what I do. The request for a _subset_ of POSIX.2 is so
that this will work for whatever Bourne like shell is there. When
something doesn't work on an OS, I circumvent using a more limited
subset on all. Bash is used as /bin/sh on a lot of Linuces, and R.I.S.K.
then uses Bash, but with limited POSIX.2 features. (I had to circumvent
some use of regexp because Plan9 APE relies on Plan9 regexp that does not
implement "\{m,n\}" for example. I had to circumvent a peculiarity of
Bash that exists with error when a function has an empty body---adding
just a comment will do...--- Etc.)

But as I said, this is not to argument about Go developers' choices:
they do as they see fit, since I do it this way for myself ;) But an
alternative is not only possible: it exists. (This is neither a plea for
a wide use of R.I.S.K. since it has been published by side-effect: I
didn't want to "support" it for external uses. But if I make a project
public, I publish the framework too...)

--
        Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
                      http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

Re: [9fans] rc vs sh

[Lucio De Re]

> But as I said, this is not to argument about Go developers' choices:
> they do as they see fit

I think their philosophy is sound, not just an arbitrary choice.  The
alternative is a commitment that can only be fulfilled by applying
resources best utilised on the focal issue.

For example, the kerTeX installation relies on an ftp client that
accepts a URL on the command line.  My UBUNTU installation has no such
ftp command.  That leaves you with the choice between driving the more
conventional ftp program with a small script (not nice, but it can be
done) or require (as you do for LEX and YACC) that wget be installed
everywhere, not just where ftp isn't of the neat BSD variety.

It's a choice you make on behalf of the user and you can be sure that
a significant portion of your target market would prefer the opposite.
A very small portion will also stand up and criticise you if you go
the wget rule, whereas it is much harder to challenge the use of ftp
with a script.  However, of the two, wget is more robust.

That's the way it is.  Sometimes one has the luxury of doing things
properly, sometimes it is more critical to arrive at a result first.
A healthy ethos would encourage tidying up behind one, but the costs
are seldom justified in the present development climate.  Future
conditions may be different and perhaps we can then all feel justified
in chipping in to tidy up behind our less tidy pioneers.

++L

Re: [9fans] rc vs sh

[tlaronde]

On Thu, Aug 30, 2012 at 12:26:26PM +0200, Lucio De Re wrote:
>
> For example, the kerTeX installation relies on an ftp client that
> accepts a URL on the command line.

Slight correction: this is not the kerTeX installation, this is sugar
for simplifying installation in the most common cases. The basis does
not request ftp. The "primitives" (R.I.S.K. proper) do not use this.

But I think we mostly agree on the issues.

--
        Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
                      http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

Re: [9fans] rc vs sh

[Lucio De Re]

> The basis does
> not request ftp.

I apologise for working with too little information.  I have long
wanted to have TeX installed for the rare occasions when I want to
explore the TeX Book, so I took a chance.  I'm waiting to find the
energy to solve the libc/libm/libl problem I encountered :-)

That, or the stable Plan 9 installation to install kerTeX on.

++L

Re: [9fans] rc vs sh

[Dan Cross]

[Special to Lucio: Email to proxima.alt.za from Google's SMTP servers
is failing; it looks like they're listed in rbl.proxima.alt.za.]

On Thu, Aug 30, 2012 at 3:56 PM, Lucio De Re <lucio@proxima.alt.za> wrote:
>> But as I said, this is not to argument about Go developers' choices:
>> they do as they see fit
>
> I think their philosophy is sound, not just an arbitrary choice.  The
> alternative is a commitment that can only be fulfilled by applying
> resources best utilised on the focal issue.
>
> For example, the kerTeX installation relies on an ftp client that
> accepts a URL on the command line.  My UBUNTU installation has no such
> ftp command.  That leaves you with the choice between driving the more
> conventional ftp program with a small script (not nice, but it can be
> done) or require (as you do for LEX and YACC) that wget be installed
> everywhere, not just where ftp isn't of the neat BSD variety.
>
> It's a choice you make on behalf of the user and you can be sure that
> a significant portion of your target market would prefer the opposite.
> A very small portion will also stand up and criticise you if you go
> the wget rule, whereas it is much harder to challenge the use of ftp
> with a script.  However, of the two, wget is more robust.
>
> That's the way it is.  Sometimes one has the luxury of doing things
> properly, sometimes it is more critical to arrive at a result first.
> A healthy ethos would encourage tidying up behind one, but the costs
> are seldom justified in the present development climate.  Future
> conditions may be different and perhaps we can then all feel justified
> in chipping in to tidy up behind our less tidy pioneers.

Very well put.

        - Dan C.

Re: [9fans] rc vs sh

[erik quanstrom]

> The issue raised on Go-Nuts is that Bash shouldn't be used for
> installing Go, /bin/sh should be used instead.  The response is that
> Bash is the most uniformly implemented of the /bin/sh's out there and
> that none of the other shells (generally referred to as /bin/sh) can
> be relied upon not to have incompatible foibles that would trip up a
> complicated script headed #!/bin/sh.  Therefore, intentionally using
> #!/bin/bash (or #!/usr/bin/env -c /bin/bash - from memory) is much
> more likely to work without adjustments.
>
> Hence, it makes sense to stick to bash in one's day-to-day work.
>
> Of course, rc would be preferable, but the target platforms for Go are
> not all adequately endowed, and Byron's rc proves the point: it is
> slightly incompatible with Plan 9's rc.

i think there's an unexplained twist in the logic.  byron's rc is a non
sequitor.  rc (the real one from p9p) could be made to run on all the go platforms,
and would be uniform across them all.  one suspects therefore that
the reason is either that rc doesn't run on all the platforms, or that
the go team thinks rc is not preferrable.  for example it could be
that the thought is that rc might distract from the real point here,
go.

i don't know.  but the problem isn't the consistency of rc.  byron's
rc doesn't count.  that's like saying the bourne shell is not consistent
because of bash.

- erik

Re: [9fans] rc vs sh

[Lucio De Re]

> i don't know.  but the problem isn't the consistency of rc.  byron's
> rc doesn't count.  that's like saying the bourne shell is not consistent
> because of bash.

But I am saying that, and I believe that is what motivates the Go Team
to continue using Bash.  They know that Bash works.  They also know
that at any time it is possible for a version of /bin/sh (not the
abstract shell, but the particular instance installed on a particular
platform) to bite them in the butt because of the innumerable
variations.  They avoid that by using Bash on Unix, command.com on
Windows (I think) and rc on Plan 9.

Byron's rc is a straw man, but it illustrates the conditions in the
wild.

++L

Re: [9fans] rc vs sh

[dexen deVries]

On Tuesday 28 of August 2012 16:10:39 Lucio De Re wrote:
> > Anyway, I do not understand how uniform crappiness can be advantageous...
> 
> The issue raised on Go-Nuts is that Bash shouldn't be used for
> installing Go, /bin/sh should be used instead.  The response is that
> Bash is the most uniformly implemented of the /bin/sh's out there and
> that none of the other shells (generally referred to as /bin/sh) can
> be relied upon not to have incompatible foibles that would trip up a
> complicated script headed #!/bin/sh.  (...)

that somehow reminds me of autoconf
*runs away*

--
dexen deVries

[[[↓][→]]]

I'm sorry that this was such a long lett­er, but I didn't have time to write 
you a short one. -- Bla­ise Pasc­al

Re: [9fans] rc vs sh

[hiro]

env bash - posix 2.0

Re: [9fans] rc vs sh

[hiro]

https://groups.google.com/forum/#!topic/golang-nuts/aC7Qr1qtZ2I

Re: [9fans] rc vs sh

[Balwinder S Dheeman]

On 08/28/2012 03:22 PM, dexen deVries wrote:
> On Tuesday 28 of August 2012 10:57:06 Rudolf Sykora wrote:
>> Hello,
>>
>> I am just curious...
>> Here
>> http://9fans.net/archive/2007/11/120
>>
>> Russ Cox writes he uses bash as his default shell. Does anybody know
>> the reason? Is this for practicality within the linux environment? Or
>> has he found rc too limiting?
>
> FWIW, i'm using bash as the interactive shell too, in `konsole' terminal
> emulator, because of bash' interactive line edition and command history. 9term
> doesn't fit me.

I added command line editing and history to ash under minix a decade
ago, it worked like a charm; the same ash is known as dash in Debian
world, but did not bother to submit a patch.

Whereas, the bash man-page itself explains a lot:

BUGS
     It's too big and too slow.

     There are some subtle differences between bash and traditional
     versions of sh, mostly because of the POSIX specification.

     Aliases are confusing in some uses.

     Shell built-in commands and functions are not stoppable/restartable.

     Compound commands and command sequences of the form `a ; b ; c' are
     not handled  gracefully when process suspension is attempted. When
     a process is stopped, the shell immediately executes the next
     command in the sequence. It suffices to place the sequence of
     commands between parentheses to force it into a sub-shell, which
     may be stopped as a unit.

     Array variables may not (yet) be exported.

     There may be only one active co-process at a time.

GNU Bash-4.2              2010 December 28                      BASH(1)

> all  scripting -- both standalone and in mkfiles -- goes in rc, thou.

It's strange that though ArchLinux uses bash as a system shell :P

--
Balwinder S "bdheeman" Dheeman
(http://werc.homelinux.net/contact/)

Re: [9fans] rc vs sh

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 254 bytes --]

Changing my default shell from bash to rc caused even terminal windows (let
alone 9term ones) to appear almost instantly on Ubuntu
(9term windows appear instantly on the click).

We slowly standardise on slow standards, with degradation everywhere.

[-- Attachment #2: Type: text/html, Size: 290 bytes --]

Re: [9fans] rc vs sh

[hiro]

For compatibility I use ash in xterm and rc in 9term ;)

Re: [9fans] rc vs sh

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 356 bytes --]

I have an rc script, allowing u ./configure, u make, u man, ...

% cat bin/u
#!/bin/rc
SHELL=/bin/sh
path=(/usr/local/sbin /usr/local/bin /usr/sbin /usr/bin /sbin /bin
/usr/bin/X11 /usr/games)
MANPAGER=/bin/cat
exec $*


On 29 August 2012 16:22, hiro <23hiro@gmail.com> wrote:

> For compatibility I use ash in xterm and rc in 9term ;)
>
>

[-- Attachment #2: Type: text/html, Size: 687 bytes --]

Re: [9fans] rc vs sh

[Ethan Grammatikidis]

On Wed, 29 Aug 2012 16:10:39 +0100
Charles Forsyth <charles.forsyth@gmail.com> wrote:

> Changing my default shell from bash to rc caused even terminal windows (let
> alone 9term ones) to appear almost instantly on Ubuntu
> (9term windows appear instantly on the click).

i'm not sure how ubuntu manages this when other linux distros don't
have the problem at all. os x does have the same problem... perhaps
it's some optimization ubuntu doesn't enable and os x doesn't have;
perhaps prelinking which itself is a workaround for the slowness caused
by developing hugely complex software on dynamic linking. *sigh*

>
> We slowly standardise on slow standards, with degradation everywhere.

no argument here!

--
This is obviously some strange usage of the word
"simple" that I was previously unaware of.

Re: [9fans] rc vs sh

[dexen deVries]

On Wednesday 29 of August 2012 16:10:39 Charles Forsyth wrote:
> Changing my default shell from bash to rc caused even terminal windows (let
> alone 9term ones) to appear almost instantly on Ubuntu
> (9term windows appear instantly on the click).


interactive bash reads, among others, ~/.bash_history.

also some of /usr/share/locale/{$LANG,$LC_CTYPE,$LC_NUMERIC,$LC_TIME,
$LC_COLLATE,$LC_MONETARY,$LC_MESSAGES,$LC_PAPER,$LC_NAME,$LC_ADDRESS,
$LC_TELEPHONE,$LC_MEASUREMENT,$LC_IDENTIFICATION,$LC_ALL}/*

also /etc/nsswitch.conf -- yep, bash has built-in TCP connection support.


-- 
dexen deVries

[[[↓][→]]]


How often I found where I should be going
only by setting out for somewhere else.
                -- R. Buckminster Fuller

Re: [9fans] rc vs sh

[Dan Cross]

On Tue, Aug 28, 2012 at 2:27 PM, Rudolf Sykora <rudolf.sykora@gmail.com> wrote:
> Hello,

Howdy.

> I am just curious...
> Here
> http://9fans.net/archive/2007/11/120
>
> Russ Cox writes he uses bash as his default shell. Does anybody know
> the reason? Is this for practicality within the linux environment? Or
> has he found rc too limiting?

So rc is a nice shell, but it's most useful in a particular
environment that has evolved with it in a very pleasant way.  If one
is constrained to work outside of that environment, then rc isn't so
much better than any other shell.

Note that I'm not referring to the implementation; rc is certainly
nicer than bash in this sense, but rather the tangible function from a
user perspective.  If one is in an environment where the majority of
one's coworkers are stuck using bash and one needs to retain
shell-level compatibility with them for some reason or another, then
it makes sense to use bash, as aesthetically unpleasing as that may
be.

One has to ask oneself, is rc worth it?  If the level of productivity
increase that came from using rc instead of bash was greater than the
cost of maintaining a custom environment built around rc, then one
would might make an argument for using it.  But how many of us can
honestly say that's the benefits are so great?  The basic command,
pipe and stdout redirection syntax is the same.  It's the same if I
want to run a process or pipeline in the background.  I can set the
prompts to be the same and configure things so that copy/paste works
in an identical fashion across the two.  And those are the VAST
majority of things I do with a shell; to be honest, 99% of the time, I
don't even think about what shell I'm running; regardless of what it
is.

And rc is not perfect.  I've always felt like the 'if not' stuff was a kludge.

        - Dan C.

Re: [9fans] rc vs sh

[erik quanstrom]

> And rc is not perfect.  I've always felt like the 'if not' stuff was a kludge.

no, it's certainly not.  (i wouldn't call if not a kludge—just ugly.  the
haahr/rakitzis es' if makes more sense, even if it's wierder.)

but the real question with rc is, what would you fix?

i can only think of a few things around the edges.  `{} and $ are
obvious and is some way to use standard regular expressions.  but
those really aren't that motivating.  rc does enough.

perhaps (let's hope) someone else has better ideas.

- erik

Re: [9fans] rc vs sh

[Lucio De Re]

> perhaps (let's hope) someone else has better ideas.

The Inferno shell was (is) slick!

++L

Re: [9fans] rc vs sh

[erik quanstrom]

On Tue Aug 28 11:33:06 EDT 2012, lucio@proxima.alt.za wrote:
> > perhaps (let's hope) someone else has better ideas.
>
> The Inferno shell was (is) slick!

and iirc, the slickness depends on limbo.

- erik

Re: [9fans] rc vs sh

[dexen deVries]

On Tuesday 28 of August 2012 11:26:19 erik quanstrom wrote:
> > And rc is not perfect.  I've always felt like the 'if not' stuff was a
> > kludge.
> no, it's certainly not.  (i wouldn't call if not a kludge—just ugly.  the
> haahr/rakitzis es' if makes more sense, even if it's wierder.)
> 
> but the real question with rc is, what would you fix?


switch/case would make helluva difference over nested if/if not, if defaulted 
to fall-through.

variable scoping (better than subshel) would help writing larger scripts, but 
that's not necessarily an improvement ;-) something similar to LISP's `let' 
special form, for dynamic binding.

-- 
dexen deVries

1972 - Dennis Ritchie invents a powerful gun that shoots both forward and 
backward simultaneously. Not satisfied with the number of deaths and permanent 
maimings from that invention he invents C and Unix.

Re: [9fans] rc's shortcomings (new subject line)

[erik quanstrom]

> 
> switch/case would make helluva difference over nested if/if not, if
> defaulted to fall-through.

maybe you have an example?  because i don't see that.  if not works
fine, and can be nested.  case without fallthrough is also generally
what i want.  if not, i can make the common stuff a function.

> variable scoping (better than subshel) would help writing larger
> scripts, but that's not necessarily an improvement ;-) something
> similar to LISP's `let' special form, for dynamic binding.

there is variable scoping.  you can write

	x=() y=() cmd

cmd can be a function body or whatever.  x and y are then private
to cmd.  you can nest redefinitions.  

	x=1 y=2 {echo first $x $y; x=a y=b {echo second $x $y; x=α y=β {echo third $x $y}; echo ret second $x $y}; echo ret first $x $y}
	first 1 2
	second a b
	third α β
	ret second a b
	ret first 1 2

you should try the es shell.  es had let and some other scheme-y
features.  let allows one to do all kinds of tricky stuff, like build
a shell debugger in the shell, but my opinion is that es was more
powerful and fun, but it didn't buy enough because it didn't really
expand on the essential nature of a shell.  what can one do to
manipulate processes and file descriptors.

- erik

Re: [9fans] rc's shortcomings (new subject line)

[dexen deVries]

On Tuesday 28 of August 2012 14:44:40 erik quanstrom wrote:
> (...)
> > variable scoping (better than subshel) would help writing larger
> > scripts, but that's not necessarily an improvement ;-) something
> > similar to LISP's `let' special form, for dynamic binding.
>
> there is variable scoping.  you can write
>
> 	x=() y=() cmd

thank you good sire, for you've just made my day.


now i see i can do:

x=1 y=2 z=3

...and only `z' retains its new value in the external scope, while `x' and `y'
are limited in scope.


horray for rc and helpful 9fans,
--
dexen deVries

1972 - Dennis Ritchie invents a powerful gun that shoots both forward and
backward simultaneously. Not satisfied with the number of deaths and permanent
maimings from that invention he invents C and Unix.

Re: [9fans] rc's shortcomings (new subject line)

[arisawa]

Hello,

On 2012/08/29, at 4:34, dexen deVries wrote:

> now i see i can do:
> 
> x=1 y=2 z=3
> 
> ...and only `z' retains its new value in the external scope, while `x' and `y' 
> are limited in scope.

No.

ar% a=1 b=2 c=3; echo $a $b $c
1 2 3
ar% a=() b=() c=()
ar% a=1 b=2 {c=3}; echo $a $b $c
3
ar% 

Kenji Arisawa

Re: [9fans] rc's shortcomings (new subject line)

[dexen deVries]

On Wednesday 29 of August 2012 09:06:35 arisawa wrote:
> Hello,
> 
> On 2012/08/29, at 4:34, dexen deVries wrote:
> > now i see i can do:
> > 
> > x=1 y=2 z=3
> > 
> > ...and only `z' retains its new value in the external scope, while `x' and
> > `y' are limited in scope.
> 
> No.
> 
> ar% a=1 b=2 c=3; echo $a $b $c
> 1 2 3
> ar% a=() b=() c=()
> ar% a=1 b=2 {c=3}; echo $a $b $c
> 3
> ar%


indeed, thanks.


-- 
dexen deVries

[[[↓][→]]]

I'm sorry that this was such a long lett­er, but I didn't have time to write 
you a short one. -- Bla­ise Pasc­al

Re: [9fans] rc's shortcomings (new subject line)

[Dan Cross]

On Tue, Aug 28, 2012 at 8:56 PM, erik quanstrom <quanstro@quanstro.net> wrote:
>> And rc is not perfect.  I've always felt like the 'if not' stuff was a kludge.
>
> no, it's certainly not.  (i wouldn't call if not a kludge—just ugly.

Kludge perhaps in the sense that it seems to be to work around an
issue with the grammar and the expectation that it's mostly going to
be used interactively, as opposed to programmatically.  See below.

> the haahr/rakitzis es' if makes more sense, even if it's wierder.)

Agreed; es would be an interesting starting point for a new shell.

> but the real question with rc is, what would you fix?

I think in order to really answer that question, one would have to
step back for a moment and really think about what one wants out of a
shell.  There seems to be a natural conflict a programming language
and a command interpreter (e.g., the 'if' vs. 'if not' thing).  On
which side does one err?

> i can only think of a few things around the edges.  `{} and $ are
> obvious and is some way to use standard regular expressions.  but
> those really aren't that motivating.  rc does enough.

I tend to agree.  As a command interpreter, rc is more or less fine as
is.  I'd really only feel motivated to change whatever people felt
were common nits, and there are fairly few of those.

> perhaps (let's hope) someone else has better ideas.

Well, something off the top of my head: Unix pipelines are sort of
like chains of coroutines.  And they work great for defining linear
combinations of filters.  But something that may be interesting would
be the ability to allow the stream of computations to branch; instead
of pipelines being just a list, make them a tree, or even some kind of
dag (if one allows for the possibility of recombining streams).  That
would be kind of an interesting thing to play with in a shell
language; I don't know how practically useful it would be, though.

>> switch/case would make helluva difference over nested if/if not, if
>> defaulted to fall-through.
>
> maybe you have an example?  because i don't see that.  if not works
> fine, and can be nested.  case without fallthrough is also generally
> what i want.  if not, i can make the common stuff a function.
>
>> variable scoping (better than subshel) would help writing larger
>> scripts, but that's not necessarily an improvement ;-) something
>> similar to LISP's `let' special form, for dynamic binding.

(A nit: 'let' actually introduces lexical scoping in most Lisp
variants; yes, doing (let ((a 1)) ...) has non-lexical effect if 'a'
is a dynamic variable in Common Lisp, but (let) doesn't itself
introduce dynamic variables.  Emacs Lisp is a notable exception in
this regard.)

> there is variable scoping.  you can write
>
>         x=() y=() cmd
>
> cmd can be a function body or whatever.  x and y are then private
> to cmd.  you can nest redefinitions.
>
>         x=1 y=2 {echo first $x $y; x=a y=b {echo second $x $y; x=α y=β {echo third $x $y}; echo ret second $x $y}; echo ret first $x $y}
>         first 1 2
>         second a b
>         third α β
>         ret second a b
>         ret first 1 2

This syntax feels clunky and unfamiliar to me; rc resembles block
scoped languages like C; I'd rather have a 'local' or similar keyword
to introduce a variable in the scope of each '{ }' block.

> you should try the es shell.  es had let and some other scheme-y
> features.  let allows one to do all kinds of tricky stuff, like build
> a shell debugger in the shell, but my opinion is that es was more
> powerful and fun, but it didn't buy enough because it didn't really
> expand on the essential nature of a shell.  what can one do to
> manipulate processes and file descriptors.

es was a weird merger between rc's syntax and functional programming
concepts.  It's neat-ish, but unless we're really ready to go to the
pipe monad (not that weird, in my opinion) you're right.  Still, if it
allowed one to lexically bind a file descriptor to a variable, I could
see that being neat; could I have a closure over a file descriptor?  I
don't think the underlying process model is really set up for it, but
it would be kind of cool: one could have different commands consuming
part of a stream in a very flexible way.

        - Dan C.

Re: [9fans] rc's shortcomings (new subject line)

[Bakul Shah]

On Wed, 29 Aug 2012 01:11:26 +0530 Dan Cross <crossd@gmail.com>  wrote:
> On Tue, Aug 28, 2012 at 8:56 PM, erik quanstrom <quanstro@quanstro.net> wro=
>
> > perhaps (let's hope) someone else has better ideas.
>
> Well, something off the top of my head: Unix pipelines are sort of
> like chains of coroutines.  And they work great for defining linear
> combinations of filters.  But something that may be interesting would
> be the ability to allow the stream of computations to branch; instead
> of pipelines being just a list, make them a tree, or even some kind of
> dag (if one allows for the possibility of recombining streams).  That
> would be kind of an interesting thing to play with in a shell
> language; I don't know how practically useful it would be, though.

Coming up with an easy to use syntax for computation trees (or
arbitrary nets) is the hard part. May be the time is ripe for
a net-rc or net-scheme-shell.

The feature I want is the ability to pass not just character
values in environment or pipes but arbitrary Scheme objects.
But that requires changes at the OS level (or mapping them
to/from strings, which is a waste if both sides can handle
structured objects).

Re: [9fans] rc's shortcomings (new subject line)

[erik quanstrom]

> The feature I want is the ability to pass not just character
> values in environment or pipes but arbitrary Scheme objects.
> But that requires changes at the OS level (or mapping them
> to/from strings, which is a waste if both sides can handle
> structured objects).

!?  the ability to pass typed records around is an idea that was
tarred, feathered, drawn and quartered by unix.  files, and therefore
streams, have no type.  they are byte streams.

one of the advantages of unix over, say, ibm systems, is that in unix
it is not the os' business to care what you're passing about.  but by
the same token, if you are the application, you get to arrange these
things by yourself.

rc already passes structured data through the environment.
rc variables in the environment are defined as

	var:	[^ctl-a]*
		| ([^ctl-a]*) ctl-a list

so there is precident for this in shells.

- erik

Re: [9fans] rc's shortcomings (new subject line)

[erik quanstrom]

> 	var:	[^ctl-a]*
> 		| ([^ctl-a]*) ctl-a list

sorry.  s/list/var/

- erik

Re: [9fans] rc's shortcomings (new subject line)

[Bakul Shah]

On Tue, 28 Aug 2012 21:39:06 EDT erik quanstrom <quanstro@quanstro.net>  wrote:
> > The feature I want is the ability to pass not just character
> > values in environment or pipes but arbitrary Scheme objects.
> > But that requires changes at the OS level (or mapping them
> > to/from strings, which is a waste if both sides can handle
> > structured objects).
>
> !?  the ability to pass typed records around is an idea that was
> tarred, feathered, drawn and quartered by unix.  files, and therefore
> streams, have no type.  they are byte streams.

I was not talking about "records" but s-expressions.  "json"
is kind of sort of the same thing. Without a generally useful
and simple such mechanism, people end up devising their own.
The 9p format for instance. And go has typed channels.

> rc already passes structured data through the environment.
> rc variables in the environment are defined as
>
> 	var:	[^ctl-a]*
> 		| ([^ctl-a]*) ctl-a list
>
> so there is precident for this in shells.

And this.

Re: [9fans] rc's shortcomings (new subject line)

[erik quanstrom]

> On Tue, 28 Aug 2012 21:39:06 EDT erik quanstrom <quanstro@quanstro.net>  wrote:
> > > The feature I want is the ability to pass not just character
> > > values in environment or pipes but arbitrary Scheme objects.
> > > But that requires changes at the OS level (or mapping them
> > > to/from strings, which is a waste if both sides can handle
> > > structured objects).
> >
> > !?  the ability to pass typed records around is an idea that was
> > tarred, feathered, drawn and quartered by unix.  files, and therefore
> > streams, have no type.  they are byte streams.
>
> I was not talking about "records" but s-expressions.  "json"
> is kind of sort of the same thing. Without a generally useful
> and simple such mechanism, people end up devising their own.
> The 9p format for instance. And go has typed channels.

it sounds like you're saying 9p isn't useful.  .... i must be reading
your post incorrectly.

- erik

Re: [9fans] rc's shortcomings (new subject line)

[Bakul Shah]

On Tue, 28 Aug 2012 22:23:20 EDT erik quanstrom <quanstro@quanstro.net>  wrote:
> > On Tue, 28 Aug 2012 21:39:06 EDT erik quanstrom <quanstro@quanstro.net>  wr
> ote:
> > > > The feature I want is the ability to pass not just character
> > > > values in environment or pipes but arbitrary Scheme objects.
> > > > But that requires changes at the OS level (or mapping them
> > > > to/from strings, which is a waste if both sides can handle
> > > > structured objects).
> > >
> > > !?  the ability to pass typed records around is an idea that was
> > > tarred, feathered, drawn and quartered by unix.  files, and therefore
> > > streams, have no type.  they are byte streams.
> >
> > I was not talking about "records" but s-expressions.  "json"
> > is kind of sort of the same thing. Without a generally useful
> > and simple such mechanism, people end up devising their own.
> > The 9p format for instance. And go has typed channels.
>
> it sounds like you're saying 9p isn't useful.  .... i must be reading
> your post incorrectly.

9p is quite useful. But the same semantics could've been
implemented using a more universal but compact structured
format such as s-expr. It is not the only choice but to me it
seems to strike a reasonable balance (compared to bloaty XML
at one extreme, tightly packed binary structures at another,
and byte streams with printf/parse encode/decode at the third
extreme).

Re: [9fans] rc's shortcomings (new subject line)

[erik quanstrom]

> > > > > The feature I want is the ability to pass not just character
> > > > > values in environment or pipes but arbitrary Scheme objects.
> > > > > But that requires changes at the OS level (or mapping them
> > > > > to/from strings, which is a waste if both sides can handle
> > > > > structured objects).
> > > >
> > > > !?  the ability to pass typed records around is an idea that was
> > > > tarred, feathered, drawn and quartered by unix.  files, and therefore
> > > > streams, have no type.  they are byte streams.
> > >
> > > I was not talking about "records" but s-expressions.  "json"
> > > is kind of sort of the same thing. Without a generally useful
> > > and simple such mechanism, people end up devising their own.
> > > The 9p format for instance. And go has typed channels.
> >
> > it sounds like you're saying 9p isn't useful.  .... i must be reading
> > your post incorrectly.
>
> 9p is quite useful. But the same semantics could've been
> implemented using a more universal but compact structured
> format such as s-expr. It is not the only choice but to me it
> seems to strike a reasonable balance (compared to bloaty XML
> at one extreme, tightly packed binary structures at another,
> and byte streams with printf/parse encode/decode at the third
> extreme).

i don't see the problem.  9p is not in any way special to the kernel.
only devmnt knows about it, and it is only used to mount file servers.
in theory, one could substitue something else.  it wouldn't quite be
plan 9, and it wouldn't be interoperable, but there's no reason it couldn't
be done.  authentication speaks special protocols.  venti speaks a special
protocol.  so i don't see why kernel support would even be helpful in
implementing your s-expression protocol.  and there's no reason
a 9p over s-expression device can't be implemented.

imho, the reason for constraining 9p to exactly the operations needed
is to make it easy to prove the protocol correct.

- erik

Re: [9fans] rc's shortcomings (new subject line)

[Aram Hăvărneanu]

> But something that may be interesting would
> be the ability to allow the stream of computations to branch; instead
> of pipelines being just a list, make them a tree, or even some kind of
> dag (if one allows for the possibility of recombining streams).

Rc has this. It's great. See section 10 of the rc paper or <{command}
in the rc manual. I use it all the time to see differences between
programmatically generated things.

-- 
Aram Hăvărneanu

Re: [9fans] rc's shortcomings (new subject line)

[😜]

Hi, just my 2¢ for the fanning out of pipes: if I remember correctly,
mycroftiv's hubfs (or some other software in his contrib) allowed one to
do exactly this.
hth

On 08/28/2012 09:41 PM, Dan Cross wrote:
> On Tue, Aug 28, 2012 at 8:56 PM, erik quanstrom <quanstro@quanstro.net> wrote:
>>> And rc is not perfect.  I've always felt like the 'if not' stuff was a kludge.
>>
>> no, it's certainly not.  (i wouldn't call if not a kludge—just ugly.
> 
> Kludge perhaps in the sense that it seems to be to work around an
> issue with the grammar and the expectation that it's mostly going to
> be used interactively, as opposed to programmatically.  See below.
> 
>> the haahr/rakitzis es' if makes more sense, even if it's wierder.)
> 
> Agreed; es would be an interesting starting point for a new shell.
> 
>> but the real question with rc is, what would you fix?
> 
> I think in order to really answer that question, one would have to
> step back for a moment and really think about what one wants out of a
> shell.  There seems to be a natural conflict a programming language
> and a command interpreter (e.g., the 'if' vs. 'if not' thing).  On
> which side does one err?
> 
>> i can only think of a few things around the edges.  `{} and $ are
>> obvious and is some way to use standard regular expressions.  but
>> those really aren't that motivating.  rc does enough.
> 
> I tend to agree.  As a command interpreter, rc is more or less fine as
> is.  I'd really only feel motivated to change whatever people felt
> were common nits, and there are fairly few of those.
> 
>> perhaps (let's hope) someone else has better ideas.
> 
> Well, something off the top of my head: Unix pipelines are sort of
> like chains of coroutines.  And they work great for defining linear
> combinations of filters.  But something that may be interesting would
> be the ability to allow the stream of computations to branch; instead
> of pipelines being just a list, make them a tree, or even some kind of
> dag (if one allows for the possibility of recombining streams).  That
> would be kind of an interesting thing to play with in a shell
> language; I don't know how practically useful it would be, though.
> 
>>> switch/case would make helluva difference over nested if/if not, if
>>> defaulted to fall-through.
>>
>> maybe you have an example?  because i don't see that.  if not works
>> fine, and can be nested.  case without fallthrough is also generally
>> what i want.  if not, i can make the common stuff a function.
>>
>>> variable scoping (better than subshel) would help writing larger
>>> scripts, but that's not necessarily an improvement ;-) something
>>> similar to LISP's `let' special form, for dynamic binding.
> 
> (A nit: 'let' actually introduces lexical scoping in most Lisp
> variants; yes, doing (let ((a 1)) ...) has non-lexical effect if 'a'
> is a dynamic variable in Common Lisp, but (let) doesn't itself
> introduce dynamic variables.  Emacs Lisp is a notable exception in
> this regard.)
> 
>> there is variable scoping.  you can write
>>
>>         x=() y=() cmd
>>
>> cmd can be a function body or whatever.  x and y are then private
>> to cmd.  you can nest redefinitions.
>>
>>         x=1 y=2 {echo first $x $y; x=a y=b {echo second $x $y; x=α y=β {echo third $x $y}; echo ret second $x $y}; echo ret first $x $y}
>>         first 1 2
>>         second a b
>>         third α β
>>         ret second a b
>>         ret first 1 2
> 
> This syntax feels clunky and unfamiliar to me; rc resembles block
> scoped languages like C; I'd rather have a 'local' or similar keyword
> to introduce a variable in the scope of each '{ }' block.
> 
>> you should try the es shell.  es had let and some other scheme-y
>> features.  let allows one to do all kinds of tricky stuff, like build
>> a shell debugger in the shell, but my opinion is that es was more
>> powerful and fun, but it didn't buy enough because it didn't really
>> expand on the essential nature of a shell.  what can one do to
>> manipulate processes and file descriptors.
> 
> es was a weird merger between rc's syntax and functional programming
> concepts.  It's neat-ish, but unless we're really ready to go to the
> pipe monad (not that weird, in my opinion) you're right.  Still, if it
> allowed one to lexically bind a file descriptor to a variable, I could
> see that being neat; could I have a closure over a file descriptor?  I
> don't think the underlying process model is really set up for it, but
> it would be kind of cool: one could have different commands consuming
> part of a stream in a very flexible way.
> 
>         - Dan C.
> 

Re: [9fans] rc's shortcomings (new subject line)

[Bakul Shah]

On Tue, 28 Aug 2012 14:44:40 EDT erik quanstrom <quanstro@quanstro.net>  wrote:
> >=20
> > switch/case would make helluva difference over nested if/if not, if
> > defaulted to fall-through.
>
> maybe you have an example?  because i don't see that.  if not works
> fine, and can be nested.  case without fallthrough is also generally
> what i want.  if not, i can make the common stuff a function.
>
> > variable scoping (better than subshel) would help writing larger
> > scripts, but that's not necessarily an improvement ;-) something
> > similar to LISP's `let' special form, for dynamic binding.
>
> there is variable scoping.  you can write
>
> 	x=3D() y=3D() cmd
>
> cmd can be a function body or whatever.  x and y are then private
> to cmd.  you can nest redefinitions. =20
>
> 	x=3D1 y=3D2 {echo first $x $y; x=3Da y=3Db {echo second $x $y; x=3D=CE=
> B1=
>  y=3D=CE=B2 {echo third $x $y}; echo ret second $x $y}; echo ret first $x=
>  $y}
> 	first 1 2
> 	second a b
> 	third =CE=B1 =CE=B2
> 	ret second a b
> 	ret first 1 2

This is basically the same as let. Instead of
    let x=1 y=2 foo
you say
    x=1 y=2 foo
and this is lexical scoping. try

    lex=1 { echo $lex; }
    echo $lex
vs
    { var=1; echo $var; }
    echo $var

Re: [9fans] rc's shortcomings (new subject line)

[erik quanstrom]

> > the haahr/rakitzis es' if makes more sense, even if it's wierder.)
> 
> Agreed; es would be an interesting starting point for a new shell.

es is great input.  there are really cool ideas there, but it does
seem like a lesson learned to me, rather than a starting point.

> I think in order to really answer that question, one would have to
> step back for a moment and really think about what one wants out of a
> shell.  There seems to be a natural conflict a programming language
> and a command interpreter (e.g., the 'if' vs. 'if not' thing).  On
> which side does one err?

since the raison d'être of a shell is to be a command interpter, i'd
go with that.

> I tend to agree.  As a command interpreter, rc is more or less fine as
> is.  I'd really only feel motivated to change whatever people felt
> were common nits, and there are fairly few of those.

there are nits of omission, and those can be fixable.  ($x(n-m) was added)

> > perhaps (let's hope) someone else has better ideas.
> 
> Well, something off the top of my head: Unix pipelines are sort of
> like chains of coroutines.  And they work great for defining linear
> combinations of filters.  But something that may be interesting would
> be the ability to allow the stream of computations to branch; instead
> of pipelines being just a list, make them a tree, or even some kind of
> dag (if one allows for the possibility of recombining streams).  That
> would be kind of an interesting thing to play with in a shell
> language; I don't know how practically useful it would be, though.

rc already has non-linear pipelines.  but they're not very convienient.

i think part of the problem is answering the question, what problem
would we like to solve.  because "a better shell" just isn't well-defined
enough.

my knee-jerk reaction to my own question is that making it easier
and more natural to parallelize dataflow.  a pipeline is just a really
low-level way to talk about it.  the standard
	grep x *.[ch]
forces all the *.[ch] to be generated before 1 instance of grep runs on
whatever *.[ch] evaluates to be.

but it would be okay for almost every use of this if *.[ch] were generated
in parallel with any number of grep's being run.

i suppose i'm stepping close to sawzall now.

- erik

Re: [9fans] rc's shortcomings (new subject line)

[Bakul Shah]

On Tue, 28 Aug 2012 16:34:10 EDT erik quanstrom <quanstro@quanstro.net>  wrote:
> my knee-jerk reaction to my own question is that making it easier
> and more natural to parallelize dataflow.  a pipeline is just a really
> low-level way to talk about it.  the standard
> 	grep x *.[ch]
> forces all the *.[ch] to be generated before 1 instance of grep runs on
> whatever *.[ch] evaluates to be.

Here the shell would have to understand program behavior.
Consider something like

	8l x.8 y.8 z.8 ...

This can't be parallelized (but a parallelizable loader can be
written).

May be you can define a `par' command (sort of like xargs but
invokes in parallel).

	echo *.[ch] | par -1 grep x

> but it would be okay for almost every use of this if *.[ch] were generated
> in parallel with any number of grep's being run.
>
> i suppose i'm stepping close to sawzall now.

Be careful!

Re: [9fans] rc's shortcomings (new subject line)

[erik quanstrom]

> On Tue, 28 Aug 2012 16:34:10 EDT erik quanstrom <quanstro@quanstro.net>  wrote:
> > my knee-jerk reaction to my own question is that making it easier
> > and more natural to parallelize dataflow.  a pipeline is just a really
> > low-level way to talk about it.  the standard
> > 	grep x *.[ch]
> > forces all the *.[ch] to be generated before 1 instance of grep runs on
> > whatever *.[ch] evaluates to be.
>
> Here the shell would have to understand program behavior.
> Consider something like
>
> 	8l x.8 y.8 z.8 ...
>
> This can't be parallelized (but a parallelizable loader can be
> written).

ya, ya.  improving on rc in a noticable way is hard.
and thinking aloud is a bad idea.  and a good way to look foolish.

- erik

Re: [9fans] rc's shortcomings (new subject line)

[dexen deVries]

On Tuesday 28 of August 2012 16:34:10 erik quanstrom wrote:
> my knee-jerk reaction to my own question is that making it easier
> and more natural to parallelize dataflow.  a pipeline is just a really
> low-level way to talk about it.  the standard
> 	grep x *.[ch]
> forces all the *.[ch] to be generated before 1 instance of grep runs on
> whatever *.[ch] evaluates to be.
> 
> but it would be okay for almost every use of this if *.[ch] were generated
> in parallel with any number of grep's being run.


(in Linux terms, sorry!)

you can get close with find|xargs -- it runs the command for every -L <number> 
lines of input. AFAIK xargs does not parallelize the execution itself.


find -name '*.[ch]' | xargs -L 8 grep REGEX


-- 
dexen deVries

[[[↓][→]]]

I'm sorry that this was such a long lett­er, but I didn't have time to write 
you a short one. -- Bla­ise Pasc­al

Re: [9fans] rc's shortcomings (new subject line)

[Dan Cross]

On Wed, Aug 29, 2012 at 2:04 AM, erik quanstrom <quanstro@quanstro.net> wrote:
>> > the haahr/rakitzis es' if makes more sense, even if it's wierder.)
>>
>> Agreed; es would be an interesting starting point for a new shell.
>
> es is great input.  there are really cool ideas there, but it does
> seem like a lesson learned to me, rather than a starting point.

Starting point conceptually, if not in implementation.

>> I think in order to really answer that question, one would have to
>> step back for a moment and really think about what one wants out of a
>> shell.  There seems to be a natural conflict a programming language
>> and a command interpreter (e.g., the 'if' vs. 'if not' thing).  On
>> which side does one err?
>
> since the raison d'être of a shell is to be a command interpter, i'd
> go with that.

Fair enough, but that will color the flavor of the shell when used as
a programming language.  Then again, Inferno's shell was able to
successfully navigate both in a comfortable manner by using clever
facilities available in that environment (module loading and the
like).  It's not clear how well that works in an environment like
Unix, let alone Plan 9.

>> I tend to agree.  As a command interpreter, rc is more or less fine as
>> is.  I'd really only feel motivated to change whatever people felt
>> were common nits, and there are fairly few of those.
>
> there are nits of omission, and those can be fixable.  ($x(n-m) was added)

Right.

>> > perhaps (let's hope) someone else has better ideas.
>>
>> Well, something off the top of my head: Unix pipelines are sort of
>> like chains of coroutines.  And they work great for defining linear
>> combinations of filters.  But something that may be interesting would
>> be the ability to allow the stream of computations to branch; instead
>> of pipelines being just a list, make them a tree, or even some kind of
>> dag (if one allows for the possibility of recombining streams).  That
>> would be kind of an interesting thing to play with in a shell
>> language; I don't know how practically useful it would be, though.
>
> rc already has non-linear pipelines.  but they're not very convienient.

And somewhat limited.  There's no real concept of 'fanout' of output,
for instance (though that's a fairly trivial command, so probably
doesn't count), or multiplexing input from various sources that would
be needed to implement something like a shell-level data flow network.

Muxing input from multiple sources is hard when the data isn't somehow
self-delimited.  For specific applications this is solvable by the
various pieces of the computation just agreeing on how to represent
data and having a program that takes that into account do the muxing,
but for a general mechanism it's much more difficult, and the whole
self-delimiting thing breaks the Unix 'data as text' abstraction by
imposing a more rigid structure.

There may be other ways to achieve the same thing; I remember that the
boundaries of individual writes used to be preserved on read, but I
think that behavior changed somewhere along the way; maybe with the
move away from streams?  Or perhaps I'm misremembering?  I do remember
that it led to all sorts of hilarious arguments about what the
behavior of things like, 'write(fd, "", 0)' should induce in the
reading side of things, but this was a long time ago.

Anyway, maybe something along the lines of, 'read a message of length
<=SOME_MAX_SIZE from a file descriptor; the message boundaries are
determined by the sending end and preserved by read/write' could be
leveraged here without too much disruption to the current model.

> i think part of the problem is answering the question, what problem
> would we like to solve.  because "a better shell" just isn't well-defined
> enough.

Agreed.

> my knee-jerk reaction to my own question is that making it easier
> and more natural to parallelize dataflow.  a pipeline is just a really
> low-level way to talk about it.  the standard
>         grep x *.[ch]
> forces all the *.[ch] to be generated before 1 instance of grep runs on
> whatever *.[ch] evaluates to be.
>
> but it would be okay for almost every use of this if *.[ch] were generated
> in parallel with any number of grep's being run.
>
> i suppose i'm stepping close to sawzall now.

Actually, I think you're stepping closer to the reducers stuff Rich
Hickey has done recently in Clojure, though there's admittedly a lot
of overlap with the sawzall way of looking at things.

        - Dan C.

Re: [9fans] rc's shortcomings (new subject line)

[erik quanstrom]

> > rc already has non-linear pipelines.  but they're not very convienient.
>
> And somewhat limited.  There's no real concept of 'fanout' of output,
> for instance (though that's a fairly trivial command, so probably
> doesn't count), or multiplexing input from various sources that would
> be needed to implement something like a shell-level data flow network.
>
> Muxing input from multiple sources is hard when the data isn't somehow
> self-delimited.
>[...]
> There may be other ways to achieve the same thing; I remember that the
> boundaries of individual writes used to be preserved on read, but I
> think that behavior changed somewhere along the way; maybe with the
> move away from streams?  Or perhaps I'm misremembering?

pipes still preserve write boundaries, as does il.  (even the 0-byte write) but tcp of course by
definition does not.  but either way, the protocol would need to be
self-framed to be transported on tcp.  and even then, there are protocols
that are essentially serial, like tls.

> > i suppose i'm stepping close to sawzall now.
>
> Actually, I think you're stepping closer to the reducers stuff Rich
> Hickey has done recently in Clojure, though there's admittedly a lot
> of overlap with the sawzall way of looking at things.

my knowledge of both is weak.  :-)

- erik

Re: [9fans] rc's shortcomings (new subject line)

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 532 bytes --]

http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.78.5331
Paul Haeberli, ConMan: A Visual Programming Language for Interactive
Graphics (1988)
I supervised a student who did an implementation for a Blit-like
environment on the Sun3 as a project;
unfortunately I didn't keep a copy. I remember there were several things
left to work out based on the paper.
(The Blit-like environment replaced megabytes of Sunview, in case you were
wondering, and enabled some serious fun.
Sunview enabled some serious head-banging.)

[-- Attachment #2: Type: text/html, Size: 867 bytes --]

Re: [9fans] rc's shortcomings (new subject line)

[Dan Cross]

On Wed, Aug 29, 2012 at 7:27 PM, erik quanstrom <quanstro@quanstro.net> wrote:
>> > rc already has non-linear pipelines.  but they're not very convienient.
>>
>> And somewhat limited.  There's no real concept of 'fanout' of output,
>> for instance (though that's a fairly trivial command, so probably
>> doesn't count), or multiplexing input from various sources that would
>> be needed to implement something like a shell-level data flow network.
>>
>> Muxing input from multiple sources is hard when the data isn't somehow
>> self-delimited.
>>[...]
>> There may be other ways to achieve the same thing; I remember that the
>> boundaries of individual writes used to be preserved on read, but I
>> think that behavior changed somewhere along the way; maybe with the
>> move away from streams?  Or perhaps I'm misremembering?
>
> pipes still preserve write boundaries, as does il.  (even the 0-byte write) but tcp of course by
> definition does not.  but either way, the protocol would need to be
> self-framed to be transported on tcp.  and even then, there are protocols
> that are essentially serial, like tls.

Right.  I think this is the reason for Bakul's question about
s-expressions or JSON or a similar format; those formats are
inherently self-delimiting.  The problem with that is that, for
passing those things around to work without some kind of reverse
'tee'-like intermediary, the system has to understand the the things
that are being transferred are s-expressions or JSON records or
whatever, not just streams of uninterpreted bytes.  We've steadfastly
rejected such system-imposing structure on files in Unix-y type
environments since 1969.

But conceptually, these IPC mechanisms are sort of similar to channels
in CSP-style languages.  A natural question then becomes, how do
CSP-style languages handle the issue?  Channels work around the muxing
thing by being typed; elements placed onto a channel are indivisible
objects of that type, so one doesn't need to worry about interference
from other objects simultaneously placed onto the same channel in
other threads of execution.  Could we do something similar with pipes?
 I don't know that anyone wants typed file descriptors; that would
open a whole new can of worms.

Maybe the building blocks are all there; one could imagine some kind
of 'splitter' program that could take input and rebroadcast it across
multiple output descriptors.  Coupled with some kind of 'merge'
program that could take multiple input streams and mux them onto a
single output, one could build nearly arbitrarily complicated networks
of computations connected by pipes.  Maybe for simplicity constrain
these to be DAGs.  With a notation to describe these computation
graphs, one could just do a topological sort of the graph, create
pipes in all the appropriate places and go from there.  Is the shell
an appropriate place for such a thing?

Forsyth's link looks interesting; I haven't read through the paper in
detail yet, but it sort of reminded me of LabView in a way (where
non-programmers wire together data flows using boxes and arrows and
stuff).

>> > i suppose i'm stepping close to sawzall now.
>>
>> Actually, I think you're stepping closer to the reducers stuff Rich
>> Hickey has done recently in Clojure, though there's admittedly a lot
>> of overlap with the sawzall way of looking at things.
>
> my knowledge of both is weak.  :-)

The Clojure reducers stuff is kind of slick.

Consider a simple reduction in Lisp; say, summing up a list of numbers
or something like that.  In Common Lisp, we may write this as:

    (reduce #'+ '(1 2 3 4 5))

In clojure, the same thing would be written as:

    (reduce + [1 2 3 4 5])

The problem is how the computation is performed.  To illustrate,
here's a simple definition of 'reduce' written in Scheme (R5RS doesn't
have a standard 'reduce' function, but it is most commonly written to
take an initial element, so I do that here).

    (define (reduce binop a bs)
      (if (null? bs)
        a
        (reduce binop (binop a (car bs)) (cdr bs))))

Notice how the recursive depth of the function is linear in the length
of the list.  But, if one thinks about what I'm doing here (just
addition of simple numbers) there's no reason this can't be done in
parallel.  In particular, if I can split the list into evenly sized
parts and recurse, I can limit the recursive depth of the computation
to O(lg n).  Something more like:

    (define (reduce binop a bs)
      (if (null? bs)
        a
        (let ((halves (split-into-halves bs)))
          (binop (reduce binop a (car halves)) (reduce binop a (cadr halves)))

If I can exploit parallelism to execute functions in the recursion
tree simultaneously, I can really cut down on execution time.  The
requirement is that binop over a and bs's is a monoid; that is, binop
is associative over the set from which 'a' and 'bs' are drawn, and 'a'
is an identity element.

This sounds wonderful, of course, but in Lisp and Scheme, lists are
built from cons cells, and even if I have some magic
'split-into-halves' function that satisfies the requirements of
reduce, doing so is still necessarily linear, so I don't gain much.
Besides, having to pass around the identity all the time is a bummer.

But in clojure, the Lisp concept of a list (composed of cons cells) is
generalized into the concept of a 'seq'.  A seq is just a sequence of
things; it could be a list, a vector, some other container (say, a
sequence of key/value pairs derived from some kind of associated
structure), or a stream of data being read from a file or network
connection.

What's the *real* problem here?  The issue is that reduce "knows" too
much about the things it is reducing over.  Doing things sequentially
is easy, but slow; doing things in parallel requires that reduce know
a lot about the type of thing it's reducing over (e.g., this magic
'split-into-halves' function.  Further, that might not be appropriate
for *all* sequence types; e.g., files or lists made from cons cells.

The insight of the reducers framework is that one can just ask the
container to reduce itself.  Basically, pass it a function and say,
"here, reduce yourself with this function however you see fit."  Then,
random-access containers can do things in parallel; lists and files
and things can do things sequentially; associative containers can do
whatever they want, etc.  The implementation is kind of interesting;
more information is here:
http://clojure.com/blog/2012/05/08/reducers-a-library-and-model-for-collection-processing.html

Your example of running multiple 'grep's in parallel sort of reminded
me of this, though it occurs to me that this can probably be done with
a command: a sort of 'parallel apply' thing that can run a command
multiple times concurrently, each invocation on a range of the
arguments.  But making it simple and elegant is likely to be tricky.

        - Dan C.

Re: [9fans] rc's shortcomings (new subject line)

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 155 bytes --]

typed command languages:
I F Currie, J M Foster, Curt: The Command Interpreter Language for Flex
  http://www.vitanuova.com/dist/doc/rsre-3522-curt.pdf

[-- Attachment #2: Type: text/html, Size: 287 bytes --]

Re: [9fans] rc's shortcomings (new subject line)

[dexen deVries]

On Thursday 30 of August 2012 15:35:47 Dan Cross wrote:
> (...)
> Your example of running multiple 'grep's in parallel sort of reminded
> me of this, though it occurs to me that this can probably be done with
> a command: a sort of 'parallel apply' thing that can run a command
> multiple times concurrently, each invocation on a range of the
> arguments.  But making it simple and elegant is likely to be tricky.

now that i think of it...

mk creates DAG of dependences and then reduces it by calling commands, going 
in parallel where applicable.

erik's example with grep x *.[ch] boils down to two cases:
 - for single use, do it simple & slow way -- just run single grep process for 
all files
 - but when you expect to traverse those files often, prepare a mkfile 
(preferably in a semi-automatic way) which will perform search in parallel.

caveat: output of one grep instance could end up in the midst of a /line/ of 
output of another grep instance.



-- 
dexen deVries

[[[↓][→]]]

I'm sorry that this was such a long lett­er, but I didn't have time to write 
you a short one. -- Bla­ise Pasc­al

Re: [9fans] rc's shortcomings (new subject line)

[erik quanstrom]

> caveat: output of one grep instance could end up in the midst of a /line/ of
> output of another grep instance.

grep -b.  but in general if the bio library had an option to output line-wise,
then the problem could be avoided.  otherwise, one would need to mux the
output.

- erik

Re: [9fans] rc's shortcomings (new subject line)

[dexen deVries]

On Thursday 30 of August 2012 09:47:59 you wrote:
> > caveat: output of one grep instance could end up in the midst of a /line/
> > of output of another grep instance.
> 
> grep -b.  but in general if the bio library had an option to output
> line-wise, then the problem could be avoided.  otherwise, one would need to
> mux the output.


to quote you, erik,
> pipes still preserve write boundaries, as does il

so, hopefully, a dumb pipe to cat would do the job...? :^)

grep-single-directory:VQ: $FILES_IN_THE_DIR
	grep $regex $prereq | cat


-- 
dexen deVries

[[[↓][→]]]

I'm sorry that this was such a long lett­er, but I didn't have time to write 
you a short one. -- Bla­ise Pasc­al

Re: [9fans] rc's shortcomings (new subject line)

[erik quanstrom]

> > grep -b.  but in general if the bio library had an option to output
> > line-wise, then the problem could be avoided.  otherwise, one would need to
> > mux the output.
>
>
> to quote you, erik,
> > pipes still preserve write boundaries, as does il
>
> so, hopefully, a dumb pipe to cat would do the job...? :^)
>
> grep-single-directory:VQ: $FILES_IN_THE_DIR
> 	grep $regex $prereq | cat

i think you still need grep -b, because otherwise grep uses
the bio library to buffer output, and bio doesn't respect lines.

- erik

Re: [9fans] rc's shortcomings (new subject line)

[Dan Cross]

On Thu, Aug 30, 2012 at 7:11 PM, dexen deVries <dexen.devries@gmail.com> wrote:
> On Thursday 30 of August 2012 15:35:47 Dan Cross wrote:
>> (...)
>> Your example of running multiple 'grep's in parallel sort of reminded
>> me of this, though it occurs to me that this can probably be done with
>> a command: a sort of 'parallel apply' thing that can run a command
>> multiple times concurrently, each invocation on a range of the
>> arguments.  But making it simple and elegant is likely to be tricky.
>
> now that i think of it...
>
> mk creates DAG of dependences and then reduces it by calling commands, going
> in parallel where applicable.
>
> erik's example with grep x *.[ch] boils down to two cases:
>  - for single use, do it simple & slow way -- just run single grep process for
> all files
>  - but when you expect to traverse those files often, prepare a mkfile
> (preferably in a semi-automatic way) which will perform search in parallel.
>
> caveat: output of one grep instance could end up in the midst of a /line/ of
> output of another grep instance.

The thing is that mk doesn't really do anything to set up connections
between the commands it runs.

Re: [9fans] rc's shortcomings (new subject line)

[erik quanstrom]

> The thing is that mk doesn't really do anything to set up connections
> between the commands it runs.

it does.  the connections are through the file system.

- erik

Re: [9fans] rc's shortcomings (new subject line)

[Dan Cross]

On Thu, Aug 30, 2012 at 7:56 PM, erik quanstrom <quanstro@quanstro.net> wrote:
>> The thing is that mk doesn't really do anything to set up connections
>> between the commands it runs.
>
> it does.  the connections are through the file system.

No.  The order in which commands are run (or if they are run at all)
is based on file timestamps, so in that sense it uses the filesystem
for coordination, but mk itself doesn't do anything to facilitate
interprocess communications between the commands it runs (for example
setting up pipes between commands).

        - Dan C.

Re: [9fans] rc's shortcomings (new subject line)

[erik quanstrom]

> On Thu, Aug 30, 2012 at 7:56 PM, erik quanstrom <quanstro@quanstro.net> wrote:
> >> The thing is that mk doesn't really do anything to set up connections
> >> between the commands it runs.
> >
> > it does.  the connections are through the file system.
>
> No.  The order in which commands are run (or if they are run at all)
> is based on file timestamps, so in that sense it uses the filesystem
> for coordination, but mk itself doesn't do anything to facilitate
> interprocess communications between the commands it runs (for example
> setting up pipes between commands).

what i was saying is that mk knows and insures that the output files
are there.  the fact that it's not in the middle of the conversation is
an implementation detail, imho.

that is, mk is built on the assumption that programs communicate through
files; $O^c communicates to $O^l by producing .$O files.  mk rules
know this.

- erik

Re: [9fans] rc's shortcomings (new subject line)

[dexen deVries]

On Thursday 30 of August 2012 10:41:38 erik quanstrom wrote: 
> what i was saying is that mk knows and insures that the output files
> are there.  the fact that it's not in the middle of the conversation is
> an implementation detail, imho.
> 
> that is, mk is built on the assumption that programs communicate through
> files; $O^c communicates to $O^l by producing .$O files.  mk rules
> know this.

shouldn't be the case for rules with virtual targets (V). such rules are 
always executed, and the order should only depend on implementatino of DAG 
traversing. ``Files may be made in any order that respects the preceding 
restrictions'', from manpage.

if mk was used for executing grep in parallel, prerequisites would be actual 
files, but targets would be virtual; probably 1...$NPROC targets per 
directory.


anyway, a meld of Rc shell and mk? crazy idea.


-- 
dexen deVries

[[[↓][→]]]

I'm sorry that this was such a long lett­er, but I didn't have time to write 
you a short one. -- Bla­ise Pasc­al

Re: [9fans] rc's shortcomings (new subject line)

[sl]

> anyway, a meld of Rc shell and mk? crazy idea.

What was mash?

-sl

Re: [9fans] rc's shortcomings (new subject line)

[Lucio De Re]

> anyway, a meld of Rc shell and mk? crazy idea.

Inferno (Vitanuova) released a "mash" a ways back, but apparently the
sources were lost.  It was mind-bogglingly interesting!

++L

Re: [9fans] rc's shortcomings (new subject line)

[Burton Samograd]

>> anyway, a meld of Rc shell and mk? crazy idea.

> Inferno (Vitanuova) released a "mash" a ways back, but apparently the sources were lost.  It was mind-bogglingly interesting!

In case anyone's interested (like I was):

http://www.vitanuova.com/inferno/man/1/mash.html

--
Burton Samograd

This e-mail, including accompanying communications and attachments, is strictly confidential and only for the intended recipient. Any retention, use or disclosure not expressly authorised by Markit is prohibited. This email is subject to all waivers and other terms at the following link: http://www.markit.com/en/about/legal/email-disclaimer.page

Please visit http://www.markit.com/en/about/contact/contact-us.page? for contact information on our offices worldwide.

Re: [9fans] rc's shortcomings (new subject line)

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 358 bytes --]

Errr ... no. Twice: mash was not VN code but brucee's preemptive strike
against a POSIX shell for Lucent's Inferno;
VN's Inferno had a shell with a different style done by Roger Peppe.

On 30 August 2012 16:13, Lucio De Re <lucio@proxima.alt.za> wrote:

> Inferno (Vitanuova) released a "mash" a ways back, but apparently the
> sources were lost.
>

[-- Attachment #2: Type: text/html, Size: 659 bytes --]

Re: [9fans] rc's shortcomings (new subject line)

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 400 bytes --]

The source of mash as VN inherited it from the defunct Lucent organisation
on 1 September 1999 remains in the tree,
so it wasn't lost.

On 30 August 2012 16:13, Charles Forsyth <charles.forsyth@gmail.com> wrote:
>
> On 30 August 2012 16:13, Lucio De Re <lucio@proxima.alt.za> wrote:
>
>> Inferno (Vitanuova) released a "mash" a ways back, but apparently the
>> sources were lost.
>>
>
>

[-- Attachment #2: Type: text/html, Size: 966 bytes --]

Re: [9fans] rc's shortcomings (new subject line)

[Bakul Shah]

On Thu, 30 Aug 2012 15:35:47 +0530 Dan Cross <crossd@gmail.com>  wrote:
> On Wed, Aug 29, 2012 at 7:27 PM, erik quanstrom <quanstro@quanstro.net> wrote
> :
> >> > rc already has non-linear pipelines.  but they're not very convienient.
> >>
> >> And somewhat limited.  There's no real concept of 'fanout' of output,
> >> for instance (though that's a fairly trivial command, so probably
> >> doesn't count), or multiplexing input from various sources that would
> >> be needed to implement something like a shell-level data flow network.
> >>
> >> Muxing input from multiple sources is hard when the data isn't somehow
> >> self-delimited.
> >>[...]
> >> There may be other ways to achieve the same thing; I remember that the
> >> boundaries of individual writes used to be preserved on read, but I
> >> think that behavior changed somewhere along the way; maybe with the
> >> move away from streams?  Or perhaps I'm misremembering?
> >
> > pipes still preserve write boundaries, as does il.  (even the 0-byte write)
>  but tcp of course by
> > definition does not.  but either way, the protocol would need to be
> > self-framed to be transported on tcp.  and even then, there are protocols
> > that are essentially serial, like tls.
>
> Right.  I think this is the reason for Bakul's question about
> s-expressions or JSON or a similar format; those formats are
> inherently self-delimiting.

Indeed.

>                              The problem with that is that, for
> passing those things around to work without some kind of reverse
> 'tee'-like intermediary, the system has to understand the the things
> that are being transferred are s-expressions or JSON records or
> whatever, not just streams of uninterpreted bytes.  We've steadfastly
> rejected such system-imposing structure on files in Unix-y type
> environments since 1969.

I think that it is time to try something new.  A lot of things
don't fit into into this model of bytepipes connecting
processes. A lot of commands even in this model use line
"objects". But the kind of composability one gets in Scheme,
go, functional languages etc is missing. Even go seems to go
the "one language for all" Lispy model -- its typed channels
are all within a single address space. [Actually I would have
much preferred if they had just focused on adding channels and
parallel processes to a Scheme instead of creating a whole new
language but that is whole 'nother discussion!]

> But conceptually, these IPC mechanisms are sort of similar to channels
> in CSP-style languages.  A natural question then becomes, how do
> CSP-style languages handle the issue?  Channels work around the muxing
> thing by being typed; elements placed onto a channel are indivisible
> objects of that type, so one doesn't need to worry about interference
> from other objects simultaneously placed onto the same channel in
> other threads of execution.  Could we do something similar with pipes?
>  I don't know that anyone wants typed file descriptors; that would
> open a whole new can of worms.

I am suggesting channels of self-typed objects.  The idea of
communicating self-identifying objects between loosely coupled
processes is blindingly obvious to me. And as long as you have
one producer/one consumer pair, there are no problems in
implementing this on any system but the unix model of
"inheriting" file descriptors (or even passing them around to
unrelated processes) and then letting them all blab
indiscriminately on the same channel just doesn't work. So again
Unix gets in the way.

> This sounds wonderful, of course, but in Lisp and Scheme, lists are
> built from cons cells, and even if I have some magic
> 'split-into-halves' function that satisfies the requirements of
> reduce, doing so is still necessarily linear, so I don't gain much.
> Besides, having to pass around the identity all the time is a bummer.

You can use cdr-coding. Or just use arrays like APL/j/k. But a
knowledge of function properties is essential to implement
them efficiently and for one arg version (without the initial
value). In k "/" is the reduce operator so you can say

    +/!3	// !3 == 0 1 2
    0+/!3 	// two arg version of +.

And
    */!0
    +/!0
do the right thing because the language knows identity
elements for + and *.

> But in clojure, the Lisp concept of a list (composed of cons cells) is
> generalized into the concept of a 'seq'.  A seq is just a sequence of
> things; it could be a list, a vector, some other container (say, a
> sequence of key/value pairs derived from some kind of associated
> structure), or a stream of data being read from a file or network
> connection.
>
> What's the *real* problem here?  The issue is that reduce "knows" too
> much about the things it is reducing over.  Doing things sequentially
> is easy, but slow; doing things in parallel requires that reduce know
> a lot about the type of thing it's reducing over (e.g., this magic
> 'split-into-halves' function.  Further, that might not be appropriate
> for *all* sequence types; e.g., files or lists made from cons cells.

Even more common than reduce is map. No reason why you can't
parallelize

	8c *.c

> Your example of running multiple 'grep's in parallel sort of reminded
> me of this, though it occurs to me that this can probably be done with

This is a map not reduce. The "reduce" would be implicitly
(and often wrongly) done by fd inheritance.

I have a toy array-scheme where all functions except array
functions are applied elementwise when given arrays.

	(+ #(1 2 3) #(4 5 6)) => #(5 7 9)
	(* 2 #(4 5 6)) => #(8 10 12)
	(* 2 #(4 #(5 5) 6)) => #(8 #(10 10) 12)

So I think map can be made implicit but reduction has to be
explicit. This is what APLs do.

> a command: a sort of 'parallel apply' thing that can run a command
> multiple times concurrently, each invocation on a range of the
> arguments.  But making it simple and elegant is likely to be tricky.

APL/k have peach for parallel-each ("each" is their way of saying map).

Re: [9fans] rc's shortcomings (new subject line)

[erik quanstrom]

> Even more common than reduce is map. No reason why you can't
> parallelize
> 
> 	8c *.c

we already do—with mk.

- erik

Re: [9fans] rc's shortcomings (new subject line)

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 295 bytes --]

That's true, but the C compiler also does each .c in parallel up to NPROC.

On 30 August 2012 18:18, erik quanstrom <quanstro@labs.coraid.com> wrote:

> > Even more common than reduce is map. No reason why you can't
> > parallelize
> >
> >       8c *.c
>
> we already do—with mk.
>

[-- Attachment #2: Type: text/html, Size: 668 bytes --]

Re: [9fans] rc's shortcomings (new subject line)

[erik quanstrom]

On Thu Aug 30 16:08:23 EDT 2012, charles.forsyth@gmail.com wrote:

> That's true, but the C compiler also does each .c in parallel up to NPROC.
> 
> On 30 August 2012 18:18, erik quanstrom <quanstro@labs.coraid.com> wrote:
> 
> > > Even more common than reduce is map. No reason why you can't
> > > parallelize
> > >
> > >       8c *.c
> >
> > we already do—with mk.

ha!  i hadn't seen that before.  too bad mk doesn't (generally) use it.

- erik

Re: [9fans] rc's shortcomings (new subject line)

[erik quanstrom]

> rejected such system-imposing structure on files in Unix-y type
> environments since 1969.
[...]
> other threads of execution.  Could we do something similar with pipes?
>  I don't know that anyone wants typed file descriptors; that would
> open a whole new can of worms.

i don't see that the os can really help here.  lib9p has no problem
turning an undelimited byte stream → 9p messages.  there's no reason
any other format couldn't get the same treatment.

said another way, we already have typed streams, but they're not
enforced by the operating system.

one can also use the thread library technique, using shared memory.

> Consider a simple reduction in Lisp; say, summing up a list of numbers
> or something like that.  In Common Lisp, we may write this as:
> 
>     (reduce #'+ '(1 2 3 4 5))
> 
> In clojure, the same thing would be written as:
> 
>     (reduce + [1 2 3 4 5])
> 

this reminds me of a bit of /bin/man.  it seemed that the case statement
to generate a pipeline of formatting commands was awkward—verbose
and yet limited.

	fn pipeline{
		if(~ $#* 0)
			troff $Nflag $Lflag -$MAN | $postproc
		if not{
			p = $1; shift
			$p | pipeline $*
		}
	}

	fn roff {
		...
		fontdoc $2 | pipeline $preproc
	}

> http://clojure.com/blog/2012/05/08/reducers-a-library-and-model-for-collection-processing.html
> 
> Your example of running multiple 'grep's in parallel sort of reminded
> me of this, though it occurs to me that this can probably be done with
> a command: a sort of 'parallel apply' thing that can run a command
> multiple times concurrently, each invocation on a range of the
> arguments.  But making it simple and elegant is likely to be tricky.

actually, unless i misread (i need more coffee), the blog sounds just like
xargs.

- erik

Re: [9fans] rc's shortcomings (new subject line)

[Dan Cross]

On Thu, Aug 30, 2012 at 7:03 PM, erik quanstrom <quanstro@quanstro.net> wrote:
>> rejected such system-imposing structure on files in Unix-y type
>> environments since 1969.
> [...]
>> other threads of execution.  Could we do something similar with pipes?
>>  I don't know that anyone wants typed file descriptors; that would
>> open a whole new can of worms.
>
> i don't see that the os can really help here.  lib9p has no problem
> turning an undelimited byte stream → 9p messages.  there's no reason
> any other format couldn't get the same treatment.

Yeah, I don't see much here unless one breaks the untyped stream model
(from the perspective of the system).

> said another way, we already have typed streams, but they're not
> enforced by the operating system.

Yes, but then every program that participates in one of these
computation networks has to have that type knowledge baked in.  The
Plan 9/Unix model seems to preclude a general mechanism.

> one can also use the thread library technique, using shared memory.

Sure, but that doesn't do much for designing a new shell.  :-)

>> Consider a simple reduction in Lisp; say, summing up a list of numbers
>> or something like that.  In Common Lisp, we may write this as:
>>
>>     (reduce #'+ '(1 2 3 4 5))
>>
>> In clojure, the same thing would be written as:
>>
>>     (reduce + [1 2 3 4 5])
>>
>
> this reminds me of a bit of /bin/man.  it seemed that the case statement
> to generate a pipeline of formatting commands was awkward—verbose
> and yet limited.
>
>         fn pipeline{
>                 if(~ $#* 0)
>                         troff $Nflag $Lflag -$MAN | $postproc
>                 if not{
>                         p = $1; shift
>                         $p | pipeline $*
>                 }
>         }
>
>         fn roff {
>                 ...
>                 fontdoc $2 | pipeline $preproc
>         }

Ha!  That's something.  I'm not sure what, but definitely something (I
actually kind of like it).

>> http://clojure.com/blog/2012/05/08/reducers-a-library-and-model-for-collection-processing.html
>>
>> Your example of running multiple 'grep's in parallel sort of reminded
>> me of this, though it occurs to me that this can probably be done with
>> a command: a sort of 'parallel apply' thing that can run a command
>> multiple times concurrently, each invocation on a range of the
>> arguments.  But making it simple and elegant is likely to be tricky.
>
> actually, unless i misread (i need more coffee), the blog sounds just like
> xargs.

Hmm, not exactly.  xargs would be like reducers if xargs somehow asked
stdin to apply a program to itself.

A parallel apply sort of thing could be used with xargs, of course;
'whatever | xargs papply foo' could keep some $n$ of foo's running at
the same time.  The magic behind 'papply foo `{whatever}' is that it
knows how to interpret its arguments in blocks.  xargs will invoke a
command after reading $n$ arguments, but that's mainly to keep from
overflowing the argument buffer, and (to my knowledge) it won't try to
keep multiple instances running them in parallel.

Hmm, I'm afraid I'm off in the realm of thinking out loud at this
point.  Sorry if that's noisy for folks.

        - Dan C.

Re: [9fans] rc's shortcomings (new subject line)

[Dan Cross]

On Thu, Aug 30, 2012 at 7:51 PM, Dan Cross <crossd@gmail.com> wrote:
> A parallel apply sort of thing could be used with xargs, of course;
> 'whatever | xargs papply foo' could keep some $n$ of foo's running at
> the same time.  The magic behind 'papply foo `{whatever}' is that it
> knows how to interpret its arguments in blocks.  xargs will invoke a
> command after reading $n$ arguments, but that's mainly to keep from
> overflowing the argument buffer, and (to my knowledge) it won't try to
> keep multiple instances running them in parallel.

Oops, I should have checked the man page before I wrote.  It seems
that at least some version of xargs have a '-P' for 'parallel' mode.

Re: [9fans] rc's shortcomings (new subject line)

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 318 bytes --]

If you look at the paper I referenced, you will. Similar abilities appeared
in systems that supported persistence and persistent programming
languages (cf. Malcolm Atkinson, not Wikipedia).

On 30 August 2012 14:33, erik quanstrom <quanstro@quanstro.net> wrote:

> i don't see that the os can really help here.

[-- Attachment #2: Type: text/html, Size: 573 bytes --]

Re: [9fans] rc's shortcomings (new subject line)

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 474 bytes --]

As another example, also from Flex,
J M Foster, I F Currie, "Remote Capabilities", The Computer Journal, 30(5),
1987, pp. 451-7.

http://comjnl.oxfordjournals.org/content/30/5/451.full.pdf

On 30 August 2012 15:45, Charles Forsyth <charles.forsyth@gmail.com> wrote:

> If you look at the paper I referenced, you will. Similar abilities
> appeared in systems that supported persistence and persistent programming
> languages (cf. Malcolm Atkinson, not Wikipedia).

[-- Attachment #2: Type: text/html, Size: 830 bytes --]

Re: [9fans] rc's shortcomings (new subject line)

[erik quanstrom]

> Hmm, I'm afraid I'm off in the realm of thinking out loud at this
> point.  Sorry if that's noisy for folks.

THANK YOU.  if 9fans needs anything, it's more thinking.

i'm not an edison fan, but i do like one thing he said, which was
that he had not failed, but simply discovered that the $n ways
he'd tried so far do not work.

- erik

Re: [9fans] rc's shortcomings (new subject line)

[erik quanstrom]

On Thu Aug 30 10:28:24 EDT 2012, crossd@gmail.com wrote:
> > said another way, we already have typed streams, but they're not
> > enforced by the operating system.
>
> Yes, but then every program that participates in one of these
> computation networks has to have that type knowledge baked in.  The
> Plan 9/Unix model seems to preclude a general mechanism.

that's what i thought when i first read the plan 9 papers.  but it
turns out, that it works out just fine for file servers, ssl, authentication,
etc.  why can't it work for another type of agreed protocol?  obviously
you'd need something along the lines of tlsclient/tlssrv if you wanted
normal programs to do this, but it might be that just a subset of programs
are really interested in participating.

> > one can also use the thread library technique, using shared memory.
>
> Sure, but that doesn't do much for designing a new shell.  :-)

the shell itself could have channels, without the idea escaping
into the wild.

- erik

Re: [9fans] rc's shortcomings (new subject line)

[erik quanstrom]

On Thu Aug 30 10:56:52 EDT 2012, charles.forsyth@gmail.com wrote:

> As another example, also from Flex,
> J M Foster, I F Currie, "Remote Capabilities", The Computer Journal, 30(5),
> 1987, pp. 451-7.
>
> http://comjnl.oxfordjournals.org/content/30/5/451.full.pdf

very intersting.  the paper says that although capabilities
are enforced by microcode, and therefore can be proven,
it would be possible to build the system from cots parts.
so i'm wondering if kernel participation is necessary?

- erik

Re: [9fans] rc vs sh

[Ethan Burns]

On Thursday, October 25, 2012 9:58:45 AM UTC-4, dexen deVries wrote:
> On Wednesday 29 of August 2012 16:10:39 Charles Forsyth wrote:
>
> > Changing my default shell from bash to rc caused even terminal windows (let
>
> > alone 9term ones) to appear almost instantly on Ubuntu
>
> > (9term windows appear instantly on the click).
>
>
>
>
>
> interactive bash reads, among others, ~/.bash_history.
>
>
>
> also some of /usr/share/locale/{$LANG,$LC_CTYPE,$LC_NUMERIC,$LC_TIME,
>
> $LC_COLLATE,$LC_MONETARY,$LC_MESSAGES,$LC_PAPER,$LC_NAME,$LC_ADDRESS,
>
> $LC_TELEPHONE,$LC_MEASUREMENT,$LC_IDENTIFICATION,$LC_ALL}/*
>
>
>
> also /etc/nsswitch.conf -- yep, bash has built-in TCP connection support.

On Ubuntu, I found that bash loads significantly faster (on the
order of seconds faster on my slower laptop) if you disable some
extra bash completion.  In your .bashrc, comment out the following
lines:

# enable programmable completion features (you don't need to enable
# this, if it's already enabled in /etc/bash.bashrc and /etc/profile
# sources /etc/bash.bashrc).
#if [ -f /etc/bash_completion ]; then
#    . /etc/bash_completion
#fi


Best,
Ethan

Re: [9fans] rc vs sh

[hiro]

can someone tell me how to speed up poweroff on ubuntu?

Re: [9fans] rc vs sh

[Gorka Guardiola]

On Oct 25, 2012, at 5:08 PM, hiro <23hiro@gmail.com> wrote:

> can someone tell me how to speed up poweroff on ubuntu?

Pull the cable and or battery.

G.

Re: [9fans] rc vs sh

[Matthew Veety]

[-- Attachment #1: Type: text/plain, Size: 292 bytes --]

On Oct 25, 2012 1:00 PM, "Gorka Guardiola" <paurea@gmail.com> wrote:
>
>
>
> On Oct 25, 2012, at 5:08 PM, hiro <23hiro@gmail.com> wrote:
>
> > can someone tell me how to speed up poweroff on ubuntu?
>
> Pull the cable and or battery.
>
> G.
>
>

Don't use Ubuntu.

--
Veety

[-- Attachment #2: Type: text/html, Size: 514 bytes --]

Re: [9fans] rc vs sh

[John Floren]

On Thu, Oct 25, 2012 at 10:18 AM, Matthew Veety <mveety@gmail.com> wrote:
>
> On Oct 25, 2012 1:00 PM, "Gorka Guardiola" <paurea@gmail.com> wrote:
>>
>>
>>
>> On Oct 25, 2012, at 5:08 PM, hiro <23hiro@gmail.com> wrote:
>>
>> > can someone tell me how to speed up poweroff on ubuntu?
>>
>> Pull the cable and or battery.
>>
>> G.
>>
>>
>
> Don't use Ubuntu.
>
> --
> Veety

I think that was the joke.


john

Re: [9fans] rc vs sh

[hiro]

No it wasn't. Everyone is free to use ubuntu as much as he wants if
you want my opinion. My point is this is a MAC OS-centric list, not an
ubuntu support channel.

Re: [9fans] rc vs sh

[Skip Tavakkolian]

a sledgehammer. works for mac os x also.

On Thu, Oct 25, 2012 at 8:08 AM, hiro <23hiro@gmail.com> wrote:
> can someone tell me how to speed up poweroff on ubuntu?
>