[Starkit] auto_execok and Starpacks
joey at swri.edu
Mon Aug 15 13:31:29 CEST 2005
On Aug 15, 2005, at 11:44 AM, Jeff Hobbs wrote:
> Joey Mukherjee wrote:
>> The thing is the functions no longer match the documentation if the
>> object in question is a starpack; so to me, that seems wrong.
>> Rather than having a new set of commands to manipulate the starpacks,
>> old commands no longer work unless you are working in the
>> confines of a starpack.
> Feel free to correct me with doc refs, but I believe you are
> misreading them. You can't read one page at a time, you have
> to understand the full implications of the functionality.
> Sure, 'file' ops do their stated file ops, but when you use
> VFS to mount something, what was a file can become a directory,
> and that is also according to docs. Everything is working
> exactly as it should.
Admittedly, its been a while since I had to read all the docs, but I
will go to an example which was one which I thought was wrong:
file mtime name ?time?
Returns a decimal string giving the time at which file
last modified. If time is specified, it is a
to set for the file (equivalent to Unix touch). The
measured in the standard POSIX fashion as seconds from a
starting time (often January 1, 1970). If the file
exist or its modified time cannot be queried or set
error is generated.
Running "file mtime <full path name of current starpack>" returns 0.
This is wrong nor did it return an error, unless 0 is the error, but I
was expecting a tk_error or something. Even so, this would normally
work for a file or a directory since I need this information.
IMO, if a full path name is given, it would return the time of the file
itself; if a "starpack path" (or starpack namespace) is given, it
would work on the VFS portion. Naturally, something like this might be
hard to implement, but I hope I get the "gist" of it across.
>> Don't get me wrong, I like the concept of being able to have a self
>> mounting file system, but I feel old code should not be broken,
>> especially if no workarounds are possible.
> Workarounds are possible, but I'm not even sure how you had
> working code that broke. Did you always expect to exec
Absolutely! If the program is in the path, why would it not be able to
Here is how I use it: I have a program which is a menu program that
will launch other programs. If no command line option is given, it
reads the default menu config file. If an command line parameter is
given, it will read that menu config file. Within the default menu
config file, it will call this program with a different menu config
file. It is basically exec'ing itself with a different menu config
file. It isn't a fancy program, but useful nonetheless.
I worked around this by checking if [info nameofexe] was the same as
the program to exec in the config file.
For the glob/file mtime, I have not been able to work around it. Even
so, I would like to think I should not have to.
More information about the Starkit