[Starkit] auto_execok and Starpacks

[Joey Mukherjee]

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 
name was
               last modified.  If time is specified, it is a 
modification  time
               to  set  for  the  file (equivalent to Unix touch).  The 
time is
               measured in the standard POSIX fashion as seconds from  a 
  fixed
               starting  time  (often  January  1,  1970).  If the file 
doesn't
               exist or its modified time cannot be  queried  or  set  
then  an
               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
> yourself?

Absolutely!  If the program is in the path, why would it not be able to 
exec it?

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.

Cheers,
Joey