I used Shell command from Excel VBA to run a certain .bat file. The CMD appears but exits automatically after all lines were executed. I've added the PAUSE command a the end of the bat. file but it's not working. How to stop command prompt from getting automatically closed?
Try using the /K switch to prevent exiting after running the batch file like this:
cmd /K "path to batch file including file name and extension"
e.g.
cmd /K "C:\FOLDER\BATCH FILE.BAT"
or
cmd /K "C:\FOLDER\BATCH FILE.CMD"
Obviously that won't reveal any faults with your batch code, but it won't exit after running - much the same as running the batch file from the command line.
Definitely add some ECHO output lines to indicate progress as it runs and troubleshoot. Perhaps post the file here for more help.
Try opening the command prompt and running the batch file. It is possible that the the dos shell is encountering an error and closing. If the error comes before the execution reaches Pause command, it will not pause for you to read the error and it immediately closes off.
If that doesn't work out, check if you have any exit commands in any of the branches. Alternatively, place echo statements at different places and check if the execution control reaches these echos. This way you can find out if your script if ending at some other branch.
While perhaps not actually answering the posted question, I stumbled upon this question in a search to a very related-question. I was also trying to stop a command prompt from closing as it was erroring out and closing immediately. For me, it was sufficient for me to view the output as what I really wanted was to be able to see the error in order to debug it.
The solution I found was to pipe the output of the command prompt into a text file, like so:
MyScript.bat >> text.txt
This allowed me to see the error I was getting.
Related
I just installed nvim for the first time, this is also my first time using a terminal based code editor, and I'm migrating from VSCode (ik it's going to be hard),
and now I'm configuring it, I'm following this tutorial:
https://www.youtube.com/watch?v=vdn_pKJUda8&t=347s&ab_channel=JoseanMartinez
And when put the code in the options.lua file, it does not do anything, for example, the
opt.relativenumber = true
is not doing anything
I have tried running commands to change settings, and that has worked, for example
:set relativenumber
But as soon as I exit the file and open a new one, it just breaks again
I have tried simply copy and pasting the code, restarting nvim, switching terminal emulators, etc.
It's really annoying because I am trying to get rid of this stupid feature where it continues comments to the next line and I have to run like 50 commands every time I open a new file just so I can edit it the way I want
My .config file is in
C:\Users\brady\.config
and my nvim.exe file is in
C:\Users\brady\nvim-win64\bin
I am on Windows 10 and my terminal emulator is called 'Tabby'
I figured it out! All the tutorials I am watching are on Linux, but I am on Windows. So instead of putting the nvim folder in my .config, I am supposed to put it in C:\Users\brady\AppData\Local
Are you sure that you're adding your nvim-config file in the correct directory? I'd assume that you need to add your init.vim into C:\Users\brady\.config\nvim\init.vim.
Maybe this answer helps you.
On AIX 7.2, I am using the dbx debugger. Through a command set edit emacs one can enable an "emacs" line editing mode in dbx, which allows you to edit the current command line with keyboard shortcuts like ^A, ^K, ^Y, and so on (similar to what works on the command lines in bash and ksh), and, most importantly for me, it also allows you to access the history of commands in dbx through ^P and ^N (previous and next command, respectively). Dbx allows one to put commands in a file called ~/.dbxinit, which will have these commands executed at the start of the dbx session.
To always have the emacs mode enabled by default (and another option that repeats the last command if you press enter without entering another command) I have created the following .dbxinit file:
set $repeat
set edit emacs
However, when I start dbx now, I get the following error output:
/home/redacted/.dbxinit: 2: set edit emacs
^ syntax error
(The redacted username is also 8 characters long, so the caret for the syntax error is out of place in the original output as well.)
Is this a bug in the dbx implementation or is there anything that prevents setting the edit mode from the startup command file? Is there something else that I can write in the file to get this mode enabled by default?
When I swap the two lines of the file, the error happens on line 1 instead, so I assume that it has nothing to do with the set $repeat line.
The alternative syntax set -o emacs raises the same error. Setting the vi mode instead of emacs mode fails in the same way.
The alternative of setting the EDITOR environment variable to emacs works correctly. But I do not really want to set the editor in my shell to emacs in general, I only want to put dbx into that line editing mode.
Sources:
dbx online manpage
Section about setting the edit mode
Section that describes the use of .dbxinit
(Section about the $repeat option, assumed unrelated)
In my excel VBA code I'm automating the process of running a script ("PULLSCRIPT", which is also created in the code) that runs ftp, opens my FTP address, enters my user and password, pulls a file using mget, and lastly moves that file to another folder using Name. It works in Excel VBA (I click a macro and it does all these steps, no manual input required), but when I copy and paste it to PowerPoint VBA, the line
Shell ("ftp -s:" & sWorkingDirectory & FTP_BATCH_FILE_NAME)
doesn't run. It doesn't give me an error and, F8 stepping through it, it looks like the shell opens (just like when I step through it in Excel), but it never runs PULLSCRIPT (or if it does then it's not working). When I manually open cmd and run the PULLSCRIPT it works, but the point of automating it was so people wouldn't have to do that.
To debug the command execution, add cmd /k in front of it:
Shell ("cmd /k ftp -s:" & ...)
This way, the console window stays open and you can see, what went wrong.
I want to see who locks a file, quickly.
So I created a CMD script that will run Handle, put its output in a file and then open that file in the default text editor.
prompt $
cls
handle > handle.txt
handle.txt
When I run the script a new console wnd is open, I see handle running in it, then it quickly closes. It generates a file called handle.txt, but it is empty.
I tried to run handle.exe as admin, but still doesn't work.
What I do wrong?
I'm getting an annoying error like:
The process cannot access the file 'C:\Program Files (x86)\AceHc\trfpt.exe' because it is being used by another process.
The error happens when I try to use Process.Start after File.Copy the same file.
Code:
File.Copy(PathFrom & "\trfpt.exe", PathTo & "\trfpt.exe", True)
Process.Start(PathTo & "\trfpt.exe")
What am I doing wrong?
Do you have a virus scanner that might be scanning the file directly after the copy and blocking it?
It might be worth trying to temporarily disable it and see if the problem goes away.
Also, depending in the size of the file, maybe the EXE file is still being copied (that is, the copy function doesn't block que program flow, your code continue and the copy process continue in background).
Download Handle from Windows Sysinternals and run it as admin from cmd to get a list of processes which hold a handle on that file:
handle.exe trfpt.exe
A wild guess - do you have a Windows Explorer window open looking at the folder 'Pathto' ?