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