On Wed, Jun 10, 2020 at 12:04:13PM -0400, David T. Lewis wrote:
> On Wed, Jun 10, 2020 at 07:20:09PM +0530, K K Subbu wrote:
> > On 09/06/20 1:16 am, commits at source.squeak.org wrote:
> > >----- Method: SmalltalkImage>>documentPath (in category 'command
> > >line') ----- documentPath + 	"Answer the absolute path of the
> > >document passed to the VM or nil if none."
> > 
> > This doesn't seem to be true with the unix port. It passes the document 
> > name as given in the command line. I just tried:
> > 
> >  $ run images/SpurVMMaker.image ./dummy.st hello world
> > 
> > Here is what I see:
> > {SmalltalkImage current documentPath.
> > SmalltalkImage current vmPath.
> > SmalltalkImage current imagePath.
> > SmalltalkImage current imageName}
> >  #('./dummy.st'
> > '/opt/share/squeak/sqcogspurlinuxht/lib/squeak/5.0-201804100527/'
> > '/opt/share/squeak/images'
> > '/opt/share/squeak/images/SpurVMMaker.image')
> > 
> > This could create problems because the relative path for the image and 
> > document could be different (as in this case).
> > 
> > If a script is used to launch the vm, the working directory of the same 
> > must be passed through the environment for resolving relative document 
> > path in the image.
> >
> 
> Yes that could cause problems. But I think that this is existing behavior,
> not anything related to System-dtl.1164.mcz, is that right?
> 
> If the system does not find ./dummy.st in this case, it might be necessary
> to use a fully qualified path to the document file.
>

Confirming, the above is existing behavior. The document file is located
relative to the current working directory of my terminal shell, regardless
of the VM and image paths. This is also the case for a file list and other
file based operations within the image.

I'm going to go ahead and move System-dtl.1164.mcz to trunk, and we
can take that as a baseline for other argument processing concerns.

Dave