I have a legacy VBS script that runs on a schedule via task scheduler. The script checks a folder (located in a mapped network drive) and processes the files it finds in the folder.
Recently it just stopped working. I didn't write this script, I've only inherited it. It no longer seems to find files in the folder it's looking in, even when they're there. To test we created a log file and wrote file names to it. When manually double-clicking the file and running it from explorer it writes to the log file and sees everything in the directory. If you run it from the Task Scheduler it sees no files and writes nothing to the log file. It also runs for days and never seems to exit when the scheduler runs it, even if there are no files and when I run manually it closes immediately when there are no files.
We have several other legacy scripts that are very similar in function to this one and they all work exactly as expected without issue.
This script is run as administrator (the others are as well). I set the "Start In" to it's current directory (the start in directive is not set for the other scripts and they function normally) and this did not help.
This script uses full file paths to everything (the others do as well).
It works as expected only when double clicked.
Related
In my directory I have a file called "t1.ps1" and a second file called "t1 - something.ps1".
Both of them run fine when run fine, when executed via right click run with PowerShell or when executed directly in PowerShell, but when executed via double click or cmd it seems to always execute the first script.
For me it seems like the dash is the problem, but I was kinda surprised that windows did not just throw an error or just did nothing, but instead executed a different script.
Maybe this is a well known phenomena or i just have some jank settings, that made this happen, but I was kinda surprised about it.
By default, .ps1 files are NOT executed when you double-click them in File Explorer / on the Desktop - instead, they're opened for editing.
The fact that they are executed for you implies that you modified the default configuration:
However, the fact that double-clicking t1 - something.ps1 executes t1.ps1 instead implies that your configuration is flawed:
Specifically, it suggests that the file-name argument in the underlying powershell.exe command used for invocation lacks (effective) enclosing "..." quoting - as would happen if you had used File Explorer to interactively associate .ps1 files with powershell.exe.
See this answer for more information and a fix.
The application moves files from one directory to another, runs an exe, and then moves files from one directory to another.
When I run the application manually it works as expected.
However, when trying to run it as a scheduled task I get the following error: 3762504530
I did some researching and it appears it may have to do with the application trying to run interactively even when there is no user actually logged in.
I have tried to suppress outputs but that didn't seem to have any effect.
Without seeing the code i guess u use console output or similar...
If so change write-host to write-output or alias "echo" pipe it to log file if u want...
Also be sure that your script run "non interactive" (no prompts etc.)
Unchecking compile a graphic windows program (parameter -noConsole), remedied the error.
I'm writing myself a GUI utility for use in a CMD window to navigate between folders,
rather in the style of the old Norton Change Directory utility for DOS.
When run, the app pops up a folder tree to allow the user to select a folder to which
to navigate and then closes and returns to the CMD prompt. At the moment, the way it
works is that it is run as the first command in a "main" batch file. It writes a secondary batch
file, in my app's folder under AppData, containing the commands to change drive and
directory to the folder the user selected, and the main batch file then invokes this
second batch file using CALL.
It works fine, but this way of actually changing the CMD window's current directory
strikes me as inelegant both from the point of view of needing to be run from a batch file
(so that the user's selection can be acted upon after my app has closed) and of
needing the secondary batch file to do the actual navigation.
So, my question is, how can my app send the instructions to the instance of CMD
that owns the window in which the app is run to the folder the user selected? I've tried doing a ShellExecute
of "CMD /K ..." but although that does indeed navigate to the
selected folder, it does so in a new CMD window, not the one my app is run in. The
conceptual gap I have is how to get the current CMD to act on my app's instructions
after my app has terminated.
Fwiw, I thought of trying to write the user's folder selection into an environment variable in the CMD window's environment for the CMD processor to
act upon from there, but this seems to require that the CMD window be opened via "Run as Administrator", which I definitely don't want.
Your program cannot influence the environment variables of the command interpreter because they're separate processes. Your program cannot change the directory of the command interpreter directly, either, because, again, they're separate processes.
You need to use a batch file because the command interpreter executes batch files internally. Since it's all the same process, the batch file has the power to change the current directory, and for that change to remain in effect after the batch file finishes running.
Therefore, you need some way for your interactive program to communicate the directory selection back to the batch file so that it can act on it.
Instead of writing the instructions to another batch file, you could write the result to standard output. Have the batch file capture that output into a variable, and then execute cd on that variable. The batch code would look something like this:
for /f "tokens=*" %%a in ('[select_dir.exe]') do (
set DIRSELECTION=%%a
)
cd /d %DIRSELECTION%
Your Delphi code would look like this:
writeln(selected_dir);
To allow that command to work, you'll need to make sure your program is marked as a console program, as with {$APPTYPE CONSOLE}. If it's not, then the batch file won't receive any output, and probably won't even wait for your program to finish running before proceeding. It's OK for a console program to display a TForm, just like a GUI program.
I'm writing a .bat file that calls a .exe that processes a bunch of documents. I am writing it to test the .exe's performance. Currently, the .bat file runs a for loop to run the .exe on every file in the folder. Sometimes the .exe will run into errors and will not be able to finish running due to incompatibility between the document and the .exe (still working on perfecting the .exe). How can I tell my .bat file to mark the bad files as errors and continue processing the rest of the files?
Edit: I don't want to terminate the batch file; I'd like to terminate the .exe for that specific file, and then continue with the for loop.
I have a VBS file 'migration.vbs' that runs a number of commands and then calls an AutoIt .exe file to begin the uninstall of a product. The entire script runs successfully when you call it by itself from the command line with 'cscript migration.vbs'
This script is going to be pushed out to a number of other machines where techs need to be able to double-click to run it. A lot of the machines don't execute VBS by default on a double click, so I've added a batch file to run it.
The problem is that when the batch file calls the VBS, it starts to run but never calls the exe. It just.. skips that step. I'm guessing there's an issue with nested system calls or something that I don't know about.
Anyways, any solutions? I'd rather not put the EXE call in the batch file due to logic checking the VBS does against registry keys (that'd be hard/impossible to duplicate in BAT).
Thanks again
start.bat
START /WAIT cscript .\data\migration.vbs
migration.vbs
WSHSHell.Run "uninstall.exe", 0, True
There is no nested system calls limit, I'm guessing that the path or current directory is wrong, try using a full path or monitor the filesystem calls with Process Monitor