On Sun, Aug 19, 2018 at 07:06:14PM -0400, Eric Sunshine wrote: > On Sun, Aug 19, 2018 at 5:50 PM brian m. carlson > <sandals@xxxxxxxxxxxxxxxxxxxx> wrote: > > I think what I'd like to do instead is store in a variable and make > > test_oid return unsuccessfully if the value doesn't exist. I think > > that's better for writing tests overall and will accomplish the same > > goal. > > My knee-jerk reaction is that could get clunky in practice, but > perhaps I'm not seeing the full picture. > > An alternative would be to return a distinguished error value. We already do it in several other places in the testsuite when we want to check the exit status of a command substitution, so I think it will end up being fine. I'd like to try it and see. I think that we need to fix the return code either way, though. > > Putting them in a separate directory makes it possible to do something > > like this: > > > > (cd t && ./t0002-* --verbose) > > > > and then use shell editing to change the command line. If we put them > > in the same directory as the tests, we make developers' lives a bit > > harder. > > Perhaps I'm missing something obvious, but I'm not following what > you're trying to convey. > > Okay, thinking upon this further, I guess you mean people who type > your example directly rather than using "./t0002-*.sh" or something. Right. It also makes completion nicer (in Vim at least). > I'm still open to the idea of supporting experimentation with other > hash algorithms and I see how lumping all the OID tables into a single > directory can make it easy to locate everything that will require > adjustment for a new algorithm. But, this information can also be > gleaned via a simple grep for "test_oid_cache", so I'm not sure the > lumped-directory approach buys much. > > Also, my gut feeling is that such experimentation will be very rare, > whereas the addition of new tests which have some sort of > OID-dependency will likely be a more frequent occurrence. And, the > locality of an OID-table plopped down right next to the test which > requires it seems a win (in my mind). Okay. I'll do that, and we'll see how it works. > However, I'm sympathetic to the ugliness each caller having to specify > "$TEST_DIRECTORY/...". In my review of 2/11, I suggested the idea of a > test_oid_init() function which could load those common OID tables for > scripts which need them, thus hiding that ugliness. Another idea which > has some appeal is to define an $OIDDB variable (or some such name) > with value "$TEST_DIRECTORY/oid-info", which lets callers use: > > test_oid_cache <"$OIDDB/bloop" > > which isn't so bad. I'll stuff in a test_oid_init function. I think I like that approach the best. -- brian m. carlson: Houston, Texas, US OpenPGP: https://keybase.io/bk2204
Attachment:
signature.asc
Description: PGP signature
