Tcl Source Code

View Ticket
Login
Bounty program for improvements to Tcl and certain Tcl packages.
Ticket UUID: ed5be77734b7e0dd01d2fc6f9bcc2b260c31cc8d
Title: win: "comx:" not recognized as serial port
Type: Bug Version: 8.6.3
Submitter: oehhar Created on: 2014-12-04 12:43:02
Subsystem: 24. Channel Commands Assigned To: jan.nijtmans
Priority: 5 Medium Severity: Important
Status: Open Last Modified: 2018-10-27 09:11:51
Resolution: Accepted Closed By: nobody
    Closed on:
Description:

Serial port names are not detected as such if postpended by ":".

E.g.

% open com1: r+
couldn't open "com1:": no such file or directory
% open com1 r+
file2672fb0

This was present in 8.6.2 and was normally fixed in TCL 8.6.3. Something went wrong, fix not included, whatever.

Harald

User Comments: tomkiti added on 2018-10-27 09:11:51:
Any progress on this? It's still not working in 8.6.8. This breaks our code when upgrading from 8.5 to 8.6.

oehhar added on 2015-06-24 07:11:05:

Discussion with Jan Nijtmans on ETCL:

  • It appears only in the wish console, not when the script is started like 'wish.exe -f script.tcl'
  • Jan supposes, tat the reason lies in the stdin/stdout magic of the wish console which, by accident, does something with "comx:".


oehhar added on 2015-05-06 14:57:41:

I have reverified with tcl8.6.4:

wish 8.6.4:

% set h [open com1: r+]
couldn't open "com1:": no such file or directory
% set h [open com1 r+]
file677a6e8

and with tclsh8.6.4:

% set h [open com1: r+]
file63c988
% close $h
% set h [open com1 r+]
file63d388

So the bug is still present when wish is used and not in tclsh. Harald


dgp added on 2015-05-01 14:38:44:
status?

jan.nijtmans added on 2014-12-05 15:49:09:
I'm able to reproduce it now (even though I don't have com-ports ...).

Somehow the function Tcl_FSGetNativePath() returns a path with ends with the unicode-character 0xf03a in stead of ':'. i.e. the final ':' is not stripped off.

I will investigate this further, finding out which code path is followed to reach this state.

jan.nijtmans added on 2014-12-05 15:48:26:
I'm able to reproduce it now (even though I don't have com-ports ...).

Somehow the function Tcl_FSGetNativePath() returns a path with ends with the unicode-character 0xf03a in stead of ':'. i.e. the final ':' is not stripped off.

I will investigate this further, finding out which code path is followed to reach this state.

jan.nijtmans added on 2014-12-05 15:47:00:
I'm able to reproduce it now (even though I don't have com-ports ...).

Somehow the function Tcl_FSGetNativePath() returns a path with ends with the unicode-character 0xf03a in stead of ':'. i.e. the final ':' is not stripped off.

I will investigate this further, finding out which code path is followed to reach this state.

jan.nijtmans added on 2014-12-04 14:18:15:

Starting with [80d513f9cb4b2e0350b1e822041322cb4330e90f|80d513f9cb4b2e03], unsafe characters (like ':') in filenames are replaced with Unicode character\uf0?? in the native form. This makes those files work transparantly, no matter if they are accessed using win32 tclsh or cygwin tclsh. For more information, see: https://cygwin.com/cygwin-ug-net/using-specialnames.html. This fully explains the appearance of the "dingbat". However, when the filename references a serial port, this conversion should not be done, that's what fixed in 8.6.3.

Why this still doesn't work in wish is a big question for me.


oehhar added on 2014-12-04 13:39:27:

dburns on the chat: 8.6.2 windows " open com1: w" creates a file with name "com1[]" where [] is a dingbat

The file may not be listed using "glob com1*".

Win XP with a physical com port

This is 8.6.2, so between the revevant patches...


oehhar added on 2014-12-04 13:15:57:

I have made some additional tests sheding more light ;-)

From release 8.6.3:

  • tcl86t.exe: does not show the issue
  • wish86t.exe: has the issue

The same is verified with the bugfix checkin was [f27ce7a1a5] and Tk8.6.3.

So, the issue only arises for wish and not for tclsh.