| Ticket UUID: | 1244733 | ||
| Title: | auto_execok can return relative path names | ||
| Type: | Bug | Created on: | 2005-07-25 19:33:25 |
| Submitter: | techentin | Assigned to: | dgp |
| Subsystem: | 38. Init - Library - Autoload | Severity: | Minor |
| Priority: | 5 Medium | Last modified: | 2026-05-18 10:28:52 |
| Status: | Closed | Closed by: | apnadkarni |
| Resolution: | Fixed | Closed on: | 2026-05-18 10:28:52 |
| Version: | obsolete: 8.4.11 | ||
| Description: | ||||
auto_execok can return relative path names. On Windows, "." is one of the standard search directories. And on Unix, empty directories in the path are treated as ".". In these cases, [file executable] is successful, and auto_execok returns something like "./myfile" It works fine until your application changes working directory. Then relative path names are broken. Perhaps auto_execok should use [file normalize] before returning. | ||||
| User Comments: | ||||
dgp added on 2005-11-02 01:57:39:
Logged In: YES user_id=80530 Since the purpose of [auto_execok] is to return something suitable for passing to [exec], applying [file normalize] to the return value can only make things more robust. So, I think this is a good idea. One wrinkle in the plan is that [file normalize] isn't present in safe interps. Another issue is that freewrap seems to have issues with [file normalize] (see 1072136) if someone can resolve those issues, we can move forward with this. apnadkarni added on 2026-05-18 10:28:52:
Fixed for 9.1 in TIP 753 commit [de961e8d](https://core.tcl-lang.org/tcl/info/de961e8dee5470e6). Paths are not cached - see the TIP and discussion. Tested in `auto_execok-win-6.1`. | ||||