Failing sanity check

[hepcat72]

I'm a noob (to both fswatch and xargs, honestly). I don't understand what's going on here. I just wanted to see how fswatch and the selected options work, and I don't understand why the following command only prints a series of 1s to the output file instead of the output of the date command:

fswatch -l 15 -o -m poll_monitor Data-51254E97-3127-4376-AC09-EC684CE8B64F.sqlite-wal | xargs -n1 -I{} date >> ~/Temporary/fswatch_test.txt

I let this run a bit while triggering file changes, and watched a tail -f on the output file:

>tail -f ~/Temporary/fswatch_test.txt 
1
1
1
1

Why don't the lines contain the output of date, e.g.:

>date
Sat Jun 19 17:28:58 EDT 2021

Am I doing something wrong?

I also tried supplying the -t option (though I didn't know whether it would be the time of the file change or the time of the output, given the -l option...

>fswatch -t -l 15 -o -m poll_monitor Data-51254E97-3127-4376-AC09-EC684CE8B64F.sqlite-wal 
1
1
1

I have read the documentation, but it doesn't mention what happens to STDOUT of the command supplied to xargs.

[hepcat72]

I figured out that the timestamp (-t) and -o options are not compatible, but I just don't understand where the output of the command supplied to xargs goes or when I redirect to a file, why the file seems to get the fswatch output instead of the command's output...

[hepcat72]

I have been able to simulate what I expected the xargs command would do. I'm curious. Is there a way to get the fswatch/xargs command combo to do this?

In one terminal, I run:

>while ( 1 )
fswatch -l 1 -1 -m poll_monitor tmp.txt >& /dev/null
date
end
Sat Jun 19 23:52:03 EDT 2021
Sat Jun 19 23:52:12 EDT 2021
Sat Jun 19 23:52:29 EDT 2021
Sat Jun 19 23:52:43 EDT 2021

and it shows the date output I had assumed I would see when I modify the file in another terminal with:

>echo test18 >> tmp.txt
>echo test19 >> tmp.txt
>echo test20 >> tmp.txt
>echo test21 >> tmp.txt

[hepcat72]

OK, I've been using tcsh for over 20 years, so it should have occurred to me that curly braces are used in parameter expansion when immediately adjacent to another argument (i.e. expanded to nothing and causing -I to consume the command). It took me way too long to figure out what was going on, so I'm commenting here for other tcsh users in this situation.

In tcsh, these work:

fswatch -l 1 -m poll_monitor names.txt | xargs -n1 -I'{}' date
fswatch -l 1 -m poll_monitor names.txt | xargs -n1 -I {} date      # no parameter expansion

However, this:

fswatch -l 1 -m poll_monitor names.txt | xargs -n1 -I{} date

is the same as this:

fswatch -l 1 -m poll_monitor names.txt | xargs -n1 -I date

because -I{} is converted to -I and xargs has no issue with that. It just made "date" the replace string. And since if it's not provided with a command, it just echoes what it was piped, that's why I was only seeing the fswatch output.

And as a sanity check, if you run this, xargs complains:

>fswatch -l 1 -m poll_monitor names.txt | xargs -n1 -I '' date
xargs: replstr may not be empty

Oddly, if you run this:

>fswatch -l 1 -m poll_monitor names.txt | xargs -n1 -I'' date

it doesn't complain and uses date as the replace string, the same as what I was seeing with -I{}.

I guess it parameter-expands "concatenations" and converts -I'' to -I as well.

I know others will likely see this as a drawback of tcsh, but I actually prefer this expansion behavior, because it allows me to write simpler loops that don't issue an error when an unmatching glob expands to nothing, which means it takes much less code to handle globs when not matching anything is OK.

[emcrisostomo]

Thanks @hepcat72