Menu
▾
▴
[Tcl-bugs] [ tcl-Bugs-554068 ] Windows: [exec] doesn't quote special chars
|
From: SourceForge.net <no...@so...> - 2004-02-25 18:28:01
|
Bugs item #554068, was opened at 2002-05-09 04:25 Message generated for change (Comment added) made by davygrvy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=554068&group_id=10894 Category: 27. Channel Types Group: obsolete: 8.4a5 Status: Closed Resolution: Rejected Priority: 7 Submitted By: Vince Darley (vincentdarley) Assigned to: David Gravereaux (davygrvy) Summary: Windows: [exec] doesn't quote special chars Initial Comment: If I rename 'tcl8.4' to 'tcl[{8.4' and try to run the test suite ('make test') from within there, 8 tests fail: Tests ended at Wed May 08 7:56:31 PM GMT Daylight Time 2002 all.tcl: Total 10164 Passed 9479 Skipped 677 Failed 8 Sourced 128 Test Files. Files with failing tests: io.test tcltest.test C:\Tcl-source\tcl{[8.4\win> The actual failures are listed below, and seem to be due to just two specific problems. I've attached a patch which I think fixes both problems (but tested only on Windows): io.test ==== io-34.10 Tcl_Seek testing flushing of buffered input FAILED ==== Contents of test case: set f [open test3 w] fconfigure $f -translation lf puts $f xyz\n123 close $f set f [open test3 r+] fconfigure $f -translation lf set x [gets $f] seek $f 0 current puts $f 456 close $f list $x [viewFile test3] ---- Result was: /usr/bin/cat: C:/Tcl-source/tcl: No such file or directory ---- Result should have been (exact matching): xyz {xyz 456} ---- Test generated error; Return code was: 1 ---- Return code should have been one of: 0 2 ==== io-34.10 FAILED ==== io-34.11 Tcl_Seek testing flushing of buffered output FAILED ==== Contents of test case: set f [open test3 w] puts $f xyz\n123 close $f set f [open test3 w+] puts $f xyzzy seek $f 2 set x [gets $f] close $f list $x [viewFile test3] ---- Result was: /usr/bin/cat: C:/Tcl-source/tcl: No such file or directory ---- Result should have been (exact matching): zzy xyzzy ---- Test generated error; Return code was: 1 ---- Return code should have been one of: 0 2 ==== io-34.11 FAILED ==== io-34.12 Tcl_Seek testing combination of write, seek back and read FAILED ==== Contents of test case: set f [open test3 w] fconfigure $f -translation lf -eofchar {} puts $f xyz\n123 close $f set f [open test3 a+] fconfigure $f -translation lf -eofchar {} puts $f xyzzy flush $f set x [tell $f] seek $f -4 cur set y [gets $f] close $f list $x [viewFile test3] $y ---- Result was: /usr/bin/cat: C:/Tcl-source/tcl: No such file or directory ---- Result should have been (exact matching): 14 {xyz 123 xyzzy} zzy ---- Test generated error; Return code was: 1 ---- Return code should have been one of: 0 2 ==== io-34.12 FAILED ==== io-40.7 POSIX open access modes: EXCL FAILED ==== Contents of test case: removeFile test3 set f [open test3 {WRONLY CREAT EXCL}] fconfigure $f -eofchar {} puts $f "A test line" close $f viewFile test3 ---- Result was: /usr/bin/cat: C:/Tcl-source/tcl: No such file or directory ---- Result should have been (exact matching): A test line ---- Test generated error; Return code was: 1 ---- Return code should have been one of: 0 2 ==== io-40.7 FAILED ==== io-40.13 POSIX open access modes: WRONLY FAILED ==== Contents of test case: makeFile xyzzy test3 set f [open test3 WRONLY] fconfigure $f -eofchar {} puts -nonewline $f "ab" seek $f 0 current set x [list [catch {gets $f} msg] $msg] close $f lappend x [viewFile test3] string compare [string tolower $x] [list 1 "channel \$f\ wasn't opened fo r reading" abzzy] ---- Result was: /usr/bin/cat: C:/Tcl-source/tcl: No such file or directory ---- Result should have been (exact matching): 0 ---- Test generated error; Return code was: 1 ---- Return code should have been one of: 0 2 ==== io-40.13 FAILED ==== io-40.15 POSIX open access modes: RDWR FAILED ==== Contents of test case: makeFile xyzzy test3 set f [open test3 RDWR] puts -nonewline $f "ab" seek $f 0 current set x [gets $f] close $f lappend x [viewFile test3] ---- Result was: /usr/bin/cat: C:/Tcl-source/tcl: No such file or directory ---- Result should have been (exact matching): zzy abzzy ---- Test generated error; Return code was: 1 ---- Return code should have been one of: 0 2 ==== io-40.15 FAILED tcltest.test ==== tcltest-8.13 tcltest a.tcl -testdir normaldirectory FAILED ==== Contents of test case: catch {exec $::tcltest::tcltest a.tcl -testdir normaldirectory} msg # The join is necessary because the message can be split on multiple lines regexp "testdir: $normaldirectory" [join $msg] ---- Result was: couldn't compile regular expression pattern: brackets [] not balanced ---- Result should have been (exact matching): 1 ---- Test generated error; Return code was: 1 ---- Return code should have been one of: 0 2 ==== tcltest-8.13 FAILED ==== tcltest-23.5 viewFile FAILED ==== Contents of test case: set mfdir [file join [tcltest::temporaryDirectory] mfdir] file mkdir $mfdir makeFile {foobar} t1.tmp makeFile {foobarbaz} t2.tmp $mfdir list [viewFile t1.tmp] [viewFile t2.tmp $mfdir] ---- Result was: /usr/bin/cat: C:/Tcl-source/tcl: No such file or directory ---- Result should have been (exact matching): foobar foobarbaz ---- Test generated error; Return code was: 1 ---- Return code should have been one of: 0 2 ==== tcltest-23.5 FAILED ---------------------------------------------------------------------- >Comment By: David Gravereaux (davygrvy) Date: 2004-02-25 10:24 Message: Logged In: YES user_id=7549 The real problem here is that cygwin's cat.exe doesn't parse its commandline properly. Hacks for cat can be added to the core, but then all other uses of '{' in the commandline string will be parsed improperly by all other applications including tclsh and wish themselves. The pass-thru must be identical. echo.tcl: foreach arg $argv { puts $arg } % exec [info name] echo.tcl foo \{\[ bar foo {[ bar % If the above can not be identical, then cat.exe is in error, not us. Before the fix from yesterday that was added to the 84 branch, { would have had a \ in front of it that the MS parse_cmdline routine would not strip off. Again, cat.exe is in error, not us. ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2004-02-25 08:08 Message: Logged In: YES user_id=80530 I see changes in this area were just committed to core-8-4-branch (for release in 8.4.6? ). Is the current core-8-4-branch code correct in terms of this bug report? I'm looking for someone to assert that this bug has not be re-introduced. It's a simple test to run on a Window system, but I don't have one handy to test myself. ---------------------------------------------------------------------- Comment By: David Gravereaux (davygrvy) Date: 2004-02-24 18:52 Message: Logged In: YES user_id=7549 The patch is incorrect and was removed about a month ago. As per the rules of quoting for parse_cmdline() found in msvcrt.dll, '{' doesn't require quoting. And if it is quoted, pass-through will break as tested by winpipe-7.* and winpipe- 8.* and all other programs linked to msvcrt.dll Please send this bug to CYGWIN's tools maintainer. The bug is in their cat.exe or general commandline parsing routine in their runtime. ---------------------------------------------------------------------- Comment By: Jeffrey Hobbs (hobbs) Date: 2004-02-24 17:30 Message: Logged In: YES user_id=72656 This breaks when users create command lines that have arguments which include { that aren't filenames. ---------------------------------------------------------------------- Comment By: Andreas Kupries (andreas_kupries) Date: 2002-06-17 13:06 Message: Logged In: YES user_id=75003 Patch committed to head. ---------------------------------------------------------------------- Comment By: Andreas Kupries (andreas_kupries) Date: 2002-06-17 13:04 Message: Logged In: YES user_id=75003 Applied and used the test patch to verify that the behaviour is different for Linux and Windows. I agree that the Win* behaviour is a bug. Applied the patch fixing it, compiles ok. Testsuite: New test is ok now, no new failed tests. Patch is accepted. ---------------------------------------------------------------------- Comment By: Vince Darley (vincentdarley) Date: 2002-06-14 04:46 Message: Logged In: YES user_id=32170 attaching test patch ---------------------------------------------------------------------- Comment By: Vince Darley (vincentdarley) Date: 2002-06-14 04:45 Message: Logged In: YES user_id=32170 This is then, presumably a bug in 'BuildCommandLine' in tclWinPipe.c, since the argc/argv values have simply been passed along from Tcl. BuildCommandLine(execPath, argc, argv, &cmdLine); if ((*tclWinProcs->createProcessProc)(NULL, (TCHAR *) Tcl_DStringValue(&cmdLine), NULL, NULL, TRUE, (DWORD) createFlags, NULL, NULL, &startInfo, &procInfo) == 0) { ... Had a look, and the fix is easy. Please see attached patch for fix and test of the fix. I've tested the fix and Tcl passes all tests, so I think this should be applied to cvs head. ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2002-05-10 11:34 Message: Logged In: YES user_id=80530 Most of these appear to be due to a bug (?) in [exec] on Windows. The command exec cat $filename should pass $filename as a single argument to cat, no matter what funny characters are contained in $filename. I'm reassigning this over to "Channel Types" where [exec] lives. I will commit a fix for the [regexp] problem, as well as the other test failures I saw on Linux when I ran a similar test (all of the list quoting issues on matching expected results in the test suite). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=554068&group_id=10894 |