{"thread":{"id":"49136","subject":"\"less -F\" is broken","startedAt":"2018-08-15T20:35:54Z","lastAt":"2018-08-20T15:54:29Z","messageCount":9,"participants":["Linus Torvalds","Stefan Beller","Ævar Arnfjörð Bjarmason","Mark Nudelman"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"355755","messageId":"CA+55aFzsVt9CJOBPGABcvg464W1THvwYpNhO+9DWUNw4X36Ndg@mail.gmail.com","threadId":"49136","inReplyTo":null,"subject":"\"less -F\" is broken","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2018-08-15T20:35:40Z","receivedAt":"2018-08-15T20:35:54Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"Sadly, as of less-530, the behavior of \"less -F\" is broken enough that\nI think git needs to potentially think about changing the defaults for\nthe pager, or people should at least be aware of it.\n\nOlder versions of less (at least up to less-487 - March 2017) do not\nhave this bug. There were apparently 520, 527 and 529 releases in\n2017 too, but I couldn't find their sources to verify if they were\nalready broken - but 530 (February 2018) has the problem.\n\nThe breakage is easy to see without git:\n\n (echo \"hello\"; sleep 5; echo \"bye bye\") | less -F\n\nwhich will result in no output at all for five seconds, and then you\nget both lines at once as \"less\" exits.\n\nIt's not always obvious when using git, because when the terminal\nfills up, less also starts outputting, but the default options with -F\nare really horrible if you are looking for something uncommon, and\n\"git log\" doesn't respond at all.\n\nOn the kernel tree, this is easy to see with something like\n\n git log --oneline --grep=\"The most important one is the mpt3sas fix\"\n\nwhich takes a bit over 7 seconds before it shows the commit I was looking for.\n\nIn contrast, if you do\n\n LESS=-RX git log --oneline --grep=\"The most important one is the mpt3sas fix\"\n\nthat (recent) commit is found and shown immediately. It still takes 7s\nfor git to go through all history and decide \"that was it\", but at\nleast you don't need to wait for the intermediate results.\n\nI've reported it as a bug in less, but I'm not sure what the reaction\nwill be, the less releases seem to be very random.\n\n Linus\n"},{"id":"355768","messageId":"CAGZ79kaByLdAhf4tN0P+B_S6=bC=s8oKN8NpsX1mgXODR9stAA@mail.gmail.com","threadId":"49136","inReplyTo":"CA+55aFzsVt9CJOBPGABcvg464W1THvwYpNhO+9DWUNw4X36Ndg@mail.gmail.com","subject":"Re: \"less -F\" is broken","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2018-08-15T21:23:04Z","receivedAt":"2018-08-15T21:23:18Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Wed, Aug 15, 2018 at 1:35 PM Linus Torvalds\n wrote:\n>\n> Sadly, as of less-530, the behavior of \"less -F\" is broken enough that\n> I think git needs to potentially think about changing the defaults for\n> the pager, or people should at least be aware of it.\n>\n> Older versions of less (at least up to less-487 - March 2017) do not\n> have this bug. There were apparently 520, 527 and 529 releases in\n> 2017 too, but I couldn't find their sources to verify if they were\n> already broken - but 530 (February 2018) has the problem.\n\nhttp://www.greenwoodsoftware.com/less/news.527.html\nhttp://www.greenwoodsoftware.com/less/news.520.html\nhttp://www.greenwoodsoftware.com/less/\nRelease notes for 520 and 527 contains:\n \"Don't output terminal init sequence if using -F and file fits on one screen.\"\n"},{"id":"355770","messageId":"87k1orqpxj.fsf@evledraar.gmail.com","threadId":"49136","inReplyTo":"CA+55aFzsVt9CJOBPGABcvg464W1THvwYpNhO+9DWUNw4X36Ndg@mail.gmail.com","subject":"Re: \"less -F\" is broken","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2018-08-15T21:29:28Z","receivedAt":"2018-08-15T21:29:34Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Wed, Aug 15 2018, Linus Torvalds wrote:\n\n> Sadly, as of less-530, the behavior of \"less -F\" is broken enough that\n> I think git needs to potentially think about changing the defaults for\n> the pager, or people should at least be aware of it.\n\nDownloading & trying versions of it locally reveals that it's as of\nversion 520, not 530. The last version before 520 is 487. Presumably\nit's covered by this item in the changelog:\n\n Don't output terminal init sequence if using -F and file fits on one\n screen[1]\n\n> Older versions of less (at least up to less-487 - March 2017) do not\n> have this bug. There were apparently 520, 527 and 529 releases in\n> 2017 too, but I couldn't find their sources to verify if they were\n> already broken - but 530 (February 2018) has the problem.\n\nFWIW they're not linked from\nhttp://www.greenwoodsoftware.com/less/download.html but you can just URL\nhack and see releases http://www.greenwoodsoftware.com/less/ and change\nlinks like http://www.greenwoodsoftware.com/less/less-530.tar.gz to\nhttp://www.greenwoodsoftware.com/less/less-520.tar.gz\n\n> The breakage is easy to see without git:\n>\n> (echo \"hello\"; sleep 5; echo \"bye bye\") | less -F\n>\n> which will result in no output at all for five seconds, and then you\n> get both lines at once as \"less\" exits.\n\nThe relevant change in less is this, cutting out the non-relevant parts:\n\n diff --git a/less-487/forwback.c b/less-520/forwback.c\n index 83ae78e..680fa25 100644\n --- a/less-487/forwback.c\n +++ b/less-520/forwback.c\n [...]\n @@ -444,3 +444,21 @@ get_back_scroll()\n\n \t\treturn (sc_height - 2);\n \treturn (10000); /* infinity */\n }\n +\n +/*\n + * Return number of displayable lines in the file.\n + * Stop counting at screen height + 1.\n + */\n +\tpublic int\n +get_line_count()\n +{\n +\tint nlines;\n +\tPOSITION pos = ch_zero();\n +\n +\tfor (nlines = 0; nlines <= sc_height; nlines++)\n +\t{\n +\t\tpos = forw_line(pos);\n +\t\tif (pos == NULL_POSITION) break;\n +\t}\n +\treturn nlines;\n +}\n [...]\n diff --git a/less-487/main.c b/less-520/main.c\n index 960d120..6d54851 100644\n --- a/less-487/main.c\n +++ b/less-520/main.c\n [...]\n @@ -273,10 +275,19 @@ main(argc, argv)\n \t{\n \t\tif (edit_stdin()) /* Edit standard input */\n \t\t\tquit(QUIT_ERROR);\n +\t\tif (quit_if_one_screen)\n +\t\t\tline_count = get_line_count();\n \t} else\n \t{\n \t\tif (edit_first()) /* Edit first valid file in cmd line */\n \t\t\tquit(QUIT_ERROR);\n +\t\tif (quit_if_one_screen)\n +\t\t{\n +\t\t\tif (nifile() == 1)\n +\t\t\t\tline_count = get_line_count();\n +\t\t\telse /* If more than one file, -F can not be used */\n +\t\t\t\tquit_if_one_screen = FALSE;\n +\t\t}\n \t}\n\n \tinit();\n diff --git a/less-487/screen.c b/less-520/screen.c\n index ad3fca1..2d51bbc 100644\n --- a/less-487/screen.c\n +++ b/less-520/screen.c\n [...]\n @@ -1538,7 +1555,9 @@ win32_deinit_term()\n init()\n {\n #if !MSDOS_COMPILER\n -\tif (!no_init)\n +\tif (quit_if_one_screen && line_count >= sc_height)\n +\t\tquit_if_one_screen = FALSE;\n +\tif (!no_init && !quit_if_one_screen)\n \t\ttputs(sc_init, sc_height, putchr);\n \tif (!no_keypad)\n \t\ttputs(sc_s_keypad, sc_height, putchr);\n\nIf you undo that first changed part in main.c your test case prints\n\"hello\" to the terminal immediately.\n\n> It's not always obvious when using git, because when the terminal\n> fills up, less also starts outputting, but the default options with -F\n> are really horrible if you are looking for something uncommon, and\n> \"git log\" doesn't respond at all.\n>\n> On the kernel tree, this is easy to see with something like\n>\n> git log --oneline --grep=\"The most important one is the mpt3sas fix\"\n>\n> which takes a bit over 7 seconds before it shows the commit I was looking for.\n>\n> In contrast, if you do\n>\n> LESS=-RX git log --oneline --grep=\"The most important one is the mpt3sas fix\"\n>\n> that (recent) commit is found and shown immediately. It still takes 7s\n> for git to go through all history and decide \"that was it\", but at\n> least you don't need to wait for the intermediate results.\n>\n> I've reported it as a bug in less, but I'm not sure what the reaction\n> will be, the less releases seem to be very random.\n\nVia bug-less@gnu.org? Is this report available online somewhere? Anyway,\nCC-ing that address since my digging into this will be useful to them.\n\n1. http://www.greenwoodsoftware.com/less/news.520.html\n"},{"id":"355772","messageId":"CA+55aFzC79rRMgTdxGJV0g_ABW28OBGR=y4owp1OWMLWree0Ng@mail.gmail.com","threadId":"49136","inReplyTo":"87k1orqpxj.fsf@evledraar.gmail.com","subject":"Re: \"less -F\" is broken","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2018-08-15T21:43:57Z","receivedAt":"2018-08-15T21:44:12Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"On Wed, Aug 15, 2018 at 2:29 PM Ævar Arnfjörð Bjarmason\n wrote:\n>\n> FWIW they're not linked from\n> http://www.greenwoodsoftware.com/less/download.html but you can just URL\n> hack and see releases http://www.greenwoodsoftware.com/less/ and change\n> links like http://www.greenwoodsoftware.com/less/less-530.tar.gz to\n> http://www.greenwoodsoftware.com/less/less-520.tar.gz\n\nI should have just tried that. I just downloaded the ones linked to,\nmade a git archive of the history, and started bisecting. Which was\nall pointless extra work, since it was in the last release, but\nwhatever.\n\n> > I've reported it as a bug in less, but I'm not sure what the reaction\n> > will be, the less releases seem to be very random.\n>\n> Via bug-less@gnu.org?\n\nHeh. Another thing I didn't actually find. No, I just emailed Mark\nNudelman directly, because that's what the FAQ says to do:\n\n \"There is a list of known bugs here. If you find a bug that is not in\nthe list, please send email to the author. Describe the bug in as much\ndetail as possible, and I'll do what I can to help resolve the\nproblem.\"\n\nand it doesn't mention any mailing list.\n\n> Is this report available online somewhere?\n\nIt was not all that different from the email to the git list - just\ngiving the trivial test-case and my (limited) bisection result.\n\nThe data you dug up is much more useful.\n\n Linus\n"},{"id":"355773","messageId":"CA+55aFxjUsvhHwQGthGiLr537BGHkd-LECXVv8KzBTMMCo1bKQ@mail.gmail.com","threadId":"49136","inReplyTo":"87k1orqpxj.fsf@evledraar.gmail.com","subject":"Re: \"less -F\" is broken","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2018-08-15T21:57:05Z","receivedAt":"2018-08-15T21:57:19Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"On Wed, Aug 15, 2018 at 2:29 PM Ævar Arnfjörð Bjarmason\n wrote:\n>\n> Downloading & trying versions of it locally reveals that it's as of\n> version 520, not 530. The last version before 520 is 487. Presumably\n> it's covered by this item in the changelog:\n>\n> Don't output terminal init sequence if using -F and file fits on one\n> screen[1]\n\nSide note: that's sad, because we already use X in the default exactly\nfor that reason.\n\nSo apparently \"less\" was broken for us to fix something that we\nalready had long solved. The code basically tried to do \"automatic X\nwhen F is set\".\n\nAnd all that line_count stuff (which is what breaks) is pointless when\n-X is already given.\n\nThat does give a possible fix: just stop doing the line_count thing if\nno_init is set.\n\nSo \"-F\" would continue to be broken, but \"-FX\" would work.\n\nSomething like the attached patch, perhaps?\n\n Linus\n\n\n main.c | 3 ++-\n 1 file changed, 2 insertions(+), 1 deletion(-)\n\ndiff --git a/main.c b/main.c\nindex 179bd78..961a9db 100644\n--- a/main.c\n+++ b/main.c\n@@ -59,6 +59,7 @@ extern int\tmissing_cap;\n extern int\tknow_dumb;\n extern int\tpr_type;\n extern int\tquit_if_one_screen;\n+extern int\tno_init;\n \n \n /*\n@@ -274,7 +275,7 @@ main(argc, argv)\n \t{\n \t\tif (edit_stdin()) /* Edit standard input */\n \t\t\tquit(QUIT_ERROR);\n-\t\tif (quit_if_one_screen)\n+\t\tif (quit_if_one_screen && !no_init)\n \t\t\tline_count = get_line_count();\n \t} else \n \t{\n"},{"id":"355819","messageId":"87in4araa4.fsf@evledraar.gmail.com","threadId":"49136","inReplyTo":"CA+55aFxjUsvhHwQGthGiLr537BGHkd-LECXVv8KzBTMMCo1bKQ@mail.gmail.com","subject":"Re: \"less -F\" is broken","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2018-08-16T08:22:11Z","receivedAt":"2018-08-16T08:22:20Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Wed, Aug 15 2018, Linus Torvalds wrote:\n\n> On Wed, Aug 15, 2018 at 2:29 PM Ævar Arnfjörð Bjarmason\n> wrote:\n>>\n>> Downloading & trying versions of it locally reveals that it's as of\n>> version 520, not 530. The last version before 520 is 487. Presumably\n>> it's covered by this item in the changelog:\n>>\n>> Don't output terminal init sequence if using -F and file fits on one\n>> screen[1]\n>\n> Side note: that's sad, because we already use X in the default exactly\n> for that reason.\n\nAnd as another note for those following along (and myself until a short\nwhile ago, I didn't remember how this worked).\n\nWe set those default options at compile-time here:\nhttps://github.com/git/git/blob/63749b2dea5d1501ff85bab7b8a7f64911d21dea/Makefile#L1761-L1763\n\nI.e. set LESS=FRX and then when we setup the pager we use that unless we\ncan find LESS (and LV) set in the env already:\nhttps://github.com/git/git/blob/63749b2dea5d1501ff85bab7b8a7f64911d21dea/pager.c#L71-L96\n\n> So apparently \"less\" was broken for us to fix something that we\n> already had long solved. The code basically tried to do \"automatic X\n> when F is set\".\n>\n> And all that line_count stuff (which is what breaks) is pointless when\n> -X is already given.\n>\n> That does give a possible fix: just stop doing the line_count thing if\n> no_init is set.\n>\n> So \"-F\" would continue to be broken, but \"-FX\" would work.\n>\n> Something like the attached patch, perhaps?\n\nThis works for me under -FX.\n\n> Linus\n> main.c | 3 ++-\n> 1 file changed, 2 insertions(+), 1 deletion(-)\n>\n> diff --git a/main.c b/main.c\n> index 179bd78..961a9db 100644\n> --- a/main.c\n> +++ b/main.c\n> @@ -59,6 +59,7 @@ extern int\tmissing_cap;\n> extern int\tknow_dumb;\n> extern int\tpr_type;\n> extern int\tquit_if_one_screen;\n> +extern int\tno_init;\n>\n>\n> /*\n> @@ -274,7 +275,7 @@ main(argc, argv)\n> \t{\n> \t\tif (edit_stdin()) /* Edit standard input */\n> \t\t\tquit(QUIT_ERROR);\n> -\t\tif (quit_if_one_screen)\n> +\t\tif (quit_if_one_screen && !no_init)\n> \t\t\tline_count = get_line_count();\n> \t} else\n> \t{\n"},{"id":"355851","messageId":"e7fb0ae0-b3e3-d7ad-7f6e-c114ee563d59@greenwoodsoftware.com","threadId":"49136","inReplyTo":"CA+55aFxjUsvhHwQGthGiLr537BGHkd-LECXVv8KzBTMMCo1bKQ@mail.gmail.com","subject":"Re: \"less -F\" is broken","fromName":"Mark Nudelman","fromEmail":"markn@greenwoodsoftware.com","sentAt":"2018-08-16T16:50:25Z","receivedAt":"2018-08-16T16:58:36Z","isPatch":false,"sender":{"key":"markn@greenwoodsoftware.com","avatar":null},"body":"-X is a workaround for the previous behavior of -F, but it's not a great \nsolution. By not sending the terminal init sequence, some things can be \nbroken, depending on the terminal. For example, some terminals send the \n\"wrong\" sequences for the arrow keys when the terminal doesn't receive \nthe init sequence. For that reason and similar ones, I've never liked \n-X. The change in behavior for -F was to deal with some other types of \n(arguably broken) terminals that switch to an alternate screen when they \nreceive the init sequence. This makes -F fairly useless on such \nterminals. However this does change the behavior to the one Linus \nobjected to, where the first page is not output until we know whether it \nfits on the screen, so any delays in the first screen will delay all \noutput. (Note that this doesn't happen for delays that occur after the \nfirst screen has been displayed.)\n\nSo I'm not sure what the best solution is. Linus's proposal to disable \nthe line counting stuff if -X is set seems reasonable. I will look into \nthat and see if there are any issues with it.\n\n--Mark\n\nOn 8/15/2018 2:57 PM, Linus Torvalds wrote:\n> On Wed, Aug 15, 2018 at 2:29 PM Ævar Arnfjörð Bjarmason\n> wrote:\n>>\n>> Downloading & trying versions of it locally reveals that it's as of\n>> version 520, not 530. The last version before 520 is 487. Presumably\n>> it's covered by this item in the changelog:\n>>\n>> Don't output terminal init sequence if using -F and file fits on one\n>> screen[1]\n> \n> Side note: that's sad, because we already use X in the default exactly\n> for that reason.\n> \n> So apparently \"less\" was broken for us to fix something that we\n> already had long solved. The code basically tried to do \"automatic X\n> when F is set\".\n> \n> And all that line_count stuff (which is what breaks) is pointless when\n> -X is already given.\n> \n> That does give a possible fix: just stop doing the line_count thing if\n> no_init is set.\n> \n> So \"-F\" would continue to be broken, but \"-FX\" would work.\n> \n> Something like the attached patch, perhaps?\n> \n> Linus\n> \n"},{"id":"355855","messageId":"CA+55aFzutOgNbw2jeKox81-9O4+eSDntgrSAqaZrf0-28sTSUg@mail.gmail.com","threadId":"49136","inReplyTo":"e7fb0ae0-b3e3-d7ad-7f6e-c114ee563d59@greenwoodsoftware.com","subject":"Re: \"less -F\" is broken","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2018-08-16T17:10:35Z","receivedAt":"2018-08-16T17:10:49Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"On Thu, Aug 16, 2018 at 9:50 AM Mark Nudelman\n wrote:\n>\n> So I'm not sure what the best solution is. Linus's proposal to disable\n> the line counting stuff if -X is set seems reasonable. I will look into\n> that and see if there are any issues with it.\n\nOne option that I didn't try to go for - because I just don't know the\nless code base well enough - is to basically make the behavior of '-F'\nbe something like this:\n\n - as long as all the lines are short and well-behaved, and we haven't\nseen enough lines to fill the screen, act like 'cat' and just feed\nthem through\n\n - when you fill the screen (or when you hit some other condition that\nmakes you go \"now I won't exit\" - that could be a long line, but maybe\nit could also be the user giving keyboard input for a less command?)\nyou send the init sequence and just redraw the whole screen.\n\nThat sounds like the best of both worlds.\n\nIn fact, right now \"less -F\" is in my opinion a bit broken in other\nways that my patch doesn't fix.\n\nDo this:\n\n (echo 1; sleep 10; echo 2) | LESS=FX less\n\nand with my patch it will show \"a\" immediately. So far so good.\n\nBut let's say that that was all the user was interested in, and the\nuser presses 'q' to quit less. That doesn't work at all - it will wait\nfor that full ten seconds.\n\nThat actually happens even without -F too.\n\nWouldn't it be good to react to things like searches to highlight\nsomething (and to 'quit' for the 'never mind, alteady got it' case)\neven if there isn't enough data to fill the whole screen yet?\n\nthat said, ^C works, and this is not new behavior, so I'm just\nthrowing this out as a \"maybe a different approach would fix _both_\nthe -F behavior _and_ the above traditional issue\"?\n\n Linus\n"},{"id":"356091","messageId":"00804f16-f265-c4a1-332d-4b362548e663@greenwoodsoftware.com","threadId":"49136","inReplyTo":"CA+55aFzutOgNbw2jeKox81-9O4+eSDntgrSAqaZrf0-28sTSUg@mail.gmail.com","subject":"Re: \"less -F\" is broken","fromName":"Mark Nudelman","fromEmail":"markn@greenwoodsoftware.com","sentAt":"2018-08-20T15:54:13Z","receivedAt":"2018-08-20T15:54:29Z","isPatch":false,"sender":{"key":"markn@greenwoodsoftware.com","avatar":null},"body":"On 8/16/2018 10:10 AM, Linus Torvalds wrote:\n> One option that I didn't try to go for - because I just don't know the\n> less code base well enough - is to basically make the behavior of '-F'\n> be something like this:\n> \n> - as long as all the lines are short and well-behaved, and we haven't\n> seen enough lines to fill the screen, act like 'cat' and just feed\n> them through\n> \n> - when you fill the screen (or when you hit some other condition that\n> makes you go \"now I won't exit\" - that could be a long line, but maybe\n> it could also be the user giving keyboard input for a less command?)\n> you send the init sequence and just redraw the whole screen.\n\nI'm not sure that this would be a very nice user experience. On a \nterminal where the init sequence opens an alternate screen, some lines \nfrom the start of the file would be printed in the main screen, and then \nthe whole file would be viewed in the alternate screen. After exiting \nless, the user would see his main screen with some lines from the first \npage of the file displayed and then cut off at a seemingly arbitrary \npoint. Seems like that could be confusing and annoying.\n\n\n> But let's say that that was all the user was interested in, and the\n> user presses 'q' to quit less. That doesn't work at all - it will wait\n> for that full ten seconds.\n> \n> That actually happens even without -F too.\n> \n> Wouldn't it be good to react to things like searches to highlight\n> something (and to 'quit' for the 'never mind, alteady got it' case)\n> even if there isn't enough data to fill the whole screen yet?\n> \n> that said, ^C works, and this is not new behavior, so I'm just\n> throwing this out as a \"maybe a different approach would fix _both_\n> the -F behavior _and_ the above traditional issue\"?\n\nThis issue is, as you say, not related to the -F issue, but arises \nbecause less doesn't have a way to be reading a file and simultaneously \nreact to terminal key presses. When I first wrote less, there was no \neasy way to do this in Unix. Less also runs on other OSes which don't \nprovide this functionality. The best I was able to do was to allow \nctrl-C to interrupt the read. Of course in a modern OS that has \nselect() or similar functionality this could be implemented, but I think \nit would require some largish changes to the architecture. (Or maybe \nnot; I haven't really investigated this in detail.)\n\nBTW, your first message seems to indicate that you didn't find the less \nproject on github. It's at https://github.com/gwsw/less (mentioned in \nthe README). The latest version (v535) has the -F change implemented, \nbut I haven't yet released this for beta testing.\n\n--Mark\n\n"}]}