* Re: #!/usr/bin/env tclsh
[not found] ` <49663810.3010202@eCosCentric.com>
@ 2009-01-08 17:51 ` John Dallaway
2009-01-08 18:21 ` Jonathan Larmour
0 siblings, 1 reply; 7+ messages in thread
From: John Dallaway @ 2009-01-08 17:51 UTC (permalink / raw)
To: Jonathan Larmour; +Cc: ecos-maintainers
[ 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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: #!/usr/bin/env tclsh
2009-01-08 17:51 ` #!/usr/bin/env tclsh John Dallaway
@ 2009-01-08 18:21 ` Jonathan Larmour
0 siblings, 0 replies; 7+ messages in thread
From: Jonathan Larmour @ 2009-01-08 18:21 UTC (permalink / raw)
To: John Dallaway; +Cc: ecos-maintainers
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: #!/usr/bin/env tclsh
[not found] <496635B7.8060808@dallaway.org.uk>
[not found] ` <49663810.3010202@eCosCentric.com>
@ 2009-02-06 12:24 ` Bart Veer
2009-02-06 12:38 ` Gary Thomas
2009-02-06 13:49 ` John Dallaway
1 sibling, 2 replies; 7+ messages in thread
From: Bart Veer @ 2009-02-06 12:24 UTC (permalink / raw)
To: John Dallaway; +Cc: ecos-maintainers
[-- 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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: #!/usr/bin/env tclsh
2009-02-06 12:24 ` Bart Veer
@ 2009-02-06 12:38 ` Gary Thomas
2009-02-06 12:53 ` Bart Veer
2009-02-06 13:49 ` John Dallaway
1 sibling, 1 reply; 7+ messages in thread
From: Gary Thomas @ 2009-02-06 12:38 UTC (permalink / raw)
To: Bart Veer; +Cc: John Dallaway, ecos-maintainers
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
------------------------------------------------------------
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: #!/usr/bin/env tclsh
2009-02-06 12:38 ` Gary Thomas
@ 2009-02-06 12:53 ` Bart Veer
0 siblings, 0 replies; 7+ messages in thread
From: Bart Veer @ 2009-02-06 12:53 UTC (permalink / raw)
To: Gary Thomas; +Cc: john, ecos-maintainers
[-- 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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: #!/usr/bin/env tclsh
2009-02-06 12:24 ` Bart Veer
2009-02-06 12:38 ` Gary Thomas
@ 2009-02-06 13:49 ` John Dallaway
2009-02-06 14:03 ` Gary Thomas
1 sibling, 1 reply; 7+ messages in thread
From: John Dallaway @ 2009-02-06 13:49 UTC (permalink / raw)
To: Bart Veer, Gary Thomas; +Cc: ecos-maintainers
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: #!/usr/bin/env tclsh
2009-02-06 13:49 ` John Dallaway
@ 2009-02-06 14:03 ` Gary Thomas
0 siblings, 0 replies; 7+ messages in thread
From: Gary Thomas @ 2009-02-06 14:03 UTC (permalink / raw)
To: John Dallaway; +Cc: Bart Veer, ecos-maintainers
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
------------------------------------------------------------
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2009-02-06 14:03 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <496635B7.8060808@dallaway.org.uk>
[not found] ` <49663810.3010202@eCosCentric.com>
2009-01-08 17:51 ` #!/usr/bin/env tclsh John Dallaway
2009-01-08 18:21 ` Jonathan Larmour
2009-02-06 12:24 ` Bart Veer
2009-02-06 12:38 ` Gary Thomas
2009-02-06 12:53 ` Bart Veer
2009-02-06 13:49 ` John Dallaway
2009-02-06 14:03 ` Gary Thomas
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).