I'm not sure what item contains the most current "pico problems"
discussion, so I'll just make a new one.

I've replaced the version of pico we were running (1.8) by the
previous one (1.7).  It seems not to have the fussiness about
parity that 1.8 suffered from.  Try it out and let us know if you
have problems.

Version 1.8 is still available as "pico-1.8".

40 responses total.

I just tried it, and it works.  Thanks.

vi is the superior editor!

Isn't there an item somewhere for editor comparison, and flame-bait like #2?

Yes, I just drifted into this to make a point.  Bye.

Hmmm.  I'm having a pico problem now.


I recently upgraded my terminal program (Term for the Amiga) to version 4.1
Since doing this I have noticed that when logging on to Grex directly I get
gobldy-gook in my lookback and capture buffers when I use 8-N-1 with the 8th
bit stripped.  This always used to work well for me.  I tried using 7-E-1
and that fixed the buffer problem, but when I do that, pico (the only editor
I'm willing to use) doesn't work.  Instead of drawing the screen it just spits
char oops...characters at me.  Yuck.  No matter which settings I use my primary
terminal screen works fine for most things.  It is only the buffers that get
messed up with 8-N-1-Stripped.  Anyone got any idea what's going on?  I realize
that it's a 7/8  bit translation thing, but what do I do about it?

I just tried pine and that works fine at 7-E-1.  That doesnt make sense... I
thought that pico was the same as pine's editor... Why does one work and not
the other??

Any thoughts on what I should do (not change editors) would be appreciated!

Thanks

A.J.

Hmm.  This is puzzling -- I installed Pico 1.7 because it *does* work
with 7E1.  Not sure what's going on here.  You might try fiddling with
your comm. program a bit more.  In particular, if it will let you set
"space" parity, try that.

Hmm....
Space parity doesn't work.  It makes a terible mess of things!  Right now,
though, I'm trying 7-N-1 (who ever heard of that?!) and it seems to be working.
I just ran pico a minute ago and it drew the screen fine.  I guess I'll try 
this for a while and see if I can come across any problems, or if this is a 
goot (albiet) unexplainable solution.

Ah-Ha!
I knew it was too good to be true.  It turns out that If I use 7-N-1 I can
get the pico screen drawn correctly, but then my cursor keys don't work (so 
what good is a pico screen?)  Arrrrrggggghhhhh!

Are you using vt102 emulation in the upgrade, as specified in your .profile?

Nice thought Rane, but that's not the problem.  I'm not using vt102 anymore,
I'm using vt220 (should still work shouldn't it) but I'm also changing the
setting to vt220 at logon.  setenv returns TERM vt220 right now but it still
doesn't work.  It does work, however when I come in over the link at 7-E-1.
This is really weird!

It is indeed. <sigh>

This response has been erased.

I don't think so, Valerie.  On *input*, yes, though, which is one of the
things that's so baffling.  But on output (as seen from the terminal, I
mean, since that's what's being set) it should always zero the parity bit,
whereas 7N implies that the state of the bit is of no interest & it may
be left either 0 or 1.

That is, the difference between 7N1 & 7S1 explains nicely why (maybe)
the cursor keys don't work with 7N1 - maybe, but not for sure - but
the screen should definitely work the same.

This response has been erased.

Actually Valerie the one that I'm using is considered by most Amiga users to
be the best pd/shareware term available for the platform.  It is a very very
capable package, but it is so complex in scope that there seem to be
interesting" features " in every new release.  V4.1 is the first one that has
given me this  trouble, but it fixes some other annoying bugs in earlier
versions.  So far Grex is the only place where Ive had this happen.  I suspect
that my buffer problem is a new bug that causes the 8th bit stripping feature
to affect only the  screen display, and not the buffers.  I think I may write
the author about  that one, however, the failure of pico to work with my 7-E-1
setting may be something coming from grex and not from my terminal.  After all,
pico works just  fine when called through pine, just not by itself.  Also I
beleive I've seen pico  working just fine for me on other systems.  (I'll check
next I am on one of the oth systems).

Does pine call pico, or does it just have its own pico *like* interface?
Cicero, your .profile says you still specify vt102 emulation (but I
can't tell you if that's a problem, if you chose TERM vt220 on login,
when running /b shell. I'd suggest a) edit your .profile to vt220
(or, use change, if it is now up to this), or b) find the right guru ;-).

Neither - pine has its own pico, in that pico is one module of pine,
extracted & separately compiled.  But we definitely had different revs at
one point, & pico gave trouble - but some of the things that have been
tried should have been sufficient to avoid *those* troubles.

He says he's choosing vt220 on login & that it shows as correct in his
environment, so the .profile is not the issue.

cicero, I hope you'll let us know what's going on when (& if) you do trace
it down.  This is pretty weird, & I'd like to know.

Yet another test.  I am currently logged in over a dial-in at 7-E-1
Pico doesn't work, I get the following:
HP.NewBfferHHHetHelriteteilereP
                              
                               ierPoxittifereiextPDelioSellH3HifileH3HlieH.ile:c
                               icerocf.ffer3HYetotertet.crretlloeioeril-it--Pico
                               oe'tworettefollowi:H

This looks to me like some kind of description for the screen that pico is 
supposed to be drawing.  

However, I just ran our gopher client, gophered from U Minn to MSU-gopher
and from there logged back in to grex (so I was on twice--cool!)  At that
point when I ran pico it worked fine, whatever is wrong, going through gopher
is fixing it.  Now I should try to see if I can make it work on M-net over a 
dial-in.  Have to go re-join m-net first though...

well I just tried it over on M-net.  They have pico V2 and also 1.7
like us.  It worked fine.  What I forgot was that unlike us, 
M-net is 8-N-0 so that really doesnt prove anything.  I'll see if
there's somewhere else we can test.

Sounds like an stty problem (I know from stty problems, as most unix boxes
are unable to find the correct terminal size of my xterm if I telnet from
my unix box (I only recently found out about resize), and have problems

finding my correct terminal size from any normal vt100 if I include resize in
my .bashrc (the solution being to use an if on the vaulue of $TERM, but
I only found the second problem today).

This response has been erased.

Well, I just got a software patch for my terminal which fixes the lack of 
bit strpping to my buffers (It even says so in the docs,) so my problems are
fixed.  I can now go back to 8-N-1 stripped.  I still have no idea why 7-E-1 
doesn't work though.  (sigh)

re 21: stty rows and stty cols do indeedwork for most purposes, and I've 
been using them for  some time.  Problem is, when telnetting out aof an 
xterm, I can have a screen size of whatever I want, and my default is
80x25, not 80x24 (and when I telnet from other places, I need 80x24, of
course).  My previous solution included using a vaguely complicated shell
expression to test whether $TERM was set properly, and didn't work.
Fortunately, for fully vt100 compatible terms, there's a better solution: 
set `resize` or something like that.
Unfortunately, while this works nicely in highter versions of Sunos, I can't
find it here, so I'll hve to make do.
 

Right, I don't think we have resize.  As I understand it, it's a "smart"
resizer that actually queries the terminal as to how big it is.  Thus,
the user doesn't even have to know.

I think we talked about "resize" a long time back and someone said
that it was part of the Xwindows package, and thus unlikely to be
installed here on Grex.  Has the situation changed any?

This response has been erased.

Resize is part of X.  Its invocation varies with the flavour of Unix;
the AIX version just does its thing straight.

So far as 7e1 vs. 8n1 - you might try 'stty istrip' first.  With 'stty
istrip' it doesn't matter which way the parity bit is set on incoming
characters.

7e1 is more or less the closest thing there is to a "standard"; that's
what you should find if you dial up merit, sprint, compuserve, or most
other ascii timeshared service.  8n1 is popular on 8086 based bbs
systems because it allows the use of the graphics character set, and if
you're mainly a upload/download site for pc-dos software you can be
quite confident that all your users are using ibm pc comaptible
machines.  However, the macintosh uses a different, and incompatible,
character set, and other machines (sun's, etc.) are quite likely to have
either no interpretation of such characters, or their own unique
implementation.  Hence, using 8 bit characters is not a good idea.

Some terminals include a "mode" bit that sets the 8th bit, and some
versions of Emacs, in particular, use the "mode" bit as an extra
modifier, sort of like shift or control.  Pine, being sort of an emacs
clone, might be trying to pull the same stunt, or may just have been
configured in some bizarre fashion.  It would probably make more sense
to fix pine than it would be to fix sprint, merit, and compuserve.

Of course, when you dial up the NAS at UM, you use 8N1 now...and the
7E1 SCP's are going away and being replaced by NAS's...  That doesn't
mean there aren't problems with 8-bit connections, as mdw points out.
It's just that 7E1 doesn't seem to be as popular now as it used to be.

This response has been erased.

I was one of them, using PCPlus for DOS from my home PC.  Unfortunatley, I
don't have a monitor at the moment, so I can't be of help in testing that.

Later on I was having problems.  I'll try them out!

I did too (just *trying* pico), but no longer remember how I was configured
at that time.

Well, I've tried both.  I like them--There are more functions! :)
I have the same old problems that I always had however: Pine is fine
but Pico will not draw the screen if I run 7E1.  Since my terminal prog
has been fixed, I am now able to use 8N1 (stripped) without garbling my
capture buffers and this works fine so that is what I do.  (Yuk, what a
terrible sentence!)  I still have no idea what the problem with 7E1 is,
but it does not seem to be a product of a particular PICO version.

Well, I'm not really having a problem with pico, but rather properly
defining it as my editor of choice in PicoSpan with the options I want.

what I want:  Pico to execute in "tool mode" (-t option) so that I don't
have to confirm the write on exit nor confirm the filename.  it is just a
nicer exit to the program, and picospan asks me if I want to abort an
entry anyway, so I find it all rather redundant.

what I have tried:  setenv editor 'pico -t' 
                    this generates an error message - bad exit or something.
                    
                    define editor 258 "pico -t"
                    same thing

                    define pico 9 'unix "pico -t"
                    the editor just uses pico straight, and I get
                    a "can't execute" error when I type pico at the
                    Ok: prompt.

any answers?  thanks in advance...

What you need is a scipt to run pico -t.  Mine can be seen in /u/scg/bin/pt.

This response has been erased.

(It's because PicoSpan tries to run your editor with one of the
"exec" family of system calls, and doesn't try to tokenize the
editor name you give it.  So, instead of trying to run the program
"pico" with the argument "-t", it tries to run the program "pico -t",
and fails miserably.)

(Bad PicoSpan!  Bad PicoSpan!)

(Down boy!  **Down**)

- Backtalk version 1.3.30 - Copyright 1996-2006, Jan Wolter and Steve Weiss