+++ This bug was initially created as a clone of Bug #141171 +++ From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910 Description of problem: I have a strange problem with using the expect language in a simple script that is used to change a users password. I attached some simple code that is part of a wrapper we use to change users passwords. The failure is intermittent and happens about every 2 out of 3 times using a gnome-terminal or an xterm to run. The script does not fail if using the kconsole terminal or another terminal emulator we use, (SecurCRT), from a Windows machine. I turned on debuging with the "expect -d" option in the script. Below is the output when the script fails and then works. Note when it fails expecting the second passwd prompt expect sees the password, (j1jd8%Mt), passed to it after the first prompt is processed! I tried various passwords with the same results. This particular passwd works sometimes and fails most of the time. I tried setting the timeout variable to 60 seconds and it still fails. I have also seen the script fail expecting the eof and also fail on the "[wait]" call. I am hoping fixing one problem will fix the others. It seems related to the tty, I saved the stty settings from the kconsole (stty --save) and then used these setting to set the gnome-terminal and this did not help. Don't know if this matters but here is what the /etc/pam.d/password config password section is set to: password required /lib/security/pam_cracklib.so password required /lib/security/pam_pwdb.so nullok use_authtok md5J shadow audit Version-Release number of selected component (if applicable): expect-5.38.0-92.2 How reproducible: Sometimes Steps to Reproduce: Run the expect script under a gnome-terminal, change the user variable to a local test user on you system: #!/usr/bin/expect -d set timeout 5 log_user 1 set newPasswd j1jd8%Mt set user astroboy send_user "**spawn /usr/bin/passwd $user ...\n" spawn "/usr/bin/passwd" "$user" expect { timeout { send_user "Timeout waiting for spawn /usr/bin/passwd\n" exit 1 } "ssword:*" { send_user "**sending passwd once...\n" exp_send "$newPasswd\r" } } send_user "**expect second passwd prompt...\n" expect { timeout { send_user "Timeout waiting for second passwd prompt:\n" exit 1 } "ssword:*" { send_user "**sending passwd twice...\n" exp_send "$newPasswd\r" } } send_user "**expecting eof ...\n" expect EOF send_user "**wait for process...\n" set progReturn [wait] send_user "**finished wait for process...\n" Actual Results: --------------- expect version 5.38.0 argv[0] = /usr/bin/expect argv[1] = -d argv[2] = ./sux set argc 0 set argv0 "./sux" set argv "" executing commands from command file ./sux **spawn /usr/bin/passwd astroboy ... spawn /usr/bin/passwd astroboy parent: waiting for sync byte parent: telling child to go ahead parent: now unsynchronized from child spawn: returns {6360} expect: does "" (spawn_id exp4) match glob pattern "ssword:*"? no Changing password for user astroboy. expect: does "Changing password for user astroboy.\r\n" (spawn_id exp4) match glob pattern "ssword:*"? no New UNIX password: expect: does "Changing password for user astroboy.\r\nNew UNIX password: " (spawn_id exp4) match glob pattern "ssword:*"? yes expect: set expect_out(0,string) "ssword: " expect: set expect_out(spawn_id) "exp4" expect: set expect_out(buffer) "Changing password for user astroboy.\r\nNew UNIX password: " **sending passwd once... send: sending "j1jd8%Mt\r" to { exp4 } **expect second passwd prompt... expect: does "" (spawn_id exp4) match glob pattern "ssword:*"? no j1jd8%Mt expect: does "j1jd8%Mt\r\n" (spawn_id exp4) match glob pattern "ssword:*"? no expect: timed out Timeout waiting for second passwd prompt: Expected Results: ----------------- expect version 5.38.0 argv[0] = /usr/bin/expect argv[1] = -d argv[2] = ./sux set argc 0 set argv0 "./sux" set argv "" executing commands from command file ./sux **spawn /usr/bin/passwd astroboy ... spawn /usr/bin/passwd astroboy parent: waiting for sync byte parent: telling child to go ahead parent: now unsynchronized from child spawn: returns {6356} expect: does "" (spawn_id exp4) match glob pattern "ssword:*"? no Changing password for user astroboy. expect: does "Changing password for user astroboy.\r\n" (spawn_id exp4) match glob pattern "ssword:*"? no New UNIX password: expect: does "Changing password for user astroboy.\r\nNew UNIX password: " (spawn_id exp4) match glob pattern "ssword:*"? yes expect: set expect_out(0,string) "ssword: " expect: set expect_out(spawn_id) "exp4" expect: set expect_out(buffer) "Changing password for user astroboy.\r\nNew UNIX password: " **sending passwd once... send: sending "j1jd8%Mt\r" to { exp4 } **expect second passwd prompt... expect: does "" (spawn_id exp4) match glob pattern "ssword:*"? no expect: does "\r\n" (spawn_id exp4) match glob pattern "ssword:*"? no Retype new UNIX password: expect: does "\r\nRetype new UNIX password: " (spawn_id exp4) match glob pattern "ssword:*"? yes expect: set expect_out(0,string) "ssword: " expect: set expect_out(spawn_id) "exp4" expect: set expect_out(buffer) "\r\nRetype new UNIX password: " **sending passwd twice... send: sending "j1jd8%Mt\r" to { exp4 } **expecting eof ... expect: does "" (spawn_id exp4) match glob pattern "EOF"? no expect: does "\r\n" (spawn_id exp4) match glob pattern "EOF"? no passwd: all authentication tokens updated successfully. expect: does "\r\npasswd: all authentication tokens updated successfully.\r\n" (spawn_id exp4) match glob pattern "EOF"? no expect: read eof expect: set expect_out(spawn_id) "exp4" expect: set expect_out(buffer) "\r\npasswd: all authentication tokens updated successfully.\r\n" **wait for process... **finished wait for process... Additional info:
*** Bug 131366 has been marked as a duplicate of this bug. ***
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2005-526.html