Ticket UUID: | 432499 | |||
Title: | command string passed to exec not quoted | |||
Type: | Bug | Version: | obsolete: 8.3.3 | |
Submitter: | kenpoole | Created on: | 2001-06-12 18:47:30 | |
Subsystem: | 27. Channel Types | Assigned To: | andreas_kupries | |
Priority: | 5 Medium | Severity: | ||
Status: | Closed | Last Modified: | 2001-08-24 04:20:45 | |
Resolution: | Fixed | Closed By: | andreas_kupries | |
Closed on: | 2001-08-23 21:20:44 | |||
Description: |
If I pass the fully qualified path to an executable that has spaces in its path to the exec command, it will execute properly. If I pass just the command name, it will error out with "invalid argument" as the error message. If I modify the source in tclWinPipe.c (starting at line 1525 from the packaged 8.3.3 tar ball) as follows: #define KEP_EXEC_PROBLEM #ifdef KEP_EXEC_PROBLEM if (arg[0] == '\0') { #else if (argv[i][0] == '\0') { #endif quote = 1; } else { #ifdef KEP_EXEC_PROBLEM for (start = arg; *start != '\0'; start++) { #else for (start = argv[i]; *start != '\0'; start++) { #endif the exec works as I expect. The second set of changes is what actually fixes my problem (start=arg). If the fully qualified path is specified, the argv[0] and arg contain identical strings. if invoked as: exec application the var argv[0] will contain "application", arg will contain the fully qualified path (ie c:\Program Files\appdir\application.exe). Since the code that checks for "quoting" was looking at argv[0], it wasnt seeing the "space" in the fully qualified path and the command to actually launch the app would fail. | |||
User Comments: |
andreas_kupries added on 2001-08-24 04:20:45:
File Added - 9912: 432499.diff andreas_kupries added on 2001-08-24 04:20:44: Logged In: YES user_id=75003 Patch accepted. It looks good (other parts of the code use 'arg' instead of 'argv[i]') and does not introduce new errors. Attaching final patch. Committed this patch to both core-8-3-1-branch (8.3.3) and the HEAD. andreas_kupries added on 2001-08-24 03:00:32: Logged In: YES user_id=75003 Looking deeper I see the same difference between 'arg' and 'argv [i]' in the case of 'exec app' without full path. But it doesn't seem to matter anymore to the OS. kenpoole added on 2001-08-24 02:58:23: Logged In: YES user_id=68713 The problem occurs when KEP_EXEC_PROBLEM is not defined. Sorry about not being clearer ... as to a sample program to run, I dont see anything that would be "on all windows systems" ... it needs to be an application which has a space somewhere in its path (like any application in "c:\Program Files\...") that is also in the "PATH" enviroment variable such that in a "dos" window (cmd.exe on nt) it can be run by just typing the program name (without typing the absolute path). It (unfortunatly) seems to be machine specific ... I have two machines that show the problem here (both NT5), and some people around me dont see the problem ... I also sent the "modified" tcl83 exe to another of our sites since they were showing the same problem ... I dont know what the "differing" factor is between these boxes are ... What I do know is that when I modified the function BuildCommandLine to include the argument "executable" in the check for quoting (which is the affect of the above code change), then the "executable" string is quoted and the application executes as expected ... andreas_kupries added on 2001-08-24 02:47:31: Logged In: YES user_id=75003 I am unable to verify this for 8.3.3 as well, using Windows NT 5. andreas_kupries added on 2001-08-24 02:37:46: File Added - 9907: demo432499.tcl Logged In: YES user_id=75003 The above description is a bit confusing. Does the problem occur when KEP_EXEC_PROBLEM is defined or when it is not defined ? What would be a nice example application I could use ? (Something which is hopefully everywhere where we have Windows) Attaching a demo script which uses our local 'perforce' client (p4.exe) as the application to run. _______________________________________ >> I cannot verify the problem << What is your operating system ? I use WinNT 5 and tried to verify this problem for tcl8.4a3 I will try 8.3.3 now too. |