Tcl Source Code

View Ticket
Login
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.

Attachments: