I am using solaris OS. the problem is when is redirect /dev/null to a "growing big log file", it becomes unreadable. Also it helps to decrease the file size to zero, but I can not open it with less command du to error that says it is "binary file, do you want to open it?"
Do you know how to work around this problem?
Related
Emacs 24 in Ubuntu 14.
I have file opened only in emacs, and it gives me this constantly, after each saving. that is annoying.
This is strange, because earlier everything worked fine. I can hardly guess what could I break during this time. I'am total newbie in Ubuntu, using it according to instructions found in internet.
Now I'm using emacs 23, everything is fine. I guess, I need auto-syncronization of opened buffer with saved file right after saving. Anyway, how can I fix it?
It sounds like some other program on your computer is reading the file when it changes, and possibly even introducing changes (perhaps just to the modification time, rather than to the contents). It's hard to say off-hand just what that would be.
A workaround try M-x global-auto-revert-mode. It will only auto-revert if you have no local modification since the last saving. This is generally a nice mode to turn on if you use multiple editors, and I keep it enabled all the time.
Other ideas:
Check if any other process currently has the file open using fuser /path/to/filename.txt (note: it only shows open file descriptors, not processes that hold the file content in memory and write it later)
Do you use any non-standard filesystem? (check with df -h /path/to/filename.txt and mount)
Is your system time stable? (Manually check date, scan the output of dmesg for obvious errors concerning timekeeping, and look for errors related to NTP in the logfiles in /var/log/.
I'm using Perl 5.16.1 from Strawberry in a Windows environment. I have a Perl script reading very large text files. The smallest text file is 30M. When reading files that do not have a line feed at the end of the very last line I get very peculiar results. It may not happen all the time but when it does It's as though it is reading cached data from the I/O system for another file that I previously opened with the Perl script. If I manually edit the file and add a line feed it's fine. I added a line counter and some inline code to display what happens when I'm near the end of the file to make sure I wasn't going nuts. To try and fix I tried adding this to my script:
open (SS_LOG, ">>", $SSFile) or die "Can't open $SSFile\r\n $!\r\n";
print SS_LOG "\r\n";
close SS_LOG;
but it does nothing. The file stays the same size. I'm also storing data in large arrays.
Has anyone else seen anything like this?
Try unbuffering your output:
SS_LOG->autoflush(1);
I am having this script to find a file and select it
set filePath to ("filePath.ext" as POSIX file)
tell application "Finder"
if (exists filePath) then
select filePath
activate
else
display alert "File " & filePath & " does not exist"
end if
end tell
it is working perfect well on Mac os x 10.6.x (LION) but when I try to run this script on Mac os x 10.5.x (snow-leopard) it is selecting file but taking too much time. Any suggestion how can I make this code work fine on both versions of Mac.
Thanks in advance :)
EDIT:
I am selecting file from a network drive and hostel system is having a Windows Os. All systems are located in the same network.
The reveal command may be of assistance to you. It simply locates a file in the finder, opens a new window if necessary, and then selects the file—all that using just one line of code:
tell application "Finder" to reveal path:to:some:file
The file must actually exist for this to work, of course. You know a particular file/directory exists when it is presented in alias form (I.e. Macintosh HD:Users:billybob:Desktop:howToHack.pdf). Attempting to coerce a nonexistent file into an alias will result in an error. If you are 100% certain that the file exists and know exactly where it is, congratulations! You have one less thing to worry about. If your certainty level is anything less than 100%, use a try-catch block. They have saved my life on multiple occasions. That way, if you distribute your applications via the Internet like I do, your clients are not presented with undecipherable error messages.
An example of this is demonstrated below:
set theFile to "/Users/billybob/Desktop/folder/subfolder/subfolder2/subfolder3/fineByMe.mp3"
try
set theFile to (theFile) as alias
tell application "Finder" to reveal theFile
on error
display alert "The file " & quoted form of theFile & "does not exist."
-- The variable 'theFile' couldn't be coerced into an alias.
-- Therefore, 'theFile' still has a string value and it can be used in dialogs/alerts among other things.
end try
Is this more efficient or less time consuming than what you've written? I'm not particularly sure, to be honest. However, I have written many scripts that have included the reveal command on Mac OS X 10.5.8 (Leopard), Mac OS X 10.6.8 (Snow-Leopard), and Mac OS X 10.7.3 (Lion), and the results have been satisfying.
You have errors in your code.
You forgot a period after "exists" in the display alert line.
You cannot display a posix file. It must be converted to string. Apple doesn't have this optimization.
The exists command will always return false the way you've used it because you didn't provide a full file path. Although java and c++ allow abbreviated file paths, apple does not.
I cannot comment, so I was forced to put this as an answer instead.
Not really sure if this is possible, but I am running this on Terminal:
script -q \/my\/directory\/\/$outfile \.\/lexparser.csh $file
Explanation
Through a perl script. The first directory and $outfile is where I am saving the output of the Terminal command. the \.\/lexparser.csh $file is just calling on that script to work on the input file, $file.
Problem
However, I put -q b/c I didn't want to save the unnecessary print to the file. The file is big ~ 30 thousand lines of text. It has been running for some time now, which was expected.
Question
I would like to check and ensure everything is going smoothly. The file output name is in Finder, but I'm afraid if I click on it, it will ruin the output. How can check the progress (possibly the current text file) without disrupting the process?
Thanks for your time, let me know if the question is unclear.
Open a new Terminal, navigate to the output directory, and:
tail -f <output_file>
You will continue to see new appends to the file without interruption to any writing process. Just leave the Terminal open with the tail going, and you can watch it all day long. Grab some popcorn.
In addition to tail, you can also learn about tee. The point of tee is to output to a file while also outputting to STDOUT in your terminal. Best of both worlds! Well, someone good aspects of two possible worlds.
You could tail the file via the command line which shouldn't cause problems.
Additionally you could have the program print to stderr as well as stdout, redirect stdout to the file and allow stderr through so it could tell you it's progress. Though that is more of a 20 / 20 hindsight solution.
I am new to UNIX and when I was reading a book about UNIX, I came across following two problems that I didn't understand. I would really appreciate your help.
1) Look up the man page for the file command, and then use it on all files in the /dev directory. Can you group these files into two categories?
2) Run the tty command, and note the device name of your terminal. Now use this device name(/dev/pst/6) in the command cp /etc/passwd /dev/pts/6. what do you observe?
Fair question really... it's so easy for us to take so much for granted.
To read the manual page for the command called file, just type...
man file
...which will present a lot of information that will probably be quite confusing, but you'll get used to this stuff pretty quick if you keep at it. Crucially, file is a program that tries to categorise the files you ask it to. If you type...
file /dev/*
...that will do what the question asked, and invoke file with a list of the files in the /dev/ subdirectory. The list is actually prepared by the "shell" program that you're typing into, which then executes the file program and passes it the list. file then outputs some description of the files. On my computer, and where [SHELL-PROMPT] will be different on your computer, I typed file /dev/* and part of the output looked like:
[SHELL-PROMPT] file /dev/*
...lots of stuff...
/dev/cevt: character special (255/176)
/dev/console: character special (5/1)
/dev/core: symbolic link to `/proc/kcore'
/dev/cpqci: character special (10/209)
/dev/cpqhealth: directory
/dev/crom: character special (255/180)
...lots of stuff...
/dev/md8: block special (9/8)
/dev/md9: block special (9/9)
/dev/mem: character special (1/1)
/dev/mice: character special (13/63)
/dev/mouse0: character special (13/32)
/dev/mptctl: character special (10/220)
/dev/net: directory
/dev/nflog: character special (36/5)
/dev/null: character special (1/3)
/dev/parport0: character special (99/0)
...lots of stuff...
There's a filesystem entry for each directory/file combination (known as a path) in the left column, and file is describing the content in the right. Those descriptions may not make a lot of sense, but you can see that some patterns: some entries are "block special", others "character special", some are directory which implies you may find more files underneath (i.e. ls /dev/net/*). The numbers after "special" files are just operating system identifiers to differentiate the files mentioned. The import of this is that input and output from some devices connected to the computer is being made possible as if the device was a file in the filesystem. That "file" abstraction is being used as a general model for input and output. So, /dev/tty for example is tty - or terminal - device. Any data you try to read from there will actually be taken from the keyboard you're using to type into the shell (in the simple case), and anything you write there will become visible in the same terminal you're typing into. /dev/null is another interesting one: you can read and write from it, but it's an imaginary thing that never actually provides data (just indicates and End-of-File condition, and throws away any data written into it). You can keep reading from /dev/random and it will produce random values each time... good if you need random numbers or file content for encryption or some kind of statistical work.
2) Run the tty command, and note the
device name of your terminal. Now use
this device name(/dev/pst/6) in the
command cp /etc/passwd /dev/pts/6.
what do you observe?
By typing "tty" you can ask for the device representing your terminal...
[SHELL-PROMPT] tty
/dev/pts/11
But, I just said /dev/tty is another name for the same thing, so there's normally no need to use the "tty" program to find this more specific name. Still, if you create a couple terminal windows to your host, and type tty in each, you will see that each shell is connected to a different pseudo-terminal device. Still, each shell - and program run from the shell - can by default also refer to its own terminal input and output device as /dev/tty... it's a convenient context-sensitive name. The command...
cp /etc/passwd /dev/pts/6
...where you replace 6 with whatever your tty program really reported (e.g. 11 in my case), does the same thing as...
cp /etc/passwd /dev/tty
...it just reads the contents of the file /etc/passwd and writes them out on your screen. Now, the problem is that /etc/password looks like a lot of unintelligible junk to the average person - it's no wonder you couldn't make sense of what was happening. Try this instead...
echo "i said hello" > /tmp/hello.file
cp /tmp/hello.file /dev/tty
...and you'll see how to direct some specific, recognisable content into a new file (in this case putting it in the tmp "temporary" directory (the file will disappear when you reboot your PC), then copying that file content back to your screen.
(If you have logged on in two terminal windows, you can even go into one shell and copy the file to the /dev/pts/NN device reported by the other shell, effectively sending a message to the other window. You can even bypass the file and echo 'boo' > /dev/tty/NN. You'll only have permissions to do this if the same userid is logged into both windows.)