This is the mail archive of the mailing list for the eCos project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: #!/usr/bin/env tclsh

>>>>> "Gary" == Gary Thomas <> writes:

    Gary> Bart Veer wrote:
    >>>>>>> "John" == John Dallaway <> 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).

    Gary> Why isn't this working? According to 'man sh' on my Linux
    Gary> system:
    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
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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]