expect: mkpasswd: can't find package Expect

[arnaud.fortier@…]

Hi,

I need the mkpasswd software for scripting purpose. I did a port install expect in order to have it. Everything went fine for the installation. However, now, when I launche mkpasswd I got:

$ mkpasswd
can't find package Expect
    while executing
"package require Expect"
    (file "/opt/local/bin/mkpasswd" line 6)

Line 6 of mkpasswd:

package require Expect

What should I do to make it work. The path are correct I can even launch expect from the command line.

Best regards,

Arnaud

[mf2k (Frank Schima)]

In the future, please Cc the maintainer(s) and don't set the Milestone field.

[ryandesign (Ryan Carsten Schmidt)]

The same was ​reported on the mailing list about autoexpect.

[markd@…]

So the problem is that this starts autoexpect fine: 'expect /opt/local/bin/autoexpect'

whereas neither of these methods works:

'expect autoexpect' expect1.1> 'autoexpect' (the latter from within expect)

Is that correct? I don't know the reason, but maybe there is a developer mailing list where this could be reported.

[arnaud.fortier@…]

As on the mailing list, upgrading ports (includes a new version ogf tcl/expect) doesn't do the trick :( It was working "before", at least 1 year ago I installed this program and never updated ports and it was working without problems

[kobayos@…]

I experienced the same problem.

Currently mkpasswd looks woking file by tentatively using system tclsh instead of the tclsh of Macports. Please find an attached patch file for mkpasswd.

[ryandesign (Ryan Carsten Schmidt)]

I'm not sure why this problem occurs when running with the MacPorts tclsh, but I don't think we want to "fix" it by using the system tclsh, for all the usual reasons why we don't want to use system components.

Based on the above information that loading the script directly into expect (rather than running it through tclsh) works, I decided the fix would be to modify the scripts' shebang (#!) lines to reference /opt/local/bin/expect directly. It was then that I discovered that the scripts' shebang lines are rather convoluted:

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

This means the script is initially run with sh, and is then relaunched with tclsh. I don't understand why this song and dance is performed, so I patched each of the scripts to just call expect directly, tried a few of the scripts and verified that they no longer exhibit this problem, and committed it as r92644.

It was only after committing this that I realized that during the destroot process some of the scripts' shebang lines got transformed again, now looking like:

#!/bin/sh
# \
exec expect "$0" ${1+"$@"}

I don't know where in the destroot process that's happening, and I didn't intend for that to happen. It's not really a problem though, unless the user doesn't have /opt/local/bin in their $PATH, so I'm not too concerned about it.

Note that these changes basically undo the fix for ​this ten-year-old upstream bug. It only affected users who don't actually have a binary called "expect", and that's not the case in MacPorts, so it should be ok for us.

[ryandesign (Ryan Carsten Schmidt)]

Replying to ryandesign@…:

I don't know where in the destroot process that's happening, and I didn't intend for that to happen. It's not really a problem though, unless the user doesn't have /opt/local/bin in their $PATH, so I'm not too concerned about it.

Note that these changes basically undo the fix for ​this ten-year-old upstream bug. It only affected users who don't actually have a binary called "expect", and that's not the case in MacPorts, so it should be ok for us.

Reading the upstream bug report more closely, I now realize it's their "fixline1" script that's doing this.