Tcl Source Code

At Tcl 8.3
% exec echo [list 1 2 "3 and 4"]
1 2 {3 and 4}

This looks correct to me

At Tcl 8.4
% exec echo [list 1 2 "3 and 4"]
1 2 \{3 and 4}

Note the extra back-slash at 8.4 which looks wrong to 
me.

I am running on Windows (98) with version 
ActiveTcl8.4.1.0-2-win32-ix86.exe

[email protected]

Logged In: YES 
user_id=80530


What does this change
do to Tcl Bug 554068?

Logged In: YES 
user_id=7549

FYI, no test case existed to show the need for the custom 
setargv() used in both the tcl and wish shells.  Therefore, it 
was removed in favor of the c-runtime's work.

Logged In: YES 
user_id=7549

Committing fix to HEAD. tclWinPipe.c -r1.41

File Deleted - 70719:

File Added - 75040: patch.txt

Logged In: YES 
user_id=7549

Updated patch..  Needs test suite additions or, rather, 
verification with cases.

File Added - 70719: patch.txt

Logged In: YES 
user_id=7549

Here's a patch that fixes this.  It needs some more work to 
polish it.

Logged In: YES 
user_id=695046

When I found the problem, I was sending arguments from one Tcl/Tk script to another. In trying to understand the 
problem, I simplified it to running echo (from cygwin) from the wish shell by hand. It looks to me like cygwin reads 
the arguments exactly the same way the Tcl/Tk does now. I am assuming that the problem is with sending the 
arguments rather than reading them - hence your error going via $env(COMSPEC). Therefore, I am hopeful that 
cygwin interfaces will prove OK.

I am unable to compile, but other than that, I am happy to help test.

[email protected]

Logged In: YES 
user_id=32170

As dgp asked, the original problem was on Win2000. I don't know if 
behaviour is different across different Win systems.  Also, as Dave 
points out, cygwin may do something completely different -- if so, then 
cygwin is at fault, I think -- we should fix for the standard Win shell.

Anyway, I'm happy to test any proposed fixes, and we obviously need to 
add appropriate tests to the test suite as well.

Logged In: YES 
user_id=695046

David

The Tcl/Tk community is so very helpful. Thank you so much 
for looking at my problem with such enthusiasm and skill! I 
hopebody minds me putting this personal comment here for 
the record.

Mick

Logged In: YES 
user_id=7549

Ok, first job is to make BuildCommandLine() exportable to 
the private Stubs table so I can put it in a test suite.

Then we can compare it against the runtime's parse_cmdline
() and against the custom one of win/tclAppInit.c and get this 
matter squashed.

Logged In: YES 
user_id=7549

The problem is compounded by the fact that tclsh (in 
win/tclAppInit.c) uses a custom argv setting routine that is 
not the default of the runtime.

We may fix Tcl to itself, but then calls to others apps will not 
be correct which tends to show itself when launching cygwin 
utilities which probably use a whole different rule set anyways.

Logged In: YES 
user_id=7549

Yes, Tcl must be internally consistent, but it must go 
EXTERNAL to do it according to the quoting rules that the C-
runtime uses.

The rules for turning a commandline string into a vector is 
contained by parse_cmdline() found in the MS runtime 
src\crt\stdargv.c

BuildCommandLine in tclWinPipe.c must be the inverse of 
the runtime's parse_cmdline().  This is the problem here.

Logged In: YES 
user_id=695046

I do not quite understand the comments here, but I wonder 
if it is helpful to add thaat if I call a second Tcl script from a 
first script with arguments the problem is apparent. That 
is, the second script will get aruments with extra back-
slash characters in it:
e.g. 
exec wish printargs.tcl -- {3 and 4}
So Tcl/Tk is not internally consistent. 
I hope this helps. Mick

Logged In: YES 
user_id=7549

% exec $env(COMSPEC) /c echo asd a="b"
asd a=\"b\"

The above should NOT be doing what you see.  
BuildCommandLine() MUST turn those quotes into two and 
NOT place a backslash in front of it.

Logged In: YES 
user_id=7549

There is a double-quote problem in the current behavior of 
BuildCommandLine().  Somehow this was recently broken.

if the commandline is this to CreateProcess():
a.exe b c=""d""

_SHOULD_ expand to an argv array of
argv[0] = a.exe
argv[1] = b
argv[2] = c="d"

if the commandline is this to CreateProcess():
a.exe b "c = d"

_SHOULD_ expand to an argv array of
argv[0] = a.exe
argv[1] = b
argv[2] = c = d

GetCommandLine()->argv processing is done by the C-
runtime of the process launched.  It is out of Tcl's control.  If 
some processes follow the quoting rules and others do not...  
then we're fighting a losing battle.

Logged In: YES 
user_id=7549

That behavior can be removed by taking out the part where 
that is quoted.

diff -c -r1.32 tclWinPipe.c
*** tclWinPipe.c17 Dec 2002 02:47:39 -00001.32
--- tclWinPipe.c23 Jan 2003 21:43:15 -0000
***************
*** 1594,1604 ****
  Tcl_DStringAppend(&ds, "\\\"", 2);
  start = special + 1;
      }
!     if (*special == '{') {
  Tcl_DStringAppend(&ds, start, special -
 start);
  Tcl_DStringAppend(&ds, "\\{", 2);
  start = special + 1;
!     }
      if (*special == '\0') {
  break;
      }
--- 1594,1604 ----
  Tcl_DStringAppend(&ds, "\\\"", 2);
  start = special + 1;
      }
! /*    if (*special == '{') {
  Tcl_DStringAppend(&ds, start, special -
 start);
  Tcl_DStringAppend(&ds, "\\{", 2);
  start = special + 1;
!     }*/
      if (*special == '\0') {
  break;
      }

What's interesting is that this is now showing itself.  There 
are a set of rules this quoting mechanism needs to do so 
args can be pulled back out of the single string and placed in 
an argv array by the process that this line is handed.

Logged In: YES 
user_id=80530

Just curious whether this bug an Bug 554608
were reported for the same release of Windows?

Logged In: YES 
user_id=695046

I am advised that this problem (new at 8.4) could be a consequence of fixing a previous exec bug:

554068