Package home | Report new bug | New search | Development Roadmap Status: Open | Feedback | All | Closed Since Version 1.2.2

Bug #16850 Parse9 test (password) fails.
Submitted: 2009-11-30 18:26 UTC
From: rquadling Assigned: izi
Status: Closed Package: Console_CommandLine (version 1.1.1)
PHP Version: 5.3.1 OS: Windows XP SP3
Roadmaps: (Not assigned)    
Subscription  


 [2009-11-30 18:26 UTC] rquadling (Richard Quadling)
Description: ------------ Hello. Parse9 test does not include the "(warning: will echo)" text as part of the expected output and as such fails. Including the text allows the test to pass.

Comments

 [2009-11-30 18:27 UTC] rquadling (Richard Quadling)
 [2009-11-30 18:53 UTC] izi (David Jean Louis)
Hi Richard, in fact this is only displayed on windows, I didn't find a way to make the password not echo on this platform... have you any hints for this btw ? So the good fix would be: --EXPECTF-- Password%s: array(11) { I'll fix this ASAP.
 [2009-11-30 20:37 UTC] rquadling (Richard Quadling)
Aha. I see. As you cannot capture input from the console without the console echo-ing it ... Not without a rewrite of PHP's interpretation of the fgetc() function (which requires a newline to be entered AND echo's the input), then there is no way to suppress the display. A _LONG_ time ago, I used to do C programming (Point of Sale for DOS environments). In there I'd use a combination of kbhit() and getch() to read from the keyboard. No display required. You could even handle function keys - when kbhit() is true and getch() = 0 then the next getch() will return the function key value. Also cursor keys, etc. the same way. All excellent for console apps. But coding this for PHP is now way beyond me. Though http://forums.devarticles.com/c-c-help-52/getch-and-kbhit--c-problem- 7921.html does make mention of something like this for non-windows. I'll find a patch for the test when I get it working. Password%s: array(11) { didn't work. It seems %s only works for --EXPECTF-- (http://qa.php.net/write- test.php#expectf). There is the option of --EXPECTREGEX--, which, once all the escaping is done, seems to work. Patch coming.
 [2009-11-30 20:38 UTC] rquadling (Richard Quadling)
 [2009-11-30 20:47 UTC] izi (David Jean Louis)
Ha, in fact this should work: --EXPECTF-- Password%s array(11) { Note the removed ":", it should match "Password:" and "Password (whatever):". Do you confirm ?
 [2009-11-30 21:10 UTC] rquadling (Richard Quadling)
Nope. %s only works for --EXPECTF--, when there is a fault/error/etc. Most commonly used to skip the exact file location ... %sTestName.phpt on line %d sort of thing. --EXPECT-- does not support %s, %d, etc. I've raised a feature request to allow this, but there would be an issue with ... --EXPECT-- sprintf('%s', x); where %s is literally %s currently.
 [2009-11-30 21:40 UTC] izi (David Jean Louis)
Hmm, are you sure of this ? Because I modified the file to "simulate" a windows box and the test passes when using: --EXPECTF-- Password%s array(11) { I do this on many tests, see: http://qa.php.net/phpt_details.php#expectf_section
 [2009-11-30 21:50 UTC] rquadling (Richard Quadling)
Aha. You also changed --EXPECT-- to --EXPECTF--. Considering the output is not a fault/exception, is this the wrong sort of tag? But, if that is OK, then --EXPECTF-- and %s will be fine.
 [2009-11-30 21:53 UTC] rquadling (Richard Quadling)
 [2009-11-30 21:55 UTC] rquadling (Richard Quadling)
Oh so stupid me. EXPECTF is like printf. Not expect fault as I was reading it. It was just that all the tests I was looking at were errors where %s and %d where used for the filename and line number. DOH!
 [2009-11-30 21:57 UTC] izi (David Jean Louis)
No, it's the right tag I think. EXPECTF is not limited to errors, it also works for normal output, look at the examples in the manual: http://qa.php.net/sample_tests/sample020.php I'm committing the changes for the 3 bugs, thanks for your time. -- David
 [2009-11-30 22:05 UTC] izi (David Jean Louis)
-Status: Open +Status: Closed -Assigned To: +Assigned To: izi
This bug has been fixed in SVN. If this was a documentation problem, the fix will appear on pear.php.net by the end of next Sunday (CET). If this was a problem with the pear.php.net website, the change should be live shortly. Otherwise, the fix will appear in the package's next release. Thank you for the report and for helping us make PEAR better.