Is this a known issue that has since been fixed?
--Greg
| I'm running ykpersonalize version 0.93 (I know that's not the latest). I
| have noticed that it will happily exit with zero status if it is run
| without a Yubikey plugged in. It reports a Yubikey core write error on
| stdout, but I think that should cause an error exit status that could be
| detected when it is run in a script.
: tfheen@qurzaw ..96/build-x86_64-linux-gnu > ./ykpersonalize
Yubikey core error: no yubikey present
: tfheen@qurzaw ..96/build-x86_64-linux-gnu > echo $?
0
Doesn't seem to be fixed (in 0.96)
--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are
I fixed it in r181:
http://code.google.com/p/yubikey-personalization/source/detail?r=181#
I will release 0.98 with this change now.
Thanks,
/Simon
> I fixed it in r181:
I confirmed that this issue is fixed, but the "hexfixed" option has been
removed, which broke my script. I am now going to have to hassle with
converting to modhex first. Was there some reason for removing hexfixed?
--Greg
...and, in case anyone else runs into this, the -c and -oaccess flags
have been changed between 0.93 and 0.98 to require hex instead of
modhex. This hex/modhex thing gives me a headache :-)
--Greg
Richard changed parsing of value fields so that you can specify
'h:hexvalue' or 'm:modhexvalue' to specify all values in either hex or
modhex respectively. This avoids the need for having separate parameter
names for hex and modhex variants of the same parameter.
/Simon
See NEWS file for 0.96:
** Make all input numbers hex by default.
It's still possible to give modhex numbers by preceding them with
`m:'.
I know it broke backwards compatibility to change this, but we hope the
current approach is more reasonable. Since 0.96 we promise to maintain
backwards compatibility forever -- if we want to change the interface in
a backwards incompatible manner, we'll do so under a new tool name.
/Simon