Re: Elementary fie naming question
Re: Elementary fie naming question
- Subject: Re: Elementary fie naming question
- From: Axel Luttgens <email@hidden>
- Date: Sun, 11 Jan 2004 19:06:55 +0100
(sorry Ken, again forgot to change to "To:" field...)
Graff wrote:
It is generally a bad idea to use certain characters in names.
I really felt uncomfortable with your reply, as it seemed very unrelated
to my initial post.
But again, I'm not sure not to have missed something.
So I'm back ;-)
Those characters are mainly forward slashes (/) and colons (:). The
forward slash is a path delimiter for the shell environment and the
colon is a path delimiter for the Finder.
It used to be that if you specified a date as part of a name in the
Finder and it had a format of xx/xx/xx it would automatically change
to xx-xx-xx.
Damn! I never noticed this...
But you may never be sure, and as you insisted upon this, I immediately
woke my good old PB 170 with MacOS 7.5.5 and gave this a trial.
No problem: I renamed a folder as "Dossier 03/03/99" and it happily kept
that name unchanged.
Should I go back to Finder 4.1?
It now looks like the Finder leaves that untouched, which is
potentially a bad thing. If a shell tool is used on a name that has
forward slashes in it then that name could get misinterpreted. For
example a file with the name aaa/bbb in the Desktop folder would be
referenced like this in the shell:
/Users/username/Desktop/aaa/bbb
No; as I wrote, it would be:
/Users/username/Desktop/aaa:bbb
because of a nice trickery used by the Finder in order to avoid problems
with the underlying unix file system, while allowing compatibility with
the full line of MacOS behaviors (conversely, a file/folder created in
unix with a ":" in its name would display a "/" in the Finder).
From the Finder's point of view, there is a slash in the name.
From a unix point of view, there is a semicolon in the name.
So, when I create a file named "aaa/bbb" in the finder and stay in the
finder, I'll use that name to refer to that file.
Now, if for some reason I need to work on that file from within unix, I
know I will have to use "aaa:bbb" as the file's name.
What's the problem?
Moreover, you even have the tools to transparently and consistently
manage such conventions. For example:
POSIX path of file "SartupDisk:aaa/bbb"
--> "/aaa:bbb"
To the shell that looks like file bbb in directory aaa in directory
Desktop, and so on.
Your argument is fallacious.
You spoke above about a Finder file on the desktop, say:
StartupDisk:Users:username:Desktop:aaa/bbb
and (erroneously) said that it would be appear as:
/Users/username/Desktop/aaa/bbb
So, tell me why you removed the disk name, converted the ":" into "/",
but left the "/" unchanged?
That is, you definitely know that Finder paths and unix ones don't have
the same semantics, but still try to create a semantic confusion to
prove your point.
The same thing happens for files with a colon in them in the Finder,
although it is rarer to have a problem there due to the fact that the
Finder doesn't depend on paths as much.
No? In what sense?
Here's how the file aaa:bbb looks in the Finder:
Macintosh HD:Users:username:Desktop:aaa:bbb
???
Again, a similar problem to the shell, the Finder can sometimes
interpret this as file bbb in folder aaa in folder Desktop, and so on.
Again, only if you just take a string literal from unix and use it as is
in the Finder.
But the bug would then be yours...
Another example of confusion, I named a folder "Date 10/20/02" on the
Desktop in the Finder. When I did a listing of the Desktop through
the shell environment that same folder was named "Date 10:20:02".
Didn't I precisely write that in my previous post?
This sort of conversion is useful under certain circumstances but it
also has potential to cause big problems.
No, if you don't logically confuse the Finder environment with the unix one.
Best bet is to entirely avoid using forward slashes and colons in
your file and folder names. This will steer clear of any confusion
and bugs that might pop up due to the handling of those file names.
That's yet another debate.
But yes, as soon as I know that a file is going to be used under various
environments (MacOS, unix, windoze, file sharing, web serving...), I
tend to become very conservative for naming it. [1]
And your argument about bugs is not to be understated [2].
We thus agree on something ;-)
- Ken
Axel
[1] Even the Finder doesn't allow everything; just try from the Finder
to create a file named "aaa/bbb" (or "aaa\bbb" or "aaa:bbb") on a DOS or
UFS volume.
[2] For example, I remember a multi-platform software that used to
internally store file paths as unix-like ones; sounded a good idea (from
a code maintenance point of view) until it encountered a file such as
"Disk:Desktop Folder:aaa/bbb", stored its path as, say, "/Disk/Desktop
Folder/aaa/bbb" and later tried to access that file...
And note that what appeared as a VBI (very bad idea) didn't need an
environment change (eg. Finder vs unix); it just went about lost
one-to-one mappings.
On Jan 10, 2004, at 12:31 PM, Axel Luttgens wrote:
Graff wrote:
The problem is the underlying Unix-like nature of Mac OS X. You
can't have a file name that has a slash (/) in it because that
character is used for separating directories. In the Finder all
slashes (/) are automatically translated to dashes (-).
I'm not sure to fully understand what you mean.
This one:
tell application "Finder"
make new file at desktop with properties {name:"aaa/bbb"}
end tell
--> document file "aaa/bbb" of folder "Desktop"...
allows to create a file named "aaa/bbb" that appears as such on the
Desktop.
On the other hand, doing an ls in the shell, I get:
-rw-r--r-- 1 luttgens luttgens 0 10 Jan 18:19 aaa:bbb
That is, a substitution occured, but with a ":" (quite a nice trick).
Weren't you in fact thinking about the impossibility to create, in
the Finder, an item whose name contains a ":"?
_______________________________________________
applescript-users mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/applescript-users
Do not post admin requests to the list. They will be ignored.