Re: [9fans] usage of CPU server

Re: [9fans] usage of CPU server

[okamoto]

Thanks a lot, Lucio and Charles.

Yes, it did work right.   I get headache usually when I read man pages
of sh/csh/rc.   ^_^

Kenji

Re: [9fans] usage of CPU server

[Lucio De Re]

On Wed, Nov 01, 2000 at 06:53:02PM +0000, okamoto@granite.cias.osakafu-u.ac.jp wrote:
> 
> Yes, it did work right.   I get headache usually when I read man pages
> of sh/csh/rc.   ^_^
> 
David Korn <dkg@research.att.com> has written a book about the Korn
shell, which seems greatly respected in development circles.  The new
Korn shell is quite novel, but its roots are in the Bourne shell of yore
and David's knowledge is probably unsurpassed.

Of course, Tom Duff did a better job with RC, but he had no legacy to
contend with; he could _learn_ from previous mistakes instead of having
to be compatible with them.

++L

Re: [9fans] usage of CPU server

[Rick Hohensee]

> 
> On Wed, Nov 01, 2000 at 06:53:02PM +0000, okamoto@granite.cias.osakafu-u.ac.jp wrote:
> > 
> > Yes, it did work right.   I get headache usually when I read man pages
> > of sh/csh/rc.   ^_^
> > 
> David Korn <dkg@research.att.com> has written a book about the Korn
> shell, which seems greatly respected in development circles.  The new
> Korn shell is quite novel, but its roots are in the Bourne shell of yore
> and David's knowledge is probably unsurpassed.
> 
> Of course, Tom Duff did a better job with RC, but he had no legacy to
> contend with; he could _learn_ from previous mistakes instead of having
> to be compatible with them.
> 
> ++L
> 

More flame bait:

The -n test, "newer than" I believe entered unix shells with the Korn
shell. IMNNSHO (In My Notoriously Not So Humble Opinion), that obsoleted
the "make" utility. 

It also seems like much of the POSIX spec for the shell is from Korn, 
where it's not from Bourne. This is the impression of someone who's never
actually seen a POSIX in real life.

Rick Hohensee

Re: [9fans] usage of CPU server

[nigel]

 > More flame bait:
> 
> The -n test, "newer than" I believe entered unix shells with the Korn
> shell. IMNNSHO (In My Notoriously Not So Humble Opinion), that obsoleted
> the "make" utility. 
> 

Which bit of the Korn shell models the dependency graph?

Re: [9fans] usage of CPU server

[Rick Hohensee]

> 
>  > More flame bait:
> > 
> > The -n test, "newer than" I believe entered unix shells with the Korn
> > shell. IMNNSHO (In My Notoriously Not So Humble Opinion), that obsoleted
> > the "make" utility. 
> > 
> 
> Which bit of the Korn shell models the dependency graph?
> 
> 

A dependancy graph is a tiny subset of what you can construct with -n and
friends, isn't it?

Rick Hohensee

Re: [9fans] usage of CPU server

[Boyd Roberts]

the korn shell is an unmitigated disaster.

i remember korn standing up after the first
paper at a usenix to ask a question.  his
real agenda was to promote a new release
of that abortion.

FYI: i put up the first version, back in '83/'84
     at basser.  after reading the doc once i
     swore i'd never use it.  i use it now,
     'cos i need history.  in a (once) (near)
     perfect world i used byron's rc.

now, the 8th Edition shell, now that was a shell.

as rob once wrote 'programming the inputs'.

'whatis' over 'type' -- no comparison.

typing of shell variables?  give me a break.
a PRNG in the shell -- don't make me puke.

steve bourne had the right idea.  the problem
was the quoting was a nightmare (one i understand)
and it had no real grammar.  tom duff nailed the
grammer down with yacc and fixed the quoting -- a
brilliant piece of insight.

korn reminds me of wnj.  he wrote a 'shell' too.

Re: [9fans] usage of CPU server

[Rick Hohensee]

> 
> the korn shell is an unmitigated disaster.
> 
> i remember korn standing up after the first
> paper at a usenix to ask a question.  his
> real agenda was to promote a new release
> of that abortion.
> 
> FYI: i put up the first version, back in '83/'84
>      at basser.  after reading the doc once i
>      swore i'd never use it.  i use it now,
>      'cos i need history.  in a (once) (near)
>      perfect world i used byron's rc.
> 
> now, the 8th Edition shell, now that was a shell.
> 
> as rob once wrote 'programming the inputs'.
> 
> 'whatis' over 'type' -- no comparison.
> 
> typing of shell variables?  give me a break.
> a PRNG in the shell -- don't make me puke.
> 
> steve bourne had the right idea.  the problem
> was the quoting was a nightmare (one i understand)
> and it had no real grammar.  tom duff nailed the
> grammer down with yacc and fixed the quoting -- a
> brilliant piece of insight.
> 
> korn reminds me of wnj.  he wrote a 'shell' too.
> 
> 

I don't doubt that there's severe
bletchery in ksh, but it's better than make. IMO.

rc is indeed nice. When abandoning Bourne altogether though,
I then look to Forth. I have put the bulk of the Linux syscalls 
in 2 Forths and my 3-stack Forth-like thing. The tricky bit is 
reconciling Forth's RPN non-syntax with unix command switches.
This may be ameliorated somewhat by most simple commands becoming
Forth words. 

There's strikingly little namespace conflict between a unix PATH
and a Forth dictionary. The only Linux syscall that's also a 
Forth word is dup.

Rick Hohensee
Forths and H3sm, tp://linux01.gwdg.de/pub/cLIeNUX/interim

Re: [9fans] usage of CPU server

[Douglas A. Gwyn]

Boyd Roberts wrote:
> now, the 8th Edition shell, now that was a shell.

Indeed, the BRL version of the Bourne shell adopted some of the
8th Edition features, which I found very handy.  It also had
job control (from-scratch implementation mainly by Ron Natalie),
which led to an argument with Korn over what POSIX j.c. specs
should look like.  Because it needed to serve as a common base
for 7th Edition, JHU/BRL, BSD, System V, etc. environments it
unfortunately had a lot of compile-time parameters for tailoring.
I fixed all the porting issues I could find, especially the one
that caught SIGSEGV to allocate memory (also addressed by Korn;
a tailorable choice in the BRL version); it was ported without
source-code changes to a large variety of UNIX variants.  The
most useful extensions, some of which are now seen in other shells:
	builtin and whatis commands
	-S flag turns on cd spelling correction
	$ENV per-shell startup command file (opposite order from Korn)
	-E flag to prevent termination on (accidental) EOF
	-H flag enables history ($HISTFILE) and command-line editing
	ESC ESC filename completion, ESC ? lists candidates
	-I flag enables reporting of process information
	-J flag enables job control
	$PPID set to parent process ID
	directories etc. not attempted to execute
	builtin cd/chdir, pwd keeps track of path a la Plan9r3
	~username substitution
	$TIMEOUT shell timeout (0 disables)
I'm still using it on Solaris 8, despite availability of Korn
and older Bourne shells there.

Re: [9fans] usage of CPU server

[Steve Kilbane]

> A dependancy graph is a tiny subset of what you can construct with -n and
> friends, isn't it?

I can see both points of view here. In one corner, we have the point that
what make does is compare the dates on two files, and issue commands via
a shell accordingly. Scripts are written ("makefiles") that test different
pairs, and recursively invoke other parts of the script if necessary.

In the other corner, we note that "recursive" is not something a shell
is good at, what with global variables and all, and coding this thing in
a shell would get old fast, since much of what's being specified is so
similar apart from the the names. Sooner or later, a little language would
arrive to macro-generate the scripts, and you're most of the way to make
anyway.

It's true that make's job could be done by other means, but make handled
a particular problem well, and did so conveniently enough to be preferable
to such alternatives.

I note that mk continues in this vein, rather than being dumped for rc scripts.

steve

Re: [9fans] usage of CPU server

[Boyd Roberts]

take a look at inferno's [brucee's] 'mash'.

Re: [9fans] usage of CPU server

[rob pike]

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

The discussions I was having at the time were with the System V people.

-rob


[-- Attachment #2: Type: message/rfc822, Size: 1762 bytes --]

From: "Douglas A. Gwyn" <DAGwyn@null.net>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] usage of CPU server
Date: Mon, 6 Nov 2000 09:44:05 GMT
Message-ID: <3A0604E3.9E11CCCB@null.net>

rob pike wrote:
> Sure, the environment gets big; so give it more space.

How?  I think you're spoiled by being in a position to
modify the operating system.  For most commercial OSes
we don't have that luxury, and therefore design choices
we make may well reflect the reality we're stuck with.

Re: [9fans] usage of CPU server

[rob pike]

You're absolutely right: every reason anyone ever gave for not
exporting functions involved a failure of imagination.  Sure,
the environment gets big; so give it more space.  Sure, you can
import from a file; so why not do that for all variables and lose
export altogether?  The point is having a dynamic programming
environment; cavils about stack size and available work-arounds
are just conservatism, and programmers are indeed a 
conservative bunch.  Pity.

I never understood the resistance. I still don't.  Fortunately, I
don't have to care any more, either, since Plan 9 has the best
implementation of the environment out there, and rc does
functions very well, thank you.

-rob

Re: [9fans] usage of CPU server

[Elliott Hughes]

"rob pike" <rob@plan9.bell-labs.com> wrote in message
news:20001103145607.93809199DC@mail...
> I never understood the resistance. I still don't.

you explain it yourself: programmers are a conservative bunch.

or did you mean that that's the part you don't understand? i see it as a
natural reaction to the general state of things. almost everything is bad,
even the stuff we produce ourselves, and it's enough trouble getting to
grips with what we've got, understanding its quirks and remembering what
works under what conditions and what doesn't, et cetera, et cetera.

it's like not getting up from a bed of nails because you're scared that the
slightest movement will only increase the pain.

 - elliott

Re: [9fans] usage of CPU server

[Boyd Roberts]

> "rob pike" <rob@plan9.bell-labs.com> wrote in message
> news:20001103145607.93809199DC@mail...
> > I never understood the resistance. I still don't.

neither did i.  the solution was to either change
the environment or be conservative on how much of
the environment you burnt up with functions.

personally, i've never run into environment/NCARGS
problems, but i've seen shell scripts that have,
written by idiots.

i used to use rc and before that i hacked 8th ed
stuff into the svr2 shell.  after getting used to
8th ed shell i couldn't live without history,
whatis, builtin or exportable functions.  i had
the code, so i coded the it.  it's not hard.

Re: [9fans] usage of CPU server

[Douglas A. Gwyn]

rob pike wrote:
> Sure, the environment gets big; so give it more space.

How?  I think you're spoiled by being in a position to
modify the operating system.  For most commercial OSes
we don't have that luxury, and therefore design choices
we make may well reflect the reality we're stuck with.

Re: [9fans] usage of CPU server

[rob pike]

The one feature in that long list that is notably absent is the ability
to export functions.  We had a long acrimonious debate with Korn.
I never understood his reason for not making functions exportable.
It was always Bourne's intention (I asked him) and the main reason
for doing the 8th edition shell was to have exportable functions.
The rest (builtin most especially) followed from that decision.

-rob

Re: [9fans] usage of CPU server

[Douglas A. Gwyn]

rob pike wrote:
> The one feature in that long list that is notably absent is the ability
> to export functions.

I have to say that I never felt the need for them.  The startup
file per interactive shell named by $ENV typically sources a
separate file in which a battery of useful functions are defined.
One constraint in many older UNIX systems is that the environment
has only a limited amount of space, and if there were a lot of
large function definitions in the environment it could easily
exceed the available space.

As a general design principle for anyone who does add function
definitions to the environment, the "env" command should print
them in a form that can be directly executed by the shell to
define the functions.  Also, exported environment variables
should be printed in a form that can be directly ditto.

$ env  # prints:
PATH=/bin:/usr/bin:~/bin export PATH
setenv(){ eval $1="'"$2"'" export $1; }
# etc.

Re: [9fans] usage of CPU server

[forsyth]

>>However, I do suggest that the conciseness of a dependency graph
>>notation is important.

it is not only the conciseness that is important, but its declarative nature.

Re: [9fans] usage of CPU server

[nigel]

>> Which bit of the Korn shell models the dependency graph?
> > 
> > 

> A dependancy graph is a tiny subset of what you can construct with -n and
> friends, isn't it?

True, but it doesn't answer my question.  I asked "which bit of the
Korn shell _models_ the dependency graph", not "which bits of the Korn
shell can be assembled to create the same effect as the dependency
graph in make".

I may as well have asked "which bits of the C language model the
dependency graph", at which point your reply would have suggested that
I should write a C program each time I want to assemble a kit of parts
in the right order to create a whole.  Any language in which you can
invoke other commands, test the relative age of files and do some
filename manipulation is, according to your reply, better than make on
the grounds that it is more general.

Now I'm not proposing that make is all we need; it's been superceded.
However, I do suggest that the conciseness of a dependency graph
notation is important.  There is plenty of evidence for this; the
concept has been preserved in subsequent tools, IDEs etc..

So the question is, "which bit of the Korn shell _models_ the
dependency graph?"

Re: [9fans] usage of CPU server

[Rick Hohensee]

> 
> >> Which bit of the Korn shell models the dependency graph?
> > > 
> > > 
> 
> > A dependancy graph is a tiny subset of what you can construct with -n and
> > friends, isn't it?
> 
> True, but it doesn't answer my question.  I asked "which bit of the
> Korn shell _models_ the dependency graph", not "which bits of the Korn
> shell can be assembled to create the same effect as the dependency
> graph in make".
> 
> I may as well have asked "which bits of the C language model the
> dependency graph", at which point your reply would have suggested that
> I should write a C program each time I want to assemble a kit of parts
> in the right order to create a whole.  Any language in which you can
> invoke other commands, test the relative age of files and do some
> filename manipulation is, according to your reply, better than make on
> the grounds that it is more general.
> 
> Now I'm not proposing that make is all we need; it's been superceded.
> However, I do suggest that the conciseness of a dependency graph
> notation is important.  There is plenty of evidence for this; the
> concept has been preserved in subsequent tools, IDEs etc..
> 
> So the question is, "which bit of the Korn shell _models_ the
> dependency graph?"
> 

You win your point, but mine is that modelling a dependancy graph within
the utility itself is not worth learning another "language". YMMV. I,
personnally, do things like convert the netpbm package to being make-less.

Rick Hohensee

Re: [9fans] usage of CPU server

[Boyd Roberts]

From: Rick Hohensee <humbubba@smarty.smart.net>

> You win your point, but mine is that modelling a dependancy graph within
> the utility itself is not worth learning another "language". YMMV. I,
> personnally, do things like convert the netpbm package to being make-less.

so, when armed with the korn shell every solution is a shell script?

whatever happened to using the right tool for the job?

Re: [9fans] usage of CPU server

[forsyth]

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

>>(2) rx diabase 'du / & >/usr/okamoto/ken'

 rx diabase 'du / >/usr/okamoto/ken &'


[-- Attachment #2: Type: message/rfc822, Size: 2025 bytes --]

From: okamoto@granite.cias.osakafu-u.ac.jp
To: 9fans@cse.psu.edu
Subject: Re: [9fans] usage of CPU server
Date: Wed, 1 Nov 2000 16:27:17 0900
Message-ID: <20001101072630.23396199D8@mail>

Thanks Russ.

I tired
term% rx diabase 'du / &'
command, and it continues to run after I logged out from the
terminal. (This command consumes about 80 seconds in my
system when output is directed to stdout.).

However,
>(It's going to fail if, say, you don't
>redirect standard output and the process
>writes something after you log off.)
occurred.

How I can redirect the output from the du command to say,
/usr/okamoto/ken.

I tried following two.
(1) rx diabase 'du / &' >/usr/okamoto/ken
(2) rx diabase 'du / & >/usr/okamoto/ken'

In case (1), the output upto the time I logged out is wrote to
/usr/okamoto/ken, and in case (2), no output is kept.

Kenji

Re: [9fans] usage of CPU server

[okamoto]

Thanks Russ.

I tired
term% rx diabase 'du / &'
command, and it continues to run after I logged out from the
terminal. (This command consumes about 80 seconds in my
system when output is directed to stdout.).

However,
>(It's going to fail if, say, you don't
>redirect standard output and the process
>writes something after you log off.)
occurred.

How I can redirect the output from the du command to say,
/usr/okamoto/ken.

I tried following two.
(1) rx diabase 'du / &' >/usr/okamoto/ken
(2) rx diabase 'du / & >/usr/okamoto/ken'

In case (1), the output upto the time I logged out is wrote to
/usr/okamoto/ken, and in case (2), no output is kept.

Kenji

Re: [9fans] usage of CPU server

[Lucio De Re]

On Wed, Nov 01, 2000 at 04:27:17PM +0000, okamoto@granite.cias.osakafu-u.ac.jp wrote:
> 
> I tried following two.
> (1) rx diabase 'du / &' >/usr/okamoto/ken
> (2) rx diabase 'du / & >/usr/okamoto/ken'
> 
> In case (1), the output upto the time I logged out is wrote to
> /usr/okamoto/ken, and in case (2), no output is kept.
> 
The right one is: rx diabase 'du / >/usr/okamoto/ken &'

the "&" actually terminates the command, so the redirection occurs as a
separate, later command.  The reason it works in the first instance is
more obscure :-)  It is because the "rx" command terminates when you log
out.

++L

Re: [9fans] usage of CPU server

[Russ Cox]

	cpu -c "command" will do the same as rx <hosname> "command".
	There is no CPU command to let the job doing on the CPU server 
	even after the user logged off from the terminal.  

	Is it difficult to implement this function?

As long as you set up the resources properly,
rx host "command &" should work, no?
(It's going to fail if, say, you don't
redirect standard output and the process
writes something after you log off.)

Russ

[9fans] usage of CPU server

[okamoto]

cpu -c "command" will do the same as rx <hosname> "command".
There is no CPU command to let the job doing on the CPU server
even after the user logged off from the terminal.

Is it difficult to implement this function?

Kenji