#!/bin/bash
## NEWER -- succeeds if first file/dir-name NEWERTHAN 2nd -- by Eugene Reimer 2009-08-31;
## needed because bash's -nt operator does not work the way one wants when either comparand is a directory!!
## METHOD:  for a directory, we use the newer of timestamp from the dir or its newest subfile;

GLOBIGNORE="."										##so star works when globbing
if [ -d "$1" ];then A=$(ls -dt1 "$1"/{.,*} |head -n1);  else A="$1"; fi			##for 1st opnd a dir, get A = name of newest subfile|.
AT=$(ls -dl --time-style=+%s "$A" |arr 6)						##now get timestamp, in seconds, of file $A

if [ -d "$2" ];then B=$(ls -dt1 "$2"/{.,*} |head -n1);  else B="$2"; fi			##for 2nd opnd a dir, get B = name of newest subfile|.
BT=$(ls -dl --time-style=+%s "$B" |arr 6)						##now get timestamp, in seconds, of file $B

##echo "A:$A AT:$AT B:$B BT:$BT $(if ((AT>BT));then echo 'true';else echo 'false';fi)"	##DEBUG;  consider -vv param to show this, and -v for just true/false??
if ((AT>BT));then exit 0; else exit 1; fi						##return success if A newerthan B, failure otherwise


exit
======
NOTES:
======
I'm amazed by how long it's taken me to discover that a directory's mtime is not what I thought.  Mind you, the manpage on open says:
	"If the file is newly created, its atime, ctime, mtime fields are set to the current time, and so are the ctime and mtime fields of the parent directory"
and the first part of that statement holds for all "newly created" files, just not the second part, so the observed behaviour may well be a bug==??==
The observed behaviour being that replacing a file (creating a new file with the same name as an existing file) does NOT update the parent directory's mtime.

I started to write NEWEST to return name of newest subfile in specified directory, for use in $(newest D) -nt F comparisons, but changed plans before finishing.
Consider directory updated by mv'ing an old file into it:  regarding "." as one of the subfiles would handle that case, provided mv'ed subfile's name was new.
That got me considering using ctime comparisons rather than mtime;  eg: for my WEBPUT-LL timestamp-comparisons, 'tis safer to err on the side of too many uploads.
Unfortunately bash has no variant of "-nt" for comparing ctimes, and I like the readability, searchability, etc of the "-nt" notation, and dislike writing them 
as $(ctime F1) > $(ctime F2) -- where ctime would return a number.  AHA, I could live with NEWERTHAN F1 F2.  And that's what I've turned this into--!!--
More on using ctime: ought changes to permissions to count?  Yup, for my uploading example that would be even better than the way I thought -nt worked:-)
or would if lftp mirror could be made to use ctimes:-(  Will keep using mtimes for now;  having my comparisons as  NEWER A B  means a switch to ctime is easier.
Would ctime make it unnecessary to consider the dir's timestamp, ie: would timestamp of newest (by ctime) subfile suffice??  Nope - consider deletions!!

NOTE: wrote this so that mtime-->ctime switching is easy:  just add -c in ls  (ie: -dt1 --> -cdt1 and -dl --> -cdl);
NOTE: the touch command has no provision for altering ctime (to other than curtime)  ==> keep using mtime--!!--
NOTE: see file-command manpage:  mentions using utime(2) or utimes(2), to preserve the access time, ie: pretend that file never read them==!!==

CONSIDER:  switching to the stat command to retrieve & format the desired flavour of timestamp;  slightly simpler than using ls + arr==??==