Welcome!

By registering with us, you'll be able to discuss, share and private message with other members of our community.

SignUp Now!

Just an out-of-curiosity question the List command vs. the @Lines function...

May
855
0
Without going into too much detail that is really irrelevant, I am creating a file using redirection (i.e. >&) that ultimately, from past experience, will take many hours to produce. (I'll just say that it has to do with an external hard drive connected via a USB port.) Well, I'd like to "check up" on the "progress" this program has made so far periodically, and one way of doing this is via the "List' command on the file being produced via redirection and scrolling down to the bottom (the "end" key followed by scrolling down to the very bottom) and looking at the line number displayed in the "List" command's title bar. However, I'm really only interested in the number of lines this file contains rather than actually looking at the contents of the file, and the "@Lines" function would be the perfect way to find that out. However, attempting to use it on this file yields "TCC: (Sys) The process cannot access the file because it is being used by another process." So the question(s) are simple: Why can't "@Lines" read the file to count the number of lines it contains whereas the "List" command can read it and is there any easy way to just determine how many lines the file contains at any given point in time?
 
... is there any easy way to just determine how many lines the file contains at any given point in time?
From Cygwin...
Code:
wc -l
 
FYI, I use the @LINES function to determine number of lines in a file, unless I also want to know the length of the longest line, in which case I do use the above wc program, option -L provides that information (or -lL reports both). I use the line count in some instances to decide whether to just type a file (because it fits on a single screen without scrolling, using the current screen size), or LIST to allow me to scroll.
 
4UTILS LC and @LC[] had the same problem. To read (count the lines) in a file to which a FILE_WRITE handle already exists, you must specify FILE_READ (access mode) **and** FILE_SHARE_WRITE (share mode). I didn't fully understand this until reading tho fine print. Of "CreateFIle/FILE_SHARE_WRITE" the docs say "If this flag is not specified, but the object has been opened for write access or has a file mapping with write access, the function fails" [i.e., regardless of the access mode]. It says something similar about FILE_SHARE_READ and FILE_SHARE_DELETE. So I imagine if all you want to do is read a file (which ohter apps usually let you do) you are most likely to get access if you specify all three share modes. I changes LC/@LC and now they can count lines in a file to which another TCC is currently writing (new one not uploaded).
 
@LINES won't read a file that another process has opened for write, because it would return a wrong/useless number. LIST doesn't care, because it's not returning anything that you're going to evaluate.

Why don't you use TAIL /F, which is actually intended for this purpose?
That doesn't tell you the number of lines and can get quite hairy if the file is being written fast. OTOH, WC.EXE (and 4UTILS's LC and @LC) tell you the number of lines at the moment the file was opened. If the user understands that, it's some indication of the file size.

I thought there could be a race condition if the file were being written faster that a line-counting function/app could read (all the way through) it. But that's apparently not the case. One TCC was doing

Code:
(for /l %i in (1,1,10000000) (echo foo)) >> foo.txt

while another was doing

Code:
do forever (echo [EMAIL]%@lc[foo.txt])[/EMAIL]

The results look like this

Code:
1767655
1767794
1767948
1768087
1768228
1768368
1768483
1768621

Obviously the writing was much faster than the reading but it was some indication of the progress of the writing and apparently the reading app's notion of EOF doesn't change as more is written.
 
Thanks, guys, for all of your good answers. But the basic question was really "How come the "List" command can read the file to display it (and then inherently allow you to count the number of lines in the file), but @Lines can't?

And Rex, the answer to your question is simple. I'm not aware of every one of the (truly awesome!) number of capabilities that TCC has, and due to my memory issues I'm almost (not quite) incapable of learning new (to me) ones.
 
@LINES won't read a file that another process has opened for write, because it would return a wrong/useless number. LIST doesn't care, because it's not returning anything that you're going to evaluate.

Why don't you use TAIL /F, which is actually intended for this purpose?
I was just bitten by this one again. I don't want to watch the file; I want to know how many lines it has at the moment.

The result may be wrong, but it was right at some recent moment in time ... and it's certainly not useless.

You could make the same argument about @FILESIZE which **does** work on a file which another process has opened for writing.
 
I try really hard to avoid returning results that I know are going to be wrong by the time you get it.

Most of the time you're not going to be able to read the file anyway; very, very few apps will open a file for write and still allow another app to open it for read. But if you want to knowingly propagate bad info, you can certainly write a simple plugin that will return a value that sometimes appears (wrongly) to be valid. But I'm not going to change @LINES.
 
I try really hard to avoid returning results that I know are going to be wrong by the time you get it.

Most of the time you're not going to be able to read the file anyway; very, very few apps will open a file for write and still allow another app to open it for read. But if you want to knowingly propagate bad info, you can certainly write a simple plugin that will return a value that sometimes appears (wrongly) to be valid. But I'm not going to change @LINES.
Perhaps you should change @FILESIZE.
 
Guys, just to be clear on my needs re all of the above. First, "tail /F" doesn't do the job for me because I don't want (at all) to look at the contents of the file, I am only interested in the number of lines it contains as of that moment. Using "list" and scrolling to the bottom gives me the information I need, it's just that that's a little more time and effort than I'd like to spend on this task (I have a good estimate of how many lines the file will contain after the process completes; the number of lines the file has in it at any point in time is nothing more than a rough estimate of how far along the process is, and its total accuracy is not needed). Second, it would appear from the above (I haven't tried it yet) that "wc" will do what I want done for the immediate future. Thank you. And Vince, I look forward to getting the updated LC and @LC since that is, as I'm sure you've figured out, exactly what I wanted. Thank you in advance for that.
 
Thank you. And Vince, I look forward to getting the updated LC and @LC since that is, as I'm sure you've figured out, exactly what I wanted. Thank you in advance for that.

What updates? LC and @LC have been in 4UTILS for quite a while and I don't think they need updating.
 
Sorry, Vince. I got the impression that getting that information for files that were open for writing was new functionality that had not yet been "delivered'. And I got that impression from your statement (above) that
Code:
I changes LC/@LC and now they can count lines in a file to which another TCC is currently writing (new one not uploaded).
So what does the above mean if you don't mind me asking?
 

Similar threads

Back
Top