Opened 13 years ago

Closed 12 years ago

Last modified 12 years ago

#31225 closed defect (fixed)

expect: mkpasswd: can't find package Expect

Reported by: arnaud.fortier@… Owned by: markd@…
Priority: Normal Milestone:
Component: ports Version: 2.0.3
Keywords: Cc: yvon.thoraval@…, kobayos@…, ryandesign (Ryan Carsten Schmidt)
Port: expect

Description

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

Attachments (1)

mkpasswd.patch (320 bytes) - added by kobayos@… 12 years ago.

Download all attachments as: .zip

Change History (9)

comment:1 Changed 13 years ago by mf2k (Frank Schima)

Keywords: expect mkpasswd removed
Milestone: MacPorts 2.0.4
Owner: changed from macports-tickets@… to markd@…

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

comment:2 Changed 13 years ago by ryandesign (Ryan Carsten Schmidt)

Summary: Problem with expectexpect: mkpasswd: can't find package Expect

comment:3 Changed 12 years ago by ryandesign (Ryan Carsten Schmidt)

Cc: yvon.thoraval@… added

The same was reported on the mailing list about autoexpect.

comment:4 Changed 12 years ago by 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.

comment:5 Changed 12 years ago by 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

Changed 12 years ago by kobayos@…

Attachment: mkpasswd.patch added

comment:6 Changed 12 years ago by 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.

comment:7 Changed 12 years ago by ryandesign (Ryan Carsten Schmidt)

Cc: kobayos@… ryandesign@… added
Resolution: fixed
Status: newclosed

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.

comment:8 in reply to:  7 Changed 12 years ago by 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.

Note: See TracTickets for help on using tickets.