downloaded the source from trunk. Most of my issues with the openmeta cli an be changed easily as most of the functionallity is already in the code:
- changed the special treatment of commas (silly assumption a user expect commas to be treated as a delimiter on commandline tool) - changed '-v' to make openmeta cli verbose, not to make it silent (look at other cli tools: admins make a utility verbose by ADDING '- v') - added new switch '-x <keyname>' , but this does not work so far
not to far away from a 'mdset <keyname> <attribute> <file>' tool
=:-)f
On 1 Mrz., 11:17, mc23646266 <u...@23646266.net> wrote:
ok, after some more slight changes I almost got a 'mdset' version of openmeta cli.
@tom.andersen I can set an kMDItem.. attribute to a file with '-s' and get it listed by mdls! (kMDItemIdentifier) If I do add the same kMDItem... attribute to a file, mdls does NOT list it, it seems to be erased.
I don't think I changed much in openmeta cli code, and did not change anything about '-a', '-s'. So I do not understand why its deleted when ADDING.
Do leap, yep, ... call the CLI?
=:-)f
On 3 Mrz., 00:32, mc23646266 <u...@23646266.net> wrote:
> downloaded the source from trunk. > Most of my issues with the openmeta cli an be changed easily as most > of the functionallity is already in the code:
> - changed the special treatment of commas (silly assumption a user > expect commas to be treated as a delimiter on commandline tool) > - changed '-v' to make openmeta cli verbose, not to make it silent > (look at other cli tools: admins make a utility verbose by ADDING '- > v') > - added new switch '-x <keyname>' , but this does not work so far
> not to far away from a 'mdset <keyname> <attribute> <file>' tool
> =:-)f
> On 1 Mrz., 11:17, mc23646266 <u...@23646266.net> wrote:
> > there are some bug-reports open for the openmeta cli for a long time, > > which are not 'accepted' and not cared about.
> > I'd like to have a 'mdset' utility also, with which it would be > > possible to > > set arbitrary kMDItem* attributes at will from the commandline.
> > I am not a programmer, so I would need some experts with me to > > update and fix the openmeta cli code correctly.
When adding info - you have to remember that it only makes sense to add information that is an array. So if you have your own kMDItemIdentifier - it will likely not be setting an array of data.
try xattr -l in terminal after you set or add attributes. That's all the cli does is set xattr for you.
> ok, after some more slight changes I almost got a 'mdset' version of > openmeta cli.
> @tom.andersen > I can set an kMDItem.. attribute to a file with '-s' and get it listed > by mdls! (kMDItemIdentifier) > If I do add the same kMDItem... attribute to a file, mdls does NOT > list it, it seems to be erased.
> I don't think I changed much in openmeta cli code, and did not change > anything about '-a', '-s'. > So I do not understand why its deleted when ADDING.
> Do leap, yep, ... call the CLI?
> =:-)f
> On 3 Mrz., 00:32, mc23646266 <u...@23646266.net> wrote: >> downloaded the source from trunk. >> Most of my issues with the openmeta cli an be changed easily as most >> of the functionallity is already in the code:
>> - changed the special treatment of commas (silly assumption a user >> expect commas to be treated as a delimiter on commandline tool) >> - changed '-v' to make openmeta cli verbose, not to make it silent >> (look at other cli tools: admins make a utility verbose by ADDING '- >> v') >> - added new switch '-x <keyname>' , but this does not work so far
>> not to far away from a 'mdset <keyname> <attribute> <file>' tool
>> =:-)f
>> On 1 Mrz., 11:17, mc23646266 <u...@23646266.net> wrote:
>>> there are some bug-reports open for the openmeta cli for a long time, >>> which are not 'accepted' and not cared about.
>>> I'd like to have a 'mdset' utility also, with which it would be >>> possible to >>> set arbitrary kMDItem* attributes at will from the commandline.
>>> I am not a programmer, so I would need some experts with me to >>> update and fix the openmeta cli code correctly.
>>> greetz >>> =:-)f
> -- > You received this message because you are subscribed to the Google Groups "OpenMeta" group. > To post to this group, send email to openmeta@googlegroups.com. > To unsubscribe from this group, send email to openmeta+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/openmeta?hl=en.
@tom.andersen the problem with xattr is: it does not 'encode' the arguments to the required bin plist format, so it is useless to use it for setting attributes. ok, leap .... don't use the cli, nevertheless I do think there's something wrong here:
adding does definitly erase parts of the information!
------------------------- setting an attribute --------- then reading it --------------------------------------------------------------------------- -------------------- $ ~/Documents/openmeta-read-only/trunk/openmeta/build/Release/openmeta -x kMDItemIdentifier -s "mit zwei" -p ./bcedit.cfg $ ls -l@ bcedit.cfg
------------------------- ADDING an attribute --------- then reading it --------------------------------------------------------------------------- -------------------- $ ~/Documents/openmeta-read-only/trunk/openmeta/build/Release/openmeta -x kMDItemIdentifier -a "mit zwei" -p ./bcedit.cfg $ ls -l@ bcedit.cfg
@tom.andersen I cannot follow your thesis for: ' it only makes sense to add information that is an array'
there are a couple of attributes where an array does not make any sense: kMDItemAcquisitionModel, kMDItemAudioSampleRate, ...
from reading through the forums I believe you are rather fixed on 'tagging'. For me 'tagging' is only a small part of the whole metadata story.
Yes, there are many attributes which are best suited as arrays, but it simply depends on the case. No general assumptions, please. Let there be freedom of choice.
BTW: I just used the first array-element to set an arbitrary attribute when changing your code.
greetz
=:-)f
On 4 Mrz., 15:53, Tom Andersen <tom.ander...@gmail.com> wrote:
> -s 'sets' the information, erasing any previous.
> When adding info - you have to remember that it only makes sense to add information that is an array. So if you have your own kMDItemIdentifier - it will likely not be setting an array of data.
> try xattr -l in terminal after you set or add attributes. That's all the cli does is set xattr for you.
> @tom.andersen > I cannot follow your thesis for: ' it only makes sense to add > information that is an array'
> there are a couple of attributes where an array does not make any > sense: kMDItemAcquisitionModel, kMDItemAudioSampleRate, ...
> from reading through the forums I believe you are rather fixed on > 'tagging'. > For me 'tagging' is only a small part of the whole metadata story.
> Yes, there are many attributes which are best suited as arrays, but it > simply depends on the case. > No general assumptions, please. Let there be freedom of choice.
> BTW: I just used the first array-element to set an arbitrary > attribute when changing your code.
> greetz
> =:-)f
> On 4 Mrz., 15:53, Tom Andersen <tom.ander...@gmail.com> wrote: >> Leap and Yep, etc don't call the cli.
>> -s 'sets' the information, erasing any previous.
>> When adding info - you have to remember that it only makes sense to add information that is an array. So if you have your own kMDItemIdentifier - it will likely not be setting an array of data.
>> try xattr -l in terminal after you set or add attributes. That's all the cli does is set xattr for you.
>> --Tom
> -- > You received this message because you are subscribed to the Google Groups "OpenMeta" group. > To post to this group, send email to openmeta@googlegroups.com. > To unsubscribe from this group, send email to openmeta+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/openmeta?hl=en.
