Re: ANNOUNCE: freeWrap 6.1 released
Available news archives: comp.lang.tcl - comp.lang.python - comp.security.firewalls - sci.crypt - comp.lang.php - comp.lang.javascript
Google
 
Web news.hping.org


comp.lang.tcl archive

Re: ANNOUNCE: freeWrap 6.1 released

From: <joey@swri.edu>
Date: Mon Sep 12 2005 - 16:35:59 CEST

Bryan Oakley <oakley@bardo.clearlight.com> wrote:

> >>>mechanism and the fact that certain commands no longer work under a
> >>>starpack with no workarounds.
> >
> > The ones I have found are auto_execok, file, and glob. The problem is
> > the name of the executable is now a directory so commands which would
> > normally work for the starpack as a file now no longer work from within
> > the starpack on the starpack itself. Does that make sense?
>
> Yes. I knew about that restriction. I guess it never occured to me that
> a program would want use a filesystem command on itself. Can you not
> simply special-case the starkit itself? That is, put a wrapper around
> glob so that if you're globbing something that should return the
> startkit, you append [info nameofexecutable] to the result? Likewise for
> auto_execok and the file commands.
>
> I can understand though, how this would be problematic if you're writing
> something like a file manager.

In fact this program is a file manager type of program! I was able to work
around everything but the "file mtime" command.

What I don't understand is why this restriction must exist. Why couldn't
the filesystem/starpack name be given some other temp name which is
retrievable from info or something rather than making a reserved word for
the file. All the other commands would work and if someone wanted to do
something within a starpack, they have a new [info starpackname] to work
with.

Joey
Received on Thu Sep 29 14:36:33 2005