I'm sure I must be missing something really basic but I've been revisiting Powershell of late to get up to speed with 7.1 and can't seem to get it to tell me where an error is thrown, either in VSCode or ISE.
In the above from VSCode (same report in ISE) the error isn't on that line, it's a couple of levels deeper in a function called by CompareFiles, but it always seems to report the caller of the caller of the code which has failed, rather than the actual failing line.
I've searched here, there and everywhere and found lots of clever tweaks and debugging ideas which I could add but I don't understand why it doesn't just give me the failing line here, rather than a line a level or two up in the call stack. It's as if the CompareFiles function has some kind of pragma that says "Dont record debugging info for me or anything I call" but it hasn't (and that probably doesn't exist anyway!).
I can't help feeling I've just not set some obvious debug setting, or set one incorrectly while I've been tinkering.
If it makes a difference, I'm calling a PS module from a PS Script, the module is loaded fine from the PSPath via Import-Module, and the line being reported is in the module, as is the actual failing line (both are in the same module), so it's not some problem where it's only debugging the script and not the module.
Both the script and the module have the below at the top;
Set-StrictMode -Version Latest
$ErrorActionPreference = "Stop"
As I say, I get an identical error when I use the ISE so it's not a VSCode setting.
Debugging line by line works fine, so I can step through to find the failing line but surely it should just pop up and tell me.
[Later] I should not it's not just this error, it's been like that for days with all sorts of runtime errors with this and other scripts.
Silly me - I simply removed..
$ErrorActionPreference = "Stop"
..from the script and the module, this was essentially implementing the imaginary pragma I mentioned. I removed it and now get the failing error line.
I probably only need it at one of the two levels if anywhere but error handling works just fine without it, so have removed it everywhere, perhaps I'll look into what it does properly at some point.
Serves me right for adding something blindly because it sounded good, i.e. "Sure, I want it to stop when there's an error, why wouldn't I ? - I'll add that statement then" and not re-testing or looking further into it.
Related
I've been looking around.
storeEval does not exist anymore.
Commands 'runScript' & 'executeScript' seem to replace it.
However, the syntax proposed in many posts javascript{script here} is not accepted: it refuses the first {. Same for the variables with the storeVars['foo'] which seems to be replaced by ${foo}.
Trying any javascript expression (even very simple) with both commands gets me a message 'Failed: missing ) after argument list'.
For instance: | run Script | "aString" + ${previouslyStoredVar} | outputVar |
(note: the syntax of the command seems to be 'runScript', but appears as 'run script' in the IDE window).
I tried adding a return(expression), putting brackets around the expression, enclosing ${previouslyStoredVar} in double quotes, trying with an even simpler expression, and everything I could think of, but with always the same error message.
What is it I am doing wrong? It must be obvious but I can't figure it out!
Many thanks,
E.
My bad: just tried with 'return ${price_string}.substr(0, 5)' and it works. Have to find out why the other commands were not working. I'll dig and report!
OK, the pb remain but is quite different from my exepectation. The exact same expression and the same context works in a second test, but fails in the first test (with the missing parenthesis message). Seems to be a bug in the IDE then, or a corruption of some sort of the Selenium script...
In Maya, when running a Python script, the script editor is reporting back every time the script select and unselects something. It is messy and I would rather have that happen under the hood. Is there a way for the script editor to not report those commands, and can I have my script turn the option off in the editor before running?
Yes, I am the author of the script. I believe it to be a Maya issue. It will report certain actions and you can't turn it off.
That sounds a little odd... do you happen to have echo all commands turned on in the script editor?
The only other thing I can think of is that the script may be explicitly running print statements - do you have access to the source code so you can comment out any print lines?
Edit:
If you wrote it, maybe you could tweak the code to no longer require selection. There are really very few Maya commands that actually require selection - they work with selection, but also allow you to explicitly provide node names... most commands also return node names that you can capture into a variable.
If you are no longer selecting/deselecting things in your script, it shouldn't clutter your script editor output with those prints anymore.
Before you answer, I'm not looking for the functionality of ; to suppress command line printing.
I have a set of scripts which are not mine and I do not have the ability to change. However, in my scripts I make a call to these other scripts through evalin('base', 'scriptName'). Unfortunately, these other scripts do a lot of unnecessary and ugly printing to the command window that I don't want to see. Without being able to edit these other scripts, I would like a way to suppress output to the command line for the time that these other scripts are executing.
One potential answer was to use evalc, but when I try evalc(evalin('base', 'scriptName')) MATLAB throws an error complaining that it cannot execute a script as a function. I'm hoping there's something like the ability to disable command window printing or else redirecting all output to some null file much like /dev/null in unix.
I think you just need to turn the argument in your evalc example into a string:
evalc('evalin(''base'', ''scriptName'')');
Have you tried this solution
here ?
echo off;
I don't know if it will fit your needs, but another solution can be to open a new session of Matlab, and use there only minimized -nodesktop form (-just the command window). You can run from there the annoying scripts, and work on the main session as usual.
The problem here is that the sessions can't be synchronized, so if you need to work with the results of the scripts all the time, it'll be a little bit complicated. Maybe you can save the result to disk, than call it from the main session...
But it mainly depends on your workflow with those scripts.
I have a script, in which this code fails, with an exit code of -2145124322
$new.ExitCode > $null
$filePath = "wusa.exe"
$argumentList = "`"\\PX_SERVER\Rollouts\Microsoft\VirtualPC\Windows6.1-KB958559-x64-RefreshPkg.msu`" /quiet /norestart"
$exitCode = (Start-Process -FilePath:$filePath -argumentList:$argumentList -wait -errorAction:Stop -PassThru).ExitCode
Write-Host $exitCode
Now, the main script has about 15,000 lines of "other stuff going on", and these lines where not originally exactly like this. The variables are pulled from XML, there is data validation and try/catch blocks, all sorts of stuff. So, I started pulling the pertinent lines out, and put them in a tiny separate script, and hard coded the variables. And there, it works, I get a nice 3010 exit code and off to the races. So, I took my working code, hard coded variables and all, and pasted it back into the original script, and it breaks again.
So, I moved the code out of the function where it belongs, and just put it after I initialize everything and before I start working through the main loop. And there it works! Now, I gotta believe it's the usual "polluted pipeline", but dang if I can figure out what could cause this. My next step I guess is to just start stepping through the code, dropping this nugget in somewhere, run the test, if it works move it farther down, try again. Gack!
So, hopping someone has some insights. Either what it might be, or perhaps an improved test protocol. Or some trick to actually see the whole pipeline and somehow recognize the pollution.
FWIW, I normally work with PoSH v2, but I have tried this with v4 with the exact same results. But perhaps there is some pipeline monitoring feature in a later version that could help with the troubleshooting?
Also, my understanding is that PoSH v2 has issues with negative return codes, so they can't be trusted. But I think newer versions fixed this, correct? So the fact that I get the same code in v4 means it is meaningful to Google? Not that I have found any hint of that exit code anywhere thus far.
Crossed fingers.
EDIT: OK, a little more data. I searched on the exit code without the -, and with DuckDuckGo instead of Google, and found this.
0x8024001E -2145124322 WU_E_SERVICE_STOP Operation did not complete because the service or system was being shut down.
OK, that's some direction. And I have some code that would allow me to kill a service temporarily. But that seems a little draconian. Isn't the whole point of this, like 10th way to install updates from Microsoft, supposed to be to make automation easier? In any case, I can't find any indication there are command line flags for WUSA that would avoid the problem, but I have to believe I am doing something wrong.
Solved! After tracking a number of different errors trying different things, including turning off the firewall and such, it turns out the error isn't that a service won't stop, but that a service won't start. See, some of that 15K lines of code suppresses Windows Update for the duration of my script, because Windows Update causes lots of Autodesk deployments to fail, which is the whole point of my code. Well, of course WUSA needs that service. So, it looks like, rather than suppressing Windows Update for the duration of script execution, I need to be less heavy handed and only suppress for the duration of a deployment task. that will take a few hours to implement and test, but is totally doable. And probably more elegant anyway. Woot!
And yeah, for once it wasn't me pooping in my pipeline unintentionally. ;)
I have compiled a Matlab routine using the MCR and deployed it to other computers without having them installed matlab. So far, so good. But of course, the routine is not completely error-free, particularly the GUI part. The problem is that when the MCR tries to write the error message to the terminal, it seems to corrupt the terminal so that everything is no longer legible - not even the prompt. Sometimes I also get an extra window, vaguely resembling the matlab editor window, full of illegible ascii characters. Does anyone know what is causing this, or how to avoid it?
My first attempt was a big try-catch block around everything, but whatever it is still seems to get through. The catch block just tries to divert the error to an errordlg rather than the command prompt:
catch e
errordlg({e.message;['in: ',e.stack.name]})
end
MATLAB Compiler does not support command window functions.
Peter Webb tells on Loren's blog:
Certain MATLAB functions cannot be deployed because they act on
objects that are not present in a deployed application. For example,
since deployed applications have no command window, functions that
modify the command window can't be deployed.
So, you probably need to get rid of any function that prints to the command window.
Also, you can check out the mccExcludedFiles.log file.