On 27/07/2025 16.51, Jim DeLaHunt wrote: > Mark: > > On 2025-07-27 09:42, Mark Filipak wrote: >> This is a serious post about a serious issue -- restarted due to >> distracting responses. >> >> The best way to see and replicate the problem is to run this script >> (which creates three AC3s and a FOO.TXT on c:\): >> >> ffmpeg -y -f lavfi -i anullsrc=channel_layout=2:sample_rate=48000 -t >> 240.0 -c ac3 "c:\file1.ac3" >> ffmpeg -y -f lavfi -i anullsrc=channel_layout=2:sample_rate=48000 -t >> 240.0 -c ac3 "c:\file2.ac3" >> echo ffconcat version 1.0>c:\concat.txt >> echo file 'file1.ac3'>>c:\concat.txt >> echo file 'file2.ac3'>>c:\concat.txt >> ffmpeg -y -safe 0 -i "c:\concat.txt" "c:\concat.ac3" >> echo this is foo>c:\foo.txt >> >> On my computer, '-t 240.0' created silent AC3s that were long-large >> enough to provoke the issue -- on your system, '-t' may need to be bigger. >> >> In the terminal output shown below, note these lines: >> >> <quote> >> Enter command: <target>|all <time>|-1 <command>[ <argument>] >> >> Parse error, at least 3 arguments were expected, only 1 given in string >> 'ho this is foo>c:\foo.txt' >> </quote> > > I was unable to reproduce this problem, on macOS Sonoma 14.7.6, using > zsh, and making the anullsrc files 10x the length.
Hi, Jim. Thanks! So, you did not get "Enter command ... Parse error ..." in zsh, eh? Hmmm... As you can see above, I did. My theory is as follows: 1 - The next line of my script is echo ffconcat version 1.0>c:\concat.txt 2 - The redirection (>) somehow causes the running FFmpeg to see ec as a command. 4 - It errors out and cites ho this is foo>c:\foo.txt as the error. I remember seeing "Enter command..." from FFmpeg a couple of times in the distant past, but I didn't know how or why it was appearing. Now I know how but I don't know why. > Here is your test script, modified for zsh and Unix-style paths: > > ffmpeg -y -f lavfi -i anullsrc=channel_layout=2:sample_rate=48000 -t > 2400.0 -c ac3 "$HOME/tmp/file1_2025-07-27.ac3" > ffmpeg -y -f lavfi -i anullsrc=channel_layout=2:sample_rate=48000 -t > 2400.0 -c ac3 "$HOME/tmp/file2_2025-07-27.ac3" > echo ffconcat version 1.0>$HOME/tmp/concat_2025-07-27.txt > echo file "$HOME/tmp/file1_2025-07-27.ac3">>$HOME/tmp/concat_2025-07-27.txt > echo file "$HOME/tmp/file2_2025-07-27.ac3">>$HOME/tmp/concat_2025-07-27.txt > ffmpeg -y -safe 0 -i "$HOME/tmp/concat_2025-07-27.txt" > "$HOME/tmp/concat_2025-07-27.ac3" > echo this is foo >$HOME/tmp/foo_2025-07-27FOO.TXT Oh, that's great. Thanks. >> Egad! That should not be happening. To me, it indicates that after a >> certain length of execution time, FFmpeg goes into some sort of command >> mode during which it fetches the 'echo' string and responds to it as >> though it was a command to FFmpeg. WTF? If FFmpeg does have some sort of >> automatic command mode that it monitors, isn't that asking for trouble? >> Certainly I consider it a bug (or design flaw). > > I understand that FFmpeg routinely monitors stdin while running... Oh, yes, of course. But-- But-- But my understanding is that > redirects to stdout. I'm not sending anything to stdin. ...So, (?). --Mark. _______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
