ykpersonalize exit status

186 views
Skip to first unread message

Greg Woods

unread,
Sep 4, 2009, 5:00:57 PM9/4/09
to yubico...@googlegroups.com
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.

Is this a known issue that has since been fixed?

--Greg


Tollef Fog Heen

unread,
Sep 5, 2009, 4:45:09 AM9/5/09
to yubico...@googlegroups.com
]] Greg Woods

| 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

Simon Josefsson

unread,
Sep 8, 2009, 4:48:32 AM9/8/09
to yubico...@googlegroups.com
Greg Woods <wo...@ucar.edu> writes:

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

Greg Woods

unread,
Sep 8, 2009, 3:13:49 PM9/8/09
to yubico...@googlegroups.com
On Tue, 2009-09-08 at 10:48 +0200, Simon Josefsson wrote:
> Greg Woods <wo...@ucar.edu> writes:
>
> > 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.

> 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


Greg Woods

unread,
Sep 8, 2009, 3:45:47 PM9/8/09
to yubico...@googlegroups.com
On Tue, 2009-09-08 at 13:13 -0600, Greg Woods wrote:
> the "hexfixed" option has been
> removed, which broke my script.

...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


Simon Josefsson

unread,
Sep 8, 2009, 4:09:44 PM9/8/09
to yubico...@googlegroups.com, lev...@yubico.com
Greg Woods <wo...@ucar.edu> writes:

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

Simon Josefsson

unread,
Sep 8, 2009, 4:12:44 PM9/8/09
to yubico...@googlegroups.com
Greg Woods <wo...@ucar.edu> writes:

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

Reply all
Reply to author
Forward
0 new messages