This is less a code thing so I'm not sure how to provide reproducible example. But this is more or less it.
pb <- txtProgressBar(min = 0, max = 11, style = 3)
for(i in 2:10){
setTxtProgressBar(pb, i)
file <- read.file("file/path")
file <- gsub(date[i-1], date[i], file)
write.file(file, "file/path")
Sys.sleep(2)
System('"*.exe" "./file.txt"')
Sys.sleep(3)
}
I have a script that has a for loop that changes a file then runs a System() call to another program. I have a progress bar embedded so I could track the...well...progress... by viewing it in the console as it updates. Script works fine, worked fine. Re-running the script and RStudio/R being a little weird. Whole program gets sluggish sometimes non-responsive, but the scripts are running just fine. I checked memory usage from before and after and no obvious difference (i.e., me staring at task manager while the script runs). Rest of computer seems to work fine while scripts are running (I guess processing not hogged, too, as I have run with and without other applications open / running simultaneously). Even when the scripts complete (I know from looking at the written output files), RStudio does not come out of the funk. I can see RStudio processes in task manager still taking up resources though not as much.
I just can't figure out why this is happening? How to improve coding approach to avoid? Maybe a fresh install could fix (but what lead to the problem to begin with (forced stops of program?))? Could it just be that I am sourcing inside a notebook .nb? I'm going to re-install regardless, just trying to figure it out.
Windows 10 Desktop
Related
I have a server on which we execute multiple bash scripts to automate tasks (like copying files to other servers, kicking off backups, etc). It has been working for some months, but today it started to get erratic.
What is happening, is that the script gets 'stuck' for a while, and after that, it runs with no problem. If I copy and paste the commands one by one on the terminal, it works, so is not something on the script itself, but it seems something that is preventing the bash interpreter (if that makes sense).
Another weird behavior is that the same script will run with no issues eventually. However, as we use Jenkins for automation, the scripts are re-created every time a new job starts.
For example, I created a new script, tst.sh, which only contains an echo. If I try to run it directly, it gets stuck for a while. I tried to debug it with bash -xeav but it does not print my script code, which means that it is not reading it. After a while, the script ran, with no changes. However, creating one script, with the same content and a different name, resurfaces the issue.
My hypothesis is that something prevents the script to be read, and just waits until whatever is blocking it to finish. However, I did not see any process holding the file, which means that it may not the case.
Is there any other thing I should try? My knowledge in bash is pretty basic, so I don't know if there is a flag that may help me on debugging this internally.
I am working on RHEL 8.85, the bash version is GNU bash, version 4.4.20(1)-release (x86_64-redhat-linux-gnu)
UPDATES BASED ON THE COMMENTS
Server resources are OK, no usage for them.
Hardware for the server also works fine, the ops team has not reached out with any known issue at least
Reboot makes the issue disappear, however, it reappears after 5 minutes or so
The issue seems that is not related to bash profiles and such.
Issue solved, posting this as an answer so people can find it quicker.
Turns out, as multiple users suggested in the comments (thanks to all!!) the problem was caused by a security monitor, which analyzed each of the scripts that were executed. The team changed some settings on that end to prevent it from happening, and so far is working.
While I'm using my computer a blue window will pop up for a second then go away. The label said windows power shell, I've tried looking at the event viewer but I could not identify anything there since I'm a new user. What could be causing this?
Running windows 10
Sometimes installed programs open up command prompts to run services/init tasks, so its not completely unusual.
I've never seen it happen with powershell however.
it could be innocent and just a program you have installed running init behavior, but it could also be malicious.
the first thing to try is checking what programs are set to startup automatically. if there is a load of bloat, you could try turning off the unnecessary ones and see if it still happens.
but realistically the only real way forward is to get a good quality antivirus, and run a full system scan over your pc to double check. it wont give you 100% certainly as things could possibly get passed it, but realistically if it passes you should be fine
I have written a program generating a simple tray icon using cl-cffi-gtk and Common Lisp called tray-icon.lisp which is defined in a ASDF system called hourly-player. My problem is now that while this app starts fine from the command line, starting it from a script turns out to be a bit more difficult.
If I try
sbcl --eval '(asdf:load-system "hourly-player")' --eval '(hourly-player:run)'
my application is correctly loaded into the SBCL REPL and the tray icon displays correctly. However if I add a & to launch my script in the background it seems to immediately terminate.
Adding a (loop) at the end of my run function keeps the script from terminating but obviously also occupies my CPU a lot more than would be necessary for such a app (roughly 12% load according to conky compared to basically nothing when running in sbcl).
Is there some canonical way to keep my script alive as a background process?
I'm also aware that there are other ways of executing a lisp programm but they either share the same problem (e.g. core dumps) or seem to break my system definitions dependencies (at least buildapp and cl-launch seem to do so).
If it helps, my project can be found here.
A quick shot might be to do (loop (sleep 60)) to keep your main program alive. You also might want to look at using within-main-loop-and-wait instead of within-main-loop (from gtk+).
I've run into an issue with a program I created using Livecode, and now I'm looking for some help from the experts. My Google-fu is strong, yet the answer eludes me...
So here's the deal. I made a very basic note-taking program for Windows only, using very noob skills. I've been using it daily for work for the past month at least. It functions exactly as it should, except for these few things that don't make sense:
When loading the program, it takes 25-30 seconds to load. Not convenient considering it's pretty basic; one button and 5-6 text input fields, with the same number of label fields. And one background. The button just clears the text input fields.
I started to notice a problem when I went to create a batch file to load all my work programs. When the program is loaded thru Command Prompt, if I close CMD it will close the program too. I tried the same using Powershell, and it still closes as soon as the Powershell window closes. Really really strange.
I managed to find another standalone program made with Livecode, downloaded it and tested the CMD command to see if the same thing happened. It didn't, that program loaded instantly and it is ENORMOUS. It also didn't close when I closed the CMD window. I even tried this: opened my program and the downloaded program using the same CMD session, and when I closed CMD, my program closed but the downloaded one did not.
Then, I downloaded the source code for the program that was working correctly. I created a standalone for it, and tried to open that. It acts the same way as my note program does.
I don't get it. It's got to be something in my Standalone Application Settings considering what happened in the last step I mentioned, and I've been over and over those settings for hours, but I just don't have the knowledge of LC to know what to look for. I've scoured the web looking for answers to this, but it seems to be just me having this issue (story of my life, lol).
I'll be happy to post any codes, scripts, or files needed, please let me know. I just don't know which things to post =P
Any suggestions are very much appreciated!! Thank you. =)
If you call the program from the prompt directly, e.g. using
C:\program files (x86)\your_standalone.exe
the app is treated as a command line app. I have also noticed that a LiveCode app can sometimes close if the invoking command line prompt is closed, while it may sometimes continue to run. Perhaps the handling of the relaunch message has to do with it, since this message basically handles commands from the command line.
If you want the command line process to finish independently from the invoked LiveCode application, you can use the start command:
start "" "C:\program files (x86)\your_standalone.exe"
don't have enough info to be able to tell what your issue is. But that much of a delay is not usual for LiveCode apps so something is definitely wrong. How long does your app take to load if you open the stackfile in the IDE?
Not sure what StackOverflow allows but if you could upload your scripts and if possible stackfile that will give us more to go on
This has nothing to do with Windows, Batchfiles, or CMD.
CMD can workaround your problem, if it's a GUI program. See Start command, and read the help as it explains the starting behaviour of CMD and CMD's Start.
Explorer has different rules. Anything else that starts programs call CreateProcessExW which has it's own rules.
I tried to wrap a little command in a batchfile to prevent me from typing it the whole time. But the result was a mess! I'm ended up with thousands of cmd processes and was unable to stop it with CTRL+C
The command was quite simple START iisreset
System Win7 64bit
Why is that happening?
EDIT:
With some help and additional tests I can now say that the Batch command START within a *.cmd file cause that mess. It opens a new commandwindow with every window until it crashes. Maybe you have luck and hit CTRL-C exactly the right time, but that really has to be luck. Anyway I will not use this command in future and it also seems not to be applicable to all machines. (Read the comments for full history of this)
It works OK on Windows 7 pro, 64 bit, but based on the other stuff you've tried, it looks like it might be a bug... You could try raising a bug report
(although that seems like a non-trivial exercise).