Re: #!/usr/bin/env tclsh

[Gary Thomas <gary@mlbassoc.com>]

Bart Veer wrote:
>>>>>> "John" == John Dallaway <john@dallaway.org.uk> writes:
> 
>     John> This patch simplifies the #! magic used to invoke Tcl
>     John> scripts by using "/usr/bin/env tclsh" to find the tclsh
>     John> executable. Very old Cygwin installations providing only
>     John> tclsh83.exe or cygtclsh80.exe are no-longer supported.
>     John> Checked-in.
> 
> Actually, this patch has broken things in various ways. Consider e.g.
> file2c.tcl in the romfs package. The CDL invokes this using e.g.:
> 
>   sh file2c.tcl testromfs_le.bin testromfs_le.h
> 
> With the old magic this still worked fine because sh would ignore the
> #! at the start completely and move on to the 'exec sh -c' on line 3.
> With the new '#!/usr/bin/env tclsh' the sh invocation ignores the
> #! comment on line 1 so ends up trying to run the whole Tcl script as
> a shell script. Needless to say this is not very successful.
> 
> io/framebuf is similarly affected. services/memalloc/common is not. I
> have not yet checked all the other packages that use Tcl scripts.
> 
> Possible solutions are:
> 
> 1) revert the change
> 2) remove the 'sh' bits from the relevant CDL scripts, treating the
>    Tcl script as plain executables.
> 3) make the CDL invoke /usr/bin/env tclsh directly, treating the
>    Tcl scripts as Tcl scripts.
> 
> (1) would be a bad move. I think I would prefer (3) to (2).

Why isn't this working? According to 'man sh' on my Linux system:
       If the program is a file beginning with #!, the remainder of the first line specifies an  interpreter
       for  the program.  The shell executes the specified interpreter on operating systems that do not han-
       dle this executable format themselves.  The arguments to the interpreter consist of a single optional
       argument following the interpreter name on the first line of the program, followed by the name of the
       program, followed by the command arguments, if any.

It would seem that since Linux *does* handle this directly, 'sh'
chooses to ignore it :-(

In any case, I vote for (2), otherwise you may end up with the
same problem all of this was trying to fix in the first place,
namely not knowing where/how to find 'tclsh'


-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------