I am using a log file which is logged in using redirected output method and not the usual logging functions or subroutines.
I need to open the file in appending mode in order to truncate the same every hour.
In linux, i can successfully open the file in append mode and use truncate() function.
But in windows, the file doesnt open in append mode or open using the perl file operators.
Running with if statement gives me false value condition on appending the files, in windows.
the same code and logic works differently on linux and windows.
tried the >>,+>,> file operators in perl but none works in windows.
What can be the reason for the same and solution for this?
No reason appending to a file wouldn't work in Windows. But this nugget in perlport might be what you need to know:
truncate
If a FILEHANDLE is supplied, it must be writable and opened in append mode (i.e., use open(FH, '>>filename') or sysopen(FH,...,O_APPEND|O_RDWR). If a filename is supplied, it should not be held open elsewhere. (Win32)
Related
My goal is to open image files in a default image viewer (Windows 10 Photos app), and close them per user input. My file path contains backslashes, not standard slashes, although replacing them doesn't seem to change the results I mention below.
I tried the following:
Kernel.system('full_path_to_image')
or the same thing using exec instead, but it simply returns a format error Errno::ENOEXEC. Manually entering the file path in the command interpreter works even if the interpreter is opened via:
Kernel.system('cmd')
I tried to avoid the shell by using a multi-argument version of system, but I could not.
Is it possible to do what I want to?
According to this answer, this should work on windows.
system("start #{path_to_image}")
I was just curious as to why with Windows O/S a simple Ruby file that prints one line to the command prompt can execute correctly from one path, but not the other.
Currently, I have said file in C:\Ruby193\test\lib saved inside the lib folder. When I go to the command prompt and set the path to C:\Ruby193\test\lib, I'd expect to see the code string be printed to the command prompt. However, nothing but an empty line is produced, and if I go up the path and set it to C:\Ruby193\test and execute the ruby file from there, it works just fine.
Does anyone have a sound explanation as to why it works that way? Would this also be the same case for a MAC O/S as well?
I have a shell script which contains a sed command that does the insertion into an existing file:
sed -i "/<test name=\"test-$NUMBER\">/i $NEW_TEST_SUITE" test.xml
After running this shell script, I opened the file test.xml in Notepad++, and there is indeed a new line being inserted before:
<test name="test-XXXX">
However, when I tried to do a pretty print (by clicking CTRL+ALT+SHIFT+B) and save that file, it popped up an alert saying:
Please check if this file is opened in another program
So I was thinking could that be caused by modifying the file while not closing it? Do I need to close the file after using sed? If so, could you tell me what the command is since I've searched online but didn't find anything regarding this? (my platform is Windows 7)
No. When sed exits, the file is closed.
This is probably a permissions issue. Verify that your Windows user has write access to the file.
If it's on a Windows partition, try running Notepad++ as administrator. If it's on a Linux shared fs, try chmod.
No, sed does not keep files open. Once the script has completed, all open files are then closed.
Try using Process Explorer to find what process has the file open. Use Ctrl-F to find an open handle that is attached to the file you are having problems with.
I'm writing a bash script to automatically decrypt file for editing and encrypt it back after file is closed. File type could be any: plain-text, office document, etc. I am on Linux Mint with Mate.
I'm stuck: can't reliably detect if file was closed in application so that script can proceed to encrypting it back and removing decrypted version.
The first version of the script simply used vim with text files. Script was calling it directly and hadn't been going any further until vim was closed. Now as I want to be able to do so with other files, I tried the following things:
xdg-open: exits immediately after calling the application associated with file type. Thus script continues and does no good.
xdg-open's modified function for calling an associated app: runs it inside the current script so now I see program exit. Works only if the application hasn't been running already. If it has, then new process is finished and script continues.
So what I am trying to do now is to watch somehow that file was closed in already running application. Currently experimenting with pluma/gedit and inotifywait. It doesn't work either - instantly after file was opened it detects CLOSE_NOWRITE,CLOSE event.
Is it at all possible to detect this without specific hooks for different applications? Possibly some X hooks?
Thank you.
You could use lsof to determine if a file is opened by a process:
myFile="/home/myUser/myFile"
/usr/sbin/lsof "$myFile" | grep "$myFile"
You can use a 1 second loop and wait until the lsof response is empty. I have used this to help prevent a script from opening a newly discovered file that is still being written or downloaded.
Not all processes hold a file open while they are using it. For example, vim holds open a temporary file (/home/myUser/.myFile.swp) and may only open the real file when loading or saving.
You might do something like this.
decrypt "TheFile"&
pluma "TheFile"
encrypt "TheFile"
The & at the end of a line will execute the line then fall through to Pluma. The script will pause until pluma closes.
I could offer more help if you post your script.
How do I pipe standard error to a file in a DOS batch file? Piping using >> only pipes the standard output and the standard error still goes to the console.
Details of my issue:
I am running WinRAR via command line, in an automated daily backup. And the following example pipes WinRar's output, but not the error output which is what I want most, to winraroutput.txt:
RAR.exe a -esh -r "E:\backup.rar" "D:\*.*" >> winraroutput.txt
The issue is sometimes files are in use and when they are I want to know they were missed in the archive and record this in a .txt file next to each .rar file in case we ever have to go back. The missing files are easily replaced by reinstalling programs so it's no big deal to replace them, as long as we know they are missing. So it's just information that would be great to know, not necessary, in the time of need.
How do I output just the standard error output to the .txt file and, if possible but not necessary, leave the the regular output to the console?
Bonus points:
Bonus points if you can tell me how to delete the file if it's blank (no errors)! Asked here: How do I Detect (and Delete) a File if it is Empty using a Windows Batch File?.
Try this:
command.exe 2>file.txt
Or if you prefer not to see any errors, send it to nul:
command.exe 2>nul
This should leave std::cout on the console.