As the user base grows it might become appropriate to have an FAQ.
Is the current query:
vedcharinsert in linux console
just a re-hash of the recently answered query:
how to run ved in linux console ?
For me this was solved (as per Aaron's post) by either:
> if running bash, sh or ksh:
> TERM=xterm
> export TERM
> or fetch
> http://www.cs.bham.ac.uk/research/poplog/linuxterm.tar.gz
which consists of a README and 3 *.p files.
Here's the one that fixes it:
======= $usepop/pop/lib/ved/term/vedlinuxkeys.p
/* --- Copyright University of Sussex 2000. All rights reserved. ----------
> File: C.all/lib/ved/term/vedlinuxscreen.p
> Purpose: Set up VED for linux type terminals
> Author: Andrew Sayers, 16 Feb 2000
> Documentation: REF * VEDTERMINALS
> Related Files: LIB * VEDXTERMSCREEN, LIB * VEDLINUXKEYS, LIB * VEDLINUX
*/
compile_mode :pop11 +strict;
section;
uses vedxtermscreen;
define vedlinuxscreen = vedxtermscreen
enddefine;
endsection;
===============
Stephen Isard <S.IsardDeleteThis@ed.ac.uk>
> That is, go to the beginning of a line, type a character, say 'a'.
> Do ctrl-a to get back to the beginning of the line and type another
> character, say 'b'. The line ought now to contain "ba", but instead it
> contains "b a". The space isn't really there in the ved buffer, because
> it goes away if I do vedrefresh and it doesn't show up if I write the
> file and cat it.
Yes I get bad-stuff and spaces between chars on command line, unless I
do: TERM=xterm ; export TERM or
load $usepop/pop/lib/ved/term/vedlinuxkeys.p - as above.
kers@hplb.hpl.hp.com
> No, I get a completely different effect (having just tried it). All the
> ved output goes to the bottom line of the screen, nowhere else. Normally
> I use xved in my KDE environment, so I'm not hot on consoles.
yes as above ... "goes to the bottom line of the screen"
axs@cs.bham.ac.uk (Aaron Sloman)
> Actually it would be very nice to have a mini-pop-11 which supports
> the text based teaching tools (e.g. teach river, teach grammar,
> etc.) so that people who want to try it out can do so before getting
> the full-blown version.
The availability of a minimalist (confirm before comit)
version is of tremendous value for the potential new user.
I would never have downloaded the present *tar.gz, except that I
luckily browsed two pop-11 text books some 10 years ago (when it
was still safe to go 'down town' Johannesburg library), so I knew it was
a 'must have'.
Consistent with a minimal system for 'test before commit' is
the provision of a sequence of test/confirm points along the
installation route. Sensible installers don't want to execute
long sequences of actions without reassuring feedback.
Multiple test/confirm points allows recovery from the inevitable
problems.
One should plan, not for problem-free installation, but for easy
recovery from errors/problems.
zcat $tardir/bhamteach.tar.gz | tar xf -
is very 'wizz-bang'. But some of these expanders delete the original
*.tar.gz. So at least warn the user to make a backup first.
A more defensive/conservative way is to first expand to *.tar,
then: tar -tvf <tarFile.tar>
shows the contents.
I did tar -tvf <tarFile.tar> > dirListing
to get a file listing of all the dirs/files which I often find usefull to
search, eg. to see if and where a particular file is located.
Since mc (midnight commander) can directly see and list the dir/file
structure of a *.tar.gz there is a one line command which will show
(or save to file) the dir/file structure of a *.tar.gz - I don't know how to.
Chris Glur.
PS. I want to discuss AI and pop-11. Is it more appropriate to join
a mailing list(s) ?
|