...pathname-pathname? Talk about a stutter. Paging Major Major.
And what was wrong with pathname-sans-filename? Too accurate and easy
to remember? Or have the English still not gotten over all those wars
with France?
I mean the wheels just came off when they got to pathnames, didn't they?
Lousy language...
kzo
From: Richard M Kreuter
Subject: Re: path-pathname? too embarrassed to call it...
Date:
Message-ID: <87ej3u8gly.fsf@progn.net>
Kenny <·········@gmail.com> writes:
> ...pathname-pathname? Talk about a stutter. Paging Major Major.
>
> And what was wrong with pathname-sans-filename? Too accurate and easy
> to remember? Or have the English still not gotten over all those wars
> with France?
directory-namestring? Or (enough-namestring full-path non-directory-part)?
--
RmK
On Sep 8, 11:36 pm, Richard M Kreuter <·······@progn.net> wrote:
> Kenny <·········@gmail.com> writes:
> > ...pathname-pathname? Talk about a stutter. Paging Major Major.
>
> > And what was wrong with pathname-sans-filename? Too accurate and easy
> > to remember? Or have the English still not gotten over all those wars
> > with France?
>
> directory-namestring? Or (enough-namestring full-path non-directory-part)?
Depends. Since you are using '-namestring' suffixes it means you are
getting namestrings and not pathnames as results.
Cheers
--
Marco
From: Richard M Kreuter
Subject: Re: path-pathname? too embarrassed to call it...
Date:
Message-ID: <877i9l876r.fsf@progn.net>
Marco Antoniotti <·······@gmail.com> writes:
> On Sep 8, 11:36 pm, Richard M Kreuter <·······@progn.net> wrote:
>> Kenny <·········@gmail.com> writes:
>> > ...pathname-pathname? Talk about a stutter. Paging Major Major.
>>
>> > And what was wrong with pathname-sans-filename? Too accurate and easy
>> > to remember? Or have the English still not gotten over all those wars
>> > with France?
>>
>> directory-namestring? Or (enough-namestring full-path non-directory-part)?
>
> Depends. Since you are using '-namestring' suffixes it means you are
> getting namestrings and not pathnames as results.
Right, but namestrings are (supposed to be) usable as pathname
designators everywhere. And if that's not good enough for you:
(defun enough-pathname (pathname defaults)
(parse-namestring (enough-namestring pathname defaults)
(pathname-host pathname)))
--
RmK
On Sep 9, 9:12 pm, Richard M Kreuter <·······@progn.net> wrote:
> Marco Antoniotti <·······@gmail.com> writes:
> > On Sep 8, 11:36 pm, Richard M Kreuter <·······@progn.net> wrote:
> >> Kenny <·········@gmail.com> writes:
> >> > ...pathname-pathname? Talk about a stutter. Paging Major Major.
>
> >> > And what was wrong with pathname-sans-filename? Too accurate and easy
> >> > to remember? Or have the English still not gotten over all those wars
> >> > with France?
>
> >> directory-namestring? Or (enough-namestring full-path non-directory-part)?
>
> > Depends. Since you are using '-namestring' suffixes it means you are
> > getting namestrings and not pathnames as results.
>
> Right, but namestrings are (supposed to be) usable as pathname
> designators everywhere.
Not quite. Subtleties and the (root of all) evil "implementation
dependent" bits of the pathname specs make me quite vary of using
namestrings apart from real file system interaction. When you deal
with namestrings it is too easy to fall for the (format nil "~A/~A"
ns1 ns2) trap. Then your program does not work reliably on TOPS-20.
> And if that's not good enough for you:
>
> (defun enough-pathname (pathname defaults)
> (parse-namestring (enough-namestring pathname defaults)
> (pathname-host pathname)))
>
Fair enough. Although note that the above may (modulo ITS and the
evil "implementation dependencies") result in a no-op with the
argument and the result being EQUAL.
Cheers
--
Marco
From: Richard M Kreuter
Subject: Re: path-pathname? too embarrassed to call it...
Date:
Message-ID: <873ak887i5.fsf@progn.net>
Marco Antoniotti <·······@gmail.com> writes:
> On Sep 9, 9:12 pm, Richard M Kreuter <·······@progn.net> wrote:
>> Marco Antoniotti <·······@gmail.com> writes:
>> > On Sep 8, 11:36 pm, Richard M Kreuter <·······@progn.net> wrote:
>> >> Kenny <·········@gmail.com> writes:
>> >> > ...pathname-pathname? Talk about a stutter. Paging Major Major.
>>
>> >> > And what was wrong with pathname-sans-filename? Too accurate and easy
>> >> > to remember? Or have the English still not gotten over all those wars
>> >> > with France?
>>
>> >> directory-namestring? Or (enough-namestring full-path non-directory-part)?
>>
>> > Depends. Since you are using '-namestring' suffixes it means you are
>> > getting namestrings and not pathnames as results.
>>
>> Right, but namestrings are (supposed to be) usable as pathname
>> designators everywhere.
>
> Not quite. Subtleties and the (root of all) evil "implementation
> dependent" bits of the pathname specs make me quite vary of using
> namestrings apart from real file system interaction. When you deal
> with namestrings it is too easy to fall for the (format nil "~A/~A"
> ns1 ns2) trap. Then your program does not work reliably on TOPS-20.
I can see why you're pointing this out, but you're preaching to the
choir. I didn't say that strings in general were portably usable as
pathnames, or that you can perform arbitrary string manipulations on
namestrings and get back namestrings; I said that namestrings are
usable as pathname designators, which is true by definition:
namestring n.
a string that represents a filename using either the standardized
notation for naming logical pathnames described in Section 19.3.1
(Syntax of Logical Pathname Namestrings):, or some
implementation-defined notation for naming a physical pathname.
So you're right that (format nil "~A/~A" s1 s2) won't return a string
you can use as a pathname designator on TOPS-20, but that's because
the result of the manipulation isn't a namestring there! ;)
OTOH, if you get a string from a standard routine that's supposed to
return a namestring, then ISTM you may rely on the string being usable
as a pathname designator. I'd consider a pathnames implementation
that returned strings that weren't usable as pathname designators from
any of the namestring functions to be faulty.
--
RmK
From: Kaz Kylheku
Subject: Re: path-pathname? too embarrassed to call it...
Date:
Message-ID: <20080910132910.963@gmail.com>
On 2008-09-08, Kenny <·········@gmail.com> wrote:
> ...pathname-pathname? Talk about a stutter. Paging Major Major.
I can't find a PATH-PATHNAME in the CLHS. Where did you find this?
There is a PATHNAME-NAME accessor for the PATHNAME class, to get the
name component; is that what you are thinking of?
A better name for this slot would be BASENAME (borrowing from Unix).
But you see, the whole class should just have been called PATH. NAME is
redundant in PATHNAME. A PATH is generally understood to designate (something
akin to name) a location. See, this makes sense. You have a path, which has
a name. (As well as a directory, type, and other attributes).
> And what was wrong with pathname-sans-filename? Too accurate and easy
What's wrong with PATHNAME-DIRECTORY?
Note that the basename might not be a file, so ``sans-filename'' is inaccurate.
> to remember? Or have the English still not gotten over all those wars
> with France?
Gotten over? Are you saying they lost some?
Kaz Kylheku wrote:
> On 2008-09-08, Kenny <·········@gmail.com> wrote:
>
>>...pathname-pathname? Talk about a stutter. Paging Major Major.
>
>
> I can't find a PATH-PATHNAME in the CLHS. Where did you find this?
>
> There is a PATHNAME-NAME accessor for the PATHNAME class, to get the
> name component; is that what you are thinking of?
>
Ah, sorry, the "lookup" keychord in ACL does not usually take me to
ACL-specific functions. This is in their EXCL package.
kt