I have a strange problem concerning disk size while using the Dos Dir command in Excel VBA.
I am developing a procedure within which, I need to get a directory listing of a directory with all of it's sub directories, on the same computer and save it to a text file. This piece of code will be run several times by the complete routine. The computer is a generic desktop running Windows 10. Excel is running in the C:, the directory to be listed is in the E: (an internally mounted drive) and the file is being saved to the root directory of the N: (a USB drive).
The format I am running is "Dir/s E:\'Directory Name'\ >>n:\Edir.txt"
When I run this manually in a 'Command Prompt' it works perfectly but when I try to embed it in a 'Shell' command I normally get an error message in the Command Prompt pane saying 'Not enough space on the disk'. and the text file is created but truncated at a random point in the listing.
The code line I am using is '''PID = Shell("cmd /k Dir/s E:\Directory Name\ >>N:\Edir.txt", vbNormalFocus)'''
Each of the disks used has more than 150gb free space and the complete text file comes out at about 3.3mb.
I find this very confusing, each of the drives has plenty of free space and the fact that it works every time when invoked manually and sometimes when invoked from the shell command makes it even more so. Any ideas?
R. Frankham
I think I've found the answer, although I'm unclear exactly what the why's and wherefores are. The 'Red Herring' is in the Dos error message "Not enough space on the disk".
It would appear that the real problem is the time taken to process the Dos Dir command. If I put a 10 second delay ( "Application.Wait (Now + TimeValue("0:00:10"))") to give time for the 'Dir' command to complete, it works perfectly. A bit of a nuisance because it slows execution considerably but not a great problem.
R. Frankham
Related
Working with Pure Data, trying to record audio output from a patch I've made, and am 1) unable to create a file within pure data to write to and 2) attempting to use the writesf~ object causes the program to freeze after about two to three seconds. I suspect the two things are related- perhaps the program is attempting to write data somewhere, somehow, but it's going in the wrong place or some such and causing the program to freeze?
I've uninstalled the latest Pure Data release (0.51-1) and installed an earlier stable release (0.5-2) and even tried an alternative called "purr data (latest release)" all with the exact same result on my windows 10 acer laptop: no file created, and program freezes after a few seconds.
I'm testing with this patch:
I first click on the message that reads "open rec.wav" then the start then the stop, and if I take longer than three or so seconds to click on "stop" the program freezes, otherwise nothing at all happens.
I have performed system wide search for the audio file, including the folder that the patch is in, all to no avail.
Any trouble shooting hints will be carefully attempted.
Are you sure you have write-permissions on the target directory?
If your example you use rec.wav which has no explicit target directory (and is just using the "current", so it's hard to tell from outside what this directory would be).
#max-n's answer suggests to use /tmp/foo.wav which is an illegal directory on Windows. Due to a known bug, using an illegal (or otherwise non-writable) path will lock up Pd.
If your "current" directory happens to be your system root (aka C:\), you might well lack the permissions to write there.
You could check by starting the Pd from the cmdline and see whether the terminal spits out any weird errors:
⊞ Win+R
type cmd and hit Enter
in the opening terminal type the full path to your Pd-executable, e.g.:
C:\Program Files\Pd\bin\pd + Enter
(ideally leave out the extension (that is: use .../pd rather than .../pd.exe)
If the problem is indeed a permission problem, you can simply work around it by specifying the full path of the output file (and make sure that it is in a writable directory).
The easiest way to do this is by using a file-selector to choose the output file:
[bang(
|
[savepanel]
|
[open $1(
|
[writesf~]
There might be a reason why the helpfile uses a [delay 1000] to schedule a stop message in a predefined time.
There's quite a bit of information out there on this topic, but for some reason I just can't get it to work. This is on a raspberry pi running the 'DietPi' flavor over the raspian distro, and is perhaps what separates my question from the others.
So I have a GUI application that I wish to launch at boot, after the LXDE session has begun. So I have utilized the following file here:
/etc/xdg/lxsession/LXDE/autostart
and added the line:
#/myapplication
This works, however, it launches multiple instances of this program, and the first one always crashes. This creates problems because there's some competition for resources (IO, files, etc). So what I did was create script file, /myapplication-autostart.sh instead like so:
if pgrep "myapplication" > /dev/null
then
echo "my application is already running"
else
/myapplication
fi
and then changed /etc/xdg/lxsession/LXDE/autostart to #/myapplication-autostart.sh. Now what I find is the program launches once, but the instance crashes. It crashes when it attempts to create a window (opencv imshow). This is strange because the program will also run headless if an X-session is not available, but for some reason it crashes and I do not know where to check why.
Also, to test it wasn't an issue with the script file, I commented everything out except the /myapplication and I have found the script file runs in a continuous loop and every time I close the application it opens back up. I'm not sure why this is either.
I've tried adding a sleep delay in the script and it does not help. For whatever reason, it seems the LXDE autostart script is ran at least 3 times when booting the pi and the circumstances around the first cause the program to crash. Does anybody understand this sequence and behavior of calling this autostart script?
It is also possible to use the XDG standard Autostart - which is independent of the used desktop environment - by placing desktop files at
$XDG_CONFIG_HOME/autostart (by default ~/.config/autostart)
or for system-wide autostarts at $XDG_CONFIG_DIRS/autostart (by default /etc/xdg/autostart).
Such a .desktop-file could look like:
[Desktop Entry]
Type=Application
Version=1.0
Name=JDownloader
Exec=/usr/local/bin/my-application.sh
Categories=Utilities
The specification of desktop-files can be found at freedesktop.org.
Here was the final solution...
/etc/xdg/lxsession/LXDE/autostart added the line:
/myapplication-autostart.sh
and /myapplication-autostart.sh was changed to:
#!/bin/bash
if pgrep "myapplication" > /dev/null
then
echo "my application is already running"
else
if [[ "$DISPLAY" = ":0" ]]
then
/myapplication
fi
fi
I had to write the display variable to file in combination with the errors to file to discover the issue. At login 2 X sessions were created, display ":1" and display ":0", in that sequence. Display ":1" crashed because, although not headless, it was not initialized to a particular resolution and there was some resizing code in my program. Display ":0" was the actual display on the HDMI out and the one I wanted. Really, the conditional check to see if the application isn't necessary but I left it in there to be safe. I could have also left the # on the LXDE autostart file but it got annoying in the cases I wanted to close the application because it'd keep re-opening. Possibly I'll put it back later.
Thanks for the help!
First, some comments about opening several instances of the program: when you use "#" at the beginning of the line on the startup file (ex.: #/myapplication), this requests your system to try to launch the program, but if the program fails to open correctly, then the system will try to open it multiple times until it opens correctly -- if you remove "#" from the line beginning, then the system will only try to open the program once.
Now, to find out why the program is failing, I advise you to add
2> /file/log
to the end of every command on your script. Doing so would append any error message to a log (/file/log), and analyzing those error messages would be key to find out why the program is misbehaving.
One important note: if your program needs root privileges to run, then it will fail when called via /etc/xdg/lxsession/LXDE/autostart, as this method calls programs without elevated permissions.
This is an old thread but I was having problems getting autostart to start all the tasks listed. After many days I concluded there were one or more "invisible" characters that autostart didn't like. So I deleted the lines for the tasks that didn't start and retyped them. That solved the problem!
I think I corrupted the lines because I was editing some of the lines on my Windows computer. It was likely inserting CR with LF or some other stuff. I WILL NEVER EDIT TEXT FOR LINUX USING WINDOWS!
Maybe someone else will hit this problem and this may help them. I don't know where else to put this information.
My Excel VBA macro creates a the gs.cmd file containing the following lines:
"C:\Program Files\gs\gs9.10\bin\gswin64c.exe" #gsparams
echo %ProgramFiles%
pause
Then executes Shell "gs.cmd".
The resulting PDF file generated by Ghostscript misses a few links and the console shows C:\Program Files (x86).
If I start a cmd.exe from the Start menu and execute the same gs.cmd script, the resulting PDF file is correct and the console shows C:\Program Files.
The PDF file it contains many 36"x24" CAD drawings, with mostly vector content and a few large bitmaps, with hundreds of bookmarks and thousands of links defined in the pdfmarks file.
The only difference I see between the executions is that one seems to be 32 bit and the other 64 bit.
I don't understand why Ghostscript makes a perfect job in the 64 bit instance, but in the 32 bit instance does most of the job correctly and it just misses the creation of about 5% of the links. I would expect for it to either fail or work.
I googled around to see if I could get the Shell to run in a 64 bit environment, but I didn't find a solution.
How can I do to fix the problem?
What about creating a second .cmd file that launches the cmd version that you want?
It may look like this:
launcher.cmd :
%SYSTEMROOT%\System32\cmd.exe /c c:\temp\gs.cmd
The 32 bit version of cmd.exe will be inside %SYSTEMROOT%\Syswow64\ on 64 bit systems. On a 32 bit system I guess the script will use the only cmd.exe available (%SYSTEMROOT%\System32\cmd.exe) so no problem there.
Good day,
I am a CNC program not a computer programer. I am using CAM software to make cutting programs for our CNC router. The router is a bit old and can only take files 200-300 kb big. We are doing carvings that require 1-2 megs text files. I am using a program called GSplit ( http://www.gdgsoft.com/gsplit/ ) to divvy up the text file. It generates 10-25+ files with a custom header that our machine can read. All the files are great and it works, but I have to manually add the closing lines/footer to each file. The files that are created and used are normal .txt files but with a specific extension, .ANC.
Is there any way to automate this process of opening each individual file, scrolling to the end and copy/pasting the same 1-2 lines of code? The files are NAME[number].ANC in a contained folder. Would it be possible to just direct to a folder and say "add this 'text' to every file in this folder"?
Thanks for your time.
What OS are you using? Using Unix you can do a simple script on command line. If you are in the directory with the specific files simply execute:
for file in *; do echo "APPEND THIS" >> $file; done
If you are running Windows you should be able to do the same using cygwin (probably you could also use the power shell, but I don't know anything about the that)
I found a program Notepad++ (apparently the last person to find it...). USed the find/replace files option. A regular expression(note sure exactly what these are but I'm sure you guys do) "\s+\z" as to what to look for. It finds the last space or whatever at the end of all the files and then adds the code I need. Easy, free, and I don't need to write any computer code. Thanks for the attempt to help me Dirkk! :)
I am trying to open a downloaded .exe file but it closes as soon as it opens. Is there any possible way so that I can open it for a longer duration to read the content.
It's probably a console application rather than a GUI application. Use the command prompt to run the .exe.
Do the following...
Hold down your Windows key on your keyboard and then tap "R".
This will bring up the Run dialog. Type in "cmd" (without the quotes). Hit enter.
(this will work in all Windows versions - browsing the start menu/screen differs in each version)
If you saved the file to c:\downloads and it's called myFile.exe, type
C:
cd C:\Downloads
myFile.exe
Some of the steps are a bit redundant - if you know what you're doing in the command prompt then skip as needed (but then you probably wouldn't be posting this question). This will work even if you saved the file to D:\downloads.
Another example - if you saved the file to D:\folderA\Folder with a space\ and the file is called "my file with a space.exe" then type
D:
cd "D:\folderA\Folder with a space"
"my file with a space.exe"
If there is an issue (eg it's a 64-bit executable and you're on 32-bit Windows) then you may get a better error message at the command line.
There are so many reasons why the executable does not run. Here are some ways to check what is going wrong:
Is it your .exe? Do you known the "normal" behavior?
When you download it manually, it the result the same?
Do you download the .exe manually or via your application?
Do you see any problem in your Windows Event Viewer?
Is it the same result if you try to download the .exe via different browsers (IE, FF, ...)?
More details are welcome!
The nuget.exe file is not a console GUI application but rather a console package. Once you've downloaded it, you'll want to place it in a folder outside your Downloads folder. For example, C:\NuGet\nuget.exe - then set it as a PATH variable so that it's executable from anywhere.