Tcl Source Code

OriginalBugID: 621 RFE
Version: 8.1a2
SubmitDate: '1998-05-25'
LastModified: '1999-03-23'
Severity: LOW
Status: Assigned
Submitter: hershey
ChangedBy: surles
OS: All
OSVersion: NA
Machine: NA
FixedDate: '2000-10-25'
FixedInVersion: NA
ClosedDate: '2000-10-25'


I have a Tcl script started from the inetd daemon but am unable to get

[fconfigure stdin -peername] because stdin is a 'file' rather than a

'socket'.  The following patch to tcl8.1a2/unix/tclUnixChan.c (v 1.217)

modifies the Tcl_MakeFileChannel() function to make a channel with the

socket ('tcp') channel type if it responds sucessfully to a

getsockname() request.



Could you please include this change in future versions of Tcl?  If you

are the wrong person to send this to please let me know.



I have to say that the SUPPORTS_TTY logic in Tcl_OpenFileChannel()

should probably also be present in the Tcl_MakeFileChannel() function as

well.

---

Matthew Costello

(619)485-2926

[email protected]

*** tclUnixChan.c.ORIG  Fri Feb 20 15:20:43 1998

--- tclUnixChan.c       Thu Apr 30 16:10:49 1998

***************

*** 1387,1392 ****

--- 1387,1398 ----

      char channelName[16 + TCL_INTEGER_SPACE];

      int fd = (int) handle;

      ThreadSpecificData *tsdPtr = TCL_TSD_INIT(&dataKey);

+     Tcl_ChannelType *channelTypePtr;

+ #define SUPPORTS_SOCKET

+ #ifdef SUPPORTS_SOCKET

+     struct sockaddr sockaddr;

+     int socklen = sizeof(sockaddr);

+ #endif

  

      if (mode == 0) {

          return NULL;

***************

*** 1410,1418 ****

      fsPtr->nextPtr = tsdPtr->firstFilePtr;

      tsdPtr->firstFilePtr = fsPtr;

  

      fsPtr->fd = fd;

      fsPtr->validMask = mode | TCL_EXCEPTION;

!     fsPtr->channel = Tcl_CreateChannel(&fileChannelType, channelName,

              (ClientData) fsPtr, mode);

      

      return fsPtr->channel;

--- 1416,1441 ----

      fsPtr->nextPtr = tsdPtr->firstFilePtr;

      tsdPtr->firstFilePtr = fsPtr;

  

+ #ifdef SUPPORTS_SOCKET

+     if (getsockname(fd,&sockaddr,&socklen ) == 0) {

+       /*

+       * Initialize the serial port to a set of sane parameters.

+       * Especially important if the remote device is set to echo and

+       * the serial port driver was also set to echo -- as soon as a char

+       * were sent to the serial port, the remote device would echo it,

+       * then the serial driver would echo it back to the device, etc.

+       */

+       

+       channelTypePtr = &tcpChannelType;

+     } else 

+ #endif        /* SUPPORTS_SOCKET */

+     {

+       channelTypePtr = &fileChannelType;

+     }

+ 

      fsPtr->fd = fd;

      fsPtr->validMask = mode | TCL_EXCEPTION;

!     fsPtr->channel = Tcl_CreateChannel(channelTypePtr, channelName,

              (ClientData) fsPtr, mode);

      

      return fsPtr->channel;

Logged In: YES 
user_id=80530

Re-opening this patch since it appears to
have introduced new bugs.

http://sf.net/tracker/?func=detail&atid=110894&aid=471374&group_id=10894

http://sf.net/tracker/index.php?func=detail&aid=465761&group_id=12997&atid=112997

File Added - 7067: unixchantype.patch

Logged In: YES 
user_id=79902

(Bah! Next time check that it really works *first*; this new
version seems to do the business though.)

File Deleted - 7062:

File Added - 7062: chantype.patch

Logged In: YES 
user_id=79902

After investigation, I've got a solution for this (well, one
that goes a bit better and handles serial lines as well.)

Sounds like a reasonable request to me, though it is a UNIX-specific change as Windows places sockets and pipes/terminals into mutually exclusive sets.  Stupid operating system...

I wouldn't fix it exactly as described though; if we are going to allow stdio channels to be represented as socket channels, then they should have names from the sock* series as well.  Also ought to check errno to figure out if we've really got a socket (succeeds => yes, fails with errno==ENOTSOCK => no, other failures => machine is very short of resources!)