Unsolved
This post is more than 5 years old
9 Posts
0
79612
July 20th, 2014 09:00
Passing Arguments to External Command in OME using Alert Application Launch - How to obtain multi-line strings
Dear Dell,
Using the external command functionality included in Dell OpenManage Essentials (Alert Application Launch) is there a way to pass the multi-line string arguments as variables?
As unfortunately some of the alerts that are generated are contained in strings that span across multiple lines (\n \r characters).
As a result of this when passing these arguments to an external command the majority of the contents of the string are lost as it is contained on the next line e.g. output of $m for a redundancy lost alert:
"Redundancy lost
Redundancy unit: System Board PS Redundancy
Chassis location: Main System Chassis
Previous redundancy state was: Normal"
As a result the above when passed as an argument will only provide "Redundancy lost" and not provide information for the rest of the alert.
Is there a hotfix available to only parse the string contained in $m as a single-line instead of multi-line so that it can be passed as a variable via an external command?
As unfortunately the standard windows shell does not handle new lines (LF, etc) without using '^' character and since the result is already parsed it is unable to be escaped.
The only possible workaround is to pass all of the arguments to a text file to be read.
Unfortunately this method can cause possible race condition issues when alerts are received on the exact same interval. Which would then require another command to run on a different schedule to then read the contents line by line.
I'm surprised the $m argument does not already facilitate to trim all '\n\r' characters from the alerts parsed in order for them to be passed as arguments via the command-line. Looking forward to a hotfix or patch to make this task easier.
Keep up the great work :emotion-2:
Looking forward to a solution.
DELL-Rob C
3 Apprentice
•
2.8K Posts
0
July 21st, 2014 07:00
Hi and thanks for the post.
Yeah, the various device instrumentation may include these chars (\n\r) in the event itself. You may try double quotes around $m, perhaps that would work, but I've not tested.
You may need to open a ticket so they can review and capture any issues you have come across (800-945-3355).
Thanks,
Rob
Trent B
2 Posts
0
August 11th, 2014 22:00
I'm having a similar issue, I'm trying to pass a couple of different args into a powershell script and convert to a JSON object. If I include $m I get no output at all. I can omit that arg and everything is appended to my JSON file correctly.
DELL-Rob C
3 Apprentice
•
2.8K Posts
0
August 13th, 2014 11:00
Hi Trent,
Are you using single quotes?
Thx
Rob
www.delltechcenter.com/ome
NioByte
9 Posts
0
May 7th, 2015 14:00
Any chance that this can be addressed in the current or future version of the product? As it has been identified that the same issue occurs using the PowerShell CLI method as well.
DELL-Rob C
3 Apprentice
•
2.8K Posts
0
May 7th, 2015 14:00
Will check...did using double quotes make any difference or did you see the same behavior?
Rob
NioByte
9 Posts
0
May 7th, 2015 15:00
Hi Rob,
I have exhausted all possible combinations, none of them work.
Also trying to remove the CR,LF and other characters does not fix this issue. It appears the actual internal 'External Command' call function is not parsing the complete line. So it appears to be at the pre-processing stage.
As I did test with my own message text using my method. Entered a message that contained multiple CR and LF characters and these were removed successfully.
Yet when performing this through Dell OME via 'External Command' it does not parse the whole line. This is why I think it is not even completely parsed in the pre-processing stage to the $m argument.
If this can be confirmed, this will be ideal.
DELL-Rob C
3 Apprentice
•
2.8K Posts
0
May 7th, 2015 15:00
got it. Will pass this info along. If you happen to open a ticket at 800-945-3355 it might help it get traction as well. I'll report back what else I hear on this.
Thanks,
Rob
NioByte
9 Posts
0
May 7th, 2015 15:00
Thanks.
NioByte
9 Posts
0
May 28th, 2015 03:00
Any update on this?
DELL-Rob C
3 Apprentice
•
2.8K Posts
1
May 28th, 2015 07:00
Hi there,
Right, so the issue along with the details of this post have been passed along to the development team for review. They are looking to see if it is something that can be addressed in the upcoming release of OME. But I don't have timelines that I can announce here.
It should be easy to reproduce. Only that it is somewhat dependent on the instrumentation that is sending out the text. Still, it seems like OME can do some formatting if needed.
Regards,
Rob
NioByte
9 Posts
0
May 28th, 2015 16:00
Hi Rob,
Thanks for the prompt update. :emotion-1:
DELL-Rob C
3 Apprentice
•
2.8K Posts
1
June 29th, 2015 10:00
Right....it looks like an issue was opened for tracking based on this thread. I can't commit to a fix, but I know that it _is_ being reviewed and scoped during this current development effort. So it is possible a fix might be delivered in the next release of OME. I don't have any official dates, but I would expect to see a release later this year.
Thanks,
Rob
NioByte
9 Posts
0
June 29th, 2015 10:00
Any further update on this?
Were R&D able to investigate this further?
Will this enhancement be introduced in a later release of the product?
Any further information on this will be greatly appreciated.
NioByte
9 Posts
0
June 29th, 2015 11:00
Hi Rob,
Thanks for the prompt update and further information.
Looking forward to seeing this available in a future release.
Trent B
2 Posts
0
June 29th, 2015 12:00
FYI...I solved my particular issue by enclosing $m in single quotations