Re: [OpenIndiana-discuss] stty source code

[Jim Klimov]

2012-09-04 7:05, Reginald Beardsley пишет:

Where does one find the source for the stty in 151a?

https://hg.openindiana.org/

really isn't very helpful in this regard.

All I want is what's needed to recompile stty w/ -g and run it under dbx.  I'll 
deal w/ the dependencies if and when I have to.



Try the OpenGrok interface at http://src.illumos.org to the
illumos-gate  and illumos-userland projects. Namely:

http://src.illumos.org/source/search?project=illumos-gate&project=illumos-userland&q=stty

This has several pages of hits, I'd bet on
  /illumos-gate/usr/src/ucbcmd/stty/
  /illumos-gate/usr/src/cmd/ttymon/
  /illumos-gate/usr/src/lib/libc/common/sys/
for starters...

//Jim

___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] stty source code

[Andrew Gabriel]

James Carlson wrote:

Reginald Beardsley wrote:
  

I don't want any inbound connections.  But the documentation I read suggested that one 
had to setup ttymon on the port.  Possibly for no reason other than, "This is what I 
did when it finally worked."



Where'd you read that?  Even when it's active, ttymon just camps out on
the /dev/term/ (dial-in only) nodes, meaning that it'll stay asleep
while you do your work on /dev/cua/.

And it's not active on any of the normal serial ports by default and I
believe that no reasonable person should make it active.

The main blocking item in removing it is making sure that the system
console service still works right after removal.


The console uses ttymon -g anyway (i.e. ttymon pretending to be getty, 
and ignoring all the SAC/SAF stuff).

On rare occations I setup another login port, I use ttymon -g on that too.

--
Andrew

___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] stty source code

[James Carlson]

Reginald Beardsley wrote:
> I don't want any inbound connections.  But the documentation I read suggested 
> that one had to setup ttymon on the port.  Possibly for no reason other than, 
> "This is what I did when it finally worked."

Where'd you read that?  Even when it's active, ttymon just camps out on
the /dev/term/ (dial-in only) nodes, meaning that it'll stay asleep
while you do your work on /dev/cua/.

And it's not active on any of the normal serial ports by default and I
believe that no reasonable person should make it active.

The main blocking item in removing it is making sure that the system
console service still works right after removal.

-- 
James Carlson 42.703N 71.076W 

___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] stty source code

[Reginald Beardsley]

I don't want any inbound connections.  But the documentation I read suggested 
that one had to setup ttymon on the port.  Possibly for no reason other than, 
"This is what I did when it finally worked."

In principle serial line comms are simple, but in practice the exceptional 
cases can eat you alive.



--- On Fri, 9/7/12, James Carlson  wrote:

> From: James Carlson 
> Subject: Re: [OpenIndiana-discuss] stty source code
> To: openindiana-discuss@openindiana.org
> Date: Friday, September 7, 2012, 8:39 AM
> On 09/07/12 08:47, Reginald Beardsley
> wrote:
> > The pathological complexity is in the morass of sac/saf
> stuff.  It was much simpler in 4.1.1. And is simpler on
> other *nix.
> 
> SAC/SAF is horrible, awful stuff from New Jersey.  The
> less said about
> that, the better.  If you have any dial-in service at
> all (really? in
> 2012?), you're much better off using mgetty instead.
> 
> I had plans to remove that crap when I was at Sun, but I
> never got
> around to it -- other priorities and eventually a new
> opportunity
> intervened.  If you have to touch pmadm and the rest of
> that stuff, then
> my condolences.
> 
> Fortunately, it's got nothing to do with 'tip' or
> communicating with
> external devices, and is only tangentially related to serial
> ports.
> It's used for dial-in and locally-connected character cell
> terminals only.
> 
> > C-Kermit installed from source was my immediate
> response to the problem but I found it didn't seem to have
> the ability to do anything either which *really* surprised
> me.  Perhaps you can direct me to kermit documentation
> that tells how to convert NL from the remote host to NL-CR
> on the terminal.  I spent a great deal of time reading
> the docs and experimenting w/o finding  way.
> 
> "set terminal lf-display crlf"
> 
> ... at least it's there on a "modern" C-Kermit.
> 
> -- 
> James Carlson         42.703N
> 71.076W         
> 
> ___
> OpenIndiana-discuss mailing list
> OpenIndiana-discuss@openindiana.org
> http://openindiana.org/mailman/listinfo/openindiana-discuss
> 

___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] stty source code

[Udo Grabowski (IMK)]

On 07/09/2012 16:03, Reginald Beardsley wrote:

Thanks.  I've not looked at the source yet, but it doesn't appear to be in the 
last (9.x) release.


James Carlson is right, 'set terminal lf-display crlf' is available
in the 9.0.302 release (Unix), no need to fiddle with source code.

--
Dr.Udo GrabowskiInst.f.Meteorology a.Climate Research IMK-ASF-SAT
www-imk.fzk.de/asf/sat/grabowski/ www.imk-asf.kit.edu/english/sat.php
KIT - Karlsruhe Institute of Technologyhttp://www.kit.edu
Postfach 3640,76021 Karlsruhe,Germany  T:(+49)721 608-26026 F:-926026

___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] stty source code

[Reginald Beardsley]

Thanks.  I've not looked at the source yet, but it doesn't appear to be in the 
last (9.x) release.  However, that might just be a documentation glitch.  It 
clearly wasn't in 8.x which I find really surprising.

--- On Fri, 9/7/12, Udo Grabowski (IMK)  wrote:

> From: Udo Grabowski (IMK) 
> Subject: Re: [OpenIndiana-discuss] stty source code
> To: "Discussion list for OpenIndiana" 
> Date: Friday, September 7, 2012, 8:00 AM
> On 07/09/2012 14:47, Reginald
> Beardsley wrote:
> > Perhaps you can direct me to kermit documentation that
> tells how to
> > convert NL from the remote host to NL-CR on the
> terminal.
> 
> I presume that NL is meant to be LF, this may helps you:
> <http://fixunix.com/protocols/61525-convert-lf-lf-cr.html>
> A really old post, but Kermit does not change that often
> nowadays.
> -- Dr.Udo Grabowski    Inst.f.Meteorology
> a.Climate Research IMK-ASF-SAT
> www-imk.fzk.de/asf/sat/grabowski/
> www.imk-asf.kit.edu/english/sat.php
> KIT - Karlsruhe Institute of Technology     
>       http://www.kit.edu
> Postfach 3640,76021 Karlsruhe,Germany  T:(+49)721
> 608-26026 F:-926026
> 
> 
> -Inline Attachment Follows-
> 
> ___
> OpenIndiana-discuss mailing list
> OpenIndiana-discuss@openindiana.org
> http://openindiana.org/mailman/listinfo/openindiana-discuss
> 

___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] stty source code

[James Carlson]

On 09/07/12 08:47, Reginald Beardsley wrote:
> The pathological complexity is in the morass of sac/saf stuff.  It was much 
> simpler in 4.1.1. And is simpler on other *nix.

SAC/SAF is horrible, awful stuff from New Jersey.  The less said about
that, the better.  If you have any dial-in service at all (really? in
2012?), you're much better off using mgetty instead.

I had plans to remove that crap when I was at Sun, but I never got
around to it -- other priorities and eventually a new opportunity
intervened.  If you have to touch pmadm and the rest of that stuff, then
my condolences.

Fortunately, it's got nothing to do with 'tip' or communicating with
external devices, and is only tangentially related to serial ports.
It's used for dial-in and locally-connected character cell terminals only.

> C-Kermit installed from source was my immediate response to the problem but I 
> found it didn't seem to have the ability to do anything either which *really* 
> surprised me.  Perhaps you can direct me to kermit documentation that tells 
> how to convert NL from the remote host to NL-CR on the terminal.  I spent a 
> great deal of time reading the docs and experimenting w/o finding  way.

"set terminal lf-display crlf"

... at least it's there on a "modern" C-Kermit.

-- 
James Carlson 42.703N 71.076W 

___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] stty source code

[Udo Grabowski (IMK)]

On 07/09/2012 14:47, Reginald Beardsley wrote:

Perhaps you can direct me to kermit documentation that tells how to

> convert NL from the remote host to NL-CR on the terminal.

I presume that NL is meant to be LF, this may helps you:

A really old post, but Kermit does not change that often nowadays.
--
Dr.Udo GrabowskiInst.f.Meteorology a.Climate Research IMK-ASF-SAT
www-imk.fzk.de/asf/sat/grabowski/ www.imk-asf.kit.edu/english/sat.php
KIT - Karlsruhe Institute of Technologyhttp://www.kit.edu
Postfach 3640,76021 Karlsruhe,Germany  T:(+49)721 608-26026 F:-926026

___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] stty source code

[Reginald Beardsley]

The pathological complexity is in the morass of sac/saf stuff.  It was much 
simpler in 4.1.1. And is simpler on other *nix.

C-Kermit installed from source was my immediate response to the problem but I 
found it didn't seem to have the ability to do anything either which *really* 
surprised me.  Perhaps you can direct me to kermit documentation that tells how 
to convert NL from the remote host to NL-CR on the terminal.  I spent a great 
deal of time reading the docs and experimenting w/o finding  way.

If I continue down this rabbit hole, I'm going to run a loop from a real serial 
port to a USB  adapter port w/ terminals at both ends.  However, that requires 
configuring OI on another system. And I don't have a system w/ 2 serial ports 
so it's just a cobble anyway. As the required effort grows, the motivation is 
shrinking.

Have Fun!
Reg

___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] stty source code

[James Carlson]

On 09/06/12 20:37, Reginald Beardsley wrote:
> The real issue is the pathologically complex handling of serial lines in 
> Solaris and the ambiguous documentation.  I am not convinced that anyone, 
> myself included, knows which direction is which.  I know which direction is 
> in and out for communication w/ the local host, but that is all I'm sure of.  
> Coupled w/ the fact that no one seems to have done  much w/ a serial port 
> connection in many years makes it more difficult.  

I disagree.  I've had some trouble with the USB drivers, to be sure, but
not with serial I/O in Solaris.

The driver naming scheme is fairly simple.  /dev/term/* are for inbound
connections, and their behavior is:

- if DCD is not asserted, then open() blocks, and the tty is
  not busy.

- when DCD is asserted and no other process has the /dev/cua
  node open, open() will unblock and the process has use of
  the line.

- if another process opens the /dev/cua/ node, then the open()
  stays blocked (regardless of DCD) until the last close on
  /dev/cua/ occurs.

The /dev/cua/* nodes are for outbound connections:

- if some process has /dev/term/ opened with DCD asserted,
  then you get EBUSY.

- otherwise, open() connects to the serial port right away
  and will either block (if DCD is down and it's a blocking
  open), or will complete (if DCD is up or if it's a non-
  blocking open).

- if the open is blocked waiting for DCD to come up, it
  will wake up when DCD is asserted.

Normal dial-out behavior is to do one non-blocking open of the
/dev/cua/* node, communicate with the modem (or TA or whatever is out
there), then open a second file descriptor on the same device in
blocking mode, which will sleep until DCD goes high.

As for the terminal modes, they're all explained in the termio(7I) man
page in excruciating detail.  However, they're frankly mostly obsolete,
except for SUS and POSIX conformance, and except for controlling the
low-level port configuration (bit rate, parity, hardware flow control,
and so on).  Normal applications that use serial ports immediately
disable opost and icanon and do their own processing on the raw bytes
because, frankly, who wants to have the driver corrupting the data?

If you believe that there's "ambiguity" in the documentation, then I
think it'd be a service to all users to point out the ambiguous points
and (if at all possible) suggest non-ambiguous replacements.

> I last used tip 14 years ago to connect to my ISDN router.  It took only a 
> couple of minutes to setup.  The first forth MCU also took a couple of 
> minutes to setup.  The second beat me senseless for 6 hours.
> 
> In light of the long history of misery and suffering by system admins at the 
> hands of serial port connections, this should not be a big surprise. When I 
> actually did a lot of RS-232 work I was running VMS 4.x on a MicroVAX  
> connecting to a variety of terminals and an 11/780 w/ an FPS-120B attached.  
> That was a long time ago when Sun was a young upstart I'd not even heard of.
> 
> I *may* build up OI from source so I can run under the debugger and resolve 
> the issue.  But because I've modified the remote host to emit NL-CR, it's 
> really not important to me other than it would be nice to have a reasonably 
> behaved facility for connecting over a serial line to a remote host.  If I 
> really get in a jam, I can run Linux. I just prefer not to if I can avoid it. 
>  If I elect to work on the OI/Illumos serial port discipline, it will be for 
> aesthetic  rather than practical reasons.

I argue that the problems occurred because you did not understand how
the components actually worked, and thus spent untold hours manipulating
the wrong bits.

I suggest getting a copy of C-Kermit rather than using tip.  tip doesn't
really do much in terms of terminal emulation -- it's truly ancient and
assumes that you have equivalent UNIX systems at both ends -- while
Kermit is highly configurable and has no such assumptions.

-- 
James Carlson 42.703N 71.076W 

___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] stty source code

[Roel_D]

I understand your frustration. 

But I am wondering how Solaris could have a poor serial-line communication
when there are millions of Sparc servers that have no graphics-card and they
can only be managed over a serialline. Ok, this is from serial -> to server
but sure I still argue your explanation. 

-Original Message-
From: Reginald Beardsley [mailto:pulask...@yahoo.com] 
Sent: vrijdag 7 september 2012 2:38
To: Discussion list for OpenIndiana
Subject: Re: [OpenIndiana-discuss] stty source code

The MCU is 3.3V, so it requires a level shifter to match the 5V coming from
the USB-serial adapter to the MCU. The level shifter and Keyspan work just
fine, though the USB driver may not be playing nice.

The real issue is the pathologically complex handling of serial lines in
Solaris and the ambiguous documentation.  I am not convinced that anyone,
myself included, knows which direction is which.  I know which direction is
in and out for communication w/ the local host, but that is all I'm sure of.
Coupled w/ the fact that no one seems to have done  much w/ a serial port
connection in many years makes it more difficult.  

I last used tip 14 years ago to connect to my ISDN router.  It took only a
couple of minutes to setup.  The first forth MCU also took a couple of
minutes to setup.  The second beat me senseless for 6 hours.

In light of the long history of misery and suffering by system admins at the
hands of serial port connections, this should not be a big surprise. When I
actually did a lot of RS-232 work I was running VMS 4.x on a MicroVAX
connecting to a variety of terminals and an 11/780 w/ an FPS-120B attached.
That was a long time ago when Sun was a young upstart I'd not even heard of.

I *may* build up OI from source so I can run under the debugger and resolve
the issue.  But because I've modified the remote host to emit NL-CR, it's
really not important to me other than it would be nice to have a reasonably
behaved facility for connecting over a serial line to a remote host.  If I
really get in a jam, I can run Linux. I just prefer not to if I can avoid
it.  If I elect to work on the OI/Illumos serial port discipline, it will be
for aesthetic  rather than practical reasons.

Have Fun!
Reg


___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss


___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] stty source code

[Reginald Beardsley]

The MCU is 3.3V, so it requires a level shifter to match the 5V coming from the 
USB-serial adapter to the MCU. The level shifter and Keyspan work just fine, 
though the USB driver may not be playing nice.

The real issue is the pathologically complex handling of serial lines in 
Solaris and the ambiguous documentation.  I am not convinced that anyone, 
myself included, knows which direction is which.  I know which direction is in 
and out for communication w/ the local host, but that is all I'm sure of.  
Coupled w/ the fact that no one seems to have done  much w/ a serial port 
connection in many years makes it more difficult.  

I last used tip 14 years ago to connect to my ISDN router.  It took only a 
couple of minutes to setup.  The first forth MCU also took a couple of minutes 
to setup.  The second beat me senseless for 6 hours.

In light of the long history of misery and suffering by system admins at the 
hands of serial port connections, this should not be a big surprise. When I 
actually did a lot of RS-232 work I was running VMS 4.x on a MicroVAX  
connecting to a variety of terminals and an 11/780 w/ an FPS-120B attached.  
That was a long time ago when Sun was a young upstart I'd not even heard of.

I *may* build up OI from source so I can run under the debugger and resolve the 
issue.  But because I've modified the remote host to emit NL-CR, it's really 
not important to me other than it would be nice to have a reasonably behaved 
facility for connecting over a serial line to a remote host.  If I really get 
in a jam, I can run Linux. I just prefer not to if I can avoid it.  If I elect 
to work on the OI/Illumos serial port discipline, it will be for aesthetic  
rather than practical reasons.

Have Fun!
Reg


___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] stty source code

[Roel_D]

I only buy new laptops with building rs232 ports, like the HP 6550b I own. 
I wasted too much time on crappy USB convertors. 

-Original Message-
From: James Carlson [mailto:carls...@workingcode.com] 
Sent: donderdag 6 september 2012 20:46
To: Discussion list for OpenIndiana
Subject: Re: [OpenIndiana-discuss] stty source code

Roel_D wrote:
> "never" use USB-> Serial when you're testing something. There is a 
> huge difference between products, and the bad products behave very
unpredictable.
> 
> Don't forget that the voltage of USB is 5V MAXIMUM but can be much 
> lower depending on the hardware, legacy serialports need a good 5V for 
> a logical 1.
> So communication can be disrupted by voltagedrops because the logical 
> 1's are not transmitted at the right voltage.

Good devices have a charge pump to get the standard +/- 12VDC, such as the
MAX232 or SP213.  It wouldn't be too surprising to find "cheap"
designs that lack the charge pump.  :-<

However, you are certainly right that USB serial adapters are in general all
too often substantially less than ideal.  In my experience, it's due to the
layers of software between the actual bits on the wire and the interface
exposed to the application.  If you can get a real serial port (often not
included in modern hardware, but usually available on an adapter board),
you're far, far better off using that.

(Yeah, I'm trying to be charitable with that ...)

-- 
James Carlson 42.703N 71.076W 

___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss


___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] stty source code

[James Carlson]

Roel_D wrote:
> "never" use USB-> Serial when you're testing something. There is a huge
> difference between products, and the bad products behave very unpredictable.
> 
> Don't forget that the voltage of USB is 5V MAXIMUM but can be much lower
> depending on the hardware, legacy serialports need a good 5V for a logical
> 1. 
> So communication can be disrupted by voltagedrops because the logical 1's
> are not transmitted at the right voltage. 

Good devices have a charge pump to get the standard +/- 12VDC, such as
the MAX232 or SP213.  It wouldn't be too surprising to find "cheap"
designs that lack the charge pump.  :-<

However, you are certainly right that USB serial adapters are in general
all too often substantially less than ideal.  In my experience, it's due
to the layers of software between the actual bits on the wire and the
interface exposed to the application.  If you can get a real serial port
(often not included in modern hardware, but usually available on an
adapter board), you're far, far better off using that.

(Yeah, I'm trying to be charitable with that ...)

-- 
James Carlson 42.703N 71.076W 

___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] stty source code

[Roel_D]

"never" use USB-> Serial when you're testing something. There is a huge
difference between products, and the bad products behave very unpredictable.

Don't forget that the voltage of USB is 5V MAXIMUM but can be much lower
depending on the hardware, legacy serialports need a good 5V for a logical
1. 
So communication can be disrupted by voltagedrops because the logical 1's
are not transmitted at the right voltage. 




-Original Message-
From: Reginald Beardsley [mailto:pulask...@yahoo.com] 
Sent: donderdag 6 september 2012 17:14
To: Discussion list for OpenIndiana
Subject: Re: [OpenIndiana-discuss] stty source code

Sorry, I missed that detail.  I just opened the connection w/ tip, went to
the window where I was setuid to uucp and did "stty olcuc  wrote:

> From: Andrew Gabriel 
> Subject: Re: [OpenIndiana-discuss] stty source code
> To: "Discussion list for OpenIndiana" 
> 
> Date: Thursday, September 6, 2012, 9:34 AM The stty changes will be 
> lost when the last stream closes and the port settings are reset, 
> which is probably the very instant that the stty command which makes 
> the changes exits in your example. So this will only work if something 
> else is holding the port open. That's why I said try it when tip is 
> running.
> 
> Alternatively, just to check you can change the parameter, use some 
> other command in another window to keep it open, such as sleep 1 < 
> /dev/cua/0
> 
> Reginald Beardsley wrote:
> > Andrew,
> > 
> > There are no serial ports and hence no /dev/term/b on
> this system.  In fact if the USB<->RS-232 adapter is not plugged in, 
> there is no /dev/term or /dev/cua either.
> Which may explain some of the weirdness when I was setting up the port 
> as I don't think I had plugged in the Keyspan adapter when I started 
> configuring it. /dev/{term,cua}/0 don't get created until you plug in 
> the adapter and disappear when you unplug it.
> > 
> > ttymon holds /dev/term/0, so even root or uucp cannot
> open /dev/term/0.  stty just hangs until interrupted.  Everything I've 
> read suggests that it is not possible to have a port be outbound only 
> and that is must be bidirectional.  However, I've not attempted to 
> test that. I've got enough annoyance as it is.
> However, I  can see lots of opportunity for trouble w/ ttymon running 
> on a port that goes away when the USB-serial adapter is unplugged.
> > 
> > I can open /dev/cua/0 w/ stty, but do not seem to be
> able to make any changes.
> >   
> 
> -- Andrew
> 
> 
> ___
> OpenIndiana-discuss mailing list
> OpenIndiana-discuss@openindiana.org
> http://openindiana.org/mailman/listinfo/openindiana-discuss
> 

___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss


___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] stty source code

[Gary Mills]

On Thu, Sep 06, 2012 at 11:45:45AM -0400, James Carlson wrote:
> 
> By far, I believe the best way to solve the problems you're having here
> are to either (a) use something with more sophisticated terminal
> emulation processing than just 'tip', which inherently assumes that
> you've configured the remote terminal configuration to be compatible
> with the local terminal emulator (which you have not done), or (b)
> reconfigure xterm and/or the remote system such that they have
> compatible terminal emulation modes.

Keep in mind that the function of `tip' is to emulate an ASCII
terminal.  To do that, it places the terminal in raw mode, disabling
most of the tty settings.  When you type a line of text followed by
[Enter], it sends the text followed by CR (0x0d).  The device at the
other end of the serial line should echo each of those characters,
including the CR.  If that device is another Unix system, its tty will
be in cooked mode.  That means that it will send a LF (0x0a) after the
CR.  The cursor on your terminal should first return to the left, and
then drop down one line.  A firmware device should be doing the same
thing.

-- 
-Gary Mills--refurb--Winnipeg, Manitoba, Canada-

___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] stty source code

[James Carlson]

Reginald Beardsley wrote:
> Sorry, I missed that detail.  I just opened the connection w/ tip, went to 
> the window where I was setuid to uucp and did "stty olcuc  back to the tip window. No effect.  Everything is still lower case.

Don't forget opost.

And don't forget that the "output" options you're changing on /dev/cua/0
will reflect how that port processes output text going *TO* that serial
port, and not the data you see coming back.

If your concern is (as it was before) with the characters coming from
that remote system and being displayed on your xterm, then here are the
players involved:

- remote system transmits some characters
- the /dev/cua/0 tty receives them and processes according to
  the current input settings on that device
- tip reads some data from the tty and writes it to stdout
- tip's stdout is the slave side of the pty connected to xterm
  (this is your session tty)
- the pty's output is processed by the output settings on that
  pty
- xterm reads the master side of the pty and decides (based on
  configuration) how to render those characters for the display
- xterm writes the characters to the display

As you can see, doing stty on /dev/cua/0 may or may not do what you
desire to do here.  More likely, I'd expect that cranking up tip and
then doing stty on the pty that tip is using will produce the sorts of
results you want.  But it's still the Wrong Way To Solve The Problem
because it's based on a fairly fundamental set of misunderstandings.

By far, I believe the best way to solve the problems you're having here
are to either (a) use something with more sophisticated terminal
emulation processing than just 'tip', which inherently assumes that
you've configured the remote terminal configuration to be compatible
with the local terminal emulator (which you have not done), or (b)
reconfigure xterm and/or the remote system such that they have
compatible terminal emulation modes.

> At this point, I think I need to make a non-setuid copy of tip and run tip 
> under truss from a shell which is setuid to uucp.  I'll have to wait until 
> tomorrow to try that though as other things will take up the rest of the day.

If you run truss as user 'uucp' or as 'root', you shouldn't have that
problem.  Simple enough to try if all you're doing is debugging.  No
need to make a copy.

> I'm beginning to suspect that there's something in the USB serial driver 
> which is being more "helpful" than it should.  So another thing is to spin up 
> OI on a box w/ a real serial port and see how it behaves.

I still think you're really barking up the wrong tree here, and it makes
the problem far harder to solve.

-- 
James Carlson 42.703N 71.076W 

___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] stty source code

[Reginald Beardsley]

Sorry, I missed that detail.  I just opened the connection w/ tip, went to the 
window where I was setuid to uucp and did "stty olcuc  wrote:

> From: Andrew Gabriel 
> Subject: Re: [OpenIndiana-discuss] stty source code
> To: "Discussion list for OpenIndiana" 
> Date: Thursday, September 6, 2012, 9:34 AM
> The stty changes will be lost when
> the last stream closes and the port settings are reset,
> which is probably the very instant that the stty command
> which makes the changes exits in your example. So this will
> only work if something else is holding the port open. That's
> why I said try it when tip is running.
> 
> Alternatively, just to check you can change the parameter,
> use some other command in another window to keep it open,
> such as
> sleep 1 < /dev/cua/0
> 
> Reginald Beardsley wrote:
> > Andrew,
> > 
> > There are no serial ports and hence no /dev/term/b on
> this system.  In fact if the USB<->RS-232 adapter
> is not plugged in, there is no /dev/term or /dev/cua either.
> Which may explain some of the weirdness when I was setting
> up the port as I don't think I had plugged in the Keyspan
> adapter when I started configuring it. /dev/{term,cua}/0
> don't get created until you plug in the adapter and
> disappear when you unplug it.
> > 
> > ttymon holds /dev/term/0, so even root or uucp cannot
> open /dev/term/0.  stty just hangs until
> interrupted.  Everything I've read suggests that it is
> not possible to have a port be outbound only and that is
> must be bidirectional.  However, I've not attempted to
> test that. I've got enough annoyance as it is. 
> However, I  can see lots of opportunity for trouble w/
> ttymon running on a port that goes away when the USB-serial
> adapter is unplugged.
> > 
> > I can open /dev/cua/0 w/ stty, but do not seem to be
> able to make any changes.
> >   
> 
> -- Andrew
> 
> 
> ___
> OpenIndiana-discuss mailing list
> OpenIndiana-discuss@openindiana.org
> http://openindiana.org/mailman/listinfo/openindiana-discuss
> 

___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] stty source code

[Andrew Gabriel]

The stty changes will be lost when the last stream closes and the port 
settings are reset, which is probably the very instant that the stty 
command which makes the changes exits in your example. So this will only 
work if something else is holding the port open. That's why I said try 
it when tip is running.


Alternatively, just to check you can change the parameter, use some 
other command in another window to keep it open, such as

sleep 1 < /dev/cua/0

Reginald Beardsley wrote:

Andrew,

There are no serial ports and hence no /dev/term/b on this system.  In fact if the 
USB<->RS-232 adapter is not plugged in, there is no /dev/term or /dev/cua 
either. Which may explain some of the weirdness when I was setting up the port as I 
don't think I had plugged in the Keyspan adapter when I started configuring it. 
/dev/{term,cua}/0 don't get created until you plug in the adapter and disappear when 
you unplug it.

ttymon holds /dev/term/0, so even root or uucp cannot open /dev/term/0.  stty 
just hangs until interrupted.  Everything I've read suggests that it is not 
possible to have a port be outbound only and that is must be bidirectional.  
However, I've not attempted to test that. I've got enough annoyance as it is.  
However, I  can see lots of opportunity for trouble w/ ttymon running on a port 
that goes away when the USB-serial adapter is unplugged.

I can open /dev/cua/0 w/ stty, but do not seem to be able to make any changes.
  


--
Andrew


___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] stty source code

[Reginald Beardsley]

Andrew,

There are no serial ports and hence no /dev/term/b on this system.  In fact if 
the USB<->RS-232 adapter is not plugged in, there is no /dev/term or /dev/cua 
either. Which may explain some of the weirdness when I was setting up the port 
as I don't think I had plugged in the Keyspan adapter when I started 
configuring it. /dev/{term,cua}/0 don't get created until you plug in the 
adapter and disappear when you unplug it.

ttymon holds /dev/term/0, so even root or uucp cannot open /dev/term/0.  stty 
just hangs until interrupted.  Everything I've read suggests that it is not 
possible to have a port be outbound only and that is must be bidirectional.  
However, I've not attempted to test that. I've got enough annoyance as it is.  
However, I  can see lots of opportunity for trouble w/ ttymon running on a port 
that goes away when the USB-serial adapter is unplugged.

I can open /dev/cua/0 w/ stty, but do not seem to be able to make any changes.

To wit:

root@openindiana:~# /bin/sh
root@openindiana:~# su uucp
root@openindiana:~# stty -a ;
eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; dsusp = ^Y;
rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O;
-parenb -parodd cs8 -hupcl -cstopb cread -clocal -crtscts
-ignbrk brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff
-iuclc -ixany imaxbel
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab3 bs0 vt0 ff0
isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt
echoctl echoke
root@openindiana:~# stty olcuc ;
eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; dsusp = ^Y;
rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O;
-parenb -parodd cs8 -hupcl -cstopb cread -clocal -crtscts
-ignbrk brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff
-iuclc -ixany imaxbel
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab3 bs0 vt0 ff0
isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt
echoctl echokeroot@openindiana:~# stty olcuc 
;
eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; dsusp = ^Y;
rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O;
-parenb -parodd cs8 -hupcl -cstopb cread -clocal -crtscts
-ignbrk brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff
-iuclc -ixany imaxbel
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab3 bs0 vt0 ff0
isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt
echoctl echoke


Note that attempting to set olcuc on /dev/cua/0 had no apparent effect.  

Reg

___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] stty source code

[Andrew Gabriel]

Reginald Beardsley wrote:

Having established that the stty behavior is a  red herring produced by 
/bin/tcsh here is a precis of the situation (pwd is /etc):

oi%rhb {180} /app/bin/rcsdiff remote ttydefs
===
RCS file: RCS/remote,v
retrieving revision 1.1
diff -r1.1 remote
5a6
  

u0::dv=/dev/cua/0:br#9600:el=^C^S^Q^U^D:ie=%$:oe=^D:


===
RCS file: RCS/ttydefs,v
retrieving revision 1.1
diff -r1.1 ttydefs
63a64
  

msp430:9600 -parenb cs8 -cstopb ixon opost olcuc onlcr:9600 hupcl sane::msp430


oi%rhb {181} pmadm -l
PMTAG  PMTYPE SVCTAG FLGS ID   
zsmon  ttymon tty0   uroot /dev/term/0 b - 
/usr/bin/login - msp430 ldterm,ttcompat login:  - - -  -S n #MSP430
oi%rhb {182} /bin/sh
rhb@openindiana:/etc$ tip u0

connected
  ok.
   ok.
ok.
   ~
[EOT]
rhb@openindiana:/etc$ stty -a 


You're running stty on your terminal, not on /dev/term/b.
Try running "stty -a < /dev/term/b" whilst you have the tip running on it.
(or I'm misunderstanding what you're trying to do.)

--
Andrew

___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] stty source code

[Reginald Beardsley]

Having established that the stty behavior is a  red herring produced by 
/bin/tcsh here is a precis of the situation (pwd is /etc):

oi%rhb {180} /app/bin/rcsdiff remote ttydefs
===
RCS file: RCS/remote,v
retrieving revision 1.1
diff -r1.1 remote
5a6
> u0::dv=/dev/cua/0:br#9600:el=^C^S^Q^U^D:ie=%$:oe=^D:
===
RCS file: RCS/ttydefs,v
retrieving revision 1.1
diff -r1.1 ttydefs
63a64
> msp430:9600 -parenb cs8 -cstopb ixon opost olcuc onlcr:9600 hupcl sane::msp430
oi%rhb {181} pmadm -l
PMTAG  PMTYPE SVCTAG FLGS ID   
zsmon  ttymon tty0   uroot /dev/term/0 b - 
/usr/bin/login - msp430 ldterm,ttcompat login:  - - -  -S n #MSP430
oi%rhb {182} /bin/sh
rhb@openindiana:/etc$ tip u0

connected
  ok.
   ok.
ok.
   ~
[EOT]
rhb@openindiana:/etc$ stty -a   
   
speed 38400 baud; 
rows = 77; columns = 107; ypixels = 0; xpixels = 0;
csdata ?
eucw 1:0:0:0, scrw 1:0:0:0
intr = ^c; quit = ^\; erase = ^h; kill = ^u;
eof = ^d; eol = ; eol2 = ; swtch = ;
start = ^q; stop = ^s; susp = ^z; dsusp = ^y;
rprnt = ^r; flush = ^o; werase = ^?; lnext = ^v;
-parenb -parodd cs8 -cstopb hupcl cread -clocal -loblk -crtscts -crtsxoff 
-parext 
-ignbrk brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl -iuclc 
ixon ixany -ixoff imaxbel 
isig icanon -xcase echo echoe echok -echonl -noflsh 
-tostop echoctl -echoprt echoke -defecho -flusho -pendin iexten 
opost -olcuc onlcr -ocrnl -onocr -onlret -ofill -ofdel 
rhb@openindiana:/etc$ stty olcuc
   
RHB@OPENINDIANA:/ETC$ TIP U0
   
connected
  ok.
   ok.
ok.
   ~
[EOT]
RHB@OPENINDIANA:/ETC$   
Note that I have "olcuc onlcr" set in ttydefs, but it's not being done.  With 
italso set in the terminal window it doesn't get applied to the remote host 
traffic. (The "connect" is from the USB adapter)

Communication w/ the remote host is 9600 baud, 8 bits, no parity, one stop bit. 
 The remote host is returning just NL in its output.  

Note: The entries in /etc/remote and /etc/ttydefs are a single line each in 
case they appear differently on receipt.

Suggestions?  Does anyone see anything wrong w/ the ttydefs line?  This is 
precisely what I expect ttydefs & ttymon to fix.  At this point, the only 
explanation I can think of is that only inbound traffic passed to /bin/login 
gets the effect of the arguments in ttydefs and that they are not applied to 
traffic using tip.  If that's the case, it's not broken, it's just brain dead.

Reg

___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] stty source code

[Reginald Beardsley]

--- On Wed, 9/5/12, James Carlson  wrote:

> From: James Carlson 
> Subject: Re: [OpenIndiana-discuss] stty source code
> To: "Discussion list for OpenIndiana" 
> Date: Wednesday, September 5, 2012, 1:26 PM
> Reginald Beardsley wrote:
> > This is an example of one symptom:
> > 
> > oi%rhb {9} stty -a | egrep opost
> > opost -olcuc onlcr -ocrnl -onocr -onlret -ofill -ofdel
> 
> > oi%rhb {10} stty -onlcr
> > oi%rhb {11} stty -a | egrep opost
> > opost -olcuc onlcr -ocrnl -onocr -onlret -ofill -ofdel
> 

[snip]

> 
> As an experiment, try this:
> 
>     stty -onlcr ; stty -a
> 
> You may well find that the output is jagged (due to the lack
> of
> "onlcr"), and that the output includes "-onlcr".

Well, well...

Apparently /bin/tcsh "helpfully" resets certain of the tty modes.  Can't trust 
a user to know what they need. /bin/sh and /bin/csh behave as expected.

What a staggering waste of time. Command line retrieval and editing is nice, 
but not at this price.

Sigh...
Reg

___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] stty source code

[James Carlson]

Reginald Beardsley wrote:
> This is an example of one symptom:
> 
> oi%rhb {9} stty -a | egrep opost
> opost -olcuc onlcr -ocrnl -onocr -onlret -ofill -ofdel 
> oi%rhb {10} stty -onlcr
> oi%rhb {11} stty -a | egrep opost
> opost -olcuc onlcr -ocrnl -onocr -onlret -ofill -ofdel 

You're probably best off just using "truss -vioctl" to figure out what
those commands are actually doing.  I'll bet that you see a TCGETS with
oflag set to 005 followed by a TCSETSW with oflag set to 001,
showing that stty is in fact attempting to toggle that bit.

Then, when you do stty -a again, oflag is stubbornly set to 005.

The conclusion you can draw from that is that there's nothing at all
wrong with stty -- it's doing precisely what you asked -- and that it's
something else that's being cantankerous.

As an experiment, try this:

stty -onlcr ; stty -a

You may well find that the output is jagged (due to the lack of
"onlcr"), and that the output includes "-onlcr".

The conclusion to draw from that experiment is that you're being
confused by your shell.  The shell itself (on issuing the prompt) is
"helpfully" setting some sane stty modes for you.

In other words, recompiling stty isn't going to do anything useful.

> I'm using tip running in an xterm to connect to an USB<->RS-232 adapter 
> connected to an MSP430G2553 installed in a TI MSP430 LaunchPad.  The 'G2553 
> is running a forth interpreter.

OK.  I expect that the problems you have are related to the behavior of
"tip", not of stty.

> The example I gave looks like OBP because OBP is also a forth interpreter. I 
> should probably have commented on that previously.  It's not really relevant, 
> but could be confusing.

It's relevant because that remote system is sending data that is then
copied by tip through the tty to xterm.  Knowing what's going on
necessarily involves knowing precisely what the remote system is
expected to send.

> I have two different forth interpreters that run on the MSP430G2553, a 20 pin 
> DIP w/ 16K flash & 512 byte RAM.  One was sending NL-CR and worked properly.  
> The second sent just NL which ttymon & tip *should* be able to convert to 
> NL-CR for the display terminal, but did not.

When you're running "tip" in the foreground, it's in charge of the modes
on the tty.  stty has very little to do with it.

Looking at the tip source code (usr/src/cmd/tip/), it looks like tip
always puts the tty into "raw" mode (c_oflag = 0, and c_flag ~ICANON)
when handling data from the remote system.

Thus, that bare NL is going straight to xterm, and it's doing what the
xterm's default VT102-like terminal emulation tells it to do.  If this
is really xterm (and not the GNOME Terminal application or something
else), then setting "autolinefeed" (accessed by holding the ctrl key and
pressing the middle mouse- button) should fix the problem.

In short, the configuration of the terminal emulator (xterm in this
case) MUST match what the remote system thinks it's talking to.  If it
doesn't, you'll see unfortunate results.

> As noted previously, I've now modified the second forth so that it sends 
> NL-CR and things work fine for my purposes.
> 
> In summary, I'm connecting to a remote host over a serial line. Old and 
> obsolete cruft to most these days, but the predominate means of communicating 
> w/ microcontrollers today and probably always will be.  It only takes 2 pins, 
> Rx & Tx. (Gnd doesn't require an MCU pin) In the microcontroller world MCU 
> pins are very precious. It also doesn't even require a UART in the MCU, 
> though many have them.  So *any* MCU w/ 2 free pins can use RS-232 to talk to 
> the outside world.
> 
> This is what stty & ttymon exist for.  But it doesn't seem to work and 
> appears to have been broken for some time as Solaris 10 has the same problem. 
>  Nemeth et al note Solaris serial line discipline is a mess.  However, it 
> appears to be worse than that.  It appears to be broken.

I don't think anything at all is wrong with the Solaris line discipline
support.  But those writing books can say whatever they want.  ;-}

-- 
James Carlson 42.703N 71.076W 

___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] stty source code

[Reginald Beardsley]

This is an example of one symptom:

oi%rhb {9} stty -a | egrep opost
opost -olcuc onlcr -ocrnl -onocr -onlret -ofill -ofdel 
oi%rhb {10} stty -onlcr
oi%rhb {11} stty -a | egrep opost
opost -olcuc onlcr -ocrnl -onocr -onlret -ofill -ofdel 

Notice that stty did *not* toggle onlcr. As noted earlier, I can toggle olcuc 
and some other output modes, but there are several I can't.

I started checking just the xterm window stty settings when I couldn't get tip 
to do this by setting things in /etc/ttydefs.  It appears to me that something 
is broken in code which is common to stty and ttymon.

I'm using tip running in an xterm to connect to an USB<->RS-232 adapter 
connected to an MSP430G2553 installed in a TI MSP430 LaunchPad.  The 'G2553 is 
running a forth interpreter.

The example I gave looks like OBP because OBP is also a forth interpreter. I 
should probably have commented on that previously.  It's not really relevant, 
but could be confusing.

I have two different forth interpreters that run on the MSP430G2553, a 20 pin 
DIP w/ 16K flash & 512 byte RAM.  One was sending NL-CR and worked properly.  
The second sent just NL which ttymon & tip *should* be able to convert to NL-CR 
for the display terminal, but did not.

As noted previously, I've now modified the second forth so that it sends NL-CR 
and things work fine for my purposes.

In summary, I'm connecting to a remote host over a serial line. Old and 
obsolete cruft to most these days, but the predominate means of communicating 
w/ microcontrollers today and probably always will be.  It only takes 2 pins, 
Rx & Tx. (Gnd doesn't require an MCU pin) In the microcontroller world MCU pins 
are very precious. It also doesn't even require a UART in the MCU, though many 
have them.  So *any* MCU w/ 2 free pins can use RS-232 to talk to the outside 
world.

This is what stty & ttymon exist for.  But it doesn't seem to work and appears 
to have been broken for some time as Solaris 10 has the same problem.  Nemeth 
et al note Solaris serial line discipline is a mess.  However, it appears to be 
worse than that.  It appears to be broken.

Have Fun!
Reg


___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] stty source code

[James Carlson]

Reginald Beardsley wrote:
> I find that I am unable to convert a newline returned by a remote host to 
> NL-CR for display in a terminal window. 
> 
> So instead of:
> 
> ok
> ok
> ok
> 
> I get:
>  
> ok
>ok
>   ok

It's unclear to me what problem you're trying to solve.  A "terminal
window" contains a terminal emulator that's displaying data from a
remote system.  The remote system decides what it will send, and that's
what stty affects.  Stty doesn't (normally, at least) affect what the
terminal window itself does with the data it sees.

The reason I say that is that the "ok" prompt you're showing looks like
it comes from a SPARC OBP prompt.  If it does, then what I think you'd
need is either an OBP command to change the CF/LF behavior or a
different terminal emulator or configuration.  OBP isn't UNIX and
doesn't have stty.

> I thought I'd try to find out why.  I also found I can't actually set 
> "-onlcr" w/ stty though I can toggle "olcuc".  Some things in stty work and 
> some don't.

I sometimes find "stty -g" helpful in figuring out what the line is
really configured to do, but I'm a little geeky that way.

What does your "stty -a" output say?  Does it say "opost" or "-opost?"
If it's the latter, then there'll be no output processing at all.

What application is using the tty in question, and does it issue any
ioctls?  If so, then all bets with stty may well be off -- applications
can (and very often do!) change anything they want.

The setting you logically want here is "opost onlcr -onlret".  I don't
think it's related to your problem, though.

> I've actually modified the forth interpreter to send NL-CR and reassembled 
> the code, so my original problem is solved.  But it bugs me that things don't 
> seem to work properly.  While ttys are not used much now in the wider world, 
> they are still heavily used as the interface to microcontrollers both for 
> interaction and for loading new firmware.  
> 
> I'm *very* resistant to having to use Linux for this and simply won't use 
> Windows which is the predominate environment for working w/ microcontrollers. 
>  Unfortunately there's a fair bit of open source stuff that doesn't like 
> Solaris :-(  It was a good bit of work to get this far.
> 
> In view of the admin overhead, I'll probably defer working on ttymon & 
> friends until I can setup a faster OI machine.  Working on OI wasn't actually 
> in my plans at this time.

I think you may well be barking up the wrong tree.  Details on precisely
what software you're using and what you have connected to what via a
serial link would probably be helpful in getting a more useful response.

-- 
James Carlson 42.703N 71.076W 

___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] stty source code

[Reginald Beardsley]

I find that I am unable to convert a newline returned by a remote host to NL-CR 
for display in a terminal window. 

So instead of:

ok
ok
ok

I get:
 
ok
   ok
  ok

I thought I'd try to find out why.  I also found I can't actually set "-onlcr" 
w/ stty though I can toggle "olcuc".  Some things in stty work and some don't.

I've actually modified the forth interpreter to send NL-CR and reassembled the 
code, so my original problem is solved.  But it bugs me that things don't seem 
to work properly.  While ttys are not used much now in the wider world, they 
are still heavily used as the interface to microcontrollers both for 
interaction and for loading new firmware.  

I'm *very* resistant to having to use Linux for this and simply won't use 
Windows which is the predominate environment for working w/ microcontrollers.  
Unfortunately there's a fair bit of open source stuff that doesn't like Solaris 
:-(  It was a good bit of work to get this far.

In view of the admin overhead, I'll probably defer working on ttymon & friends 
until I can setup a faster OI machine.  Working on OI wasn't actually in my 
plans at this time.

Thanks for the pointers.

Have Fun!
Reg

--- On Wed, 9/5/12, James Carlson  wrote:

> From: James Carlson 
> Subject: Re: [OpenIndiana-discuss] stty source code
> To: "Discussion list for OpenIndiana" 
> Date: Wednesday, September 5, 2012, 7:52 AM
> Reginald Beardsley wrote:
> > I've cloned the repository but find that the Makefile
> is expecting state to be set in the shell.  Where would
> I find details on what I need to have set to compile just
> the things in 
> > 
> > usr/src/cmd/ttymon
> > 
> > Is that possible?
> 
> Look for the "bldenv" and "ws" scripts, part of the ON build
> tools in
> usr/src/tools.  A good starting point might be:
> 
> http://hub.opensolaris.org/bin/view/Community+Group+on/devref_4
> 
> >  I'm really not eager to take on building
> everything as my OI box is a
> dual core Atom.
> 
> Building just a portion of the tree can be a little
> tricky.  In general,
> you have to do a "make install" in usr/src/head to make sure
> that you
> have a proto area with the right header files.  You
> might then be able
> to build in usr/src/cmd/ttymon, but it's very likely that
> you'll have to
> build some of the libraries on which it depends first.
> 
> The ON build was never designed to allow builds of
> individual parts of
> the tree, except after building everything.
> 
> An interesting (and possibly useful) project would be to
> break up the
> usr/src/cmd and usr/src/lib trees into separate projects, so
> that each
> can be built separately.  Doing so, though, likely
> requires a lot of
> careful planning so that flag-day changes are still
> reasonably doable.
> 
> If you have a really slow target machine, it might be an
> interesting
> idea to work on a cross-compilation environment on a faster
> one.  I'm
> not sure, though, how hard that'd be.
> 
> Why are you hacking at stty ... ?
> 
> -- 
> James Carlson         42.703N
> 71.076W         
> 
> ___
> OpenIndiana-discuss mailing list
> OpenIndiana-discuss@openindiana.org
> http://openindiana.org/mailman/listinfo/openindiana-discuss
> 

___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] stty source code

[Reginald Beardsley]

Thanks. 

--- On Wed, 9/5/12, Yuri Pankov  wrote:

> From: Yuri Pankov 
> Subject: Re: [OpenIndiana-discuss] stty source code
> To: "openindiana-discuss" 
> Date: Wednesday, September 5, 2012, 7:57 AM
> On Tue, 4 Sep 2012 14:40:29 -0700
> (PDT), Reginald Beardsley wrote:
> > I've cloned the repository but find that the Makefile
> is expecting state to be set in the shell.  Where would
> I find details on what I need to have set to compile just
> the things in
> >
> > usr/src/cmd/ttymon
> >
> > Is that possible?  I'm really not eager to take on
> building everything as my OI box is a dual core Atom.
> 
> http://wiki.illumos.org/display/illumos/How+To+Build+illumos
> 
> ___
> OpenIndiana-discuss mailing list
> OpenIndiana-discuss@openindiana.org
> http://openindiana.org/mailman/listinfo/openindiana-discuss
> 

___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] stty source code

[Yuri Pankov]

On Tue, 4 Sep 2012 14:40:29 -0700 (PDT), Reginald Beardsley wrote:

I've cloned the repository but find that the Makefile is expecting state to be 
set in the shell.  Where would I find details on what I need to have set to 
compile just the things in

usr/src/cmd/ttymon

Is that possible?  I'm really not eager to take on building everything as my OI 
box is a dual core Atom.


http://wiki.illumos.org/display/illumos/How+To+Build+illumos

___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] stty source code

[James Carlson]

Reginald Beardsley wrote:
> I've cloned the repository but find that the Makefile is expecting state to 
> be set in the shell.  Where would I find details on what I need to have set 
> to compile just the things in 
> 
> usr/src/cmd/ttymon
> 
> Is that possible?

Look for the "bldenv" and "ws" scripts, part of the ON build tools in
usr/src/tools.  A good starting point might be:

http://hub.opensolaris.org/bin/view/Community+Group+on/devref_4

>  I'm really not eager to take on building everything as my OI box is a
dual core Atom.

Building just a portion of the tree can be a little tricky.  In general,
you have to do a "make install" in usr/src/head to make sure that you
have a proto area with the right header files.  You might then be able
to build in usr/src/cmd/ttymon, but it's very likely that you'll have to
build some of the libraries on which it depends first.

The ON build was never designed to allow builds of individual parts of
the tree, except after building everything.

An interesting (and possibly useful) project would be to break up the
usr/src/cmd and usr/src/lib trees into separate projects, so that each
can be built separately.  Doing so, though, likely requires a lot of
careful planning so that flag-day changes are still reasonably doable.

If you have a really slow target machine, it might be an interesting
idea to work on a cross-compilation environment on a faster one.  I'm
not sure, though, how hard that'd be.

Why are you hacking at stty ... ?

-- 
James Carlson 42.703N 71.076W 

___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] stty source code

[Reginald Beardsley]

I've cloned the repository but find that the Makefile is expecting state to be 
set in the shell.  Where would I find details on what I need to have set to 
compile just the things in 

usr/src/cmd/ttymon

Is that possible?  I'm really not eager to take on building everything as my OI 
box is a dual core Atom.

Thanks.

Reg

--- On Mon, 9/3/12, Bill Sommerfeld  wrote:

> From: Bill Sommerfeld 
> Subject: Re: [OpenIndiana-discuss] stty source code
> To: openindiana-discuss@openindiana.org
> Date: Monday, September 3, 2012, 11:17 PM
> On 09/03/12 20:05, Reginald Beardsley
> wrote:
> > Where does one find the source for the stty in 151a?
> >
> > https://hg.openindiana.org/
> 
> check out a copy of illumos-gate from
> 
>     https://hg.openindiana.org/sustaining/oi_151a/illumos-gate/
> 
> (which looks like it's OI's copy of illumos-gate) and look
> in:
> 
>     usr/src/cmd/ttymon
> 
>            
>         - Bill
> 
> 
> 
> 
> 
> ___
> OpenIndiana-discuss mailing list
> OpenIndiana-discuss@openindiana.org
> http://openindiana.org/mailman/listinfo/openindiana-discuss
> 

___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] stty source code

[Reginald Beardsley]

Thanks.  It was a rather daunting array of possibilities.

--- On Mon, 9/3/12, Bill Sommerfeld  wrote:

> From: Bill Sommerfeld 
> Subject: Re: [OpenIndiana-discuss] stty source code
> To: openindiana-discuss@openindiana.org
> Date: Monday, September 3, 2012, 11:17 PM
> On 09/03/12 20:05, Reginald Beardsley
> wrote:
> > Where does one find the source for the stty in 151a?
> >
> > https://hg.openindiana.org/
> 
> check out a copy of illumos-gate from
> 
>     https://hg.openindiana.org/sustaining/oi_151a/illumos-gate/
> 
> (which looks like it's OI's copy of illumos-gate) and look
> in:
> 
>     usr/src/cmd/ttymon
> 
>            
>         - Bill
> 
> 
> 
> 
> 
> ___
> OpenIndiana-discuss mailing list
> OpenIndiana-discuss@openindiana.org
> http://openindiana.org/mailman/listinfo/openindiana-discuss
> 

___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] stty source code

[Bill Sommerfeld]

On 09/03/12 20:05, Reginald Beardsley wrote:

Where does one find the source for the stty in 151a?

https://hg.openindiana.org/


check out a copy of illumos-gate from

https://hg.openindiana.org/sustaining/oi_151a/illumos-gate/

(which looks like it's OI's copy of illumos-gate) and look in:

usr/src/cmd/ttymon

- Bill





___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss