Hi Kazutaka. MORITA Kazutaka <morita.kazutaka at lab.ntt.co.jp> writes: > On second thought, "setattr/getattr" looks better to me because it is > like an extended attribute of a file. And if so, it may be better > that "setattr" reads a value from stdin like the attr command by > default; > > $ collie vdi setattr [key] < value_file > or > $ collie vdi setattr [key] -V [value] I prefer this design too. For our purposes, I just hope to store short text values in a handful of these keys, but this interface has the advantage that it's eight-bit clean for people who want that. Could probably get away with $ collie vdi setattr KEY < value_file $ collie vdi setattr KEY VALUE as you can cleanly distinguish between the two cases by the presence or absence of a VALUE argument. > In that case, to unset key, a delete option would be required. > > $ collie vdi setattr [key] -d > > > > > In an ideal world, it would be good to have some sort of > > no-clobber/exclusive mechanism too. For example: > > > > $ collie vdi setdata [key] [value] exclusive > > > > which if [key] is unset, sets it to value [value], or if it is set, fails > > with non-zero exit code. (This could be used by a management layer to > > implement exclusive access to drives, for example.) > > Yes, it would be useful to have the feature. Perhaps a -x argument to specify exclusive/no-clobber behaviour, so the final syntax might be $ collie vdi getattr KEY $ collie vdi setattr KEY [-x] < VALUEFILE $ collie vdi setattr KEY [-x] VALUE $ collie vdi setattr KEY -d with getattr returning the value on STDOUT and exit status 0, or exit status != 0 if the key doesn't exist, and setattr returning exit status != 0 if the key does exist and -x is given. Best wishes, Chris. |