This is the mail archive of the
mailing list for the eCos project.
Re: #!/usr/bin/env tclsh
- From: Bart Veer <bartv at ecoscentric dot com>
- To: Gary Thomas <gary at mlbassoc dot com>
- Cc: john at dallaway dot org dot uk, ecos-maintainers at ecos dot sourceware dot org
- Date: Fri, 06 Feb 2009 12:53:29 +0000
- Subject: Re: #!/usr/bin/env tclsh
- References: <496635B7.email@example.com> <firstname.lastname@example.org> <498C2F1E.email@example.com>
>>>>> "Gary" == Gary Thomas <firstname.lastname@example.org> writes:
Gary> Bart Veer wrote:
>>>>>>> "John" == John Dallaway <email@example.com> 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.
>> 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).
Gary> Why isn't this working? According to 'man sh' on my Linux
Gary> If the program is a file beginning with #!, the
Gary> remainder of the first line specifies an interpreter
Gary> for the program. The shell executes the specified
Gary> interpreter on operating systems that do not han- dle
Gary> this executable format themselves. The arguments to
Gary> the interpreter consist of a single optional argument
Gary> following the interpreter name on the first line of
Gary> the program, followed by the name of the program,
Gary> followed by the command arguments, if any.
Gary> It would seem that since Linux *does* handle this directly, 'sh'
Gary> chooses to ignore it :-(
If you run 'sh xx' instead of just 'xx', is 'xx' still a "program" by
the above definition is or is it just data for sh? I don't know the
official answer, but it appears that Linux sh treats it as just data.
Gary> In any case, I vote for (2), otherwise you may end up with
Gary> the same problem all of this was trying to fix in the first
Gary> place, namely not knowing where/how to find 'tclsh'
Hence the "/usr/bin/env tclsh" in the CDL script as opposed to just
"tclsh". Although come to think of it, I am not sure that gains
anything. Either make (or the shell invoked by make) or the env
utility will end up searching PATH for tclsh.
Bart Veer eCos Configuration Architect
eCosCentric Limited The eCos experts http://www.ecoscentric.com/
Barnwell House, Barnwell Drive, Cambridge, UK. Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.
Besuchen Sie uns vom 3.-5.03.09 auf der Embedded World 2009, Stand 11-300
Visit us at Embedded World 2009, Nürnberg, Germany, 3-5 Mar, Stand 11-300