Silent overriding of the command?
Victor Wagner
name as existing core Tcl command doesn't produce an error.
I always have thought that in order to replace Tcl command with own
procedure one have to rename this command first.
This behavoir leads to obscure problem. For instance, user writes
procedure named "scan", thus overriding builtin scan command.
But Tk text widget support scripts use this command. They start to use
user version itself and fail miserably.
So,
Question one: Is there way to invoke Tcl core command regardless of what
user have messed up in global namespace, say using some special
namespace? ::tcl::scan doesn't work.
Question two: If there is such way, why Tk library procedures from
namespace Tk do not use it?
Question three: What is better to file as bug report - ability to
silently override core command or absense of way to call original
command?
--
Ulrich Schoebel
this is _not_ a Tcl 8.4 feature, it has always been so.
You only have to rename Tcl commands, if you want to use
the original command later on. So there is no bug to file.
Best regards
Ulrich
--
For those of you who don't get this e-mail, let me know and I'll re-send it.
Cameron Laird
Ulrich Schoebel <ulrich....@tclers.tk> wrote:
>Hi Victor,
>
>this is _not_ a Tcl 8.4 feature, it has always been so.
>You only have to rename Tcl commands, if you want to use
>the original command later on. So there is no bug to file.
.
.
True.
I know Victor's experienced with Tcl, and I wonder if there's some
deeper story afoot here. I've certainly heard others mention re-
lated needs--that their design requires, for example, a way to
"lock in" specific commands, so that they canNOT be overwritten.
I've never needed such in my own work ...
I suspect if I spent time, I could find "prior art" for a modified
[proc] that refuses to overwrite existing commands. It should only
take a dozen lines, in any case.
ALSO, note that recent (I'll not make the time now to research its
introduction) Tcl-s provide [trace] capabilities triggered on com-
mand modifications. That's the contemporary way to implement
solutions in this area.
--
Cameron Laird <cla...@phaseit.net>
Business: http://www.Phaseit.net
Bryan Oakley
>
> So,
> Question one: Is there way to invoke Tcl core command regardless of what
> user have messed up in global namespace, say using some special
> namespace? ::tcl::scan doesn't work.
No.
>
> Question two: If there is such way, why Tk library procedures from
> namespace Tk do not use it?
>
> Question three: What is better to file as bug report - ability to
> silently override core command or absense of way to call original
> command?
I'd say neither is a bug. It's just the way it is. If you don't like it
you can always rename and rewrite the proc command to first check that
the proc it is creating doesn't already exist as a command. Of course,
you'd also need to do that with the image command, and all the widget
commands too if you're really paranoid.
Victor Wagner
: I know Victor's experienced with Tcl, and I wonder if there's some
: deeper story afoot here. I've certainly heard others mention re-
Story is just simple:
Some novice user was caught in this trap - he wrote procedure named
"scan" in some Tk script and thus destroyed behavoir of Up/Down arrows
in text widget.
He wrote in Russian Tcl mailing list very complete report of this
problem.
It took me some time to track down cause of error. And this with my
eight years of Tcl experience and some more with full-time work in
softwore engineering.
Earlier today I've discovered that some new commands are available in Tk
8.4 (I forget to upgrade tk8.3-doc package to tk8.4-doc) also with
names which are quite easy to override, such as labelframe.
Now, I've just thought of how easy it is to not remember, or not know
that there is some core command with certain name, which is used in
standard library procedures. There are lot of them in the Tk and they
are quite complex.
You just call your procedure some obvois name, like scan or format, or
seek, and behold - behavoir of standard Tk widgets is broken.
Perl folk give some more thought to this problem. So they provided magic
namespace CORE::, which allows to call standard builtin command even
if user desired to override it in root namespace .
In Tcl such approach possibly would clash with interp alias mechanism,
which is essential for safe interpreters. But something simular is
desirable.
If people want to override behavoir of library routines, they would
override upper level, documented functions, or, in case of Tk, use bind
scripts.
So, it wouldn't harm anybody if internal calls from library scripts
would be explicitely made to core commands.
: I suspect if I spent time, I could find "prior art" for a modified
: [proc] that refuses to overwrite existing commands. It should only
: take a dozen lines, in any case.
Of course, Tcl makes it easy to protect from overriding commands in your
application. If I'd allow user scripting, I probably would use slave
interpreter for it.
But package authors are helpless in this situation. Command can be
overriden even before package, which depends on it, is loaded.
--
I think it's a new feature. Don't tell anyone it was an accident. :-)
-- Larry Wall on s/foo/bar/eieio in <10...@jpl-devvax.JPL.NASA.GOV>
Don Porter
> Question one: Is there way to invoke Tcl core command regardless of what
> user have messed up in global namespace, say using some special
> namespace? ::tcl::scan doesn't work.
As others have noted, this is the way Tcl's always been.
To speculate about an alternative world (Tcl 9 ?), if Tcl's built-in
commands were defined in the namespace ::tcl instead of the global
namespace ::, and were then [namespace import]ed into :: for the
same availability as currently, then one could redefine, say,
[::scan] as they like, while leaving [::tcl::scan] unmolested, and
available for calling by code the really, really, really, knows it
needs the original built-in command, and not any wrapper.
--
| Don Porter Mathematical and Computational Sciences Division |
| donald...@nist.gov Information Technology Laboratory |
| http://math.nist.gov/~DPorter/ NIST |
|______________________________________________________________________|
Jeff Hobbs
> Victor Wagner wrote:
>
>>Question one: Is there way to invoke Tcl core command regardless of what
>>user have messed up in global namespace, say using some special
>>namespace? ::tcl::scan doesn't work.
>
>
> As others have noted, this is the way Tcl's always been.
>
> To speculate about an alternative world (Tcl 9 ?), if Tcl's built-in
> commands were defined in the namespace ::tcl instead of the global
> namespace ::, and were then [namespace import]ed into :: for the
> same availability as currently, then one could redefine, say,
> [::scan] as they like, while leaving [::tcl::scan] unmolested, and
> available for calling by code the really, really, really, knows it
> needs the original built-in command, and not any wrapper.
I think that's an intriguing idea for Tcl 9, BTW.
--
Jeff Hobbs, The Tcl Guy
http://www.ActiveState.com/, a division of Sophos
km...@socrates.berkeley.edu
Of course, as someone else pointed out, you have to be careful
with safe interpreters and not exposing, say, [::tcl::exec].
Keith
Derk Gwen
# user have messed up in global namespace, say using some special
# namespace? ::tcl::scan doesn't work.
rename "scan" "::tcl::scan"
# Question three: What is better to file as bug report - ability to
# silently override core command or absense of way to call original
# command?
You can always silently override the rename command
rename rename ::tcl::rename
proc rename {cmd1 cmd2} {
if {[llength [info command $cmd2]]} {
error "command already exists: $cmd2"
}
::tcl::rename $cmd1 $cmd2
}
% proc xyz {} {puts xyz}
% xyz
xyz
% rename xyz pqr
% pqr
xyz
% xyz
invalid command name "xyz"
% rename xyz scan
command already exists: scan
% pqr
xyz
--
Derk Gwen http://derkgwen.250free.com/html/index.html
TEMPORARILY CLOSED
BE OPENED AFTER FIRST PERIOD
ulis
> Hi Victor,
>
> this is _not_ a Tcl 8.4 feature, it has always been so.
> You only have to rename Tcl commands, if you want to use
> the original command later on. So there is no bug to file.
>
> Best regards
>
> Ulrich
You're true Ulrich but I find your answer very short.
On this subject the feature and the doc agree. It's great.
But the subject is not close: The fact that this feature is sometimes
fooling matters.
To have features is great.
To have documented features is greater.
To have easy to use documented features would be... very, very, very
great. And very appealing for newcomers.
ulis
Aric Bills
talking about procs being overridden without preserving the original proc in
any way (preservation being the normal role of [rename]).
-Aric
Robert Seeger
standard init.tcl?
foreach command {scan puts ... other tcl core commands} {
rename $command ::tcl::$command
interp alias {} $command {} ::tcl::$command
}
This would make it so that extension writers could use ::tcl::command
to get the default behavior for various commands, even if someone
redefined them in the root namespace. The same could be done with
various Tk commands.
Robert Seeger
NOTE: Not much in the way of testing went into the above. Its possible
there's a good reason not to do that.
Don Porter
> Would it be worthwhile to add something like the following to the
> standard init.tcl?
>
> foreach command {scan puts ... other tcl core commands} {
> rename $command ::tcl::$command
> interp alias {} $command {} ::tcl::$command
> }
No. If/when we decide to make the change we should just do it.
Besides there are "issues" with [rename] of an [interp alias].
Search the Bug DB for more info.
Gerald Lester
> Victor Wagner wrote:
>
>>Question one: Is there way to invoke Tcl core command regardless of what
>>user have messed up in global namespace, say using some special
>>namespace? ::tcl::scan doesn't work.
>
> As others have noted, this is the way Tcl's always been.
>
> To speculate about an alternative world (Tcl 9 ?), if Tcl's built-in
> commands were defined in the namespace ::tcl instead of the global
> namespace ::, and were then [namespace import]ed into :: for the
> same availability as currently, then one could redefine, say,
> [::scan] as they like, while leaving [::tcl::scan] unmolested, and
> available for calling by code the really, really, really, knows it
> needs the original built-in command, and not any wrapper.
Don,
This just pushes the problem down a level unless you can also "lock" a command
so it can not be deleted/renamed/overridden.
In other words, what is to prevent someone from redefining ::tcl::scan.
Yes I understand your proposal makes it harder to accidentally shoot your leg
off -- but it does not stop you from doing so.
--
+--------------------------------+---------------------------------------+
| Gerald W. Lester | "The man who fights for his ideals is |
| Gerald...@cox.net | the man who is alive." -- Cervantes |
+--------------------------------+---------------------------------------+
Ulrich Schoebel
No, I don't think it's a good idea. It would only (unnecessarily)
complicate things and wouldn't provide anything you can't have now.
If you really want/need this behaviour, just create a tiny init script,
that creates aliases in ::tcl and redefines proc accordingly.
A change in the core would be a giant solution to a small, seldom
encountered and easy to master problem.
KISS
Ulrich
Bruce Hartweg
Gerald Lester wrote:
> Don Porter wrote:
>
>> Victor Wagner wrote:
>>
>>> Question one: Is there way to invoke Tcl core command regardless of what
>>> user have messed up in global namespace, say using some special
>>> namespace? ::tcl::scan doesn't work.
>>
>>
>> As others have noted, this is the way Tcl's always been.
>>
>> To speculate about an alternative world (Tcl 9 ?), if Tcl's built-in
>> commands were defined in the namespace ::tcl instead of the global
>> namespace ::, and were then [namespace import]ed into :: for the
>> same availability as currently, then one could redefine, say,
>> [::scan] as they like, while leaving [::tcl::scan] unmolested, and
>> available for calling by code the really, really, really, knows it
>> needs the original built-in command, and not any wrapper.
>
>
> Don,
>
> This just pushes the problem down a level unless you can also "lock" a
> command so it can not be deleted/renamed/overridden.
>
> In other words, what is to prevent someone from redefining ::tcl::scan.
>
> Yes I understand your proposal makes it harder to accidentally shoot
> your leg off -- but it does not stop you from doing so.
>
locking it would be a bad idea. for people who are intentionally
overriding commands and know what they are doing (i.e. make sure it
does what it is supposed to) it can be very useful and powerful.
even without the lock, the namespaced versions would be a pain, because
If I override scan because I *want* to & then some library uses the old
scan instead of my new improved version my app isn't behaving the way
*I* want it to.
Bruce
Ralf Fassel
| Question three: What is better to file as bug report - ability to
| silently override core command or absense of way to call original
| command?
[x] none of the above.
Introduce your users to the `namespace' concept and show them how to
define their procs in their own namespace. More typing for calling
the procs, yes.
R'
Don Porter
> In other words, what is to prevent someone from redefining ::tcl::scan.
> Yes I understand your proposal makes it harder to accidentally shoot your leg
> off -- but it does not stop you from doing so.
True. Tcl has a long history of keeping everything open to
introspection and revision. No private/public distinction among
commands.
If one really needs the security of a "locked-down" command, they can
get the illusion of it using [incr Tcl], and perhaps other packages
that offer a notion of "private" commands or methods.
For even more robust control over what code can do in terms of
modifying existing commands, a carefully crafted slave interpreter is
probably the best solution.
lvi...@yahoo.com
According to Bryan Oakley <br...@bitmover.com>:
:you can always rename and rewrite the proc command to first check that
:you'd also need to do that with the image command, and all the widget
:commands too if you're really paranoid.
I think that it would be really useful for those of us who find this
a useful topic to consider building a "protected tcl" and "protected tk"
set of extensions that one could package require to get the behavior we
discuss.
Of course, this still wouldn't help Victor's area of concern - code
written by j. average programmer which is unable to know whether the
"set" command they are executing is the core set or some nefarious or
accidentally modified version which will result in malfunctions of
software.
--
<URL: http://wiki.tcl.tk/ > In God we trust.
Even if explicitly stated to the contrary, nothing in this posting
should be construed as representing my employer's opinions.
<URL: mailto:lvi...@yahoo.com > <URL: http://www.purl.org/NET/lvirden/ >
lvi...@yahoo.com
According to Victor Wagner <vi...@45.free.net>:
:Cameron Laird <cla...@lairds.com> wrote:
:
:: I know Victor's experienced with Tcl, and I wonder if there's some
:: deeper story afoot here. I've certainly heard others mention re-
:
:Story is just simple:
:
:Some novice user was caught in this trap - he wrote procedure named
:"scan" in some Tk script and thus destroyed behavoir of Up/Down arrows
:in text widget.
I worry about the same things. However, if we train users from the beginning
to make use of namespaces, then the likelihood of such name collisions are
reduced.
Such collisions will be reduced even further once Tcl, Tk move to make
use of namespaces - many extensions (most?) do so now.
:In Tcl such approach possibly would clash with interp alias mechanism,
:which is essential for safe interpreters. But something simular is
:desirable.
And in fact, if tcl is embedded and taking arbitrary commands from the users,
the use of safe interpreters would probably be best, reducing even further
the kinds of collisions.
:But package authors are helpless in this situation. Command can be
:overriden even before package, which depends on it, is loaded.
On the other hand, if package authors had access to the direct core, then
programs like debuggers might not be able to interpose profiling, coverage
stats, and other things by way of careful renaming of the appropriate commands.
lvi...@yahoo.com
According to Ulrich Schoebel <ulrich....@tclers.tk>:
:If you really want/need this behaviour, just create a tiny init script,
:that creates aliases in ::tcl and redefines proc accordingly.
:A change in the core would be a giant solution to a small, seldom
:encountered and easy to master problem.
Alas, the extension/package developer can't do that, since rename, alias,
proc, etc. are already potentially suspect before ever reaching the
package itself.
Darren New
> Alas, the extension/package developer can't do that, since rename, alias,
> proc, etc. are already potentially suspect before ever reaching the
> package itself.
And someone could replace /bin/wish with code that includes different
behavior for the [set] command already. So it's all suspect. At some
point, you have to assume that the commands you're calling substantially
behave the way they're documented.
--
Darren New, San Diego CA USA (PST)
Why is it called "a stay of execution"
if the execution goes away?
Gerald Lester
> Gerald Lester wrote:
>
>>In other words, what is to prevent someone from redefining ::tcl::scan.
>>Yes I understand your proposal makes it harder to accidentally shoot your leg
>>off -- but it does not stop you from doing so.
>
>
> True. Tcl has a long history of keeping everything open to
> introspection and revision. No private/public distinction among
> commands.
>
> If one really needs the security of a "locked-down" command, they can
> get the illusion of it using [incr Tcl], and perhaps other packages
> that offer a notion of "private" commands or methods.
>
> For even more robust control over what code can do in terms of
> modifying existing commands, a carefully crafted slave interpreter is
> probably the best solution.
This tread started because someone accidentally shot themselves -- personally
I believe it is a good learning experience, they will be more careful in the
future with their remaining pieces of anatomy -- for crafting a secure robust
controlled environment nothing but nothing bets slave interpreters in my book.
Ulrich Schoebel
> lvi...@yahoo.com wrote:
>
>> Alas, the extension/package developer can't do that, since rename, alias,
>> proc, etc. are already potentially suspect before ever reaching the
>> package itself.
>
>
> And someone could replace /bin/wish with code that includes different
> behavior for the [set] command already. So it's all suspect. At some
> point, you have to assume that the commands you're calling substantially
> behave the way they're documented.
>
the builtin commands to work as documented. An extension is always
loaded by a surrounding program.
If a programmer decides to implement a command with the same name
as a builtin but with a different behaviour, he does (should) know
that this might have side effects on the extension loaded later on.
This doesn't happen accidently.
Best regards
lvi...@yahoo.com
^^^^^^^^^^
:as a builtin but with a different behaviour, he does (should) know
:that this might have side effects on the extension loaded later on.
:This doesn't happen accidently.
Programmers should - but don't always - know. Users of Tcl applications,
however, seldom realize how they might mess up a program by the accidentally
bad choice of a proc name when extending an application.
Darren New
> That's exactly the point, Darren. an extension author can rely on the
> the builtin commands to work as documented.
% ln /bin/cat /bin/wish
Built-in commands no longer work. That's what I meant. :-)
> If a programmer decides to implement a command with the same name
> as a builtin but with a different behaviour, he does (should) know
> that this might have side effects on the extension loaded later on.
He should, yes. If he doesn't, it's a bug. There's nothing you're going
to be able to do to guarantee that the built-in commands work the way
you expect them to. The best you can hope for is that they work close
enough to how you expect that your program still works.
Arguably, things like variable traces affecting [set] can cause as much
confusion as renamed local commands. Both are equally documented, both
are equally open to abuse.
> This doesn't happen accidently.
Sure it does. I once spent 4 days trying to figure out what the heck was
happening when I accidentally defined a "flush" command inside a
namespace and other commands in that namespace were calling [flush]
instead of [::flush]. How many of the commands in your own namespace
invoke commands in the global namespace without explicitly making them
global? Each of those is open to being clobbered too.
If you want a *safe* language, try Ada. ;-) Any rule you add to make
Tcl safer is going to make Tcl more complicated as well. Not necessarily
bad, but there's definitely a cost.