[9fans] What the reason of much change of rc(1)

[9fans] What the reason of much change of rc(1)

[okamoto]

I noticed today, so much of the sources of /sys/src/cmd/rc
have been changed recently.
Why?

Kenji

Re: [9fans] What the reason of much change of rc(1)

[okamoto]

> I noticed today, so much of the sources of /sys/src/cmd/rc
> have been changed recently.
> Why?

I reexamined it this morning, and found most changes are
only for coding style or habit ☺ except of adding a file of
havefork.c.   Probably for generalization of codes for various
operating systems...
Then, now, I'm convinced rc(1) has not been changed. ☺

Kenji

Re: [9fans] What the reason of much change of rc(1)

[David Presotto]

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

I did indeed reformat it.  I was making a version that would work
both on windows and unix/plan9 and got angry at the formating style.

The have{nt}fork.c was indeed for os's without fork.

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

From: okamoto@granite.cias.osakafu-u.ac.jp
To: 9fans@cse.psu.edu
Subject: Re: [9fans] What the reason of much change of rc(1)
Date: Thu, 17 Jul 2003 10:38:55 +0900
Message-ID: <b7a88f7100cd508c482096dba21ab4de@granite.cias.osakafu-u.ac.jp>

> I noticed today, so much of the sources of /sys/src/cmd/rc
> have been changed recently.
> Why?

I reexamined it this morning, and found most changes are
only for coding style or habit ☺ except of adding a file of
havefork.c.   Probably for generalization of codes for various
operating systems...
Then, now, I'm convinced rc(1) has not been changed. ☺

Kenji

Re: [9fans] What the reason of much change of rc(1)

[Philippe Anel]

At 10:37 17/07/03 -0400, you wrote:
>I did indeed reformat it.  I was making a version that would work
>both on windows and unix/plan9 and got angry at the formating style.
>
>The have{nt}fork.c was indeed for os's without fork.

Hi,

I suggest you to read "Windows NT/2000: Native API reference"
by Gary Nebbett (ISBN: 1-57870-199-6).

It contains the set of system services provided by the Window NT
executive (the native syscall interface).

Even though it only works with NT(2k/xp) kernels, the book contains
the source code for a Un*x-like fork.

The NT executive has a lot similarities with the M*ch kernel and the
IO subsystem is entierly object oriented. That being said, the main
problem is the Win32 API.

All system objects are files, processes, threads, events or ports.
Even sockets are handled as files (TDI).

         Philippe.

Re: [9fans] What the reason of much change of rc(1)

[Scott Schwartz]

| I did indeed reformat it.  I was making a version that would work
| both on windows and unix/plan9 and got angry at the formating style.

There's always Byron's rc.  It does one thing that I really like:
lists can be broken across lines without trailing backslashes:

	foo=(
	stuff stuff stuff
	more more more
	)
	echo $foo

Very handy for cutting and pasting.

Re: [9fans] What the reason of much change of rc(1)

[rog]

> There's always Byron's rc.  It does one thing that I really like:
> lists can be broken across lines without trailing backslashes:

interesting: i never knew byron's rc did that, though
i used it for years. i did the same thing in the inferno
shell. actually, that's the only line continuation mechanism
in the inferno shell; i never saw a pressing need for backslashes...

(although one thing i liked about es, an rc relative,
was that you could use backslash escapes, e.g.

	echo one line\nand another

literal newlines screw up my indentation, so
i often end up setting $nl to a single newline character.
)

> Very handy for cutting and pasting.

also for using the output of pipelines, e.g.

	ls | grep -v '\.(tgz|tar\.gz)'

edit further as appropriate, bung "files=(" at the top of the output, and ")"
at the bottom, Send, and script at will.
actually, that's probably what you were thinking of...

i do miss this in rc sometimes.

BTW, byron's rc probably has too many subtle differences
from the real rc to be considered a possible alternative for
interpreting plan 9 scripts.

Re: [9fans] What the reason of much change of rc(1)

[boyd, rounin]

> All system objects are files, processes, threads, events or ports.
> Even sockets are handled as files (TDI).

that may well be the case, but i have a 'bad feeling' about trying trick
or mess with the Win32 API, by going behind its back.

as i've mentioned before the 'kernel' knows about who's calling
what and if it doesn't like it, well you're SOL.

Re: [9fans] What the reason of much change of rc(1)

[boyd, rounin]

> BTW, byron's rc probably has too many subtle differences
> from the real rc to be considered a possible alternative for
> interpreting plan 9 scripts.

yeah, it'd need an OS/360'n size effort.