Script to prepend EML Date

Just in case anyone else needs this.

// Prepend EML Date: as YYYY-MM-DD HHhMM e.g. https://i.imgur.com/2lK2VF6.png
for ( j = 1; ; j++ ) {
// Date: Thu, 31 Aug 2017 14:12:00 -0400
line = app.parseTags( '<File Line:'+j+'>' ) ; // WARNING AR replaces ':' by unknown character
// Date- Thu, 31 Aug 2017 14-12-00 -0400
if(line == '') throw new Error("No Date: found");
g = line.match(/^(?<n>Date.)?(?<v> (\w+, )?(?<d>\d+) (?<m>\w\w\w) (?<y>\d+) (?<h>\d\d).(?<i>\d\d).*$)?/).groups;
if(g.n !== undefined ) {
if( g.v === undefined) throw new Error("Bad Date")
monthn = "Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec".split(' ').indexOf(g.m)+1
if(monthn < 1) throw new Error("Bad month");
dt = g.y+"-"+monthn.toString().padStart(2,'0')+"-"+g.d+" "+g.h+"h"+g.i
return dt + " "+ item.newBasename;
}
}

Any improvement suggestions gratefully received.

Reply to #1:

Nice work Chris! I like the match()...groups syntax. Since ARen just added named capture groups in v4 I never think of using it, so thanks for reminding me that it is now available.

If I can make one small suggestion, or at least personal preference for my workflow, I personally wouldn't use the "throw... error" syntax, since an error in one file causes the whole batch to fail. Again, just personally, I'd use something like:

if(line == '') {app.log("No Date found- file #: " + (index+1) + "; line: "+line); return } ;

...so you can still run the batch and rename the files that don't have errors. OR, before running, you can use the files-list context menu to remove unchanged. There are a lot of ways to deal with the unchanged files, but that's just my .02

(BTW, you'd think that "Remove special / remove erroneous items" would take out just the filenames that "throw...error" touches, but that's not the case, at least in my experience. It doesn't seem to work on errors created by throw... error. Maybe not even javascript errors in general, I don't remember since I don't tend to work that way.

Best,
DF

Reply to #2:

Thanks DF.

> I personally wouldn't use the "throw... error" syntax, since an error in one file causes the whole batch to fail.

Understood. That's the behaviour that most suits me, since in my use it's imperative that no error gets overlooked. But I can understand a milder response might suit others. Unfortunately for me, app.log() out is invisible by default and so would get overlooked by me.

Having said which, it is causing me a problem, which might be related to the one you report. This first file is Error OK - but adding an intended-erroring file causes that first file to report an error: https://i.imgur.com/oCLLGkr.png . And despite that the addition is below. Looks like a bug to me. o way should one file's result affect another.

Reply to #3:

Exactly, Chris,

> This first file is Error OK - but adding an intended-erroring file causes that first file to report an error

That's the behavior I was mentioning. And you don't need to be able to see the app.log output, or even add it, because just throwing in that "return" at the end causes the filename to be unchanged and no error message for such problems. So executing the batch works on the files that can be changed, but the others are unchanged.

Best,
DF

Reply to #4:

> That's the behavior I was mentioning.

Thanks for the confirmation DF.

I'll post a report with minimal test separately.

> just throwing in that "return" at the end causes the filename to be unchanged and no error message for such problems. So executing the batch works on the files that can be changed, but the others are unchanged.

Verified: https://i.imgur.com/dXVoCFW.png . (Though given that's undefined behaviour (Help does not say that returning undefined leaves the files unchanged) it is not something I personally would feel safe relying upon.)

However such ignoring errors doesn't work for me. "No Date: found" is critical so I do need it to be handled as a fatal error or at least a reported error. I accept other use cases may differ.

So it looks like for the moment I am stuck with "throw error" and its reporting problem.

Reply to #5:

Hi Chris,

If you are not comfortable with just "return" you can always use "return item.newBasename". That always returns the filename that was passed to the script method in question. Or "return item.name" will return the original filename passed to ARen (only different from item.newBasename if you have other methods before the script that have changed the original filename).

Best,
DF

Reply to #6:

> If you are not comfortable with just "return" you can always use "return item.newBasename".

Thanks.