Welcome!

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

SignUp Now!

Documentation FOLDERMONITOR /W Option

Jun
744
16
The help for the FOLDERMONITOR command says that the "/Wn" option waits "n milliseconds". I put in "/w500", and the command never ran (for as long as I was willing to wait). At first I thought that instead of milliseconds, the time unit was Windows ticks, but after even that time elapsed, I thought it must be "seconds". I tried "/W1" and the delay did seem to be one second.

I also noticed that running the command with no arguments does not show that wait time value. It would be good if it did.

Also, it seems that the command specified by FOLDERMONITOR does not run unless the TCC session from which it was launched is currently active. From another TCC session (with a different current directory), I created a new file in the monitored directory, and the script command did not run. When I used a command from the other TCC session that had a delay and I switched back to the original session, the command did run after the file was created (and with the 2-second delay I programmed using "/W2").
 
Also, it seems that the command specified by FOLDERMONITOR does not run unless the TCC session from which it was launched is currently active.

Not true in my (considerable) experience.

In one TCC.

Code:
v:\> foldermonitor %tmp /i"*" deleted modified renamed forever beep

In another.

Code:
d:\> touch /c t:\foobar.txt
2024-12-28 21:18:40.639  T:\foobar.txt

d:\> del t:\foobar.txt
Deleting T:\foobar.txt
     1 file deleted

I heard two beeps.
 
Thanks, Vince. Perhaps the difference is that my foldermonitor-programmed command is writing to the screen buffer. In general, it is hard to get foldermonitor to work with commands that generate screen output. I have had to add multiple delays and "keystack enter" to get the output to appear and to get a new command prompt to appear after that output. Everything seemed to work fine until I tried adding a file from another TCC window. Nothing happened.

When I specify the beep command, it works fine, as you say. Try it with a command such as "echo This is some text".

Can you figure out a way to display on the screen all files created today whenever a file is added or deleted? I'm trying to do this in my SCANS: folder with the scanner software running. Whenever a new file is generated by the scanner, I want the TCC window from which the scanner was launched to produce a display of all the new files.

By the way, I see that you included the option /i"*". That doesn't seem to be necessary. Perhaps that is the default if there is no include option. As with much of TCC/TCMD, the help is a bit sparse.
 
The help for the FOLDERMONITOR command says that the "/Wn" option waits "n milliseconds". I put in "/w500", and the command never ran (for as long as I was willing to wait). At first I thought that instead of milliseconds, the time unit was Windows ticks, but after even that time elapsed, I thought it must be "seconds". I tried "/W1" and the delay did seem to be one second.

That's not what /W means -- it specifies the amount of time to wait after the last folder / file change before executing the command. It's intended to be used when you have something making multiple changes to the folder / file in a short period of time (as in a few milliseconds), and you don't want to execute the command repeatedly.

I also noticed that running the command with no arguments does not show that wait time value. It would be good if it did.

See above.

Also, it seems that the command specified by FOLDERMONITOR does not run unless the TCC session from which it was launched is currently active. From another TCC session (with a different current directory), I created a new file in the monitored directory, and the script command did not run. When I used a command from the other TCC session that had a delay and I switched back to the original session, the command did run after the file was created (and with the 2-second delay I programmed using "/W2").

Definitely not the case - the folder monitor runs in a separate thread, and whether the TCC session is active or not is not relevant. However, if you're running in a TCMD tab window, the non-visible windows are not updated (in order to improve the performance of the active visible window).
 
By the way, I see that you included the option /i"*". That doesn't seem to be necessary. Perhaps that is the default if there is no include option. As with much of TCC/TCMD, the help is a bit sparse.

/I is only necessary if you want to only include specific files. I don't think it's necessary to add something to FOLDERMONITOR (and every other command that takes filenames) that says "* is equal to everything".

I'm not sure I would say that a 1,500 page help file is "sparse". Would you be more inclined to read the help if it were 15,000 pages? Would you be willing to forgo updates for 5 years so the help could be expanded by an order of magniture (or two)?
 
Perhaps the difference is that my foldermonitor-programmed command is writing to the screen buffer. In general, it is hard to get foldermonitor to work with commands that generate screen output.
Do you mean normal terminal output? I have no such problems. In one TCC ...

Code:
v:\> foldermonitor t:\ /i"*" created deleted modified renamed forever echo %%_foldercount %%_foldername %%_foldertime %%_folderaction %%_folderfile1 %%_folderfile2

In another TCC ...

Code:
v:\> del t:\foobar2.txt
Deleting T:\foobar2.txt
     1 file deleted

v:\> touch /c t:\foobar.txt
2024-12-29 09:51:21.133  T:\foobar.txt

v:\> ren t:\foobar.txt foobar2.txt
T:\foobar.txt -> T:\foobar2.txt
     1 file renamed

Back in the first TCC, these appeared instantly.

Code:
1 t:\  9:51:07.850 DELETED foobar2.txt
2 t:\  9:51:21.133 CREATED foobar.txt
3 t:\  9:51:21.133 MODIFIED foobar.txt
4 t:\  9:51:28.419 RENAMED foobar.txt
5 t:\  9:51:28.419 RENAMED  foobar2.txt
 
Code:
v:\> foldermonitor t:\ /i"*" created deleted modified renamed forever echo %%_foldercount %%_foldername %%_foldertime %%_folderaction %%_folderfile1 %%_folderfile2

In another TCC ...

Code:
v:\> del t:\foobar2.txt
Deleting T:\foobar2.txt
     1 file deleted

v:\> touch /c t:\foobar.txt
2024-12-29 09:51:21.133  T:\foobar.txt

v:\> ren t:\foobar.txt foobar2.txt
T:\foobar.txt -> T:\foobar2.txt
     1 file renamed

Back in the first TCC, these appeared instantly.

Code:
1 t:\  9:51:07.850 DELETED foobar2.txt
2 t:\  9:51:21.133 CREATED foobar.txt
3 t:\  9:51:21.133 MODIFIED foobar.txt
4 t:\  9:51:28.419 RENAMED foobar.txt
5 t:\  9:51:28.419 RENAMED  foobar2.txt
A great example, Vince, which should be included in the public help file.

I have added it as an example to my personal TCC Help File.

Joe
 
/I is only necessary if you want to only include specific files. I don't think it's necessary to add something to FOLDERMONITOR (and every other command that takes filenames) that says "* is equal to everything".

Huh? The issue is not the meaning of "". It's that /I"" is the default if no other /I options are specified. When I first read the help, I wondered about that and whether I needed to use /I"*" (as Vince, too, apparently thought). I also wondered if it could specify files beyond the specified folder. For example, if there is no /S option, can one still monitor for a specific file in a subdirectory by using /I"subdir\file", or is the argument of the /I option only files with no path? I suspect the latter, but the help does not make that clear. This could be made clear with very few extra words.

That's not what /W means -- it specifies the amount of time to wait after the last folder / file change before executing the command. It's intended to be used when you have something making multiple changes to the folder / file in a short period of time (as in a few milliseconds), and you don't want to execute the command repeatedly.

Huh again? That's exactly why I was adding the /W option. When my scanner produced a new file, the monitor was being triggered more than once (for reasons I don't understand but using Vince's example could probably figure out). So I wanted to add a 500 millisecond delay, per the help, before the monitor decided on the folder status. Since the delay turned out to be 500 seconds rather than 500 milliseconds, the monitor never triggered for as long as I was willing to wait. Now that the command has /W2, the monitor is working just fine.
 
Do you mean normal terminal output? I have no such problems.

Here's an example of what I was talking about.

Code:
TCC33.00.20 C:\temp>fm /c & fm c:\temp\ created deleted forever (echo Line 1 & echo Line 2)

TCC33.00.20 C:\temp>fm
c:\temp\   created deleted   (0/FOREVER)   (echo Line 1 & echo Line 2)

TCC33.00.20 C:\temp>echo junk > junk

TCC33.00.20 C:\temp>del junk
Deleting C:\temp\junk
Line 1
Line 2
     1 file deleted

TCC33.00.20 C:\temp>

When the file "junk" was created, nothing appeared. When it was deleted, the output appeared in the middle of TCC's output. I've gotten many other results for the same test. As I wrote, I finally realized that it's a timing issue. Two processes are trying to write to the same screen buffer at the same time. NOTE: I nearly always work in TCMD, not standalone terminals. Things may be different in that case.

Adding a /W1 one-second wait to the monitor solves part of the problem, but not all of it. When the file is created, the two lines are echoed a second later, after the command prompt has come up. For some reason, nothing appeared when the file was deleted.

Code:
TCC33.00.20 C:\temp>fm /c & fm /w1 c:\temp\ created deleted forever (echo Line 1 & echo Line 2)

TCC33.00.20 C:\temp>echo junk > junk

TCC33.00.20 C:\temp>Line 1
Line 2
                    del junk
Deleting C:\temp\junk
     1 file deleted

TCC33.00.20 C:\temp>

For monitoring my scanner folder, I think I have gotten things working (but I've thought that before and been proven wrong) with a delay in the monitor itself, delays in the batch file it executes, and an extra KEYSTACK ENTER in the batch file to get a command prompt. It's quite a kludge.

Basically, I seem to be trying to do something that is not really appropriate, at least in a TCC tab in TCMD. Maybe I should play around in a standalone TCC window.
 
Vince, I tried your example and found two interesting differences. I'm now working in a standalone TCC window.

When I run your example by copying it from here, it works, but the first line of output appears on the line with the command prompt, and the rest of the output appears on separate lines below. The window then shows no command prompt, but input appears where it would if the prompt were there. You seemed to imply above that all the output appeared on their own lines.

Here's something even odder. I tried to fix the problem by making a compound command with "echo." followed by your echo command. So the command at the end of the FOLDERMONITOR line was

Code:
(echo. & echo %%_foldercount %%_folder name %%_foldertime %%_folderaction %%_folderfile1 %%_folderfile2)

In that case, the double percents were not collapsed, and the resulting monitor became:

Code:
TCC33.00.20 C:\temp>fm
c:\temp\   created deleted modified renamed   (0/FOREVER)   (echo. & echo %%_foldercount %%_foldername %%_foldertime %%_folderaction %%_folderfile1 %%_folderfile2)

Something funky is going on with a compound command.

If I change all the %% to %, the command works, but there is a third strange thing. Now the output lines have an extra blank line after each one that was not there before I used a compound command.
 
When I run your example by copying it from here, it works, but the first line of output appears on the line with the command prompt, and the rest of the output appears on separate lines below. The window then shows no command prompt, but input appears where it would if the prompt were there. You seemed to imply above that all the output appeared on their own lines.
That just can't be helped. The FOLDERMONITOR thread and TCC's main thread can both write to the console (period!). It's the same with TCC's THREAD command. If you want to see the events immediately in an interactive session, you'll have to deal with the consequences. Some things can be kludged around. For example, you can force output to begin in column 1 like this.

Code:
foldermonitor t:\ created deleted modified renamed forever echo ^^e[1G%%_foldercount %%_foldername %%_foldertime %%_folderaction %_folderfile1 %%_folderfile2

You can avoid lots of anomalies by specifying a BTM as the command and having the BTM write to a log file.

Perhaps you'd try this.

Code:
copy ftp://vefatica.net/4plugins/x64/4threads64.zip

It used to be on lucky.syr.edu. It hasn't been available since I retired (2017). It contains WATCHDIR (hard to use, a couple useful features, otherwise a lot like FOLDERMONITOR).

Code:
WATCHDIR ID path [/+...] [/S] [/N n] [/I spec(s)] [/X spec(s)] [/R] [/B] [/O] [/L[...] [file]] [/E "command"]

    ID       req'd unique string ID; case-insensitive; will be converted to uppercase; 15 char limit; If /E
             is used, ID_ will prefix environment variables available during command (see below)
    path     req'd directory to watch
    /S       watch subdirectories
    /+...    filter list (see below); default: /+FDZW
    /N n     stop after n changes; 0 = unspec'd = no limit
    /I specs include names matching any spec (see below)
    /X specs exclude names matching any spec (see below)
    /R       case-insensitive regular expression searches (/I,/X, see below)
    /B       block: return when watch is complete/killed
    /O       console output (automatic without /L or /E)
    /L[+][format] [file] - logging, see notes below
    /E "command" - must be last on the command line; escape embedded quotes as \"
       These environment variables are set before command: ID_ACTION, ID_NAME, ID_DATE, ID_TIME, ID_COUNT
       where "ID" is the ID of the watch, and the variable WDID is also set to the watch's ID

    Filters: /+... (default: /+FDZW)
        F - filename (create, delete, rename)   Z - size
        D - dirname  (create, delete)           W - write time
        C - create time                         A - access time
        S - security                            T - attributes
        * - all of the above

    specs = spec[;spec[;...]] - wildcards (*?[]) cause a wildcard
    comparison; otherwise a case-insensitive substring search is
    done. If /I and /X are both spec'd the one spec'd second
    is seen only as exceptions to the one spec'd first.
    With /R, all I/X specs are treated as regular expressions.

    /L notes: default '/LIDCTAF .\<id>.log'
    use "/L+[...]" to append; Format elements:
        T = time  A = action  F = filename
        I = ID    C = count   D = date

WATCHDIR /L(ist) | /K(ill) | /P(ause/resume) [wildcard ID], default: *
 
Vince, can you reproduce the odd behavior I reported with compound commands? The first command inside (...) works normally, but something goes wrong with subsequent commands.

By the way, I've been experimenting in a standalone TCC window, and I haven't noticed anything different.
 
Vince, can you reproduce the odd behavior I reported with compound commands? The first command inside (...) works normally, but something goes wrong with subsequent commands.
I don't know why that happens. I worked around it in two ways, escape the '&' and strongly quote the command.

Code:
foldermonitor t:\ /i"*" created deleted modified renamed forever echo. ^& echo ^^e[1G%%_foldercount %%_foldername %%_foldertime %%_folderaction %%_folderfile1 %%_folderfile2

Code:
foldermonitor t:\ /i"*" created deleted modified renamed forever `echo. & echo ^e[1G%_foldercount %_foldername %_foldertime %_folderaction %_folderfile1 %_folderfile2`

But with ECHO. you'll get a blank line after every event.

Code:
1 t:\ 14:33:42.405 CREATED ~DFF273EFCEB6A8765B.TMP

2 t:\ 14:33:42.421 MODIFIED ~DFF273EFCEB6A8765B.TMP

3 t:\ 14:33:42.423 MODIFIED ~DFF273EFCEB6A8765B.TMP

4 t:\ 14:33:42.424 MODIFIED ~DFF273EFCEB6A8765B.TMP
 
The ()s work but delay the expansion of what's after the & ... so the %%s aren't needed.

Code:
p:\4threads\x64\release> foldermonitor t:\ /i"*" created deleted modified renamed forever (echo. & echo %_foldercount %_foldername %_foldertime %_folderaction %_folderfile1 %_folderfile2)

p:\4threads\x64\release>
1 t:\ 14:47:03.813 MODIFIED VSGitHubCopilotLogs

2 t:\ 14:47:09.618 CREATED ~DF1E6BA811D0CA5D88.TMP

3 t:\ 14:47:09.618 MODIFIED ~DF1E6BA811D0CA5D88.TMP

4 t:\ 14:47:09.634 MODIFIED ~DF1E6BA811D0CA5D88.TMP
 
OK. This looks like a bug that Rex will have to deal with. I'll make a separate thread here.
 
What's the bug ... the delayed expansion? Without it you'd get 1 below from the second command below ... desired?

Code:
v:\> set foo=1

v:\> set foo=2 & echo %foo
2
 
is there a link to the separate posting? i’m interested.
 
Huh again? That's exactly why I was adding the /W option. When my scanner produced a new file, the monitor was being triggered more than once (for reasons I don't understand but using Vince's example could probably figure out). So I wanted to add a 500 millisecond delay, per the help, before the monitor decided on the folder status. Since the delay turned out to be 500 seconds rather than 500 milliseconds, the monitor never triggered for as long as I was willing to wait. Now that the command has /W2, the monitor is working just fine.

Wait time is definitely in milliseconds.

Can you provide an example of why you think it's waiting 1000 times too long?
 
is there a link to the separate posting? i’m interested.

Sorry. I'm not sure how to create a link to another post. Search for one with the subject " Compound Commands Not Expanded Properly with FOLDERMONITOR".

Wait time is definitely in milliseconds.

Can you provide an example of why you think it's waiting 1000 times too long?

Maybe I overstrained my computer (or my brain) yesterday, because today I'm getting different results.

I entered the following command (fm is an alias for foldermonitor):

Code:
TCC33.00.20 C:\temp>fm /c & fm /w10 c:\temp\ created deleted forever beep

TCC33.00.20 C:\temp>fm
c:\temp\   created deleted   (0/FOREVER)   beep

Then I created a new file and started to count the time to the beep. Yesterday, when I tried it with /W2, it seemed to take about 2 seconds. So I started counting out 10 seconds. But the beep never sounded. When I deleted the file, the beep came immediately. And when I again created a file, again the beep came immediately. Maybe I've seen that before, that the monitor does not work the first time it should have been triggered.

Now I changed the option to /W2000. Again nothing happened the first time I created a file. It did work the second time.

Code:
TCC33.00.20 C:\temp>fm /c & fm /w2000 c:\temp\ created deleted forever beep

TCC33.00.20 C:\temp>fm

Perhaps I really am misunderstanding what the wait option is supposed to do. I thought that it would tell the monitor to watch the folder. When a file changes per the command, it would then wait the specified wait time for any further changes and only then execute the command. That seemed to work in my scanner folder. I had been getting multiple triggers when the scanner produced another file, and that stopped happening after I used /W2.

Is it possible that one cannot clear a monitor and immediately create another one? I tried the command below, but it didn't make any difference. I deleted several file one after another and waited. For some I got an immediate beep; for others I never got a beep.

Code:
TCC33.00.20 C:\temp>fm /c & delay 1 & fm /w2000 c:\temp\ created deleted forever beep & delay 1 & fm
c:\temp\   created deleted   (0/FOREVER)   beep

Help! What am I missing here?
 
What I'm missing is what your "fm" is defined to be.

Sorry. I showed that in other posts but seem to have forgotten to do that here. FM is just an alias for FOLDERMONITOR (to save me a lot of typing when running this command so often.

Here it is all expanded out.

Code:
[TCC33.00.20 | D:\archive]
>foldermonitor /c & foldermonitor c:\temp\ created forever ( echo %%tbeep & echo %%tbeep ) & foldermonitor
c:\temp\   created   (0/FOREVER)   ( echo %tbeep & echo %%tbeep )

The first %% was converted to % while the second one wasn't.
 
I think there's a misunderstanding of what the /Wn option does. It does NOT mean "after n milliseconds, execute the command that the first event triggered".

It actually means "Ignore the first n actions and only execute the command that the last (>1) event triggered". So if you have a FOLDERMONITOR definition that would only cause one trigger, you shouldn't be using /W.
 
Sorry. I showed that in other posts but seem to have forgotten to do that here. FM is just an alias for FOLDERMONITOR (to save me a lot of typing when running this command so often.

Here it is all expanded out.

Code:
[TCC33.00.20 | D:\archive]
>foldermonitor /c & foldermonitor c:\temp\ created forever ( echo %%tbeep & echo %%tbeep ) & foldermonitor
c:\temp\   created   (0/FOREVER)   ( echo %tbeep & echo %%tbeep )

The first %% was converted to % while the second one wasn't.

This has nothing to do with FOLDERMONITOR. When the parser is expanding variables, it only does it for the current command (stopping at the command separator). In this case, the parser has no idea what command you're running, or whether that command (which could be an alias, internal command, batch file, or external command) is expecting (or in this case optionally expecting) a trailing command group.

The appropriate syntax in this case would be to use back quotes to prevent expansion of anything inside the command group:

Code:
foldermonitor c:\temp\ created forever `( echo %tbeep & echo %tbeep )`
 
This has nothing to do with FOLDERMONITOR. When the parser is expanding variables, it only does it for the current command (stopping at the command separator). In this case, the parser has no idea what command you're running, or whether that command (which could be an alias, internal command, batch file, or external command) is expecting (or in this case optionally expecting) a trailing command group.

Wouldn't that comment apply to the other cases where a command group is used instead of a single command? I thought that the initial '(' told the parser that a command group was starting.

Code:
[TCC33.00.20 | D:\archive]
>if a eq a (echo %%line1 & echo %%line2)
%line1
%line2

It sounds as though you are saying that FOLDERMONITOR does not support command groups, only a single command (unless it's in a back-quoted string). Yet when the procedure for entering multiple commands as described in the help file is followed, the command displayed on the screen shows a command group (i.e., all the commands surrounded by parentheses).

May I suggest that either the code be changed so that command groups can be entered (which is what the "More?" entry case suggests) or that the help make clear that command groups may not be entered directly on the command line, only using the "More?" method or back quotes. And perhaps the output from the FOLDERMONITOR command with no arguments should show the command without parentheses.

I can use back quotes, as in the following example:

Code:
[TCC33.00.20 | C:\temp]
>fm /c & fm c:\temp\ created deleted forever `beep 440 %tbeep & beep 220 %tbeep` & fm
c:\temp\   created deleted   (0/FOREVER)   beep 440 %tbeep & beep 220 %tbeep

Note that the display of the command to be executed is not surrounded by "( )". The above command works fine. I get the two beeps. (And it may be working every time now, but that behavior has been erratic.)
 
Last edited:
Wouldn't that comment apply to the other cases where a command group is used instead of a single command? I thought that the initial '(' told the parser that a command group was starting.

Sure, that'd be great. Please tell people to stop using parenthesis in filenames, and I can make the change to the parser.

Code:
[TCC33.00.20 | D:\archive]
>if a eq a (echo %%line1 & echo %%line2)
%line1
%line2

It sounds as though you are saying that FOLDERMONITOR does not support command groups, only a single command (unless it's in a back-quoted string). Yet when the procedure for entering multiple commands as described in the help file is followed, the command displayed on the screen shows a command group (i.e., all the commands surrounded by parentheses).

I'm not saying that - FOLDERMONITOR (and every other monitoring command) supports command groups. But the parser doesn't know what command you're executing when it's doing the variable expansion.

So the parser is relying on you to help it by protecting things you don't want expanded.

Or, you can upgrade to the DWIM parser ...
 
Or, you can upgrade to the DWIM parser ...

Wow! When will that be available? I'll bet it will be a big seller. Will the new AI version of Take Command have it? You do have an AI version in the works, don't you?
 
I do have an AI version I've been playing with. But everyone would lose interest quickly when they discover the eye-watering cost of using any of the LLVM's extensively.

There's also the issue that people will immediately demand a further upgrade to the "I Didn't Really Mean That, Do What I Should Have Meant" parser.
 
There's also the issue that people will immediately demand a further upgrade to the "I Didn't Really Mean That, Do What I Should Have Meant" parser.

LMAO.

But in all seriousness... I was going to wait until April Fool’s Day to share this idea, except it’s not a joke, I’m dead serious... Has anyone thought about having an AI train itself on the forum data here, so that there is an "expert AI" that can answer obscure questions that might not be answered in the docs?

Next-level!! :)
 
Back
Top