I'm doing this:
executeShellCommand("ECHO %TIME% 1 >> C:\my_log.txt", "Execute as System", "All Operating Systems", "Halt on Fail")
Trying to run this on a Windows 10 machine several times after each other. WHAT WOULD YOU EXPECT TO HAPPEN!? :D
@Kaseya: Please explain, and also explain the text "Execute the given command as if it were typed in at a command prompt". I just want to solve a simple little problem without being a scientist.
Yes. I'm discouraged. Yes. I'm tired. Yes. I shouldn't write this post. And yes. I've been doing way to many scripts in this to still be a sane person.
Or is it just me???
If you use redirection in a procedure, append is ">>>>", not ">>". This is because the "<>" characters are used to identify Manged Variables. The doubling of the ">>" is done as an "escape" mechanism, resulting in a single ">" being used, thus ">>>>" is actually ">>".
Not uncommon in programming, but not many languages need to escape this set of symbols.
Agent Procedures guide, top of page 36, first paragraph:
Reserved Characters - Because the <, > and # characters are used to identify variable names, these characters must be entered twice as regular text in a command line. For example the following command c:\dir >> filelist.txt is interpreted at procedure runtime as c:\dir > filelist.txt
jstrandberg I agree. Things shouldn't be this difficult, but we all have workarounds for these issues!
Personally, for this kind of procedure, I tend to create a batch file containing the commands I want to run, then save that as a managed file on the VSA.
Next, use the writefile command to write this batch file to the endpoint, and use the executeshellcommand to run batchfile.bat >> textfile.txt.
Following this step, you should have the output of the batch file in the textfile and if required further on in the same procedure, this can be read into a variable using the getvariable step, choosing file content and then providing the path and name of the textfile and a variable to refer to it as from that point.
Thanks for your answer! Yes, always the workarounds.. I just got a bit upset.
I did another type of solution, using executeShellCommandToVariable and then writeToTextFile with the variable, appending to the file (which was my initial problem, the >> operator didn't append as would be expected but replaced the file).
I guess one way to look at it is; don't use executeShellCommand for anything fancy and count on having to implement a workaround for those scenarios.
That makes sense, this is the kind of information I was hoping to find in the documentation. I guess I've missed it? Where can I find more information about this in the documentation?
Thanks for the information!