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.
Related
I want to automate really simple ftp transfers with WinSCP (Example script file shown below. The real file would handle many files, but all simple stuff.)
open ftp://username:password#ftp.site.com/
option confirm off
cd remotedirectory
get file.csv
close
exit
A batch file containing:
winscp.com /script="staging get.txt"
opens a command prompt window and executes correctly in Windows 10, but in Windows 7 the command window opens and then immediately closes, and no files are transferred. WinSCP is in the path in both environments. I assume that a parameter or command is missing from one or the other file, but I don't know what it would be.
I was making a couple of small syntax errors. I couldn't see them because the command prompt window closed almost immediately, but the log file showed me what was happening and it was easy to fix. The lesson is - always create a log file.
I have a symlink named example.avi that points to a real example.avi video file. When a program tries opens the symlink, it really opens the video file. But now I would like execute a command line whenever a program tries to open the symlink file.
Is that possible?
ps: windows
No, there is no built-in way of creating a symlink or other file system object that causes a command to be executed when it is opened by an application.
It should in principle be possible to do this with a file system filter driver. But that's very complicated. I believe there are some third-party tools to simplify this sort of task, but I don't have any experience with them.
While I am clearly ignorant on the subject of symlinks in Windows (see my comments on your question). I just played with it and proved that you could basically do this by symlinking to a wrapper for your avi. I.e. symlink to an exe or a batch file, etc. which does what you want and then opens the avi. Here's a test I ran with txt files and notepad:
Create a file called test.txt with some text. Create a file next to it called test.bat. Here's the batch:
notepad test.txt
When you run the batch, it just opens the txt in notepad.
Then I added a symlink:
mklink test2.txt test.bat
Now, when I type test2.txt in the command prompt, or double click on it, it runs the batch and opens the test.txt file. Obviously, you can use the same basic logic. It doesn't, however, fire the batch off when I open the symlink in Notepad++. It just opens to batch for editing instead.
Of course, maybe you don't want a second file, in which case you need to literally embed your avi in some wrapper. I guess we ned to know more about what you want to do. It sounds like an attempt at malware hidden in a video to me...
I am trying to execute a .exe file (created by VB6) on Windows 7.
What the application will do is to simply create a text file, and then read the text for a text file.
All the functions are being tested successfully on Windows XP. When I execute the .exe file on Win 7, the functions act as usual but the file I created doesn't exist on the specific path (C:\test.txt). The most weird thing is that I can still read the content from the text file (through the .exe file) despite being unable to find the text file on file explorer.
Then I discovered that I have to choose [run as Administrator] to execute the .exe file, so that the file (test.txt) will be created on the C: drive. I am very curious how the .exe file can still read the text file even it is not existed, and how can I force the .exe file to run as Administrator?
Here is the coding to write and read a file.
Open "C:\" & "test.txt" For Output As #1
Print #1, cDrive.Text
Close #1
Open "C:\" & "test.txt" For Input As #1
Input #1, msg
Close #1
cDrive.Text = msg
Exit Sub
To answer the third remark:
Windows Vista and Windows 7 User Access Control (UAC) introduced a feature called the VirtualStore which is designed to add an extra layer of security protection for applications installed under the Program Files folder. If you search for the file on you hdd you might find a second instance of the file in /User/AppData/Local/VirtualStore
So that's why it is still able to read text.txt allthough is doesn't excist in the location you mentioned.
I suggest that you run the program as an administrator by using the feature in the shortcut (after compiling and installing).
If you asked about it when in debug mode - I believe that if the user that you use to debug is an admin - it's enough.
I have no answer for your question "I am very curious how the .exe file can still read the text file even it is not existed"
You should not specify open as #1 directly, use FreeFile() function instead Look here for a sample.
Good luck
Drive C is being protected by Win7, you can still write to it, but you really shouldn't.
If you want to run the app as admin:
right click on the EXE
select PROPERTIES
go into COMPATABILITY tab
check RUN THIS PROGRAM AS ADMINISTRATOR check box
click OK
Now every time you run the app, it will run as administrator
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.