Background: I'm using a public computer running windows 7. I don't have permissions to access to the command line (nor the control panel, nor most of C drive). So, I've written the commands I need to execute as a batch program and saved it in a file called "run.bat" onto the Desktop. I run the program by double-clicking the batch file's icon. Something goes wrong, but I can't see what the problem is since as soon at the error comes up the command line disappears. This happens extremely quickly, so I can't even take a screen shot to see the error message.
I've encountered this problem before with batch programs crashing and then disappearing. Is there a way to keep the command line up after an error occurs?
Add the command 'pause' as the last line in the batch file. If you want to get fancy, only execute that line if you detect an error (in whatever you're doing in the batch file).
Related
This is what I am doing:
Make a file or use an existing file.
Emacs filename.txt.
Type some new text into the file.
Save file.
After step 2, I receive an error after the emacs editor window pops up.
Here is the error:
2022-01-19 22:11:53.935 Emacs-x86_64-10_14[33893:994906] It's not
legal to call -layoutSubtreeIfNeeded on a view which is already being
laid out. If you are implementing the view's -layout method, you can
call -[super layout] instead. Break on void
_NSDetectedLayoutRecursion(void) to debug. This will be logged only once. This may break in the future.
I have already tried updating emacs and that didn't help, and googling didn't give me an answer. Currently, I have GNU Emacs 27.1 version.
How do I fix this error?
As far as I know you shouldn't need to "fix" the error at all and it won't cause any problems while you're actually running Emacs. In fact I'm somewhat surprised you see it at all.
I was only able to see the error (in both Emacs 27 and in pretest-28.0.90) only by running the Emacs binary (eg. ./Emacs-27.app/Contents/MacOS/Emacs) directly from a terminal, which isn't the normal way of starting Emacs on macOS. If you just run Emacs by starting it from Finder, the Dock, or via the "open" utility then you shouldn't see the error at all, and it shouldn't cause any problems.
The whole point of keyboard interaction (and emacs in particular) is that there's no need to touch the mouse. It's possible to log in (using e.g. ssh) and edit remotely, with no gui (so no way to drag and drop), and this is the 'normal' way of invoking emacs. Run 'emacs --help' from the command line to see a bunch of options. In particular see 'emacs --no-window-system' which uses a raw terminal even when a gui is available (no error message appears when it's run this way).
The gui however adds font and image support, which can be useful if you're sitting at the machine. The error message you get when you invoke 'emacs' from the command line in its default mode, with no arguments, is a diagnostic describing a bug in the mac gui implementation.
The error's still there if you start emacs through the finder; you can see that by running (e.g.)
$ open /Applications/Emacs.app/Contents/MacOS/Emacs-x86_64-10_14
which both opens an emacs gui and a terminal window containing the program's text output.
As it says in the message, 'this may break in the future'; it's not helpful to say 'you're using it wrong.'
I am plagued by a very strange phenomenon. I tend to write fairly esoteric Powershell modules for stuff I do at work. Often, after running one of these, and the module has ended I will move onto some other tasks, and when I happen to bring up my Powershell console window again, several blank lines (or just blank "space") will have appeared in the buffer. It never appears right away, which is the most confounding part.
Afterwards, the blinking cursor exists at the end of this blank space, and the blank space cannot be "backspaced" (so it's not something inadvertently entering spaces or newlines). It's just there, as part of the buffer. I usually just clear the screen with cls to keep it from annoying me.
I used to just chalk this up to the buggy Windows Powershell 5.1 buffering. However now that I've begun using Powershell 7 (and Windows Terminal), I see that the issue still exists.
Here is a screenshot of a v7 Windows Terminal tab an hour or so after my module finished running:
Sometimes it seems the longer I wait the more blank space has appeared. Here is a screenshot of the same console tab about 20 hours later:
I'm sorry I don't have a better way of explaining this. I realize that without any code or pattern to analyze, that this is a very poor question, by SO standards, but I am just as confused as you are. The only pattern I've noticed is that this only seems to happen after I run my various custom modules. However this accounts for the majority of my Powershell usage, so it might be a red herring.
Usually my modules simply do some processing (talking to computers, AD, etc) and just output some information via Write-Host, and occasionally output a [PSCustomObject], which I always capture in a variable. Even if I was accidentally outputting some blank lines or something to the pipeline, I can't see how that would manifest as blank buffer space that grows over time. I thought maybe I was incorrectly killing async jobs or something and that was somehow causing this, but this happens even in purely synchronous code.
To be clear, in the screenshots above there is no code actually running. That module was the only thing I had run in this particular console tab/session, and it doesn't run any background processes. So I can't understand why the buffer is changing all on its own. In both screenshots, the tab/window is the same size as it was when the module first completed, so it's not just a bunch of spaces in the buffer that are being dynamically resized. And as noted, when the module fist completed there were NO rogue characters in the buffer at all.
One other thing about my usage is that it's all done on a remote VM, accessed through RDP, which I use daily. The only other thing I can think of is that maybe something about the console window being minimized/maximized/resized, the resolution changing, or the login session being connected/reconnected has something to do with it.
Does this sound familiar to anyone? Any ideas for what could be causing this or what I can try to understand the behavior better are much appreciated.
I've confirmed that this actually happens as a direct result of simply "restoring" and "maximizing" the Powershell console window and/or Windows Terminal window. When the issue is "present", doing this will often add another "set" of blank space to the buffer before the cursor. Minimizing seems to have no effect, only going from maximized to "restored" and back to maximized.
I've also confirmed that this has nothing to do with my custom modules. I can replicate the issue by simply opening a fresh, maximized console window/tab, running get-process and then "restoring" and maximizing. It doesn't happen every time though.
It also has nothing to do with my custom profile script, as it happens even on a freshly-imaged computer with no profile.
At this point I'm going back to blaming it on buffer/rendering/window manager implementation bugs in powershell and moving on with my life.
I wrote an extremely lengthy script that creates a form. The main purpose of it it to connect to vCenter servers, total up hosts/vms within different datacenters and also identify ESXi host versions. Running the script in ISE the form loads fine and when I click the Button to start the many various functions to update the fields, it runs. I have Foreach() fields throughout and added in a little StatusLabel to the bottom of the form to show me where in the script it is currently scanning.
Once all was done and working, I saved the PS1 file and moved it to a shared server to be run. When I run the Powershell console (as Admin) and point to the file, the Form loads ok. Once I click the button to begin generating the info, It just changes to (Not Responding) and grays out. I know it's working and if left there long enough it will return the info.
Why does the console window not function like the ISE? I want to be able to see the information and Status Label update/change as it goes through the script (just like I do in the ISE).
Appreciate the feedback. The script is several thousand lines long and would need to be scrubbed before I upload. Was hoping to just get some general info before doing that.
I updated to v4 and verified that my command window was running as STA using the command from Jan Chrbolka. Script runs properly now.
I was also facing the same issue.(Btw, I cannot upgrade Powershell to V4 right now since it is my company owned one.)
The Browse button that I incorporated in my form was not working when I am lauching it from Powershell command line. It went to Not Responding state when I click the browse button.
I took the advise from Jan ChrbolkaMay about the STA and MTA.
I checked for the threads related to that and changed the script execution format to the below one which fixed my issue.(adding the word -STA)
powershell -STA -File D:\PS\GUI.ps1
For checking the current state. Use the below query in Commandshell as well as ISE.
I have a script named my_script.m, which has been mistakenly replaced by another file with the same name. However, prior to overwriting the script, I have run it in MATLAB console. Hence, I have the following history.
>> my_script
>>
Is there any way to recover that history file?
The reason why I think it is still possible is that I do have the run history of that script in my current console. If only I had selected all the script and run it! That way I would have every command in the console history. But now, it is simply one line as above.
Check if you had diary mode on, then everything is there:
get(0,'Diary')
You can open the file in windows explorer, right mouse button, properties. Then check if there are any other versions of the file in the Previous Versions tab ;)
Sometimes matlab writes backups, the file would be named my_script.asv. Check if it exists, it's located in the same directory.
I am trying to make an AHK script open another program everytime it is started. The problem is, I don't want this to happen if that other program is already opened.
Here's what seems to be supposed to be working, but isn't : (this section is placed at the very top of my script)
SetTitleMatchMode, 2
#IfWinNotExist, Microsoft Excel - myExcelFile.xls
Run C:\myExcelFile.xls
#IfWinExist
;REST OF MY SCRIPT GOES HERE
What should be happening :
If the window "Microsoft Excel - myExcelFile.xls" is not opened, run it. If not, do not.
What is happening :
Whether it is opened or not, it will try to run it again.
So yeah, even though I had read the documentation, I had understood that the difference between #IfWin and IfWin was whether they were used inside or out of a specific hotkey. To my understanding, "creates context-sensitive hotkeys and hotstrings" also included "context-sensitive auto-execution" (when code is not inside a hotkey)
Indeed I was wrong and the solution is to remove the #.