nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

TS 5.5.1 - iwextattr.exe

sjpfist

Hello,

Has anyone tried to call the 5.5.1 version of iwextattr.exe from Perl in workflow? We are having a problem where it returns nothing when we do the following:

$command = "iwextattr.exe -g SomeName SomePath"
$someVal = `$command`;

We always seem to get nothing back in the 5.5.1 build where we have before in 5.5 beta and our previous build of 4.5.1.

The funny thing about all this is that we can get the EA's from the command line, but not WF. It also returns EA lists different from that of the previous builds. For example:

iwextattr.exe -l SomePath

This returns the following:

value.....Name....

Where the previous builds return:
Name=Value
...
Name=Value

Heck, even that shows up different when run in wf. Just checking to see if anyone else has the same problem.

Steve

Find more posts tagged with

Comments

PaulHoughton

Try using the -u switch that they have introduced in the 5.5.1 version, this seems to solve a lot of problems regarding what is returned by iwextattr

sjpfist

Yeah, that's the feedback I got from IW... Anyways, the problem with iwextattr.exe -g is that it does not return a null-terminated string. I guess a fix will be available later on.

Steve

hillaryc

I ran into the same issue a few weeks ago - the message I received from IWOV is there is a bug with using iwextattr in workflows. A patch has been created and is in QA. Not sure when it is due to come out to the general public but I was able to get the patch from IWOV and it solved the problem.

Gregg Faus

I'm running into this same issue. Everything works great when I run an external command that the workflow would invoke. But when the script is run within the entire workflow, my iwextattr command doesn't return anything.

Guess I will have to contact support for the Windows patch.

-gf

Gregg Faus

I got the patch from Interwoven. Initially I thought it didn't work, but I had to use the correct syntax. Use this syntax if you are extracting attributes from a workflow:

$result = `iwextattr -g attr -f file`;

-gf

Migrateduser

This problem is fixed in TS 5.5.2.

Gregg Faus

Yep. That is what I was told. Alas, it has not been released within the download section as of 6/24/02.

I'm looking forward to some of the other fixes as well.

Migrateduser

TS 5.5.2 is now available for download from the Support area of the Interwoven Web site (it was posted on 6/30/2002).

plazm

We've just upgraded to 5.5.2. The problem still persists.

Gregg Faus

Are you using the -f switch?

plazm

Yes.
`iwextattr -g "TeamSite/Templating/DCR/Type" -f $file_path`

gives me the thing I need when I run the script from the command line. The same script prints nothing to the log file when run from an external task.

Is there a separate patch available for this CLT nd how to get it?

Edited by plazm on 08/14/02 02:36 PM (server time).

Migrateduser

You will need the iwextattr from TS 5.5.2. I would highly encourage you to look at upgrading to this version rather than staying on TS5.5.1.

plazm

I DID upgrade to 5.5.2. In fact it was the only reason I made this upgrade. But it looks like it still has problems with reading metadata from within workflows.

StreamServe-Project-Life-Cycle.JPG

felipel

This thread's a little old, but I'm wondering if someone has a "patched" version of iwextattr for TS 5.0.2 (Windows)? I've opened a case with IW to get the alleged patched version, but thought someone out here might be able to help sooner. Thanks!

Adam Stoller

I don't believe you need a patch for iwextattr here - I believe the problem has to do with at least one of the three standard file handlers (stdin, stdout, stderr) not being handled correctly within workflow context which necessitates having commands like `my-command` having to sometimes be written as: `my-command > /some/temp/file` - and then reading in the results from that temp file.

This was a known problem (#32914) and appears to be fixed for 5.5.2 SP2 and possibly 5.0.2 SP1.

If you cannot get `my-command` to work, but redirecting the output into a temporary file and reading it in from that file works - and you're using either 5.5.2 SP2 or 5.0.2 SP1 - please notify Interwoven Support. If you are not using one of those versions, you will probably have to use the redirection work-around or upgrade.

--fish
(Interwoven, Curriculum Development)

felipel

Just wanted to post a follow-up for anyone tracking this post. Fish's suggestions both were correct and resolved the problem. I was able to work around the problem by re-directing the output to a temp file. 5.0.2 SP1 also resolves the issue. Thanks for the help!