Set User (aka su)

Set User (aka su)

[Vadim]

From: forsyth@plan9.cs.york.ac.uk

>the thing that many people want from hp -- support for the
>ESC-based cursor addressing schemes -- is the bulk of hp's source code.

HP is an extremely poor choice of terminal to emulate, as it
is overly complicated and full of margianlly useful features.
I counted lines, BTW, and >90% of the code is spent on doing
menus, yet another line discipline, emulating "cons" and "consctl",
etc etc. Only about 100 lines are devoted to parsing command
sequences (and most of them are unnecessary).

I would prefer arguing not about beliefs but about facts, ok?

>furthermore, the people who want that here are rarely satisfied
>by hp -- they wt more more more cursor addressing codes --
>specifically support for either VT320 or PC `ANSI' escape sequences.

It definitely makes sense to do something standard if the
standard exists.  You may argue till the hell freezes that
the electric plugs are of the wrong shape, but try to manufacture
"improved" ones which won't plug into old sockets.

>i've been looking at this recently, so i've had to read lots of vt220 emulators,
>the vt/pc emulator in the linux kernel, etc.  i don't accept this statement
>at all.

You don't need to emulate anything fancy, just a minimal device
which can be used as a display.

>also, the scrolling in hp is slow because it makes no attempt to be fast.

And doing it fast would bloat the code even more.

>>made user interface incoherent (can't call sam in the same
>>window as telnet!)

>i do not understand how support for cursor addressing makes the user interface
>`coherent' on any of the systems that support this archaic crud.

Sorry, emulation of a teletype is even more "archaic" than of
a display.  Bzzt.

>sam is usable in an X11 xterm only because it makes a separate call back to the terminal to produce something that isn't an xterm.

You didn't understand what i said.  Try to do:

hp
sam somefile

(telnet and cu are barely useful without hp).

--vadim

Set User (aka su)

[Andrew]

[Byron Rakitzis]
> 
> See Ken Thomson's paper on his C compiler. It is an extension used to
> map enum constants to array indices. So
> 
> 	char *msg_string[] = {
> 		[ENOENT] "No such file or directory",
> 	}
> 
> would yield
> 
> 	msg_string[ENOENT] == "No such file or directory"

I think I missed the original message. I know that GNU C has this extension;
which other compilers support it? Does Plan 9's PCC?

-- 
/d/def/s/scale/u/dup/f/forall{load def}{loop}stopped pop/r{u 1 lt{-1 0 moveto 1
1 lineto stroke}{[[(ha_a0\211)(db\\h\(~)(eVhdOj)(jd_dbd)(dh\\bT\200)(f_ab^\211)
(c]ffe\201)(`@h`x\200)(cZhd#h)(hb^d0v)(`Lh`8t)(eVhd\223~)(gj^a\230j)(h_ab\210a)
(gd^c\211\205)]{[exch{96 sub}f]}f]{gsave 1 64 div u s concat u 1 sub r grestore
}f}ifelse pop}d 240 u s 1.25 1 translate 4 r showpage% - acb@cs.monash.edu.au -
 

Set User (aka su)

[Byron]

See Ken Thomson's paper on his C compiler. It is an extension used to
map enum constants to array indices. So

	char *msg_string[] = {
		[ENOENT] "No such file or directory",
	}

would yield

	msg_string[ENOENT] == "No such file or directory"

Set User (aka su)

[Gary]

> >As a side note... has anyone on the Plan 9 list ever used the
> >Macintosh MPW shell?  It is a Unix-like shell combined with a
> >programmer's text editor. You could select any text at any location in
> >any editing window, hit Enter, and send it off as a command.  Or
> >conversely edit any command with the full power of the text editor.
> >This gave you many of the features of the 8 1/2 terminal and Acme...
> 
> Yes, I use it all the time.  I've never understood why this style didn't
> migrate to Unix/Emacs/etc. systems...seems like there's always some
> complicated mechanism of copying things to the input line in the shell
> window or some such thing, instead of just executing the stuff in place.
> Smalltalk-80 had this years ago, of course.

Seems like a good excuse to put in a plug for Wily.  I've written
(jointly with Bill Trost) a lot of an Acme workalike for Unix/X.  It's
not ready for general release, but hackers can grab a copy to
play with now.

Please mail me: bugs, bug fixes, portability fixes, suggestions, if
you want to be added to a mail list.

Canned blurb follows:

What is Wily?

Wily is an program for Unix/X/C which attempts to provide
the functionality of Acme (http://plan9.att.com/plan9/doc/acme.html),
which is built on Plan9/Alef.  Acme/Wily provide an integrated
programming/editing environment which makes good use of a
3-button mouse, with several interesting features.

What state is it in?

Certainly far from plug'n'play.  A few people here (Basser) are
using it pretty heavily already, but there's still quite a lot of
work remaining.  Grab it if you want to have a look/play, but expect
(and please mail me) bugs.  Please mail me portability fixes (but
not problems).  It's being jointly written on a Solaris and a
FreeBSD machine.

Documentation?

Check out http://www.cs.su.oz.au/~gary/hobby/wily/auug.html

Where do you get it?

ftp://www.cs.su.oz.au/gary/wily.tgz	(tar'ed, gzip'ed file)

Set User (aka su)

[Berry]

>>>"Nigel Roles" said:
 > > I hate to find myself in the possible position of defending Sun
 > > on this one, but I would like to point out that there were two very
 > > significant reasons for this: (1) folks didn't expect that performance
 > > would be an issue, and (2) the code involved was interpreted forth
 > > running from EEPROM which require 1 usec/byte fetch.  It doesn't
 > 
 > Why is interpreted Forth a defence? Sounds more like a plea bargain.

Interpreted Forth is not the defence, it's the excuse.  The defence is most
people don't live in the raw console; they start some kind of window system
immediately upon booting; some even start it automatically.

And, by the way, it's not just the interpreted code that makes it slow; the 
raw console bitmap font lives in that EEPROM too, and the stock console
driver hits it for every row of every character.  

A friend of mine wrote a little program that copies the code to RAM and forks 
a new shell for you; this makes running on the console ENORMOUSLY faster.  I
like to use it when I'm debugging a driver that I expect to crash and 
don't want to take the time to start X up.

Later Sun EEPROM code does this (copy font to RAM) too; it may even copy out 
its own code, I'm not sure.  It gets a lot snappier.

....but this is all irrelevant to 9fans.  Maybe when my CDROM comes I can 
be more relevant :-)

  --berry

Berry Kercheval :: Xerox Palo Alto Research Center

Set User (aka su)

[Nigel]

> 
> |> From: forsyth@plan9.cs.york.ac.uk
> |> 
> |> (after all, Sun's EEPROM has the screen mapped, and did you ever see
> |> the display and scrolling time on that in the older Sparcs.  whew!)
> 
> I hate to find myself in the possible position of defending Sun
> on this one, but I would like to point out that there were two very
> significant reasons for this: (1) folks didn't expect that performance
> would be an issue, and (2) the code involved was interpreted forth
> running from EEPROM which require 1 usec/byte fetch.  It doesn't

Why is interpreted Forth a defence? Sounds more like a plea bargain.
 

Set User (aka su)

[Bill]

|> From: forsyth@plan9.cs.york.ac.uk
|> 
|> (after all, Sun's EEPROM has the screen mapped, and did you ever see
|> the display and scrolling time on that in the older Sparcs.  whew!)

I hate to find myself in the possible position of defending Sun
on this one, but I would like to point out that there were two very
significant reasons for this: (1) folks didn't expect that performance
would be an issue, and (2) the code involved was interpreted forth
running from EEPROM which require 1 usec/byte fetch.  It doesn't
take long to figure out where all the time goes...

Of course, this little factoid has nothing to do with the current
conversation.  My preference would also be to cast out support
for 'terminals', but I'll concede that it's a bit naive.  Also,
while I find plan9's user interfaces inhibiting at best, this seems
like fertile ground for folks who might be interested in exploring
new approaches.

-bj

Set User (aka su)

[Walter]

>As a side note... has anyone on the Plan 9 list ever used the
>Macintosh MPW shell?  It is a Unix-like shell combined with a
>programmer's text editor. You could select any text at any location in
>any editing window, hit Enter, and send it off as a command.  Or
>conversely edit any command with the full power of the text editor.
>This gave you many of the features of the 8 1/2 terminal and Acme...

Yes, I use it all the time.  I've never understood why this style didn't
migrate to Unix/Emacs/etc. systems...seems like there's always some
complicated mechanism of copying things to the input line in the shell
window or some such thing, instead of just executing the stuff in place.
Smalltalk-80 had this years ago, of course.

Another little-appreciated feature of MPW is that while a file is open in
the editor, the contents of the window _are_ the contents of the file (of
course, the file is really still there if you close the window without
saving).  Unlike Emacs, you don't have to save and load between the edit
buffers and the disk all the time.  If you redirect output to a file that's
open in the editor, the output spits out into the edit window.  It's also
handy to use a scratch window as an input file.  Seems like this would be
an easy namespace manipulation in Acme (of course, maybe it already works
this way...pardon me if I'm preaching to the choir).

- W

---------------------------------------------------------------
Walter Smith                            Internet: wrs@apple.com
Newton Software                         AppleLink: WALTER.SMITH
Apple Computer, Inc.                            +1 408 974 5892

Set User (aka su)

[carvell]

> 
> >>Plan 9 is
> >>a statement about its own environment, not about how to connect to
> >>Unix using telnet. 
> >
> >Ah, ok, so implementing a teletype instead of a display is a
> >"statement".
> 
> Did a teletype let you go back and edit previous output, and then resend it???

As a side note... has anyone on the Plan 9 list ever used the
Macintosh MPW shell?  It is a Unix-like shell combined with a
programmer's text editor. You could select any text at any location in
any editing window, hit Enter, and send it off as a command.  Or
conversely edit any command with the full power of the text editor.
This gave you many of the features of the 8 1/2 terminal and Acme,
e.g. you could directly execute the examples in the help files, or
make a handy file of commonly used commands.

It's been several years since I've done any Mac programming - always
missed MPW though.  It is nice to have those powerful user interface
capabilities again.  I'm still struggling with Sam (years of using
emacs has damaged my cerebral cortex, I'm afraid) but I'm already
hooked on Acme.

Well, enough rambling from me....  back to our regularly scheduled
discussion!

Gary

-- 
Gary Carvell
Galaxy Global Corporation
http://www.cards.com/home/carvell
carvell@{cards.com, sort.ivv.nasa.gov} / 1-304-367-8249 / fax 1-304-367-8223

Set User (aka su)

[dhog]

>>Plan 9 is
>>a statement about its own environment, not about how to connect to
>>Unix using telnet. 
>
>Ah, ok, so implementing a teletype instead of a display is a
>"statement".

Did a teletype let you go back and edit previous output, and then resend it???
Plan 9's windowing system (which is not named here for fear of invoking the
wrath of System V upas) is most definately not "implementing a teletype".
It is more modern than xterm, which doesn't make effective use of the mouse.
Encoding cursor motions as a series of escape sequences, now _that_'s archaic.

>May i politely inquire why didn't you decide to
>get rid of command line interface completely?  It is so archaic.
>Some people did that long time ago and already made millions.

He did.  It's called acme.  I'm using it to send this mail.  What I just can't
understand is why Unix and Dos don't provide support for acme, I mean
they're so functionally incomplete.

Set User (aka su)

[rob]

Compromises are necessary for interoperation; we want to leave them
as compromises, you want to elevate them to the level of those interfaces
in the systems you're connecting to.  We'll never agree.

I suggest a different compromise: you do whatever you want, we ignore you.  Deal?

-rob

Set User (aka su)

[rob]

>hp takes 100+ Kb to implement something which could be
>done in fifty bytes of code in 81/2, scrolls awfully slowly
>and does not handle resizing properly.

>I.e. not implementing a display instead of a typewriter in
>81/2 simply moved the complexity to other place (hp) and
>made user interface incoherent (can't call sam in the same
>window as telnet!)

The point was to try new ways of working, not reproduce the old ways.
I left cursor addressing out on purpose: what Plan 9 offers is a different
way to edit, both local and remote.  No, you can't run sam on a telnet
window but you can run it in a cpu window, and we prefer that way of
working.  Even when connected to unix, sam -r unixmachine works
fine.  Sure, that doesn't work in a telnet window, but that's a minor point.
Putting cursor addressing in 8½ would make it too easy to fall back
to the old style of interaction, obscuring the new ideas.

All your carping is really about Plan 9's interface incompatibilities with
Unix.  If it's that important to you to use Unix, go use it.  Plan 9 is
a statement about its own environment, not about how to connect to
Unix using telnet.  Putting the kind of support you want into Plan 9
compromises the ideas in the system itself.  We oppose that.

If you decide that things need to be compatible with all that's gone
before, you end up on the road Unix is on.  You'll get something like
Spring or Mach, which are really just reengineerings of the Unix
interface.  An O.S. is only as good as its view of the system.  Plan 9
provides a different view, and its tools take advantage of those
differences.  You could port emacs or whatever other tool you
feel is missing, but why bother?  You already have it where you
work now.  If you want to see what Plan 9 is about, try it as it is.
The true test is not how easily you can reproduce what Plan 9
is trying to replace; rather it's how the new environment makes
new things possible.

-rob

Set User (aka su)

[forsyth]

>>done in fifty bytes of code in 81/2, scrolls awfully slowly
>>and does not handle resizing properly.

hmmmm, all right.  show me that code (and it's not as though i'm from Missouri).

the thing that many people want from hp -- support for the
ESC-based cursor addressing schemes -- is the bulk of hp's source code.
furthermore, the people who want that here are rarely satisfied
by hp -- they wt more more more cursor addressing codes --
specifically support for either VT320 or PC `ANSI' escape sequences.
that requires somewhat more than the code in hp.
i've been looking at this recently, so i've had to read lots of vt220 emulators,
the vt/pc emulator in the linux kernel, etc.  i don't accept this statement
at all.

also, the scrolling in hp is slow because it makes no attempt to be fast.
it has little to do with the fact that it is working as a client of 8½.
(after all, Sun's EEPROM has the screen mapped, and did you ever see
the display and scrolling time on that in the older Sparcs.  whew!)

>>made user interface incoherent (can't call sam in the same
>>window as telnet!)

i do not understand how support for cursor addressing makes the user interface
`coherent' on any of the systems that support this archaic crud.
sam is usable in an X11 xterm only because it makes a separate call back to the terminal to produce something that isn't an xterm.

there is incoherence in the plan 9 user interface, because there are several.
most obviously, the mouse handling conventions in Acme are different from those elsewhere;
perhaps the conventions will eventually converge again at a new limit.
at least it is an interesting diversion.

Set User (aka su)

[Steve]

Vadim Antonov writes:
 > often what goes for minimalism is simply shifting complexity from
 > one place to another, or having a user to deal with inconvinient
 > interfaces (like, i can't really use Plan9 system as my workstation
 > exactly because i can't telnet from it and do anything useful
 > because it lacks emulation of a reasonably simple alphanumeric
 > terminal, including (horror!) direct positioning).

hp
telnet

 > My opinios is that *human interface* must be minimalistic and
 > the rest of the system should be minimal as possible while
 > supporting the functionality.  Functionality comes first.
 > Any missing piece in the basic system spawns ugly (and different)
 > workarounds.  Unix is the best example of it, what was in the
 > v7 remained the "common denominator" and the basis for portability,
 > the missing pieces were added in a multitude of different and
 > often architecturally insane ways.

agreed.

Set User (aka su)

[Steve]

avg@postman.ncube.com (Vadim Antonov) wrote:

> >Vadim, it's not Unix.  It's not supposed to be.
> >
> >-rob
> 
> It is still not an excuse for not providing elementary
> conviniences.  My next pet peeve is that telnet from Plan9
> does not even support carriage returns (although Plan9 telnetd
> does insert them).
> 
> The minimalism itself is ok.  Heck, i myself did research on
> mimimalist systems (the first report in Russian on the regular
> O.S. architecture was presented in 88).  My current home project
> is called "Trivial Routing Architecture Proposal".  However, too
> often what goes for minimalism is simply shifting complexity from
> one place to another, or having a user to deal with inconvinient
> interfaces (like, i can't really use Plan9 system as my workstation
> exactly because i can't telnet from it and do anything useful
> because it lacks emulation of a reasonably simple alphanumeric
> terminal, including (horror!) direct positioning).

May I suggest the following:

Try plan9.

If you like the plan9 user interface (rc, sam, 8 1/2),
install rc, sam and 9term on your Unix systems.
Enjoy life.

If you don't like the user interface,
install *nix over-top your plan9 partition.
Go back to enjoying life.

Set User (aka su)

[Vadim]

>Sure, that doesn't work in a telnet window, but that's a minor point.

"It does not work" is the euphmeism for "it will be fixed by
commercial vendors, many times over, and all their fixes will
be incompatible".

>Putting cursor addressing in 8½ would make it too easy to fall back
>to the old style of interaction, obscuring the new ideas.

There is a large class of applications which do not need any fancy
graphical interfaces.  You insist on making them inherently more
complex by forcing implementors to do graphics, their own cooked
mode processing (i already found eight instances in Plan9, all of
them different!) and making interaction with other systems a lot
more inconvinient than it should be.

>All your carping is really about Plan 9's interface incompatibilities with
>Unix.  If it's that important to you to use Unix, go use it. 

Sorry, i *do* use Unix, and mostly because there is a lot of
things i can't do with Plan 9, because of stupid reasons.

>Plan 9 is
>a statement about its own environment, not about how to connect to
>Unix using telnet. 

Ah, ok, so implementing a teletype instead of a display is a
"statement".  May i politely inquire why didn't you decide to
get rid of command line interface completely?  It is so archaic.
Some people did that long time ago and already made millions.

>Putting the kind of support you want into Plan 9
>compromises the ideas in the system itself.  We oppose that.

As i said you either confine system to research lab and hobbyists
or make it able to live in the real world, where legacy systems
are not going to die any time soon.

>If you decide that things need to be compatible with all that's gone
>before, you end up on the road Unix is on. 

You missed the point of my philosophy completely.  The road the
Unix went is because things were lacking in the initial system,
not because of the inherently bad interface.

It was very easy to design a good generic terminal emulator
and put it into kernel, and get rid of termcap goo in applications
forever.  Instead, users and vendors in need of a quick fix expanded
it, so it became intractable.  The same is going to happen with
Plan 9, if it is going to be a successful system.  The lack
of interface in the system will simply proliferate ugly hacks.

If you have to duplicate functionality in a number of places it
is an indication of a design failure. 

>You'll get something like
>Spring or Mach, which are really just reengineerings of the Unix
>interface. 

Does not Plan 9 include APE?  To make a statement coherent
you should remove it, as it makes people to use their old
habits of fopening and printf-ing.  It even has stty and
pseudo-terminals.

Why does it have telnet and cu at all?  It connects people
to the systems with a completely different interface (horror!).
Sure, people who want to talk to Unix systems can use Unix.

Also, to make the statement pure the name of "ls" should be
changed, so users won't forget they're not on a Unix system.

I respect people who go on hunger strikes.  As long as they
don't sneak food in when nobody watches.

--vadim

Set User (aka su)

[Vadim]

Vadim Antonov writes:
 > often what goes for minimalism is simply shifting complexity from
 > one place to another, or having a user to deal with inconvinient
 > interfaces (like, i can't really use Plan9 system as my workstation
 > exactly because i can't telnet from it and do anything useful
 > because it lacks emulation of a reasonably simple alphanumeric
 > terminal, including (horror!) direct positioning).

>hp
>telnet

hp takes 100+ Kb to implement something which could be
done in fifty bytes of code in 81/2, scrolls awfully slowly
and does not handle resizing properly.

I.e. not implementing a display instead of a typewriter in
81/2 simply moved the complexity to other place (hp) and
made user interface incoherent (can't call sam in the same
window as telnet!)

If you call *that* minimalism i'm the Pope.

--vadim

Set User (aka su)

[Vadim]

>Vadim, it's not Unix.  It's not supposed to be.
>
>-rob

It is still not an excuse for not providing elementary
conviniences.  My next pet peeve is that telnet from Plan9
does not even support carriage returns (although Plan9 telnetd
does insert them).

The minimalism itself is ok.  Heck, i myself did research on
mimimalist systems (the first report in Russian on the regular
O.S. architecture was presented in 88).  My current home project
is called "Trivial Routing Architecture Proposal".  However, too
often what goes for minimalism is simply shifting complexity from
one place to another, or having a user to deal with inconvinient
interfaces (like, i can't really use Plan9 system as my workstation
exactly because i can't telnet from it and do anything useful
because it lacks emulation of a reasonably simple alphanumeric
terminal, including (horror!) direct positioning).

Ultimately, MS-DOS is "more minimal" than Plan9.  It also is
not supposed to be and is not Unix.  Therefore it must be better.
Beat it.

My opinios is that *human interface* must be minimalistic and
the rest of the system should be minimal as possible while
supporting the functionality.  Functionality comes first.
Any missing piece in the basic system spawns ugly (and different)
workarounds.  Unix is the best example of it, what was in the
v7 remained the "common denominator" and the basis for portability,
the missing pieces were added in a multitude of different and
often architecturally insane ways.

--vadim

Set User (aka su)

[rob]

Vadim, it's not Unix.  It's not supposed to be.

-rob

Set User (aka su)

[Vadim]

Hi -- there's an equivalent of Unix "su" for Plan9, to
allow to become a different user temporarily.

It uses the file /lib/namespace.su to remount the root file
system under new user name.  On a CPU server or terminal
running kfs that should be

naiad% cat /lib/namespace.su
mount -bc /srv/kfs /
naiad% 

Does anybody know a better way to tell the file system that
user name has changed?  Also, note the magic incantation "cd `{pwd}".
God, if feels like the quote from ken/slp.c.

--vadim

naiad% pwd
/sys/src/cmd/auth
naiad% diff mkfile.old mkfile
16a17
> 	su\
37a39,41
> 
> $BIN/su:V:	$O.su
> 	cp $O.su /$objtype/bin/su
naiad% cat su.c
#include <u.h>
#include <libc.h>
#include <auth.h>
#include "authsrv.h"

void
main(int argc, char *argv[])
{
        char buf[32], pass[32], key[DESKEYLEN];
	int fd;
        Chalstate ch;
	char *s;

	if( argc != 2 ) {
		fprint(2, "usage: su user\n");
		exits("usage");
	}

        s = getenv("service");
        if(s && strcmp(s, "cpu") == 0){
                fprint(2, "su must not be run on the cpu server\n");
                exits("boofhead");
        }

        if(getchal(&ch, argv[1]) < 0) {
		fprint(2, "Authentication failure\n");
		exits("can't get challenge");
	}
        readln("Password: ", pass, sizeof pass, 1);
        passtokey(key, pass);
	strcpy(buf, ch.chal);
	netcrypt(key, buf);
	if( chalreply(&ch, buf) < 0 ) {
		fprint(2, "Authentication failed\n");
		exits("bad response");
	}
	rfork(RFNAMEG|RFENVG);
	if( (fd = create("#e/prompt", OWRITE, 0644)) >= 0 ) {
		snprint(buf, sizeof buf, "[%s]%% ", argv[1]);
		write(fd, buf, strlen(buf));
		close(fd);
	}
	if( (fd = create("#e/user", OWRITE, 0644)) >= 0 ) {
		write(fd, argv[1], strlen(argv[1]));
		close(fd);
	}
	/* Do some magic and start interactive shell */
	execl("/bin/rc", "rc", "-c", 
	      ". /lib/namespace.su; cd `{pwd}; exec /bin/rc -i", 0);
	fprint(2, "Exec failed\n");
	exits("exec");
}
naiad%