From: Slava Akhmechet
Subject: Lisp, tilde, and home directory
Date:
Message-ID: <87ps20811g.fsf@gmail.com>
Is lisp supposed to understand that tilde (~) is a home directory on
unix machines? When I do (truename "~/") on SBCL 1.0.4 on Linux/X86, I
get an error saying "~/" doesn't exist. I tried various combinations
and pathnames, but I always get weird behavior when I use tilde. Is
this to be expected?
--
Regards,
Slava Akhmechet.
On Aug 6, 8:40 pm, Slava Akhmechet <·········@gmail.com> wrote:
> Is lisp supposed to understand that tilde (~) is a home directory on
> unix machines? When I do (truename "~/") on SBCL 1.0.4 on Linux/X86, I
> get an error saying "~/" doesn't exist. I tried various combinations
> and pathnames, but I always get weird behavior when I use tilde. Is
> this to be expected?
Yes. The tilde convention originated, AFAIK, with csh; I don't think
the original Bourne shell supported it, and the kernel certainly
doesn't know about it, so it's far from universal even on Un*x.
-- Scott
P.S. How is your Web app framework coming?
From: Slava Akhmechet
Subject: Re: Lisp, tilde, and home directory
Date:
Message-ID: <87hcnc7ypn.fsf@gmail.com>
Scott Burson <········@gmail.com> writes:
> Yes. The tilde convention originated, AFAIK, with csh; I don't think
> the original Bourne shell supported it, and the kernel certainly
> doesn't know about it, so it's far from universal even on Un*x.
Thanks! I didn't know this.
> P.S. How is your Web app framework coming?
It's coming along. Project page is now here:
http://common-lisp.net/project/cl-weblocks/
It should get really interesting soon, I just need to get all the
dirty stuff out of the way so I can work on coroutine based control
flow.
--
Regards,
Slava Akhmechet.
On Tue, 07 Aug 2007 04:15:47 +0000, Scott Burson wrote:
> On Aug 6, 8:40 pm, Slava Akhmechet <·········@gmail.com> wrote:
>> Is lisp supposed to understand that tilde (~) is a home directory on
>> unix machines? When I do (truename "~/") on SBCL 1.0.4 on Linux/X86, I
>> get an error saying "~/" doesn't exist. I tried various combinations
>> and pathnames, but I always get weird behavior when I use tilde. Is
>> this to be expected?
>
> Yes. The tilde convention originated, AFAIK, with csh; I don't think
> the original Bourne shell supported it, and the kernel certainly
> doesn't know about it, so it's far from universal even on Un*x.
Well, shouldn't the answer than be "No"?
Anyway, the more portable approach would be:
(user-homedir-pathname)
[http://www.lisp.org/HyperSpec/Body/fun_user-homedir-pathname.html]
HTH Ralf Mattes
> -- Scott
>
> P.S. How is your Web app framework coming?
On Tue, 07 Aug 2007 14:27:52 +0000, Ralf Mattes wrote:
> On Tue, 07 Aug 2007 04:15:47 +0000, Scott Burson wrote:
>
>> On Aug 6, 8:40 pm, Slava Akhmechet <·········@gmail.com> wrote:
>>> Is lisp supposed to understand that tilde (~) is a home directory on
>>> unix machines? When I do (truename "~/") on SBCL 1.0.4 on Linux/X86, I
>>> get an error saying "~/" doesn't exist. I tried various combinations
>>> and pathnames, but I always get weird behavior when I use tilde. Is
>>> this to be expected?
>>
>> Yes. The tilde convention originated, AFAIK, with csh; I don't think
>> the original Bourne shell supported it, and the kernel certainly
>> doesn't know about it, so it's far from universal even on Un*x.
>
> Well, shouldn't the answer than be "No"?
> Anyway, the more portable approach would be:
>
> (user-homedir-pathname)
>
> [http://www.lisp.org/HyperSpec/Body/fun_user-homedir-pathname.html]
BTW, the HyperSpec says that the result of a call to user-homedir-pathname
without a host argument is implementation dependent ...
Of course you can always fall back to your own implementation of the
shell's ~ glob - in SBCL you could do:
(truename (posix-getenv "HOME"))
Cheers, RalfD
> HTH Ralf Mattes
>
>> -- Scott
>>
>> P.S. How is your Web app framework coming?
On Aug 7, 7:27 am, Ralf Mattes <····@mh-freiburg.de> wrote:
> On Tue, 07 Aug 2007 04:15:47 +0000, Scott Burson wrote:
> > On Aug 6, 8:40 pm, Slava Akhmechet <·········@gmail.com> wrote:
> >> Is lisp supposed to understand that tilde (~) is a home directory on
> >> unix machines? When I do (truename "~/") on SBCL 1.0.4 on Linux/X86, I
> >> get an error saying "~/" doesn't exist. I tried various combinations
> >> and pathnames, but I always get weird behavior when I use tilde. Is
> >> this to be expected?
>
> > Yes.
>
> Well, shouldn't the answer than be "No"?
Heh -- I was answering the last question in the paragraph, not the
first.
-- Scott
In article <············@news01.versatel.de>,
Ralf Mattes <··@mh-freiburg.de> wrote:
> On Tue, 07 Aug 2007 04:15:47 +0000, Scott Burson wrote:
>
> > On Aug 6, 8:40 pm, Slava Akhmechet <·········@gmail.com> wrote:
> >> Is lisp supposed to understand that tilde (~) is a home directory on
> >> unix machines? When I do (truename "~/") on SBCL 1.0.4 on Linux/X86, I
> >> get an error saying "~/" doesn't exist. I tried various combinations
> >> and pathnames, but I always get weird behavior when I use tilde. Is
> >> this to be expected?
> >
> > Yes. The tilde convention originated, AFAIK, with csh; I don't think
> > the original Bourne shell supported it, and the kernel certainly
> > doesn't know about it, so it's far from universal even on Un*x.
>
> Well, shouldn't the answer than be "No"?
No. The question was "Is this [weird behavior] to be expected?" And
because tilde is not a standard part of Unix pathname syntax, the answer
is "yes, this behavior is to be expected."
--
Barry Margolin, ······@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***
From: Kent M Pitman
Subject: Re: Lisp, tilde, and home directory
Date:
Message-ID: <uabt2vfby.fsf@nhplace.com>
Barry Margolin <······@alum.mit.edu> writes:
> In article <············@news01.versatel.de>,
> Ralf Mattes <··@mh-freiburg.de> wrote:
>
> > On Tue, 07 Aug 2007 04:15:47 +0000, Scott Burson wrote:
> >
> > > On Aug 6, 8:40 pm, Slava Akhmechet <·········@gmail.com> wrote:
> > >> Is lisp supposed to understand that tilde (~) is a home
> > >> directory on unix machines? When I do (truename "~/") on SBCL
> > >> 1.0.4 on Linux/X86, I get an error saying "~/" doesn't exist. I
> > >> tried various combinations and pathnames, but I always get
> > >> weird behavior when I use tilde. Is this to be expected?
> > >
> > > Yes. The tilde convention originated, AFAIK, with csh; I don't
> > > think the original Bourne shell supported it, and the kernel
> > > certainly doesn't know about it, so it's far from universal even
> > > on Un*x.
> >
> > Well, shouldn't the answer than be "No"?
>
> No. The question was "Is this [weird behavior] to be expected?"
> And because tilde is not a standard part of Unix pathname syntax,
> the answer is "yes, this behavior is to be expected."
I agree with Barry here.
Tilde expansion is finally the norm in most Unix tools, but it was not
always so, so even under Unix the question was open.
Nevertheless, CL didn't rule it in or out. Rather, CL generally tries
hard not to take any position whatsoever on specific operating system
and file system conventions since it doesn't want to limit itself to
the specifics of such operating systems. It was assumed that
separate, layered bindings could be created to address this where they
were needed, thus leaving the language itself unaffected.
Here's what the spec says:
| 19.1.3 Parsing Namestrings Into Pathnames
|
| Parsing is the operation used to convert a namestring into a
| pathname. Except in the case of parsing logical pathname
| namestrings, this operation is implementation-dependent, because the
| format of namestrings is implementation-dependent.
|
| A conforming implementation is free to accommodate other file system
| features in its pathname representation and provides a parser that
| can process such specifications in namestrings. Conforming programs
| must not depend on any such features, since those features will not
| be portable.
Source: http://www.lispworks.com/documentation/HyperSpec/Body/19_ac.htm
Barry Margolin <······@alum.mit.edu> wrote on Tue, 07 Aug 2007:
> In article <············@news01.versatel.de>, Ralf Mattes <··@mh-freiburg.de> wrote:
>> Well, shouldn't the answer than be "No"?
>
> No. The question was "Is this [weird behavior] to be expected?"
> the answer is "yes, this behavior is to be expected."
Yes, I have no bananas either.
_______________________________________________________________________________
Don Geddis http://don.geddis.org/ ···@geddis.org
Slava Akhmechet <·········@gmail.com> writes:
> Is lisp supposed to understand that tilde (~) is a home directory on
> unix machines?
No. (That is, if by "lisp" you understand the "Common Lisp standard").
> When I do (truename "~/") on SBCL 1.0.4 on Linux/X86, I
> get an error saying "~/" doesn't exist. I tried various combinations
> and pathnames, but I always get weird behavior when I use tilde. Is
> this to be expected?
It's implementation dependant. The equivalent and portable notion in
Cl is (USER-HOMEDIR-PATHNAME).
Instead of writing: "~/myfile"
write:
(make-pathname :name "MYFILE" :case :common
:defaults (user-homedir-pathname))
Yes, somewhat more verbose, but if you need it often you can always
abstract away: (home "MYFILE") ;-)
--
__Pascal Bourguignon__ http://www.informatimago.com/
NOTE: The most fundamental particles in this product are held
together by a "gluing" force about which little is currently known
and whose adhesive power can therefore not be permanently
guaranteed.
From: Slava Akhmechet
Subject: Re: Lisp, tilde, and home directory
Date:
Message-ID: <87ir7re17x.fsf@gmail.com>
Pascal Bourguignon <···@informatimago.com> writes:
> Instead of writing: "~/myfile"
> write:
> (make-pathname :name "MYFILE" :case :common
> :defaults (user-homedir-pathname))
>
> Yes, somewhat more verbose, but if you need it often you can always
> abstract away: (home "MYFILE") ;-)
That's what I usually do, but I'm interested in user input.
I'll just ignore the issue for now, or translate tilde to home
directory manually...
--
Regards,
Slava Akhmechet.
Slava Akhmechet <·········@gmail.com> writes:
> Pascal Bourguignon <···@informatimago.com> writes:
>
>> Instead of writing: "~/myfile"
>> write:
>> (make-pathname :name "MYFILE" :case :common
>> :defaults (user-homedir-pathname))
>>
>> Yes, somewhat more verbose, but if you need it often you can always
>> abstract away: (home "MYFILE") ;-)
> That's what I usually do, but I'm interested in user input.
>
> I'll just ignore the issue for now, or translate tilde to home
> directory manually...
Well, since you're interested in user input probably you want to
handle a click on some button with an icon representing a house, not a
string starting with "~/"... You see what I mean ;-)
--
__Pascal Bourguignon__ http://www.informatimago.com/
NOTE: The most fundamental particles in this product are held
together by a "gluing" force about which little is currently known
and whose adhesive power can therefore not be permanently
guaranteed.
On Aug 6, 8:40 pm, Slava Akhmechet <·········@gmail.com> wrote:
> Is lisp supposed to understand that tilde (~) is a home directory on
> unix machines?
Except that ~ isn't a home directory on unix machines. This is syntax
which is expanded by the shell. It is not understood in the kernel.
Try
echo ~
and you will see that the shell expanded ~ before passing it to echo.
> When I do (truename "~/") on SBCL 1.0.4 on Linux/X86, I
> get an error saying "~/" doesn't exist. I tried various combinations
> and pathnames, but I always get weird behavior when I use tilde. Is
> this to be expected?
This will also happen at the C API level. That is,
access("~/", R_OK)
should return -1 and set errno to ENOENT unless you actually have a
directory entry ~ in the current working directory.
+ Kaz Kylheku <········@gmail.com>:
| On Aug 6, 8:40 pm, Slava Akhmechet <·········@gmail.com> wrote:
|> Is lisp supposed to understand that tilde (~) is a home directory on
|> unix machines?
|
| Except that ~ isn't a home directory on unix machines. This is
| syntax which is expanded by the shell. It is not understood in the
| kernel.
But many interactive programs support it, emacs being an obvious
example. And hence the expectations for Lisp to support it: it all
comes from the interactive nature of many Lisp systems, I think.
Which does not mean it belongs in the language. I only offer this as
an explanation of why some people may expect it.
It is of course a trivial exercise for anyone who may need it to write
their own initial-tilde parser. Just for the heck of it, here is a
possible starting point:
(defun parse-namestring-with-tilde (string)
(case (mismatch "~/" string)
((0) (parse-namestring string))
((1) (if (= (length string) 1)
(user-homedir-pathname)
(error "Parsing of ~~user not implemented: ~s" string)))
((nil) (user-homedir-pathname))
(t (merge-pathnames (subseq string 2)
(user-homedir-pathname)))))
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- It is undesirable to believe a proposition
when there is no ground whatsoever for supposing it is true.
-- Bertrand Russell
Harald Hanche-Olsen <······@math.ntnu.no> wrote:
> But many interactive programs support it, emacs being an obvious
> example. And hence the expectations for Lisp to support it: it all
> comes from the interactive nature of many Lisp systems, I think.
> Which does not mean it belongs in the language. I only offer this as
> an explanation of why some people may expect it.
Would you then also want the Lisp file primitives to include:
* shell globbing (*, ?, etc. wildcards)
* environmental variable expansion ("$HOME")
* history keeping and reference
* directory stacks like with csh
* shell-like here documents and command substitution
* the need to escape (quote) any of those meta characters
* ...
There's a difference between programming API and user interface.
The Unix filesystem API has only two special characters, which are
/ (forward slash) and the NUL byte. If you start interpreting
anything else specially, you surely will run into problems, completely
unnecessary problems, even.
What can be provided are special utilities that provide some or all
of the shell's expansion mechanism. It doesn't have to be provided
by the file primitives. Typically, that would be one additional
nested function call for the programmer to type.
+ Matthias Buelow <···@incubus.de>:
| Harald Hanche-Olsen <······@math.ntnu.no> wrote:
|
|> But many interactive programs support it, emacs being an obvious
|> example. And hence the expectations for Lisp to support it: it all
|> comes from the interactive nature of many Lisp systems, I think.
|> Which does not mean it belongs in the language. I only offer this as
|> an explanation of why some people may expect it.
|
| Would you then also want the Lisp file primitives to include:
| * shell globbing (*, ?, etc. wildcards)
| * [...]
Methinks you didn't read what I wrote, since you attribute to me an
opinion opposite to one I stated in the paragraph you quoted.
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- It is undesirable to believe a proposition
when there is no ground whatsoever for supposing it is true.
-- Bertrand Russell
Matthias Buelow <···@incubus.de> writes:
> Harald Hanche-Olsen <······@math.ntnu.no> wrote:
>
>> But many interactive programs support it, emacs being an obvious
>> example. And hence the expectations for Lisp to support it: it all
>> comes from the interactive nature of many Lisp systems, I think.
>> Which does not mean it belongs in the language. I only offer this as
>> an explanation of why some people may expect it.
>
> Would you then also want the Lisp file primitives to include:
>
> * shell globbing (*, ?, etc. wildcards)
> * environmental variable expansion ("$HOME")
> * history keeping and reference
> * directory stacks like with csh
> * shell-like here documents and command substitution
> * the need to escape (quote) any of those meta characters
> * ...
>
> There's a difference between programming API and user interface.
> The Unix filesystem API has only two special characters, which are
> / (forward slash) and the NUL byte. If you start interpreting
> anything else specially, you surely will run into problems, completely
> unnecessary problems, even.
However, the Unix shell is both a programming API (for shell scripts)
and a user interface, and that seems to work out, despite the
arcaneness of the shell's notations. Further, Lisp's only standard
API for dealing with files is already beset with some of the
completely unnecessary problems you mention: Lisp's filesystem
interface already calls for (but fails to specify) wild pathnames.
All implementations I can find use a notations for namestrings that
resemble (but are usually incompatible with) the Unix shell's
"globbing", and some implementations offer the same notation as the
Unix shell for escaping wildcard characters in namestrings. So it's
not unreasonable for users to expect some other easily-implemented
features of the namestring parser, such as the leading tilde notation.
> What can be provided are special utilities that provide some or all
> of the shell's expansion mechanism. It doesn't have to be provided
> by the file primitives. Typically, that would be one additional
> nested function call for the programmer to type.
ANSI CL doesn't have any file primitives: it has a handful of
high-level functions on pathnames and streams, which map to files and
file descriptors in idiosyncratic, sometimes non-obvious,
implementation-defined ways. So a small convenience in the namestring
parser for denoting files relative to the user's home directory, even
if you don't need it, and even if it can't be used portably (because
the namestring parsers for other physical file systems don't support a
notation for the home directory), doesn't seem out of place, given the
rest of Lisp's file naming API.
What's more, there's a danger inherent to furnishing the shell's
expansion mechanisms as a collection of separate utilities, given that
the shell's expansion features don't commute. Suppose there were two
utilities, EXPAND-TILDE and EXPAND-ENVIRONMENT-VARIABLES, that
performed the appropriate expansions, and that the environment
variable FOO had the value "~"; then
(expand-tilde (expand-environment-variables "$foo/bar"))
=> "/home/me/bar"
(expand-environment-variables (expand-tilde "$foo/bar"))
=> "~/bar"
Offering these mechanisms as separate utilities effectively creates
factorially many incompatible notations [1]. There's an advantage to
having a single, albeit undisputably arbitrary, notation, which
advantage is lost entirely if users can circumvent or reorder some of
the interpretation of the notation.
--
RmK
[1] ... which, I suppose, would be in keeping with the general lack of
coherency that's a hallmark of Unix ...
Richard M Kreuter <·······@progn.net> wrote:
> Suppose there were two
> utilities, EXPAND-TILDE and EXPAND-ENVIRONMENT-VARIABLES, that
> performed the appropriate expansions, and that the environment
> variable FOO had the value "~"; then
Well, that doesn't really make sense. One would rather have _one_
function that emulated the shell's expansion, and not several that
could be combined in surprising and pointless ways.
+ Matthias Buelow <···@incubus.de>:
| Richard M Kreuter <·······@progn.net> wrote:
|
|> Suppose there were two
|> utilities, EXPAND-TILDE and EXPAND-ENVIRONMENT-VARIABLES, that
|> performed the appropriate expansions, and that the environment
|> variable FOO had the value "~"; then
|
| Well, that doesn't really make sense. One would rather have _one_
| function that emulated the shell's expansion, and not several that
| could be combined in surprising and pointless ways.
Which reminds me of the Apollo machines. Anyone else remembers them?
They ran something called Domain/OS, which would emulate both Berkeley
Unix, System V and whatever OS the early Apollos ran. (I only got to
use these machines towards the end of the lifetime of the whole
line. But I digress.) These machines actually supported environment
variables in pathnames somewhere deep inside the OS, so that you could
have a symlink /bin -> /$SYSTYPE/bin and then if you ran /bin/sh you
would get /bsd43/bin/sh or /sys5/bin/sh or whatever, based on the
value of $SYSTYPE at the moment. I probably have the particulars
wrong, but the essence is right.
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- It is undesirable to believe a proposition
when there is no ground whatsoever for supposing it is true.
-- Bertrand Russell
Matthias Buelow <···@incubus.de> writes:
>
> Would you then also want the Lisp file primitives to include:
>
> * shell globbing (*, ?, etc. wildcards)
~/foo or ~bar/baz are not valid absolute Unix paths; therefor there is
no problem with making these _invalid_ paths expand. No-one would ever
need to use them. OTOH, /foo*/bar _is_ a valid path, thus it would be a
Bad Thing to always expand it (what if the user actually meant
/foo*/bar, not /food/bar?). So globbing not should expand.
> * environmental variable expansion ("$HOME")
Ditto.
> * history keeping and reference
> * directory stacks like with csh
> * shell-like here documents and command substitution
I don't think this has anything to do with pathnames.
> There's a difference between programming API and user interface. The
> Unix filesystem API has only two special characters, which are /
> (forward slash) and the NUL byte. If you start interpreting anything
> else specially, you surely will run into problems, completely
> unnecessary problems, even.
But ~ cannot start a valid absolute path. It can start a valid relative
path, of course.
Maybe Unix implementations should have an EXPAND-NAMESTRING function?
> What can be provided are special utilities that provide some or all of
> the shell's expansion mechanism. It doesn't have to be provided by the
> file primitives. Typically, that would be one additional nested
> function call for the programmer to type.
Typed over, and over, and over by programmer after programmer instead of
once, by the implementation. Some may be buggy (supporting ~/foo but
not ~bar/baz). That doesn't seem optimal.
--
Robert Uhl <http://public.xdi.org/=ruhl>
Under John Kerry's `plan,' Saddam would still be in power, the French
would still be selling him the 68mm missiles used in the attack on Paul
Wolfowitz's Baghdad hotel last week, and there would still be Iraqis
being fed feet-first into the industrial shredders. Or have I missed
something? --Mark Steyn
Robert Uhl <·········@NOSPAMgmail.com> writes:
> Matthias Buelow <···@incubus.de> writes:
>>
>> Would you then also want the Lisp file primitives to include:
>>
>> * shell globbing (*, ?, etc. wildcards)
>
> ~/foo or ~bar/baz are not valid absolute Unix paths; therefor there is
> no problem with making these _invalid_ paths expand. No-one would ever
> need to use them. OTOH, /foo*/bar _is_ a valid path, thus it would be a
> Bad Thing to always expand it (what if the user actually meant
> /foo*/bar, not /food/bar?). So globbing not should expand.
Why this discrimination between absolute unix paths and relative unix
paths?
{
int mres=mkdir("~");
int fd=open("~/foo",O_WRONLY|O_CREAT);
int size=write(fd,"hello",/5);
...
}
is valid POSIX code...
Happily, CL leave it to the implementation to allow the use of
implementation dependant characters and syntax in pathnames:
(with-open-file (in #P"~/foo")
...)
>> What can be provided are special utilities that provide some or all of
>> the shell's expansion mechanism. It doesn't have to be provided by the
>> file primitives. Typically, that would be one additional nested
>> function call for the programmer to type.
>
> Typed over, and over, and over by programmer after programmer instead of
> once, by the implementation. Some may be buggy (supporting ~/foo but
> not ~bar/baz). That doesn't seem optimal.
But this is still unix philosophy to leave this kind of stuff up to
libraries, which is a good thing, and the same should be done in Lisp.
--
__Pascal Bourguignon__ http://www.informatimago.com/
NOTE: The most fundamental particles in this product are held
together by a "gluing" force about which little is currently known
and whose adhesive power can therefore not be permanently
guaranteed.
Pascal Bourguignon <···@informatimago.com> writes:
> Robert Uhl <·········@NOSPAMgmail.com> writes:
>> Matthias Buelow <···@incubus.de> writes:
>>>
>>> Would you then also want the Lisp file primitives to include:
>>>
>>> * shell globbing (*, ?, etc. wildcards)
>>
>> ~/foo or ~bar/baz are not valid absolute Unix paths; therefor there is
>> no problem with making these _invalid_ paths expand. No-one would ever
>> need to use them. OTOH, /foo*/bar _is_ a valid path, thus it would be a
>> Bad Thing to always expand it (what if the user actually meant
>> /foo*/bar, not /food/bar?). So globbing not should expand.
>
> Why this discrimination between absolute unix paths and relative unix
> paths?
I believe Mr. Uhl was inferring from the detail that in standard CL,
non-wild physical pathnames have predictable and portable denotations
only when a pathname's directory component starts with :ABSOLUTE to
the claim that since "~/foo" wouldn't have a predictable denotation as
a CL namestring, there's no harm done treating the leading tilde as a
special character. (IMO this inference is faulty, because all
standard CL operators merge pathnames with *DEFAULT-PATHNAME-DEFAULTS*
before going to the file system, and so just because a physical
pathname's denotation isn't known at parse-time doesn't mean that it
won't have a denotation when the pathname is used with some filesystem
operation.)
> {
> int mres=mkdir("~");
> int fd=open("~/foo",O_WRONLY|O_CREAT);
> int size=write(fd,"hello",/5);
> ...
> }
>
> is valid POSIX code...
It might be valid, but it isn't /portable/ under POSIX. From the Open
Group Base Specifications Issue 6, IEE Std 1003.1, 2004 Edition
(a.k.a., SUSv3), section 4.6:
For a filename to be portable across implementations conforming to
IEEE Std 1003.1-2001, it shall consist only of the portable
filename character set as defined in
_Portable_Filename_Character_Set.
And "Portable Filename Character Set" is defined in 3.276:
The set of characters from which portable filenames are
constructed.
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
a b c d e f g h i j k l m n o p q r s t u v w x y z
0 1 2 3 4 5 6 7 8 9 . _ -
The last three characters are the period, underscore, and hyphen
characters, respectively.
> Happily, CL leave it to the implementation to allow the use of
> implementation dependant characters and syntax in pathnames:
>
> (with-open-file (in #P"~/foo")
> ...)
It is more or less a good thing that CL leaves this to implementors'
discretion, but IWBN if they also reliably supported escaping special
characters in their namestring parsers. For instance, Clisp (as of
version 2.39) does not:
$ cd /tmp
$ touch \~
$ ls -l \~
-rw-r--r-- 1 kreuter kreuter 0 2007-08-11 11:47 ~
$ clisp -q -norc
[1]> (file-write-date "~")
*** - no file name given: #P"/home/kreuter/"
The following restarts are available:
ABORT :R1 ABORT
Break 1 [2]> :a
[3]> (file-write-date "\\~")
*** - FILE-WRITE-DATE: file #P"/tmp/\\~" does not exist
The following restarts are available:
ABORT :R1 ABORT
Break 1 [4]> :a
[5]> (file-write-date "/tmp/~")
3395836038
Consequently, under (that version of) Clisp, ENOUGH-NAMESTRING is
arguably non-conforming, since (enough-namestring "/tmp/~" "/tmp/")
returns "~", but, as shown above, the namestring "~" is not sufficient
to identify that file.
(Note: I'm picking on Clisp here for no particular reason. AFAICT,
all implementations have flaws in the pathname system.)
--
RmK
In article <·······················@o61g2000hsh.googlegroups.com>,
Kaz Kylheku <········@gmail.com> wrote:
> On Aug 6, 8:40 pm, Slava Akhmechet <·········@gmail.com> wrote:
> > Is lisp supposed to understand that tilde (~) is a home directory on
> > unix machines?
>
> Except that ~ isn't a home directory on unix machines. This is syntax
> which is expanded by the shell. It is not understood in the kernel.
But the convention has been copied by a number of other programs. For
example, Emacs recognizes it when you respond to a pathname prompt. So
does scp in cases where the tilde is not in a context that the shell
would expand it automatically (e.g. "scp remote:~/foo/bar ."). So it's
understandable that some might not realize that it's not a built-in
feature of the system, but has to be recognized as a special case by
every program that wants to support it but doesn't get its filenames
from the command line.
--
Barry Margolin, ······@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***
Slava Akhmechet <·········@gmail.com> writes:
> Is lisp supposed to understand that tilde (~) is a home directory on
> unix machines? When I do (truename "~/") on SBCL 1.0.4 on Linux/X86, I
> get an error saying "~/" doesn't exist. I tried various combinations
> and pathnames, but I always get weird behavior when I use tilde. Is
> this to be expected?
Just for the record, CLISP understands the tilde.
Magnus