iwextattr

So I am trying to get my generate content to perform better. I suspect it is do to the multiple iwexattr -s I do.

Since a generated file takes 3 calls, if I can push this down to 1, that will help.

The problem is that iwextattr does not seem to take STDIN for the XML. You have to specify a file.

So instead of calling iwextattr -s 3 times, I have to open a file, write the XML then run iwextattr. That is not going to help.

Am I missing something ?

Andy

Find more posts tagged with

Comments

Adam Stoller

So I am trying to get my generate content to perform better. I suspect it is do to the multiple iwexattr -s I do.

Since a generated file takes 3 calls, if I can push this down to 1, that will help.

The problem is that iwextattr does not seem to take STDIN for the XML. You have to specify a file.

So instead of calling iwextattr -s 3 times, I have to open a file, write the XML then run iwextattr. That is not going to help.

Am I missing something ?

Andy

you should be able to run iwextattr with a pipe and print the XML into it - e.g.:

my $xml = qq(...);
if (open(PIPE, "|$iwextattr -s $file")){
    print PIPE $xml;
    close(PIPE);
}

or something like that.

LeggMan

Another way to set multiple attributes in one call is to use the -x option...

The format of the input file can be obtained by running iwextattr on a file with just the -x option: "iwextattr -x vpath2yourfile"

After creating your update XML per the format obtained above, set your EAs with this: "iwextattr -s -x < xmlfile vpath2yourfile"

Adam Stoller

Another way to set multiple attributes in one call is to use the -x option...

The format of the input file can be obtained by running iwextattr on a file with just the -x option: "iwextattr -x vpath2yourfile"

After creating your update XML per the format obtained above, set your EAs with this: "iwextattr -s -x < xmlfile vpath2yourfile"

Sigh - I apparently left that off my previous posting - it should have been:

you should be able to run iwextattr with a pipe and print the XML into it - e.g.:
my $xml = qq(...);
if (open(PIPE, "|$iwextattr -s -x $file")){
    print PIPE $xml;
    close(PIPE);
}
or something like that.

Where

$xml

would be the appropriate XML for setting one or multiple EAs in XML format - as one would get from looking at the output of iwextattr -l -x vpath.

If you want to copy EAs from one file to another you can basically do:

iwextattr -l -x vpath1 | iwextattr -s -x vpath2

and it should work - though I seem to recall that the first part may give you empty XML elements for EAs that have no value and the second part may give you a warning/error message when processing empty XML elements for values ... but I believe it still actually works correctly.

LeggMan

I'd like to confirm that the ghoti's latest code snippet (with "PIPE") is syntactically correct and enormously useful. Setting 14 metadata items with this approach in a batch process involving 1,400 files resulted in reducing run time from a half hour to less than 15 minutes.

Meanwhile... How would one do error trapping with this technique? The usual tricks that work with backticked commands don't apply and eval{} isn't useful. I had to keep an eye on the console for variations in print output to find error messages relating to malformed XML (encoding HTML entities took care of that) and "not CDATA" errors for null s (using " " for a value suppressed those).

Adam Stoller

I'd like to confirm that the ghoti's latest code snippet (with "PIPE") is syntactically correct and enormously useful. Setting 14 metadata items with this approach in a batch process involving 1,400 files resulted in reducing run time from a half hour to less than 15 minutes.

Meanwhile... How would one do error trapping with this technique? The usual tricks that work with backticked commands don't apply and eval{} isn't useful. I had to keep an eye on the console for variations in print output to find error messages relating to malformed XML (encoding <value> HTML entities took care of that) and "not CDATA" errors for null <value>s (using " " for a value suppressed those).

I believe you can check

after the

statement - you might even be able to check the return status from

itself (usually ignored, it does return true/false values ...)

However, I believe the null <value> error can be ignored (I seem to recall someone saying that before when I noted it in a thread here) - but it's best to double-check and verify rather than take my word for it.

LeggMan

Thanks for the suggestion. Unfortunately, $! and $? report nil and 0 respectively whether there's a "CDATA error" or not. OK... that should really just be considered a warning.

When I don't encode the HTML and let one of the Gang of Five Entities slip in as a , $? reports a 256 so I guess that will have to suffice for error trapping.

Adam Stoller

(minor edit to show the code -- if you're going to embed XML/HTML directives within your text -- as opposed to within [html]...[/html] tags -- either put a space after the '<' or write it as

<<x>

.. ugly, but it works ...)

Thanks for the suggestion. Unfortunately, $! and $? report nil and 0 respectively whether there's a "CDATA error" or not. OK... that should really just be considered a warning.

When I don't encode the HTML and let one of the Gang of Five Entities slip in as a <value>, $? reports a 256 so I guess that will have to suffice for error trapping.

I wonder if CSSDK provides a better mechanism for this - though personally I still prefer coding in Perl ...