Hi, I'm the maintainer of the expect package in OpenMandriva. While I don't have the time to take over maintainership of expect properly, I would certainly volunteer to get an expect 5.46 release out of the door that essentially does what we have in our package already: Tcl 9.0 support, support for newer compilers (without needing -fpermissive), and a few assorted bugfixes.
Expect package is not thread safe
Anyone interested in maintainership is most welcome to take over. I'm unfortunately not a daily expect user for many years now and not dependent on it, so I'm really not suitable. Also my family has expanded since I took over and little free time is spent on programming these days!
This is fixed in the contributed 5.45.4.1 version linked from the Tcl 9.0 porting page at https://wiki.tcl-lang.org/page/Porting+extensions+to+Tcl+9 -- which also works with Tcl 9.0.
FYI: the released version 5.45.4 of Expect does not work with the newly-released Tcl 9.0. There is a contributed port mentioned on the 9.0 porting page (https://wiki.tcl-lang.org/page/Porting+extensions+to+Tcl+9), which as of 2024-12 can be obtained from https://www.tcl3d.org/bawt/download/InputLibs/expect-5.45.4.1.7z The porting page says that it doesn't work with GCC 14.x, but if you configure it with CFLAGS including -fpermissive, it does.
Heuristic for distinguishing Expect files from other files that might use the '*.exp' file extension
The GNU Toolchain (GCC, GDB, binutils) still relies heavily on expect for its various testsuites, so it would be a huge problem for the project if expect were to be EOL-ed...
Allow cross-compiling
I agree. This is on my to-do list, I'm afraid I've very much neglected expect since covid.
And another fix for exp_chan.c. This ports expect to the current channel code (I hope).
move VCS to git
The previous strace output was missing spawned threads, here is a more complete one: [ 3166] open(0xffffffff, "/dev/tty", O_RDWR, 0x0) = 0x3 (30 us) [ 3166] ioctl(0x3, TCGETA, 0x1c322f83560, 0x0) = 0x0 No error (16 us) [ 3166] ioctl(0x3, TIOCGWINSZ, 0x1c322f83170, 0xd40ccc888c) = 0x0 No error (14 us) [ 3166] ioctl(0x0, TCGETA, 0x7f60df9cf360, 0x20) = 0x0 No error (14 us) [ 3166] ioctl(0x1, TCGETA, 0x7f60df9cf360, 0x20) = 0x0 No error (13 us) [ 3166] ioctl(0x0, TCGETA, 0x7f60df9cf340, 0x20) = 0x0...
I have now fixed that bug: closing the pty was not unblocking poll()/select() waiting for read events on the other side of it. However, that didn't help: expect is still not noticing when the pty is closed by the child exiting.
I have made some testing of PTY behavior in Haiku and I think I found a bug: https://dev.haiku-os.org/ticket/18486 However, I am not sure where in expect or in tcl this would come into play, as I didn't find an use of select or poll (probably I just missed it because I don't know where to look).
The PTY system is configured to use openpty and should behave similarly to the BSDs, but of course, there could be bugs. It seems to be working except for the end of file detection. For example if I do: spawn echo hi expect hi This is working fine. Yes, we have strace. Here is the trace on Haiku: [ 3199] open(0xffffffff, "/dev/tty", O_RDWR, 0x0) = 0x3 (31 us) [ 3199] ioctl(0x3, TCGETA, 0x1491b524560, 0x0) = 0x0 No error (14 us) [ 3199] ioctl(0x3, TIOCGWINSZ, 0x1491b524170, 0x1d907acf8bc) = 0x0 No...
Tcl's channel system will use Expect's input handler (ExpInputProc in exp_chan.c) so verify whether ExpInputProc is even being called. The input handler basically just does a read() which should return immediately IF the pty has been properly configured. Pty misconfiguration is the most likely issue for a new port since every OS loves to have its own pty variant. Verify that configure is choosing the right implementation. If there is no right implementation, might require a comparison of other's...
Hi, Normally (on Linux) the best way to debug these sorts of issues are with strace. I don't know if something similar is available on Haiku? Regards, Nils On 30 June 2023 at 22:49:22 +02:00, Adrien Destugues pulkomandy@users.sourceforge.net wrote: [support-requests:#8] https://sourceforge.net/p/expect/support-requests/8/ Expect on Haiku fails to wait for end of file Status: open Group: Created: Fri Jun 30, 2023 08:49 PM UTC by Adrien Destugues Last Updated: Fri Jun 30, 2023 08:49 PM UTC Owner: nobody...
Expect on Haiku fails to wait for end of file
Additional changes are required in the configure script. I'm attaching what we will be using in Fedora.
Fix build with clang 15+
Outdated config.guess file cannot recognize riscv64 platform
I'm not doing expect maintenance any more but I can offer some advice: The reasons to include Tcl's internal headers were largely for the Tcl debugger (not an essential tool - can simply be deleted) and to use Expect as a standalone C library (skip it - it's not needed to run Expect). Regarding the use of "open" as a function, Expect itself calls the system open(). Expect does not have its own open().
We have patches to add support for MirBSD and DragonFly, and now SCO/SVR5. The build system seems to do different things per platform (lib naming), and in pkgsrc that's a bug. There's no static lib and the dynamic lib doesn't have the normal naming (with a major/minor version). We have a workaround for deadlocks on solaris and linux. The code uses "open" as a procedure name which fails on SVR5 (and is dodgy anyway as shadowing is at best boggling). pkgsrc is stable, but these should be applied upstream,...
Hi, This is unfortunately largely true - I will contact the tcl community and discuss the way forward - I have no time to work on expect any longer - and after a job switch no professional use for it. This makes my maintainer role less than ideal - I have a bunch of unreleased bug fixes though which I hope to push. Let me know if there's anything specific you're missing. Also - with large scale refactoring ongoing for tcl 9 expect is in a difficult situation - it relies on internal TCL headers. Cheers,...
expect appears to be unmaintained
This works in 5.45, fails in 5.45.4.
stty returns 0 rows and columns on Apple M1
I'm trying to build expect from the 5.45.4 sources for an ARM Linux target. I've got TCL v8.6.11 building fine for said target, but am getting errors when configuring expect. It indicates: checking if WNOHANG requires _POSIX_SOURCE... configure: error: Expect can't be cross compiled In searching the net I found a couple references to this issue, but links were to old posts which I couldn't retrieve. Anyone have any suggestions?
Correction: Not another version of tclsh but rather a script called tclsh which does something unexpected. If the irregular tclsh occurs in PATH, prior to /usr/bin/tclsh then something unexpected may occur. The remedy, I still think, is to call /usr/bin/tclsh rather than tclsh
unbuffer may be incompatible with other versions of tclsh in PATH
[PATCH] fix fd leak
Applied the second one - but changed the #elsepu to #else. Thank you.
In principle it looks good - except why do you use '#elsepu' and not '#else'?
There is a mistake in the previous version... This one should be better.
[PATCH] fix fd leak
CONST84 is deprecated, change to const
done. Thank you.
Fix most of compiler warnings (and some errors)
Applied! Thank you!
compling agains tcl8.7.a4 fails
I had a look at it, I'm unsure the patch fixes it. I will try to re-verify it again against the latest tcl.
any news about this issue?
CONST84 is deprecated, change to const
Hi All, Based on one of the topics posted here, i have designed my expect script to return the exit code but for some reason it keeps on running and doesnt exit at all I am using the below script to -get a file from the remote server -delete the file after the transfer is complete Below is the code written set timeout 30 set user [lindex $argv 0] set pass [lindex $argv 1] set host [lindex $argv 2] set remote_file [lindex $argv 3] set local_file [lindex $argv 4] set port [lindex $argv 5] if {$port...
Good day ! Help please can not understand what is the problem. On short messages, everything works fine. On a long message, the Match Buffer is rewritten and does not find “OK.” Then it falls off by timeout.
Program for libexpect match buffer overwrite!
libexpect match buffer overwrite!
It just returns exit code 0 when the interpreter finds syntax errors. So the following example has "set -e", but the script does not stop. I am afraid that unit-tests could not find the bug depending on how they are written. (Actually this happened in a production environment, an app calls the script) # cat ./foo.sh #!/bin/bash set -e expect -c " spawn \"wrong syntax\" " echo $? # ./foo.sh spawn wrong syntax couldn't execute "wrong syntax": no such file or directory while executing "spawn "wrong...
It just returns exit code 0 when the interpreter finds syntax errors. So the following example has "set -e", but the script does not stop. I am afraid that unit-tests could not find the bug depending on how they are written. (Actually this happened in a production environment, an app calls the script) foo.sh 1 2 3 4 5 6 7 8#!/bin/bash set -e expect -c " spawn \"wrong syntax\" " echo $? # ./foo.sh spawn wrong syntax couldn't execute "wrong syntax": no such file or directory while executing "spawn...
"Y$fr5dk" won't work unless you escape the $ with a \ like this: "Y\$fr5dk"
Fix for coping with 0 from Tcl_ReadChars()
Closing, should already be fixed by now.
Would installing to /usr/local/ on other Unix platforms work too? On Sun, Apr 15, 2018 at 2:58 PM, Nils Carlson pyssling@users.sourceforge.net wrote: I guess instrutions could be added to the web page, or we could try to autodect mac os x and change the default path. [bugs:#104] https://sourceforge.net/p/expect/bugs/104/ install fails on OS X 10.13* Status: open Group: Labels: install OS X Created: Fri Apr 13, 2018 10:54 PM UTC by Caleb Fujimori Last Updated: Fri Apr 13, 2018 10:54 PM UTC Owner:...
I guess instrutions could be added to the web page, or we could try to autodect mac os x and change the default path.
install fails on OS X 10.13
Hi Matt, I'll try to have a look at this over the coming days. Cheers, Nils
trap command affecting return values regardless of -code flag
It is definitely a router thing. I have tried escaping the bracket but it just wont thru an expect script. I can ssh into the router and issue the command directly with no problems.
Ok, I've managed to sort of reproduce this. expect eats up available memory, but actually seems to manage steady memory use if forced to do so by putting it in a cgroup. I will have a look at the patch tomorrow I hope. I see it involves refcounts which is a tricky area. Cheers, Nils
expect memory leak by using -re
Hi, sorry for the delay. I'm looking into this now.
Hi James, I tried modifying the script to run "echo" instead of the /user command. This produced the intended output. Is it possible this is an issue with the router perhaps? It could be that ] is a sensitive character. Sometimes these constitute an escape sequence.
I have a script that we are trying to use to change passwords on Mikrotik routers. I have the password we use contains a right bracket and when the script is run everything from the right bracket on gets left off. 1 2 3 4 5 6 7 8 9 10 11 12#!/usr/bin/expect set user "jamesc" set password "password" set ipaddr [lindex $argv 0] set sshport 22210 set date [clock format [clock seconds] -format {%Y-%m-%d}] set newpass "lan3\+\]2081" spawn ssh $user@$ipaddr -p $sshport "/user set 0 password=$newpass" expect...
Any possibility of getting this issue resolved? I cannot attest that gate_patch is correct, but it solves the immediate problem I have when running a long-running -re-heavy process under expect. As it stands I have to cap the process's memory and restart it when it takes up too much, which is irritating, to say the least. Thanks. --nwf;
Please add a tag and a downloadable file for version 5.45.3
Done.
expIRead misinterprets "0 bytes read" as EOF
Fixed in 5.45.3 .
This is great, thanks again!
interact mistakes Tcl_InputBlocked for EOF
This is now fixed in the expect 5.45.4 release.
Another fix for the EOF processing bug
This is now fixed in expect 5.45.4 . Thanks a bundle, will try to add testing for these cases in not too long.
Awesome, thank you!
Hi, thank you for the patch. I will try to create a release witht he fix during this weekend once I have verified it.
interact mistakes Tcl_InputBlocked for EOF
Hello to all, Here is the issue - I have a perl script that builds an expect script that spawns an ssh sesion on a number of different servers - after ssh a script is run that builds stuff from dbs. Here is the issue: This script runs perfectly about 90% of the time - spawns the session, runs the script and we are all happy campers. Then out of the blue it decides to only run on 2 servers of three. When we kill the master job that does the spawing it again runs on all the servers. the basic script...
Another fix for the EOF processing bug
I found a command to directly scp my file to a host (C) via another host (B) from my computer. The command is in this form: scp -oProxyCommand="ssh -W %h:%p B" thefile C:destination I used it and it works good in command line. but when I want to write an expect script using this command, I got some errors. the script I've written is in this form: 1 2 3 4 5 6 7#!/usr/bin/expect set arg1 [lindex $argv 0] spawn scp -oProxyCommand="ssh -W %h:%p B" ./$arg1 C:destination interact and the error is: unknown...
I found a command to directly scp my file to a host (C) via another host (B) from my computer. The command is in this form: scp -oProxyCommand="ssh -W %h:%p B" thefile C:destination I used it and it works good in command line. but when I want to write an expect script using this command, I got some errors. the script I've written is in this form: 1 2 3 4 5 6 7#!/usr/bin/expect set arg1 [lindex $argv 0] spawn scp -oProxyCommand="ssh -W %h:%p B" ./$arg1 C:destination interact and the error is: unknown...
Using tclsh & expect with binary data. Here is a test program xxx.tcl from my real...
It was a choice made for efficiency rather than elegance, sorry. It didn't seem worth...
Thanks Don for the quick response. I did not know you are still working on Expect....
You can complain about the design but it's not a bug. That behavior is documented....
expect_out(N,string) should be reset first when matching against new patterns