• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag
 

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: finding newest file in a folder
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: finding newest file in a folder


  • Subject: Re: finding newest file in a folder
  • From: Deivy Petrescu <email@hidden>
  • Date: Mon, 15 Mar 2004 15:52:59 -0500

At 1:04 PM -0800 3/14/04, Christopher Nebel wrote:
On Mar 14, 2004, at 8:15 AM, Deivy Petrescu wrote:

John, if you do not mind you can use a straight forward method, shell script.
This requires no repeat:

<script>
set d to POSIX path of (path to "docs" as Unicode text)
set AppleScript's text item delimiters to ASCII character 13
set k to text item 1 of (do shell script " ls -t -1 " & d) as Unicode text
set AppleScript's text item delimiters to {""}
display dialog k
</script>

If you're going to do this sort of thing, you should do it right.

Chris, I generally take your word because you know AppleScript just a little tiny bit more than I do ... :>
However, now I have some comments , questions and suggestions.

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.

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. 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.
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.

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.

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... :)

Also, this and the more AppleScript-y versions mentioned all suffer from the same problem: they find the most recently modified *item*, which may not be a file. Correcting this in the Finder version merely requires changing "item" to "file". Correcting this in the shell version is less obvious; here's one way:

set k to paragraph 1 of (do shell script "ls -Ft " & quoted form of d & " | grep -v '/$')

This is certainly better, I knew you knew AS a little tiny bit more AS and some other stuff, than I do... :)


--Chris Nebel
AppleScript Engineering

--
Regards
Saudagues

Deivy
http://www.dicas.com
_______________________________________________
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.


  • Follow-Ups:
    • Re: finding newest file in a folder
      • From: Michelle Steiner <email@hidden>
    • Re: finding newest file in a folder
      • From: Christopher Nebel <email@hidden>
References: 
 >finding newest file in a folder (From: John Cochrane <email@hidden>)
 >Re: finding newest file in a folder (From: Deivy Petrescu <email@hidden>)
 >Re: finding newest file in a folder (From: Christopher Nebel <email@hidden>)

  • Prev by Date: applescript to get system version
  • Next by Date: Tabs in Project Builder
  • Previous by thread: Re: finding newest file in a folder
  • Next by thread: Re: finding newest file in a folder
  • Index(es):
    • Date
    • Thread