Re: #!/usr/bin/env tclsh

Re: #!/usr/bin/env tclsh

[John Dallaway]

[ moving to ecos-maintainers list ]

Hi Jifl

Jonathan Larmour wrote:

> John Dallaway wrote:
>
>> This patch simplifies the #! magic used to invoke Tcl scripts by using
>> "/usr/bin/env tclsh" to find the tclsh executable. Very old Cygwin
>> installations providing only tclsh83.exe or cygtclsh80.exe are no-longer
>> supported. Checked-in.
> 
> Can you please refrain from further non-trivial changes until you have a
> copyright assignment.

I do not consider these changes to be copyrightable. Simplification of
the #! magic for Tcl scripts is more trivial in nature than the
documentation references I added late last year which we agreed were not
copyrightable. What aspect of these changes do you consider to be
copyrightable?

John Dallaway

Re: #!/usr/bin/env tclsh

[Jonathan Larmour]

John Dallaway wrote:
> [ moving to ecos-maintainers list ]
> 
> Hi Jifl
> 
> Jonathan Larmour wrote:
> 
>> John Dallaway wrote:
>>
>>> This patch simplifies the #! magic used to invoke Tcl scripts by using
>>> "/usr/bin/env tclsh" to find the tclsh executable. Very old Cygwin
>>> installations providing only tclsh83.exe or cygtclsh80.exe are no-longer
>>> supported. Checked-in.
>> Can you please refrain from further non-trivial changes until you have a
>> copyright assignment.
> 
> I do not consider these changes to be copyrightable. Simplification of
> the #! magic for Tcl scripts is more trivial in nature than the
> documentation references I added late last year which we agreed were not
> copyrightable.

Actually you stated that, I did not. I said "probably" and said it was very
much thin ice. I was not happy about it. And I asked you to include those
on the assignment request regardless. This is why I did not ask you to
revert the patch - with a random net contributor I would have.

> What aspect of these changes do you consider to be copyrightable?

It's sailing close to the wind. IANAL and I don't want to need to talk to
one, so under the principle of keeping it simple I have a preference for
19k patches not going in without assignment, for the sake of waiting a very
short time. That's why I was asking for no more, rather than asking you to
revert it.

Thinking about it, resubmitting the assignment request form is probably
OTT. The FSF does not include this information on the assignment itself
IIRC: but they do keep records of the information for legal reasons. So
maybe it is adequate to simply inform assign (AT) fsf.org of the extra
files. If you can do that, I'd be happy. But still hold back on anything
non-trivial in the (unlikely) event they aren't happy.

Jifl
-- 
eCosCentric Limited      http://www.eCosCentric.com/     The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.       Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.
------["Si fractum non sit, noli id reficere"]------       Opinions==mine

Re: #!/usr/bin/env tclsh

[Bart Veer]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1746 bytes --]

>>>>> "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).
   
Bart

-- 
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

Re: #!/usr/bin/env tclsh

[Gary Thomas]

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
------------------------------------------------------------

Re: #!/usr/bin/env tclsh

[Bart Veer]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3466 bytes --]

>>>>> "Gary" == Gary Thomas <gary@mlbassoc.com> writes:

    Gary> 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).

    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

-- 
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

Re: #!/usr/bin/env tclsh

[John Dallaway]

Hi Bart and Gary

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.

Good catch.

> 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
proposal?

If we can agree on this, I am happy to identify and implement these changes.

John Dallaway

Re: #!/usr/bin/env tclsh

[Gary Thomas]

John Dallaway wrote:
> Hi Bart and Gary
> 
> 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.
> 
> Good catch.
> 
>> 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
> proposal?
> 
> If we can agree on this, I am happy to identify and implement these changes.

Sure - whatever it takes to make it work [again].  Too bad "sh"
is being too "smart" about this...


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