I find the "unbuffer" command very important and useful, because I am running python code, and I don't think I can just put something equivalent to fflush() everywhere.

I used to use it just fine: unbuffer python foo.py | tee filename.log

A few months ago, I'm not sure if I had allowed my Ubuntu 16.04 to auto update some software, and it stopped working.

$ unbuffer
can't find package Expect
    while executing
"package require Expect"
    (file "/usr/bin/unbuffer" line 6)

I tried editing some files and changing Expect to lower case expect but it didn't work.

I tried (months ago) using apt-get tools to uninstall and reinstall Expect, but to no avail. I'm surprised I can't google this and find others complaining about it not working.

I just tried it on a friend's 18.04 Ubuntu. He has never used it, he downloaded it with apt-get and gets the same failure message. Any help appreciated.

Thanks @pynexj for the suggestion to cat /usr/bin/unbuffer:

# -*- tcl -*-
# The next line is executed by /bin/sh, but not tcl \
exec tclsh8.6 "$0" ${1+"$@"}

package require expect

# -*- tcl -*-
# Description: unbuffer stdout of a program
# Author: Don Libes, NIST

if {[string compare [lindex $argv 0] "-p"] == 0} {
    # pipeline
    set stty_init "-echo"
    eval [list spawn -noecho] [lrange $argv 1 end]
    close_on_eof -i $user_spawn_id 0
    interact {
    eof {
        # flush remaining output from child
        expect -timeout 1 -re .+
} else {
    set stty_init "-opost"
    set timeout -1
    eval [list spawn -noecho] $argv
    exit [lindex [wait] 3]

I have been using conda on this machine, but I'm running these tests in a terminal where I have not done any source activate. The first item in my path is /home/myusername/anaconda3/bin , if that matters.

$ apt list --installed | grep -i expect

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

expect/xenial,now 5.45-7 amd64 [installed]
python3-pexpect/xenial,xenial,now 4.0.1-1 all [installed]
tcl-expect/xenial,now 5.45-7 amd64 [installed,automatic]

$ locate '*expect*pkgIndex.tcl'

Thanks @glenn jackman, I found that my tclsh is in ~/anaconda3/bin/tclsh and points to tclsh8.6 I guess this means it was installed as part of my conda installation. As noted above, anaconda3/bin is at the top of my PATH. I haven't built anything myself.

Do we know if 8.6 is old or new? Should I try to do a apt-get update on tcl or tclsh, outside of conda stuff, and see if that helps?

  • 1
    just updated 18.04 and it works fine for me. could u cat /usr/bin/unbuffer? – pynexj Jun 19 '18 at 15:52
  • what does apt list --installed | grep -i expect show you? – glenn jackman Jun 20 '18 at 15:16
  • also: locate '*expect*pkgIndex.tcl' -- that file determines if you have to package require Expect or expect – glenn jackman Jun 20 '18 at 15:26
  • also, your tcl 8.6, is that installed through apt or did you build it yourself? – glenn jackman Jun 20 '18 at 15:27

I believe to have bumped into the exact same problem, primarily caused by the installation of Anaconda. Looks like my system was turning to what Anaconda brought with itself, rather than what had been installed ages ago - and otherwise still present.

In accordance with https://anaconda.org/Eumetsat/expect, I only needed to issue a

conda install -c eumetsat expect

to get things back in order.

| improve this answer | |
  • 1
    Thank you - I don't fully understand the details, but it worked with a quick test. I do make use of Anaconda, although I was using it before when unbuffer worked. It is quite possible that I did a "conda update conda" and other conda operations around the time that it stopped working. Are you able to tell me what Eumetsat is, and how it relates to Anaconda? Does it give me a different version of expect somehow? – Starman Oct 18 '18 at 21:50
  • Hello! Sorry for the late reply! I guess I was just trying to look up Expect in the Anaconda repository after a lucky suspicion of that one being the bad guy (maybe I saw an example of the same thing happening earlier). Then it's easy: google.com/… – brezniczky Feb 4 at 2:50
  • In my imagination Anaconda (I really don't know much about it) is otherwise somewhat like an R repository (CRAN, Bioconductor, others?), a composition of packages from multiple contributors (including individuals, organisations - profit, non-profit etc.). I guess sometimes they keep their own interests in mind when picking what to maintain (and host?). Sometimes I believe they even overlap in responsibilities (I indeed remember seeing at least one example of that, I believe the two hosted two different versions (!) which can cause a lot of problems but let's generally hope for the best :) ) – brezniczky Feb 4 at 2:53
  • Then I guess yes, you're right - since Anaconda seems to fiercely defend the compatibility (and consistency - later) of its locally installed packages by shielding away the system installations, however useful they'd be, these packages are treated effectively more or less as, in your words, different versions from anything on the system. Sticking to exact version(s) is also a strong point in reproducibility, tieing analytical results to specific software/package version(s) helps with verification by the peers and those trying to continue on the work. This should pave the way there. – brezniczky Feb 4 at 3:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.