I need help fixing a Python script, but know ABSOLUTELY NOTHING about Python (though I am an experienced programmer so I get the jargon.)
I have this script that is trying to write output to a generated path, but when I run it, it gives me an error saying something about "E:\Program", and when I check, sure enough, it creates a folder named "Program" in the root of my E: drive. I'm CERTAIN it is trying to write to "E:\Program Files" but the space is terminating the command.
I did find where "path" is assigned:
path = tkm.path_archuncomp + bs.path + bs.name + '.ext'
How would I enclose that path in quotes that are assigned to the variable?
Inserting the quotes character appears to be the same as languages like C. Simply use "slash" notion:
path = \" + some_variable + \"
Unfortunately for me, repairing the script is more complicated than that, and doing so only created errors, so I can't confirm that was done properly. :(
Related
in Jenkins file one of the variable is having the comma separated values like below.
infra_services=[abc,def,xyz]
when I write the below code it was throwing an error.
if ("{$Infra_Services}".contains("xyz"))
then
echo "$Infra_Services"
fi
yes you can do if statements in a Jenkinsfile. However if you are using declarative pipeline you need to brace it with the step script.
Your issue comes from the fact you did not put any double quotes around "abc" and all the elements of your array
infra_services=[abc,def,xyz]
A second error will raise after you fix this. If infra_services is an array, to manipulate it you should not try to cast it as string. It should throw when you do "{$Infra_Services}"
here is a working example
def Infra_Services = ["abc","def","xyz"]
if (Infra_Services.contains("xyz")) {
println "found"
}
My advice is to test your groovy before running it on jenkins, you will gain precious time. Here is a good online groovy console I use to test my code. running the groovy console from terminal is an alternative
https://groovyconsole.appspot.com/
I am attempting to send a file from IFS to an outq on our AS/400 system. Whenever I do, I get exactly what I send, as well as a line of "#" symbols of varying lengths appended to the end.
Here's the command I'm using:
qsh cmd('cat -c /path/test.txt | Rfile -wbQ -c "ovrprtf file(qprint)
outq(*LIBL/ABCD) devtype(*USERASCII) rplunprt(*no) splfname(test) hold(*no)"
qprint')
The contents of test.txt is just Hello World!
The output I get when I send the command is
Hello World!####################################################################
I have not found any posts online about a similar problem, and have tried changing values and looking for additional switches to get it to work. Nothing I'm doing seems to fix the issue.
Is there a command or switch that I am missing, or is something I have in there already causing this?
EDIT:
I found this documentation which is the first time I've seen this issue mentioned, but it's not very helpful:
“Messages for a Take Action command might consist of a long string of "at" symbols (#) in a pop-up message. (The Reflex automation Take Action command, which is configured in situations, does not have this problem.) A resolution for this problem is under construction. This problem might be resolved by the time of the product release. If you see this problem, contact IBM Software Support.”
The only differences are: 1) this is not a pop-up message, it's printed. 2) I don't believe we use Tivoli Monitoring, although I could be wrong.
Assuming we do use Tivoli Monitoring, what would the solution be? There's no additional documentation past that, and I am not a system administrator, so I can't really make the call to IBM Software Support myself. And assuming we DON'T use it, what else could cause this issue?
I get different results, yet similar. I created a test.txt with Windows Explorer, put in Hello, world!, saved it and tried the script. I got gibberish for the 'Hello, world!' and then the line of # symbols.
My system is 7.3 TR5, CCSID 37 (US English) and my IFS file is CCSID 1252 (Windows English). Results did not change if I used a stream file of CCSID 819 (US ASCII).
I didn't have any luck modifying Rfile switches.
I found that removing devtype(*userascii) produced printed output in plain English without the # symbols. Do you really need *USERASCII? I would think that would be more for a pre-formatted 'print-ready' file like Postscript or the like.
EDIT: some more things to try
I don't understand why *USERASCII is adding those # symbols; it looks like a translation issue.
I tried this and still got the extra ###... You might have to play with the TOCCSID() parameter. Although a failure, it did give me an idea: what if those # symbols are EBCDIC spaces being sent as-is to the *USERASCII print stream? All we'd need is a way to send only the number of bytes in the stream file, without any padding.
CRTPF FILE(QTEMP/PRTSTMF) RCDLEN(132)
CPY OBJ('/path/test.txt') TOOBJ('/qsys.lib/qtemp.lib/prtstmf.file/prtstmf.mbr') replace(*yes)
ovrprtf file(qprint) outq(*LIBL/prt3812) devtype(*USERASCII) rplunprt(*no) splfname(test) hold(*no)
cpyf prtstmf qprint
The data in QTEMP/PRTSTMF is in ASCII; DSPPFM shows that much. It also shows a bunch of spaces: after all, it is a fixed length file. My next step was to write an RPG program to read the stream file and print it, but Scott Klement already did that: http://www.scottklement.com/PrtStmf.zip
This works on my system:
ovrprtf file(qsysprt) outq(*LIBL/abcd) devtype(*USERASCII) rplunprt(*no) splfname(test) hold(*no)
prtstmf stmf('/path/test.txt') outq(abcd)
I need to open external exe file, and in the same time to pass some arguments to it.
The documentation in Xojo Library suggest to use the Shell, but I have not seen the practical example how to do it.
Xojo Shell command Explanation:
Dim sh As New Shell
sh.Execute("Location to a file")
I have tried the following:
sh.Execute("Location to a file" + " " + myArgumentOne + " " + myArgumentTwo)
There is no error, just the *.exe is not being run.
If there is solution using FolderItem, I would gladly use it as well.
You may not need to use a shell. When you have the folderitem, use Launch to execute the program and pass parameters. For instance
dim f as folderitem = GetFolderItem("C:\myprogram.exe", Folderitem.PathTypeShell)
f.Launch("Parameter1, Parameter2")
See http://docs.xojo.com/index.php/FolderItem.Launch
sh.Execute F.ShellPath +"\program.exe " + parameters
F is a Folderitm pointing to the directory of the program and parameters is a string
I've got a script that I'm running where I declare the path I'm using, then define my source files as all the child items in that path.
$htmPath = "c:\users\x\desktop\cgc\ht"
$srcfiles = Get-ChildItem $htmPath -filter "*.htm*"
I've run this successfully in the past, but this morning I started getting the following error:
You must provide a value expression on the right-hand side of the '*' operator.
At C:\users\x\desktop\cgc\CGC002.PS1:63 char:46
+ $srcfiles = Get-ChildItem $htmPath -filter "* <<<< .htm*"
+ CategoryInfo : ParserError: (:) [], ParseException
+ FullyQualifiedErrorId : ExpectedValueExpression
To me, it appears that this error is being thrown because the script is interpreting my wildcard as a multiplication, and wants the value on the right side necessary to complete the operation. Am I interpreting it properly? If that is indeed the case, how do I make sure that my wildcard is interpreted as a widlcard?
I did find this link, but it's a different enough scenario with different enough code that I'm not sure it applies. However, I did find this comment in the thread interesting:
Try putting the *, at the start of the property list instead of the end. I think it's just getting confused. It's mainly your formatting.
...so I exited PS, warm-booted, the usual did-you-try-turning-it-off-and-back-on-again confusion resetters, and still, the same error.
Maybe I have a typo somewhere that I can't see?
Or, if I'm completely missing the interpretation of the error...school me.
Ended up being a single double-quote off the right side of my text editor. Color coded syntax checking helped me verify that it was a mismatched quote issue...thinking to scroll to the right to FIND the " took a lot more time than it should have. Facepalm.
Thanks to #Richard who offered up this suggestion.
Anyone still using TinyGet?
When I pass a single query string parameter, everything works fine. As soon as I try to add a second param I get an error.
Here's an example of the error I'm getting:
C:\Program Files\IIS Resources\TinyGet>tinyget -srv:mydomain.com -uri:/Search/Results?q=food&pIndex=5 -loop:10
'pIndex' is not recognized as an internal or external command, operable program or batch file.
I've reviewed resources like http://code.google.com/p/toolsdotnet/wiki/TinyGet and I can't get this to work. Any ideas?
(PS: I tried tagging this "TinyGet" but I don't have enough rep, in case someone else wants to do that.)
I got an answer over at the IIS forums (http://forums.iis.net/p/1166670/1940071.aspx#1940071).
The ampersand must be escaped with the ^ character, so in this case the call would be:
C:\Program Files\IIS Resources\TinyGet>tinyget -srv:mydomain.com -uri:/Search/Results?q=food^&pIndex=5 -loop:10
You could also just wrap the uri in quotes.