[9fans] History

[9fans] History

[rob pike]

Now that you've recovered your breath from laughing uproariously at my
joke this morning - oh, was that politics you were laughing at?  sorry
- anyway, here's what I do for history.  I've sent them before but I
keep tweaking them and maybe it's time to send them again.  You need
to fix the pattern to match your prompt.  It's an exercise for the
reader to see how they work and how to use them.  Based on an idea
from rsc, I think.  I hardly ever use them when I have a mouse, but if
I'm stuck with a nipple-mouse I use them a lot.

-rob

% cat /bin/"
#!/bin/rc

rfork en

if(test -r /mnt/acme/acme/body)
	bind /mnt/acme/acme/body /dev/text

PROMPT='[^ 	]*%+[ 	]+'

fn cmds {
	grep '^'$PROMPT'[^"]' /dev/text | sed 's/^/	/'
}

switch($#*) {
case 0
	cmds | tail -1
case *
	cmds | grep '^	'$PROMPT^$"* | {echo; cat} |
		pr -t -n | sort -nr | sort -u +1 | sort -n |
		sed 's/^ *[0-9]+	//' | grep .
}

# the silly {echo; cat} gets around pr printing "empty file" when
# presented with no input.
% cat /bin/""
#!/bin/rc

rfork e

PROMPT='[^ 	]*%+[ 	]+'

_x = `{" $* | tail -1}
if(~ $#_x 0) {
	echo no such command found
	exit notfound
}

echo $_x
_x=`{ echo -n 'eval '; echo $_x | sed 's/^'$PROMPT'//'}
rc -c $"_x
% 

[9fans] Need the CS Troff Font to Print the Sam Tutorial

[Mark C. Otto]

I was trying to troff the sam tutorial in /sys/doc/sam but found that it does
not have the CS font in /sys/lib/troff/font/devutf/.  I verified it does not
come with the distribution.  Could someone tell me where I could:  (1) download
the font, (2) find a reasonable substitute for it, or (3) find another tutorial
or set of example beyond the document and manual.  Not surprisingly, sam is so
much easier to do multi-line edits than sed, but there's a lot of potential I am
missing.

Thanks for any help.
Mark

[9fans] How to use POP3 as Part of upas/fs

[Mark Otto]

I have been using Russ's pop3fs to get my mail but am having trouble
setting it up now that it is part of upas/fs.  In particular, how does
it handle a POP3 user name that is different from my plan9 name 
and how do I specify my POP3 password, mail collection rate and not
to use an APOP password.  

I updated my plan9 distribution to the current June 5 partial update.  
I have a standalone plan9 terminal.
I saw that pop3fs was part of upas/fs now.  I followed the instructions
on the Mail Configuration page, starting it using:

upas/fs -f '/pop3/MySMTPServer/First Last'

I got the following error:

upas/fs: opening mailbox: file does not exist

I think this may happen at /sys/src/cmd/upas/fs/fs.c:221 and may be
because my mailbox is /mail/box/Plan9UserName not 
'/mail/box/First Last'.  The Fish and Wildlife Service determines 
the account names, and they use names with spaces in them.  (Problems
living within a Windows network with a Lotus Bloat mail
server)  To account for the different user names, I tried

upas/fs -m/mail/box/Plan9UserName -f '/pop3/MySMTPServer/First Last' 

with the same result.

I am a little confused why fs can't find the mailbox file because 
the program looks like it makes a directory or mbox if either do not
exist.  

Has anyone else set up the pop3 part of upas/fs and is using POP3?

Thanks.
Mark

Re: [9fans] history

[Skip Tavakkolian]

> ; cat /bin/"

yep. also:

PROMPT='(;+[ ]+|cpu%[ ]+)'

for those using drawterm.

i suggest "gacme" for gnu-ized acme

[9fans] history

[Fco. J. Ballesteros]

Russ sent this time ago:

; cat /bin/"
#!/bin/rc

rfork en

if(test -r /mnt/acme/acme/body)
	bind /mnt/acme/acme/body /dev/text

PROMPT=';+[ ]+'

fn cmds {
	grep '^'$PROMPT /dev/text | sed 's/^/	/'
}

switch($#*) {
case 0
	cmds | tail -1
case *
	cmds | grep '^	'$PROMPT^$"*
}



:  > > I agree. This is an annoyance for me. I also wish rc would get *some*
:  > > kind of history; if I want to re-run troff after making a change to a
:  > > file, it's faster to type "!!" than to select the previous command,
:  > > snarfing, pasting, clicking at the end of the line, and hitting enter.
:  > >
:  >
:  > There is a command 'Send' in the Menu. Not that this is a
:  > counter-argument, I am just pointing out things ;-)

[9fans] history

[rob pike]

My semiannual mailing of " and "".  You made need local adjustments to
deal with the syntax of your shell prompt. These history commands search
/dev/text for a pattern on a line beginning with a prompt. With no
pattern, they find the previously executed command.  " prints it for
editing and sending with the mouse.  "" just runs it.

rc%% cat " #!/bin/rc

rfork en

if(test -r /mnt/acme/acme/body)
 bind /mnt/acme/acme/body /dev/text

PROMPT='[^  ]*%+[  ]+'

fn cmds {
 grep '^'$PROMPT'[^"]' /dev/text | sed 's/^/ /' }

switch($#*) { case 0
 cmds | tail -1 case *
 cmds | grep '^ '$PROMPT^$"* | {echo; cat} |
  pr -t -n | sort -nr | sort -u +1 | sort -n |
  sed 's/^ *[0-9]+ //' | grep . }

# the silly {echo; cat} gets around pr printing "empty file" when #
presented with no input. rc%% cat "" #!/bin/rc

rfork e

PROMPT='[^  ]*%+[  ]+'

_x = `{" $* | tail -1} if(~ $#_x 0) {
 echo no such command found
 exit notfound }

echo $_x _x=`{ echo -n 'eval '; echo $_x | sed 's/^'$PROMPT'//'} rc -c
$"_x rc%%

Re: [9fans] History

[Boyd Roberts]

From: <presotto@plan9.bell-labs.com>

> How many programs do I have to stick in the kernel to call all make this
> work before I have a file system?

good question.

Re: [9fans] History

[presotto]

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

How many programs do I have to stick in the kernel to call all make this
work before I have a file system?

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

From: Richard Miller <miller@hamnavoe.demon.co.uk>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] History
Date: Tue, 14 Nov 2000 20:45:58 0000
Message-ID: <E13vnWt-000Pfs-0X@anchor-post-33.mail.demon.net>

> it's possible to make a variant of "script" for plan 9 without using
> any special purpose programs at all:

Another variant is to use acme 'win' command for an interactive session,
then just 'Put' to save the log of input and output to a file.

-- Richard Miller

Re: [9fans] History

[Richard Miller]

> it's possible to make a variant of "script" for plan 9 without using
> any special purpose programs at all:

Another variant is to use acme 'win' command for an interactive session,
then just 'Put' to save the log of input and output to a file.

-- Richard Miller

Re: [9fans] History

[Boyd Roberts]

From: <anothy@cosym.net>

> file://i think the point is that you
> file://gotta break with the past.
>
> this from the guy who wants me to
> stick to ASCII text? ☺ (er, that's
> ":-)" for the unicode-impared)
> -α.
>

well said, sir.

but, i forget the RFC, but it says:

    be conservative in what you send and liberal in what you accept

where do these file:// come from?

Re: [9fans] History

[anothy]

//i think the point is that you
//gotta break with the past.

this from the guy who wants me to
stick to ASCII text? ☺ (er, that's
":-)" for the unicode-impared)
-α.

Re: [9fans] History

[rog]

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

it's possible to make a variant of "script" for plan 9 without using
any special purpose programs at all:

% > conslog
% chmod +a conslog
% pipefile -r 'tee conslog' -w 'tee conslog' /dev/cons
% rc < /dev/cons > /dev/cons >[2] /dev/cons

only slight problem seems to be that it doesn't exit when you type EOF.
a small price to pay.

  rog.


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

To: cse.psu.edu!9fans
Subject: Re: [9fans] History
Date: Tue, 14 Nov 2000 15:50:01 GMT
Message-ID: <3A115528.96770962@arl.army.mil>

Boyd Roberts wrote:
> i was gonna stay outa this, but script uses those god-awful ptys,

That's beside the point.  I didn't say "port script", I said
one measure of how good an operating system really is is how
transparent and efficient a program *like* BSD "script" is.
It ought to be possible to interpose a program "at" the user
interface that captures all user output (which might be
graphic, although for many purposes we could settle for the
text that is understood by the terminal-like text windows)
in some reviewable/replayable database (simple sequential
text log, if not supporting graphics).  Ideally, user input
should be captured also (if supporting just text, then the
displayed echo of the input might suffice).

One design issue for a script-like program is how to process
user-generated signals.

Re: [9fans] History

[Boyd Roberts]

From: Douglas A. Gwyn <gwyn@arl.army.mil>


> Boyd Roberts wrote:
> > i was gonna stay outa this, but script uses those god-awful ptys,
> 
> That's beside the point.  I didn't say "port script", ...

yes doug, i understood that.  some of us convict scum have
the odd synapse floating around :-)

Re: [9fans] History

[Douglas A. Gwyn]

Boyd Roberts wrote:
> i was gonna stay outa this, but script uses those god-awful ptys,

That's beside the point.  I didn't say "port script", I said
one measure of how good an operating system really is is how
transparent and efficient a program *like* BSD "script" is.
It ought to be possible to interpose a program "at" the user
interface that captures all user output (which might be
graphic, although for many purposes we could settle for the
text that is understood by the terminal-like text windows)
in some reviewable/replayable database (simple sequential
text log, if not supporting graphics).  Ideally, user input
should be captured also (if supporting just text, then the
displayed echo of the input might suffice).

One design issue for a script-like program is how to process
user-generated signals.

Re: [9fans] History

[Boyd Roberts]

From: rob pike <rob@plan9.bell-labs.com>


> ...because I could see xterm on the horizon (although
> - whoooo-ey, did I underestimate that horror!)..

sure, the code was huge, but at least they had the
good taste not to add in 3270 support and it only
took 6 versions to get multi line selections right,
'cos the code was unreadable or something.

call me old fashioned, or sarcastic, or ...

Re: [9fans] History

[rob pike]

Ptys were old and obsolete the day they were invented. We knew even
then that tty modes shouldn't be muxed by the kernel. I ranted some
when that happened, because I could see xterm on the horizon (although
- whoooo-ey, did I underestimate that horror!)..

-rob

Re: [9fans] History

[Boyd Roberts]

From: George Michaelson <ggm@dstc.edu.au>
To: <9fans@cse.psu.edu>
Sent: Tuesday, November 14, 2000 10:33 AM
Subject: Re: [9fans] History


> "Douglas A. Gwyn" <gwyn@arl.army.mil> writes:
> 
> >forsyth@vitanuova.com wrote:
> >> if you are intent for whatever reason on capturing, recovering, and
> >> especially modifying typed input on the fly (as with command
> >> completion but other things as well), i'd plug something (cf. pipefile)
> >> between typist and the recipient of the typing.
> 
> >Indeed, one measure of how good an operating system really is
> >is how transparent and efficient a program like BSD "script" is.
> 
> I use screen locally, because somebody else installs and supports it.
> 

i was gonna stay outa this, but script uses those god-awful ptys,
if i haven't lost all my neurons.

i think the point is that you gotta break with the past.  even those
'orrible pty's are 20 years old.

Re: [9fans] History

[George Michaelson]

"Douglas A. Gwyn" <gwyn@arl.army.mil> writes:

>forsyth@vitanuova.com wrote:
>> if you are intent for whatever reason on capturing, recovering, and
>> especially modifying typed input on the fly (as with command
>> completion but other things as well), i'd plug something (cf. pipefile)
>> between typist and the recipient of the typing.

>Indeed, one measure of how good an operating system really is
>is how transparent and efficient a program like BSD "script" is.

I use screen locally, because somebody else installs and supports it.

I have to say, it gets in the way terribly. Maybe its not possible to
intrude multiple virtual terminals on one binding without confusing
either the operating system, the user or both. But persistance and
the ability to cut-paste on a non-mouse system and migrate the UI to
different remote bindings are useful enough I can wear the bogons.

Is screen something one would say deserves to be a generic plugable or
is it too many functions collapsed into one layer and should be discrete
pluggables, each for a specific task?

	input-snarfer | virtual-terminal-switcher | persistance | rc ?

-George

Re: [9fans] History

[Douglas A. Gwyn]

forsyth@vitanuova.com wrote:
> if you are intent for whatever reason on capturing, recovering, and
> especially modifying typed input on the fly (as with command
> completion but other things as well), i'd plug something (cf. pipefile)
> between typist and the recipient of the typing.

Indeed, one measure of how good an operating system really is
is how transparent and efficient a program like BSD "script" is.

Re: [9fans] History

[forsyth]

if you are intent for whatever reason on capturing, recovering, and
especially modifying typed input on the fly (as with command
completion but other things as well), i'd plug something (cf. pipefile)
between typist and the recipient of the typing.  it could keep as much
history as desired, make the contents available as a real or virtual
file, and generally do what it liked.  putting the facility in the
shell alone seems to assume that's the only thing that would ever
benefit (which probably explains why so many other applications on gnunix
include readline, so lots-but-not-all typed-at commands get it, not just bash).
since the typed-editing-history facility is used interactively, would
tend to me to suggest that it belongs (only) along a path of interaction.
there are several points where that could be done, depending on the desired
scale of memory.

Re: [9fans] History

[rog]

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

some long commands don't deserve to be put into a function.  i'm
thinking of the usual only-useful-this-time one-shots like

for (i in `{tail -4000 odd | tr ' ' '\012' | sort | uniq -c | sort -rn | sed 's/ *[0-9]+ //'}) {
	if (test -f $home/dict/$i) {echo strange}
}

although it's probably never going to be used again, sometimes one
remembers "oh yes, i did something like that a while back" and it's
nice if it hasn't gone forever.

acme win is better than rio, where a reasonable amount of debug output
causes all previously typed commands in that window to be lost.

i'm sure there must be a better way.

  rog.


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

To: cse.psu.edu!9fans
Subject: [9fans] History
Date: Thu, 9 Nov 2000 09:01:18 -0500
Message-ID: <20001109142326.3091D199F1@mail.cse.psu.edu>

You wouldn't feel the need for history so much if you
didn't type such long commands.  Try mk or make or
defining a function.  It's much less work to type
	mk
than
	gcc -Isomenonstandardplace -Dverylongoption -Wpleasedontcomplainaboutmyprogramiknowhatimdoing ilikethingstobeclearsoigivemyfileslongnames.c

-rob

Re: [9fans] History

[Boyd Roberts]

> i'm sure there must be a better way.

i just used so save 'em all in a directory called 'hacks'.
anyway, i'd stepwise refine the command, and editing it with
sam was a lot easier than dicking around with history/xterm.
one click to write it.  one xterm click to execute.  not
perfect, but i could live with it.

Re: [9fans] History

[Axel Belinfante]

> when i was fooling around with the unix 9term i added
> 'look' on button 2, but i couldn't convince rob that
> this was a good idea.

I occasionally use the 'fwd' and 'bkwd' button-3 entries
in unix 9term to find back commands in a window that contains
a lot of output, by looking backwards for the prompt.
For such things these entries are quite useful,
in my experience.

Axel.

Re: [9fans] History

[Boyd Roberts]

when i was fooling around with the unix 9term i added
'look' on button 2, but i couldn't convince rob that
this was a good idea.  fortunately i had ultrix and
it had undocumented pty messages to tell you when
the tty modes had changed.  otherwise it was an
ioctl for each character typed -- ugly.

[9fans] History

[rob pike]

You wouldn't feel the need for history so much if you
didn't type such long commands.  Try mk or make or
defining a function.  It's much less work to type
	mk
than
	gcc -Isomenonstandardplace -Dverylongoption -Wpleasedontcomplainaboutmyprogramiknowhatimdoing ilikethingstobeclearsoigivemyfileslongnames.c

-rob