Deficiencies in addattr
|Reported by:||Pete||Owned by:||nobody|
|Component:||Applications/Command Line Tools||Version:||R1/Development|
|Has a Patch:||yes||Platform:||All|
The current addattr doesn't quite match its help text, wrt the kinds of values one can use for type codes.
Aside from the list of named types (which isn't actually quite complete compared to the choices in the source) the help says one can enter "numeric values", and gives both hex and decimal examples.
However, trying a hex value doesn't work -- only decimal numbers are accepted. This turns out to be because the sscanf format option is "%u" (actually B_SCNu32) which only handles decimal. It has to be B_SCNi32. (Which means it would be allowed to enter a negative value -- just not very sensible...)
The other example entry given is " 'ABCD' ", which apparently is meant to indicate that one can enter 'FourCC' direct type-code representations, but of course that won't work as shown because the shell will strip off the quotes. Escaping the quotes -- \'ABCD\' -- or adding a second layer -- "'ABCD'" -- does work but is not obvious. (I can't think of any other command line that requires such a convention.)
I suggest that another option should be added: "-c ABCD". The current way can still work, but the new option should be fairly evident to anyone.
I'm attaching a patch that addresses both these issues. For reference, here's the amended help test:
usage: addattr [-t type|-c code] [ -P ] attr value file1 [file2...] or: addattr [-f value-from-file] [-t type|-c code] [ -P ] attr file1 [file2...] -P : Don't resolve links The '-t' and '-c' options are alternatives; use one or the other. type is one of: string, mime, int, int32, uint32, llong, int64, uint64, float, double, bool, icon, time, raw or a numeric value (ie. 0x1234, 42, ...), or an escape-quoted type code, eg. \'MICN\' The default is "string" code is a four-char type ID (eg. MICN)
(Sorry -- I can't find a "Component" to enter this under...)