Re: finding newest file in a folder
Re: finding newest file in a folder
- Subject: Re: finding newest file in a folder
- From: Christopher Nebel <email@hidden>
- Date: Mon, 15 Mar 2004 15:13:43 -0800
On Mar 15, 2004, at 12:52 PM, Deivy Petrescu wrote:
The "-1" is superfluous, since ls(1) is defined to output one item
per line unless the device is a terminal, which "do shell script"
isn't.
I would suggest leaving it there, then 1. It is not a big overhead and
it makes life easier when debugging.
True enough.
Both coercions are also superfluous, since "POSIX path" is only
accidentally a property of strings, and "do shell script" already
returns Unicode text.
The second coercion is wrong and it stayed because I did not see it on
the last draft. However my problem is with the first coercion. You
said that " "POSIX path" is only accidentally a property of
strings". I have some problems with that.
Your mentioned problems don't have anything to do with what I was
referring to, but for others listening, the point was that "POSIX path"
is only defined to be a property of "file" and "alias" objects. It
happens to work on strings and Unicode text as well, but that's an
accident.
Posix path is not really a path. Just leave an space in your file or
folder name and your "one path" becomes 2 paths. And it is also not
text. As I was just checking, it does handle some high (apple) ascii
characters. I am not 100% certain that it handles general Unicode
text, although I am thinking of certain examples by John Delacour that
it indicates it does.
POSIX paths are allowed to have spaces in them. You're confusing path
syntax with shell argument parsing -- they're not the same thing. As
for handling Unicode, it should work fine. There was a bug in "do
shell script" in 1.8 where non-ASCII characters wouldn't work -- there
was some encoding confusion -- but that was straightened out in 1.8.3.
My point is, I believe that Posix path should return the quoted form
or the posix path. After all if I want a path, I want a path, give it
quoted if necessary. So if necessary, please understand this as a
request for AS. Makes it simpler and more logical.
This is addressed in TN2065. First, there are uses for paths other
than passing them as arguments to "do shell script", and quoting them
would be incorrect in such cases. Second, "quoted form" is useful for
many things other than paths. Therefore, we created two orthogonal
operations instead of one fused one.
There is no need to mess around with text item delimiters when what
you want is lines, since "paragraph" elements will work just as well.
This is where I have a question. Between ASCII Character 10 and ASCII
Character 13, I am never sure which one is return and which one is the
Unix line ending, unless I use a script to compare. That is why I have
AC 13 instead of return. However, as I just found out, paragraph
(which varies according to the context) is much broader than I
thought. I use TID because I was not sure that any line ending would
make a line a paragraph.
This script startled me
set x to "paragraph 1" & return & "paragraph 2" & (ASCII character 10)
& "paragraph 3" & (ASCII character 13) & "paragraph 4" & (ASCII
character 10) & "paragraph 5"
set lista to {}
repeat with j from 1 to 5
set end of lista to paragraph j of x
end repeat
lista
-- {"paragraph 1", "paragraph 2", "paragraph 3", "paragraph 4",
"paragraph 5"}
So, this is expected, can we count in this behavior? That is, it is
more powerful than TIDs.
"paragraph" elements of a string may be separated by return (CR, ASCII
character 13, Mac-traditional), line-feed (LF, ASCII character 10,
Unix-traditional), CRLF (CR+LF, Windows-traditional), or the Unicode
PARAGRAPH SEPARATOR character (U+2029). This is official behavior.
The "return" property is normally set to ASCII character 13.
Finally, the above doesn't quote the file path, so it will fail if
the path contains spaces or other interesting punctuation. A more
correct version would be this:
set d to POSIX path of (path to "docs")
set k to paragraph 1 of (do shell script "ls -t " & quoted form of d)
display dialog k
Of course, this returns a POSIX path; to convert it back into
something useful outside the shell, say "POSIX file k".
No it doesn't, it returns the name of the item, you should have left
the -1 it is very useful debugging... :)
OK, I wrote that last bit without checking -- you're correct. Adding a
-1 flag wouldn't change anything, though. I'm not sure that there's
any way to get ls to print the complete path -- I normally use find(1)
when I want that.
--Chris Nebel
AppleScript Engineering
_______________________________________________
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.