How to print only one line of my log file (that is showing the log progress) continuously in present buffer? I could not find tail -f working for me.
Basically, I have made my own command using function call in .vimrc and later on I have opened the quickfix window to show the compilation errors. Presently, i am just echoing the message "running software in background" which seems static and the user may think that the system is hanged if he runs a large design. How can I show my progress simultaneously in the current buffer from the log file which ius updated continuously?
Related
After trying to compile my program on Linux, I occasionally get error messages. Sometimes I get a lot needing me to scroll all the way to the top to see where my code broke first. Is there a short cut/faster method to scroll to the first output after I run for example a command like "make file"
I have tried "make file | less", but this chops off the first half of all the error messages, which is the part I am interested in, given that the error messages in the latter half is a result of something not being compiled correctly in the beginning of my file.
I can redirect the output of a process to a file
./prog > a.txt
But if I delete a.txt and do not restart prog, then no more output will get into a.txt. The same is the case if I use the append-redirect >>.
Is there a way to make my redirection recreate the file when it is deleted during the runtime of prog?
Redirection is part of the OS I think and not of prog. So maybe there are some tools or settings.
Thanks!
At the OS level, a file is made up of many components:
the content, stored somewhere on the storage device;
an i-node that keeps all file information except the name;
the name, listed in a directory (also stored on the storage device);
when the file is open, each application that opens it handle memory buffers that keep some of the file content.
All these are linked and the OS keeps their booking.
If you delete the file while it is open by another application (the redirect operator > keeps it open until ./prog completes), only the name is removed from the directory. The other pieces of the puzzle are still there and they keep working until the last application that keeps the file open closes it. This is when the file content is discarded on the storage medium.
If you delete the file, while ./prog keeps running and producing output the file grows and uses space on the storage medium but it cannot be open again because there is no way to access it. Only the programs that have it already open when it was deleted can still access the file until they close it.
Even if you re-create the file, it is a different file that happens to have the same name as the deleted one. ./prog is not affected, its output goes to the old, deleted file.
When its output is redirected, apart from restarting ./prog, there is no way to persuade it to store its output in a different file when a.txt is deleted.
There are several ways to make this happen if ./prog writes itself into a.txt (they all require changing the code of ./prog).
You can use gdb to redirect the output of program to file when original file is deleted.
Refer to this post.
For later references, I give the only excerpt from the post:
Find the files that are opened by the process using /proc/<pid>/fd.
Attach the PID of program to gdb.
Close the file descriptor of the deleted file through gdb session.
Redirect the program output to another file using gdb calls.
Examples
Suppose that PID of program is 19080 and file descriptor of deleted file is 2.
gdb attach 19080
ls -l /proc/19080/fd
gdb> p close(2)
$1 = 0
gdb> p fopen("/tmp/file", "w")
$2 = 20746416
(gdb) p fileno($2)
$3 = 7
gdb> quit
N.B.: If data of the deleted file is required, recover the deleted text file before closing the file handle:
cp -pv /proc/19080/fd/2 recovered_file.txt
I want empty a continuously printing log file in production,
I use below command:
echo > filename.log
I know the above command is used to empty continuously running log file if that file is getting too big.
But my query is - What happens to the old file?Does that file gets backed up or the previous data is lost forever?
How can I get the previous logs?
Previous data is basically lost forever.
You can search for backup files.There can be a file named filename.log~ for filename.log in the same directory.
It depends. If the other program has the log file permanently opened, the current log will be unlinked from its folder and your program just creates a brand new empty file. But the other program will still log to its now innaccessible file which will only be actually deleted when the program close it (or ends).
If the other program consistently uses the pattern open-write-close, you just erase previous content and new data will to that new file.
In any case old content is lost, but in first one the disk space is not reclaimed. If you want to keep it, you should google for log rotate
About 10% of the time, when I attempt to save my file in Emacs I get the following error:
Opening output file: resource temporarily unavailable,
I'm currently using Emacs GNU Emacs 24.3.1 (x86_64-pc-linux-gnu, GTK+ Version 3.4.2) on
Ubuntu 12.04. I've also verified that this issue occurs logged in as a different user and using Emacs 23.3.1.
This issue gets to be a real pain when I make a fix, attempt to save, and then wonder why my fix didn't happen.... only to find out later that the Emacs save was never successful.
If I notice it happen, I'll keep hitting Ctrl-x Ctrl-s until a save actually goes through (takes a few times).
Does anyone have any idea why this happens and how to prevent it?
Update:
(More info per request)
I'm currently on a Ruby on Rails project and have been getting the error while editing a variety of file types *.rb, *js.coffee, *js.erb, *html.erb, etc.
The files I receive the error on are always files local to my machine. I haven't tested remote files.
If I look at the *messages buffer, for every time the error message occurred, the error is prefixed with: save-buffer-2
Update 2:
Issue is encountered in multiple Emacs versions by multiple users.
Update 3:
This doesn't appear to be an Emacs specific issue as I now get the occasional "Unable to save" popup window while attempting to save files in Sublime-text editor.
This can be a bug from emacs (M-x report-emacs-bug), some issue with your filesystem (I assume this is not the case because most likely you checked if problem happens with other editors), or some process in your local setup messing with your files.
For testing if the later is the case, you could try to eval this and then reproduce the problem:
(defadvice save-buffer (around find-shenanigan activate)
(condition-case ()
ad-do-it
(error
(shell-command (format "lsof -V %s" (buffer-file-name)) "*debug-issue*"))))
What this does is every time the save operation fails, it executes a command that takes a picture of the processes that have your file opened. If you see any process, you know who investigate. man lsof will help with the details.
Note: Does the problem happen also with emacs -Q?
EDIT: if you can use sudo without password (NOPASSWD in /etc/sudoers), replace "lsof" with "sudo lsof"
EDIT: I redirected the output of the lsof to a buffer named *debug-issue*; check that buffer if error.
I have an linux app that uses cups for printing, but I've noticed that if I print and then quit my app right away my printout never appears. So I assume that my app has to wait for it to actually come out of the printer before quitting, so does anyone know how to tell when it's finished printing??
I'm using libcups to print a postscript file that my app generates. So I use the command to print the file and it then returns back to my app. So my app thinks that the document is off to the printer queue when I guess it has not made it there yet. So rather than have all my users have to look on the screen for the printer icon in the system tray I would rather have a solution in code, so if they try and quit before it has really been sent off I can alert them to the fact. Also the file I generate is a temporary file so it would be nice to know when it is finished with so I can delete it.
As soon as your CUPS web interface (localhost:631) or some other thing to look at what CUPS sees shows you that CUPS received the job, you can quit the application.
How about using a print spool service like lpr & lpq?
You certainly do not need to wait till the paper is out of the printer. However, you need to wait until your temporary file is fully received by cupsd in its spooling aerea (usually /var/spool/cups/).
If you printed on the commandline (using one of the CUPS lp or lpr commands) you'd know the job is underway if the shell prompt returns (the command will even report the CUPS job ID for the job sent), and if the exit code ($?) is 0.
You do not indicate which part of libcups and which function call you are using to achieve what you want. If I'd have to do this, I'd use the IPP function cupsSendRequest and then cupsGetResponse to know the result.
Your app likely hadn't finished printing yet when you quit it. If you're using evince to print a PDF or other document, this is a known bug--there is no visual confirmation that the printing operation is underway. If the print job has been submitted, a printer icon will appear in your system tray until the actual printing has finished. You can click on the printer icon in the system tray and see what jobs are currently running and pending.