I'm trying to write a program that reads from the serial port, and one
of the things I would like it to do is flip CLOCAL on and off from within
the program. My problem is that the attributes I get back from tcgetattr
do not match what I see in stty, and any changes I make with tcsetattr
can be read back with tcgetattr, but again the changes do not appear
when I query the port with stty, and the port behaves according to
what stty says the settings are, not what tcgetattr says they are.
It's like tcgetattr and tcsetattr maintain a parallel set of terminal
properties, which don't actually do anything.

Here's a code fragment that tries to clear CLOCAL, if it is set:

fd = open_port_noblock();
if (tcgetattr(fd, termSettings) == -1){
perror("monitor: Couldn't check tty settings - ");
exit(1);
}
printf("%08o\n", termSettings->c_cflag);
if(termSettings->c_cflag&CLOCAL){
termSettings->c_cflag &= ~CLOCAL;
if (tcsetattr(fd, TCSANOW, termSettings) == -1){
perror("monitor: Couldn't change tty settings - ");
}
}
tcgetattr(fd, termSettings);
printf("%08o\n", termSettings->c_cflag);
close(fd);

The first printf prints 00004260, and the second prints 00000260, as
you might expect. Problem is, according to stty, the control modes
on the serial port are:

-parenb -parodd cs8 hupcl -cstopb cread clocal -crtscts

which should be 00006260. Plus, stty does not show -clocal once
the program has run - it stays in exactly the same mode.

Anyone know what I might be missing here?

--

________ Jim Alexander __________________ jalex@cis.upenn.edu ______________
__
I have yet to see a problem, however complicated, which, when you looked at 
it
in the right way, did not become still more complicated.      -- Poul Anders
on

[ Post a follow-up to this message ]

In article <dgsk9o$9fmm$1@netnews.upenn.edu>,
jalex@cis.upenn.edu (Jim Alexander) wrote:

> I'm trying to write a program that reads from the serial port, and one
> of the things I would like it to do is flip CLOCAL on and off from within
> the program. My problem is that the attributes I get back from tcgetattr
> do not match what I see in stty, and any changes I make with tcsetattr
> can be read back with tcgetattr, but again the changes do not appear
> when I query the port with stty, and the port behaves according to
> what stty says the settings are, not what tcgetattr says they are.
> It's like tcgetattr and tcsetattr maintain a parallel set of terminal
> properties, which don't actually do anything.
>
> Here's a code fragment that tries to clear CLOCAL, if it is set:
>
>   fd = open_port_noblock();
>   if (tcgetattr(fd, termSettings) == -1){
>     perror("monitor: Couldn't check tty settings - ");
>     exit(1);
>   }
>   printf("%08o\n", termSettings->c_cflag);
>   if(termSettings->c_cflag&CLOCAL){
>     termSettings->c_cflag &= ~CLOCAL;
>     if (tcsetattr(fd, TCSANOW, termSettings) == -1){
>       perror("monitor: Couldn't change tty settings - ");
>     }
>   }
>   tcgetattr(fd, termSettings);
>   printf("%08o\n", termSettings->c_cflag);
>   close(fd);

The problem is with close(fd).  When tty devices are closed, they revert
back to their default settings.  If there are multiple descriptors
attached to the device (either in the same or different processes), this
happens when the last one is closed.

You need to open the device, set the attributes, do all the things that
depend on these attributes, and only then can you close the descriptor.

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

[ Post a follow-up to this message ]

In article <barmar-B3C7BB.21061521092005@comcast.dca.giganews.com>,
Barry Margolin  <barmar@alum.mit.edu> wrote:
]In article <dgsk9o$9fmm$1@netnews.upenn.edu>,
] jalex@cis.upenn.edu (Jim Alexander) wrote:
]
]> I'm trying to write a program that reads from the serial port, and one
]> of the things I would like it to do is flip CLOCAL on and off from within
]> the program. My problem is that the attributes I get back from tcgetattr
]> do not match what I see in stty, and any changes I make with tcsetattr
]> can be read back with tcgetattr, but again the changes do not appear
]> when I query the port with stty, and the port behaves according to
]> what stty says the settings are, not what tcgetattr says they are.
]> It's like tcgetattr and tcsetattr maintain a parallel set of terminal
]> properties, which don't actually do anything.
]>
]> Here's a code fragment that tries to clear CLOCAL, if it is set:
]>
]>   fd = open_port_noblock();
]>   if (tcgetattr(fd, termSettings) == -1){
]>     perror("monitor: Couldn't check tty settings - ");
]>     exit(1);
]>   }
]>   printf("%08o\n", termSettings->c_cflag);
]>   if(termSettings->c_cflag&CLOCAL){
]>     termSettings->c_cflag &= ~CLOCAL;
]>     if (tcsetattr(fd, TCSANOW, termSettings) == -1){
]>       perror("monitor: Couldn't change tty settings - ");
]>     }
]>   }
]>   tcgetattr(fd, termSettings);
]>   printf("%08o\n", termSettings->c_cflag);
]>   close(fd);
]
]The problem is with close(fd).  When tty devices are closed, they revert
]back to their default settings.  If there are multiple descriptors
]attached to the device (either in the same or different processes), this
]happens when the last one is closed.
]
]You need to open the device, set the attributes, do all the things that
]depend on these attributes, and only then can you close the descriptor.

That isn't the case on the Linux systems I'm working with. I suppose it
could be true of serial ports under to control of something like ttymon.
As Murphy's Law dictates, I found my problem shortly after posting,
and cancelled the article, but of course a lot of news servers ignore
cancel control messages.

For posterity, the problem was actually in the open_port_noblock(), whose
code I didn't post, arising from an incorrect cut-and-paste. It was always
returning 0 for the file descriptor, which means I was actually manipulating
the pty I was running the program in. So I really was manipulating a
different set of terminal properties!

--

________ Jim Alexander __________________ jalex@cis.upenn.edu ______________
__
I have yet to see a problem, however complicated, which, when you looked at 
it
in the right way, did not become still more complicated.      -- Poul Anders
on

[ Post a follow-up to this message ]