Re: [9fans] History

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

[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

[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.

[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
% 

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