Yes, another reincarnation.
[727]> (rename-file "version.bak" "version")
*** - RENAME-FILE: File #P"/home/mega/cvswork/part/cm/version.bak"
already exists
Interpretation: it tries rename "version.bak" to "version.bak" and
fails.
I understand that rename-file merges "version" with "version.bak" and
since "version" has its type set to nil the merged pathname type is
"bak". In an old thread the recommended solution was to set :type to
:unspecific which helps in CMUCL, but Clisp does not support it.
Is there (ideally) a portable way to do this?
Thanks, Gabor Melis
* Gabor Melis wrote:
> I understand that rename-file merges "version" with "version.bak" and
> since "version" has its type set to nil the merged pathname type is
> "bak". In an old thread the recommended solution was to set :type to
> :unspecific which helps in CMUCL, but Clisp does not support it.
> Is there (ideally) a portable way to do this?
I think this is interesting. The spec says that portable programs
should never provide :UNSPECIFIC as a value, so how are they meant to
specify this thing? I guess, maybe the answer is that they can't, and
that's OK, because (for instance) it's not defined portably what it
means for a file to have no type - maybe some filesystems *always*
have a non-null type (this is almost certainly true).
Given that, an implementation running on Unix, where files can have no
type, needs to be able to specify a value for the type which prevents
merging, and :UNSPECIFIC is what that is for. What, exactly, does
CLISP do if you say:
(merge-pathnames (make-pathname :name "foo" :type :unspecific)
#P"bar.crun")
?
--tim
Tim Bradshaw <···@cley.com> wrote in message news:<···············@cley.com>...
> I think this is interesting. The spec says that portable programs
> should never provide :UNSPECIFIC as a value, so how are they meant to
> specify this thing? I guess, maybe the answer is that they can't, and
> that's OK, because (for instance) it's not defined portably what it
> means for a file to have no type - maybe some filesystems *always*
> have a non-null type (this is almost certainly true).
>
> Given that, an implementation running on Unix, where files can have no
> type, needs to be able to specify a value for the type which prevents
> merging, and :UNSPECIFIC is what that is for. What, exactly, does
> CLISP do if you say:
>
> (merge-pathnames (make-pathname :name "foo" :type :unspecific)
> #P"bar.crun")
>
> ?
[1]> (merge-pathnames (make-pathname :name "foo" :type :unspecific)
#P"bar.crun")
*** - MAKE-PATHNAME: illegal :TYPE argument :UNSPECIFIC
Which is according to the clisp doc.
>
> --tim
* Gabor Melis wrote:
> [1]> (merge-pathnames (make-pathname :name "foo" :type :unspecific)
> #P"bar.crun")
> *** - MAKE-PATHNAME: illegal :TYPE argument :UNSPECIFIC
> Which is according to the clisp doc.
Well, that's OK, but then they need to provide some other way of
preventing merging: how do they do that?
--tim
Tim Bradshaw <···@cley.com> wrote in message news:<···············@cley.com>...
> * Gabor Melis wrote:
>
> > [1]> (merge-pathnames (make-pathname :name "foo" :type :unspecific)
> > #P"bar.crun")
>
> > *** - MAKE-PATHNAME: illegal :TYPE argument :UNSPECIFIC
>
> > Which is according to the clisp doc.
>
> Well, that's OK, but then they need to provide some other way of
> preventing merging: how do they do that?
>
> --tim
AFAIK they don't. Maybe it is due to my UN*X orientation but having
type as a separate component looks suspicious. That makes think:
[2]> (rename-file (make-pathname :name "version.bak") (make-pathname
:name "version"))
#P"version" ;
#P"/home/mega/version.bak" ;
#P"/home/mega/version"
Oh boy, does that stink?! Or is it an accepted form enforcing one's
will on a less-than-perfectly-fitting abstraction :-) ?
Cheers, Gabor
* Gabor Melis wrote:
> Oh boy, does that stink?! Or is it an accepted form enforcing one's
> will on a less-than-perfectly-fitting abstraction :-) ?
yes, it stinks. CLISP needs a way of preventing type merging.
--tim
On 13 Mar 2003 02:07:52 -0800, ····@hotpop.com (Gabor Melis) wrote:
>Yes, another reincarnation.
>
>[727]> (rename-file "version.bak" "version")
>*** - RENAME-FILE: File #P"/home/mega/cvswork/part/cm/version.bak"
>already exists
>
>Interpretation: it tries rename "version.bak" to "version.bak" and
>fails.
>
>I understand that rename-file merges "version" with "version.bak" and
>since "version" has its type set to nil the merged pathname type is
>"bak". In an old thread the recommended solution was to set :type to
>:unspecific which helps in CMUCL, but Clisp does not support it.
>
>Is there (ideally) a portable way to do this?
>
(rename-file "version.bak" (make-pathname :name "version" :type ""))
works using both Corman and Allegro on Windows.
······@alum.mit.edu (JP Massar) writes:
> On 13 Mar 2003 02:07:52 -0800, ····@hotpop.com (Gabor Melis) wrote:
>
> >Yes, another reincarnation.
> >
> >[727]> (rename-file "version.bak" "version")
> >*** - RENAME-FILE: File #P"/home/mega/cvswork/part/cm/version.bak"
> >already exists
> >
> >Interpretation: it tries rename "version.bak" to "version.bak" and
> >fails.
> >
> >I understand that rename-file merges "version" with "version.bak" and
> >since "version" has its type set to nil the merged pathname type is
> >"bak". In an old thread the recommended solution was to set :type to
> >:unspecific which helps in CMUCL, but Clisp does not support it.
> >
> >Is there (ideally) a portable way to do this?
> >
>
> (rename-file "version.bak" (make-pathname :name "version" :type ""))
>
> works using both Corman and Allegro on Windows.
Ick.
Some of us believe that :name "foo" :type "" means the file
named "foo.", not the file named "foo".
Pity there's no standard, but it's something people should be aware
might vary.
Kent M Pitman <······@world.std.com> writes:
> ······@alum.mit.edu (JP Massar) writes:
>
> > (rename-file "version.bak" (make-pathname :name "version" :type ""))
> >
> > works using both Corman and Allegro on Windows.
>
> Some of us believe that :name "foo" :type "" means the file
> named "foo.", not the file named "foo".
It may not matter in Windows. I tried creating a file
"foo.. .. .." and got just "foo". That was Windows 2000 on FAT32.
On 13 Mar 2003 12:21:11 -0500, Kent M Pitman <······@world.std.com>
wrote:
>
>Some of us believe that :name "foo" :type "" means the file
>named "foo.", not the file named "foo".
>
Unfortunately, none of this radical group seems to have any
influence over a certain (dare I call it) Operating System.
:-)