Re: namestring second argument

[Bruno H. <br...@cl...>]

Sam wrote:
> subprocesses inherit current directory, so passing the plain namestring
> to them should be OK.
>
> OTOH, the users might want to communicate with an independent process,
> so this functionality is indeed necessary.

Yes, that's the point. Also some tools don't accept relative filenames.
(Try passing passing a relative filename without a slash to netscape...)

So I can agree to moving the functionality from NAMESTRING to somewhere
else. I'd simply propose a new function (ABSOLUTE-PATHNAME pathname).

> How about extending TRANSLATE-PATHNAME (it is permitted by the SPEC):
> after all, this additional NAMESTRING argument makes CLISP perform an
> additional pathname _translation_: to absolute!
> So, we can make the :MERGE :ABSOLUTE argument to this transformation
> for the return values - after MERGE-PATHNAMES.
> So the default "finalization" will be determined by the :MERGE argument:
> NIL - nothing
> T - just MERGE-PATHNAMES (default, as per ANSI)
>
> :ABSOLUTE - turn into an absolute pathname and ensure no wildcards.
>
> so instead of
>    (namestring path t)
> one would have to write
>    (namestring (translate-pathname path #p"" #p"" :merge :absolute))

I'm not sure I understand this. So you have generalized ABSOLUTE-PATHNAME
from a function with 1 argument to a function with 3 arguments? What is

   (translate-pathname path from-wildcard to-wildcard :absolute)

then? How does it differ from

   (absolute-pathname (translate-pathname path from-wildcard to-wildcard)) ?

If it is the same, then I'm in favour of exporting and documenting
ABSOLUTE-PATHNAME. Because noone wants to call a monster function like
TRANSLATE-PATHNAME in order to get a simple functionality.

If it is not the same, then what shall it do precisely?

Bruno