Hi kre, > The point is that the "try this" or "try this" ... stuff in order to > find an arg sequence for date that works also allows invalid values > for the input time to be ignored,
You still seem to be referring to the first version I wrote? Here's the second one again that's being replied to. > > +fmt='%Y-%m-%d %T %z' > > +now=${SOURCE_DATE_EPOCH-$(date +%s)} > > +if date -u -d @42 +"$fmt" >/dev/null 2>&1; then # Coreutils. > > + date=$(date -u -d "@$now" +"$fmt") > > +elif date -u -r 42 +"$fmt" >/dev/null 2>&1; then # BSD. > > + date=$(date -u -r "$now" +"$fmt") > > +else # Posix, ignoring SOURCE_DATE_EPOCH. > > + date=$(date -u +"$fmt") > > +fi > > that is, on a system that does not support > > date -d @NNN .... > > date will (should) fail, but on a system where -d @NNN is > supported, date will fail if NNN is invalid, and given stderr is > sent o /dev/null, will fail in a more or less indistinguishable way. The first invocation of `date -d @NNN' uses `42', not the user's $SOURCE_DATE_EPOCH and discards stderr. If its exit value is good then the second `date -d @NNN' uses $SOURCE_DATE_EPOCH and doesn't discard stderr, nor the exit value. > if [ "${SOURCE_DATE_EPOCH+set}" ] > then > case "${SOURCE_DATE_EPOCH}" in > '' | *[!0-9]*) > printf '%s\n' >&2 \ > "Invalid SOURCE_DATE_EPOCH='${SOURCE_DATE_EPOCH}'" > exit 1 > ;; > esac > fii > > or something along those lines. That way at least the source of the > problem is known. Well, it spots some flaws with SOURCE_DATE_EPOCH. $ n=67768036191676799 $ date -ud @$n 2147485547-12-31 23:59:59 +0000 Wed $ let n++ $ date -ud @$n /bin/date: time ‘67768036191676800’ is out of range $ > If you do that, you don't need to rely as much upon versions of date > doing proper error checking of their input (I have no idea how good > NetBSD is at detecting a bad value after date -d@... (which is > supported, as is -r) for example, it might just convert digits and > ignore later noise. Yes, they might fling it at atoi(3), I agree. I don't think that's nmh's look out, and date is best off checking the parameter. > ps: -e is one of the lest relaible features of sh (not in > implementations, so much, but its definition, and then usage > expectations) - it is best not to rely upon it, and rather add "|| > fail Message" after any command that you actually want to check the > exit status off (where fail is a function that DTRT). OK, but I want all of them checked apart from those I explicitly `|| true'. That suggests a lot of clutter, or a lot of `&&' chaining before the `|| true'. -- Cheers, Ralph. https://plus.google.com/+RalphCorderoy -- nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers