This is the mail archive of the
mailing list for the eCos project.
Re: #!/usr/bin/env tclsh
- From: John Dallaway <john at dallaway dot org dot uk>
- To: Bart Veer <bartv at ecoscentric dot com>, Gary Thomas <gary at mlbassoc dot com>
- Cc: ecos-maintainers at ecos dot sourceware dot org
- Date: Fri, 06 Feb 2009 13:49:31 +0000
- Subject: Re: #!/usr/bin/env tclsh
- References: <496635B7.firstname.lastname@example.org> <email@example.com>
Hi Bart and Gary
Bart Veer wrote:
>>>>>> "John" == John Dallaway <firstname.lastname@example.org> 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).
Option 2 presents problems with CVS checkouts of the eCos repository
where execute permissions on the various Tcl scripts cannot be assumed.
I agree with Bart that invoking "/usr/bin/env tclsh" within the various
CDL custom rules doesn't gain us anything. It seems entirely reasonable
to assume that tclsh is on the PATH and users will get an intelligible
error message if it is not. In the case of heapgen.tcl, I simply
modified the custom make rule to invoke "tclsh" rather than "sh" and I
suggest we do the same with the other scripts. Are you OK with this
If we can agree on this, I am happy to identify and implement these changes.