-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
How to get back the 1 line verbosity like v1.5 #645
Comments
Hi, thanks for opening the issue. This is a bug in case you have no
scrapers enabled. With no scrapers it should default to single-line output,
but the check for it seems to be broken.
However in the case you are using scrapers, the multi-line output is the
only possible output format.
…On Sun 12. Feb 2023 at 8.15, C4lputer ***@***.***> wrote:
Now it takes 3 lines for 1 result which to me is quite frustrating
[image: image]
<https://user-images.githubusercontent.com/93414512/218296059-d04d2ac2-3ca8-41e5-845a-638f1e521b8e.png>
—
Reply to this email directly, view it on GitHub
<#645>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABH6DJPYVFEP5IYVH26QIS3WXB5XDANCNFSM6AAAAAAUZD4RRY>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
I just fuzz like I always do, but when I update to version 2 this happened. So I supposed this is a bug and there will be a fix soon? |
Same problem here. AFAIK it's not possible to create filters like: (HTTP code 400) OR (HTTP code 404) OR (HTTP code 301 AND Words 456) So I was filtering out using egrep since the results were present in one line. |
I'm experiencing the same issue. Seems like ffuf 2.0 now takes 3 lines for a result without using scrapers, which is frustrating indeed. Thanks for your work! |
Hope it will be fixed soon, but until that Anyway, thanks for your work! |
Hi, I've fixed the bug, proposed a pull request and wrote details on what was happening in #656 It now works awesomely on my end. Best regards, |
Just wanted to say I also am having this issue and look forward to this being fixed. Thank you. |
If you need, the issue is fixed in the not-yet-merged #656 Best regards, |
It's work. Thank you sir Rémi, @p0dalirius. |
Yeah. This makes ffuf unusable for me. Would love to see it back in a compact line. Back to wfuzz until then. |
The PR made by p0dalirius referenced here: #645 (comment) can be build locally by checking out their branch and following the steps for building from source. |
Given the nature of the issue and the PR fix that has been submitted, is this project a bit on hold/unmaintained right now ? |
Hey, Any progress on this @tomikoski @joohoi ? Best regards, |
…645) (#656) * Fixed incorrect len() in pkg/output/stdout.go::PrintResult() * Fixed incorrect iteration on res.Input in pkg/output/stdout.go::prepareInputsOneLine(), Fixes #645 * Update CONTRIBUTORS.md * Update pkg/output/stdout.go --------- Co-authored-by: Joona Hoikkala <5235109+joohoi@users.noreply.github.com>
This fix has now been merged. Thanks @p0dalirius !
Nope, but I've been very busy recently. Now back to it. |
Thanks a lot @joohoi ! Maybe there should be a way for some serious/recurrent/trusted contributors to the project (after for instance 5/10/15 good PRs) that they could ask to be set as co-maintainers (or recommended by other users) in order to avoid this kind of situation, maybe @p0dalirius could want to have those rights since he fixed this bug pretty fast and he is maintaining quite a lot of tools on GitHub already, but I can't just speak for him like this, he might be very busy and not a right fit for that. But it would be something to consider as an improvement for contributors/contributions, I'd guess ! |
I'd personally rather have to compile a pull request from sources rather than see random folks be allowed to simply merge changes to the main repo without vetting by the owner. This tool is primarily used by people who hack in one way or another. If all I takes is 15 good PRs before they can sneak in their own agenda.... 😂 |
Yeah you're not incorrect @HeckerBirb, then the hacker would need to have a provable record of being someone "ethical" in the community, but this was just an idea, it can be expanded, or there should be at least 2 others contributors who have 100 PRs merged in vouching for him. But I understand it's risky. Policies can be thought of or we can look how does anyone join the security team for Debian/ArchLinux and so on ? If someone bad got into those team, hell could ensue has well. |
Now it takes 3 lines for 1 result which to me is quite frustrating
The text was updated successfully, but these errors were encountered: