The new way of packaging up an Expect script...

[Kenny McCormack]

In the old days, we wrote expect scripts like this:

#!/usr/bin/expect --
# ...

And I still do.

But, nowadays, the scripts that come with Expect, such as "autoexpect"
start out like this:

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

package require Expect
# ...
--- Cut Here ---

So, is there any particular reason for this change?
And, going a little deeper, is that any good reason why I should change to
the new format?

Note: I am *NOT* looking for help about how/why this bit of trickery works.
I got that.

I just don't see the point of it. How/why is it any better than the old
way?

--
The randomly chosen signature file that would have appeared here is more than 4
lines long. As such, it violates one or more Usenet RFCs. In order to remain
in compliance with said RFCs, the actual sig can be found at the following URL:
http://user.xmission.com/~gazelle/Sigs/IceCream

[Rich]

Kenny McCormack <gaz...@shell.xmission.com> wrote:
> In the old days, we wrote expect scripts like this:
>
> #!/usr/bin/expect --

This version depends upon expect residing exactly at /usr/bin/expect.

If every system you deploy to follows this standard, you have no reason
to change.

> But, nowadays, the scripts that come with Expect, such as "autoexpect"
> start out like this:
>
> --- Cut Here ---
> #!/bin/sh
> # -*- tcl -*-
> # The next line is executed by /bin/sh, but not tcl \
> exec tclsh8.6 "$0" ${1+"$@"}

This version relies only upon sh residing exactly at /bin/sh (which,
IIRC, is dictated by POSIX), so you can reasonably safely assume "sh"
is at /bin/sh. It then relies on /bin/sh searching your PATH to find
the tclsh interpreter, making the actual location of the interpreter
not relevant to the script being run.

> So, is there any particular reason for this change?

Yes, see above. One is hard coded to a fixed location, the other
relies on searching the system defined PATH. And as long as tclsh is
in a directory on the PATH, the second will find it and launch it.

> And, going a little deeper, is that any good reason why I should
> change to the new format?

If you expect your script to work in any random Unix like system,
without editing by the person using it, then the second version is
better.

> I just don't see the point of it. How/why is it any better than the old
> way?

tclsh can be anywhere the admin/distribution wants to place it, and as
long as the PATH points there, #2 will work.

#1 will fail (unless edited) if an admin chooses to place expect into
/usr/local/bin/expect

Full disclosure: I usually just use the #!/usr/bin/[tclsh|wish] variant
as the lead in for my scripts, as all the systems where I expect them
to be run have tclsh/wish located there.

[Kenny McCormack]

In article <s4nng4$ame$1...@dont-email.me>, Rich <ri...@example.invalid> wrote:
>Kenny McCormack <gaz...@shell.xmission.com> wrote:
>> In the old days, we wrote expect scripts like this:
>>
>> #!/usr/bin/expect --
>
>This version depends upon expect residing exactly at /usr/bin/expect.
>
>If every system you deploy to follows this standard, you have no reason
>to change.

Thank you. Your response was quite informative.

--
"I have a simple philosophy. Fill what's empty. Empty what's full. And
scratch where it itches."

Alice Roosevelt Longworth