search

Genivia / ugrep

NEW ugrep 7.1: a more powerful, ultra fast, user-friendly, compatible grep. Includes a TUI, Google-like Boolean search with AND/OR/NOT, fuzzy search, hexdumps, searches (nested) archives (zip, 7z, tar, pax, cpio), compressed files (gz, Z, bz2, lzma, xz, lz4, zstd, brotli), pdfs, docs, and more
https://ugrep.com
BSD 3-Clause "New" or "Revised" License
2.66k stars 111 forks source link

The editor does not open and the program freezes #438

Closed mrkingmidas closed 2 weeks ago

mrkingmidas commented 2 weeks ago

How to repeat in cmd.exe:

ugrep 7.0.3

Windows 10 21H1, ConEmu 230724, lang: ru, codepage: 866

genivia-inc commented 2 weeks ago

It works as tested on my Windows 11 system with cmd.exe, powershell and ConEmu. I don't get what and why a code page would change that.

mrkingmidas commented 2 weeks ago

The situation is more complicated - now I was looking for how to write an example and sometimes it still works.

The problem seems to be if run ugrep -Q and move only with the Up/Down arrows (without searching) and then press F2.

If I run ugrep -Q without searching or highlighting what was found and may be scroll with arrow keys and then press F2 it causes the application to freeze.

genivia-inc commented 2 weeks ago

I tested this right now with ConEmu using SET Editor=notepad.exe then in the TUI press CTRL-Y to edit a large file. It also works with cmd.exe and powershell and when using ugrep --view=notepad.exe -Q.

This starts notepad when pressing CTRL-Y or F2. Notepad will pop up with the file just fine. After quitting notepad the TUI continues to work fine.

Note that you must stop editing the file for the TUI to continue. Otherwise it will just wait with a black screen. This is normal.

The TUI checks if the file was changed after editing or viewing. If the file is changed, then a new search for that file will happen so the TUI screen is always up to date.

genivia-inc commented 2 weeks ago

We could output Waiting on notepad.exe to finish in the TUI screen to make it clear that the TUI needs notepad to end.

Also, the TUI window needs focus to resume. Testing this with ConEmu, cmd.exe and Powershell works fine using ugrep --view=notepad.exe -Q. It doesn't matter what the current code page is.

mrkingmidas commented 2 weeks ago

Using a build with a “code page” (the same on regular 7.0.3) I recorded a GIF

Steps in ConEmu (in cmd.exe the same):

genivia-inc commented 2 weeks ago

Well, it works absolutely fine on my Windows 11 machine with cmd.exe and ConEmu using the v7.0.4 pre-update. Launching notepad.exe multiple times for files is OK. It doesn't matter if a pattern is cleared or a pattern is entered. I also tried editing the file and saving it, which also works fine.

I even tried with two ugrep instances running at the same time and then F2 in both to edit the same file. That works too, with the first ugrep just returning back and the second ugrep waiting for notepad.exe to finish. Not getting stuck.

To be perfectly honest, I am 100% convinced the logic in ugrep is correct, because _wsystem() is launched every time F2 or CTRL-Y is pressed, then ugrep just waits for notepad.exe to finish. It gets back exactly where it was or performs a new search if the file was changed.

If _wsystem() doesn't launch the specified notepad.exe command on your end, then something outside of ugrep's control must be wrong and there is nothing I can do about that that would change that.

mrkingmidas commented 2 weeks ago

If _wsystem() doesn't launch the specified notepad.exe command on your end, then something outside of ugrep's control must be wrong and there is nothing I can do about that that would change that.

May be related to active non-English locale. Now I tried to run ugrep -Q version 7.0.2 (before the appearance of _wsystem) and there calling the editor or the more command (with an empty EDITOR variable) work correctly!

Perhaps it has something to do with the contents of the files (or their display on the screen), since I also noticed that this does not happen on all files.

I found an example in the source code of ugrep - if you take two files LICENSE.txt and man.sh and place them in a separate directory (for example, D:\Other\Temp\8\) - it freezes at " empty request." If the LICENSE.txt file is renamed to z_LICENSE.txt (it becomes the second one on the screen) - there is no freezing!

genivia-inc commented 2 weeks ago

Perhaps it has something to do with the contents of the files (or their display on the screen), since I also noticed that this does not happen on all files.

Does that also happen on your end when the viewer is more which is the default viewer?

mrkingmidas commented 2 weeks ago

Does that also happen on your end when the viewer is more which is the default viewer?

Yes, demo on two files from source LICENSE.txt and man.sh, I am press F2 or Ctrl+Y:

example

genivia-inc commented 2 weeks ago

Does it happen when you first chcp 65001 and then run ugrep -Q?

mrkingmidas commented 2 weeks ago

Does it happen when you first chcp 65001 and then run ugrep -Q?

No, same effect of freeze.

Now I noticed something else: if in the same example of two files you scroll the screen to the end of the second file (using arrows or PgDn), then the second file also works and returning to the first using arrows too! But if you search for something and clear the search field, it hangs on F2 again.

And on all examples 7.0.2 works!

genivia-inc commented 2 weeks ago

I made a small change to the UTF-8 conversion, just to make sure it's not that. Try the updated bin/win64/ugrep.exe

If not that, it might be something in the keyboard read logic to make it work with ConEmu (added to v7.0.3).

I don't have this problem you describe on my Windows 11 machine, making this a mystery as to what causes it.

mrkingmidas commented 2 weeks ago

I made a small change to the UTF-8 conversion, just to make sure it's not that. Try the updated bin/win64/ugrep.exe

If not that, it might be something in the keyboard read logic to make it work with ConEmu (added to v7.0.3).

I don't have this problem you describe on my Windows 11 machine, making this a mystery as to what causes it.

This build also freezes :-(

And different options too:

genivia-inc commented 2 weeks ago

So it is not the UTF-8 logic, which makes sense. If v7.0.3 has the same problem then it is likely the ConEmu mod.

mrkingmidas commented 2 weeks ago

So it is not the UTF-8 logic, which makes sense. If v7.0.3 has the same problem then it is likely the ConEmu mod.

Can you please put together a build with ConEmu modifications disabled (appearing in 7.0.3)?

mrkingmidas commented 2 weeks ago

So it is not the UTF-8 logic, which makes sense. If v7.0.3 has the same problem then it is likely the ConEmu mod.

And I didn’t write before: closing ugrep -Q with such a freeze using Ctrl+C does not work. And Ctrl+Break works.

I ran today's tests only in cmd.exe

genivia-inc commented 2 weeks ago

Can you please put together a build with ConEmu modifications disabled (appearing in 7.0.3)?

Try the bin/win64/ugrep.exe

mrkingmidas commented 2 weeks ago

Can you please put together a build with ConEmu modifications disabled (appearing in 7.0.3)?

Try the bin/win64/ugrep.exe

Also freeze on F2 or Ctrl+Y 😥

mrkingmidas commented 2 weeks ago

Can you please put together a build with ConEmu modifications disabled (appearing in 7.0.3)?

Try the bin/win64/ugrep.exe

Please, can you create build with rollback changes from _wsystem using old 7.0.2 code ?

genivia-inc commented 2 weeks ago

BTW, trying CTRL-S to scroll down to the next match does not work when CTRL-W works. This appears to be a problem described here. I've added ENABLE_EXTENDED_FLAGS which makes CTRL-S work again. It appears to be an undocumented flag so I will test for any side effects.

Please, can you create build with rollback changes from https://github.com/Genivia/ugrep/issues/436#issuecomment-2460404260 using old 7.0.2 code ?

Sure.

mrkingmidas commented 2 weeks ago

BTW, trying CTRL-S to scroll down to the next match does not work when CTRL-W works. This appears to be a problem described here. I've added ENABLE_EXTENDED_FLAGS which makes CTRL-S work again. It appears to be an undocumented flag so I will test for any side effects.

It's strange, because in the latest builds on my system Ctrl+S works the same everywhere in cmd.exe

genivia-inc commented 2 weeks ago

It's strange, because in the latest builds on my system Ctrl+S works the same everywhere in cmd.exe

Could be Powershell.

Please, can you create build with rollback changes from https://github.com/Genivia/ugrep/issues/436#issuecomment-2460404260 using old 7.0.2 code ?

Try bin/win64/ugrep.exe

This one omits wsystem to use system again. It also sets ENABLE_EXTENDED_FLAGS to make CTRL-S work. It includes the ConEmu mod.

mrkingmidas commented 2 weeks ago

It's strange, because in the latest builds on my system Ctrl+S works the same everywhere in cmd.exe

Could be Powershell.

Please, can you create build with rollback changes from #436 (comment) using old 7.0.2 code ?

Try bin/win64/ugrep.exe

This one omits wsystem to use system again. It also sets ENABLE_EXTENDED_FLAGS to make CTRL-S work. It includes the ConEmu mod.

Works in cmd.exe and ConEmu! Ctrl+S also works. And non-ASCII filenames not work as described

genivia-inc commented 2 weeks ago

OK, if this latest version works then I wonder if the problem is actually caused by _flushall() which I've added with _wsystem() because the API doc mentions that _flushall() is required before calling _system() or _wsystem(): _"You must explicitly flush, by using fflush or _flushall, or close any stream before you call system."_

genivia-inc commented 2 weeks ago

One more version to try please. This one is without _flushall() but with _wsystem(): bin/win64/ugrep.exe

mrkingmidas commented 2 weeks ago

One more version to try please. This one is without _flushall() but with _wsystem(): bin/win64/ugrep.exe

Hooray! Works!

Thank you !

genivia-inc commented 2 weeks ago

Thanks for testing.

To summarize:

I will release an official update v7.0.4 soon.