I suggest a convenient way to set cookie or auth headers. A lot of endpoints are behind authentication. The --req-headers flag is feasible, but there should be a shortcut flag just for authentication headers. Maybe --cookie and --auth ?
Not to rain on your parade with nicely formatted code like hardly any shell projects do, but what I would have expected for such a tool that I just want to use:
Only gave it a quick look and saw the other comment asking for dependencies. if there are some, why not list them in the README.
I'm really not against installers, but falls under the "small handy tool" category and not "I will spend time automating the install, either it works or it doesn't"
I'm really sorry to the OP if I seemed annoyed, but I was merely stating my first impression.
I'm not a big fan of shell scripts for complicated tasks, but their main benefit is exactly "one file, runs everywhere, it just works" - if you take away all three of those I question if it's the right choice being a shell script. For tools of this scope I really like go. stuff everything together as a static binary and you're good to go.
Why are you using a URL in place of a domain name, in the invocation example? Seems confusing. I would expect to see just a domain name there. Although I wouldn't complain if it works with both a domain and a full URL, automatically stripping off the parts it doesn't need. Also seeing http:// instead of https:// is starting to feel strange these days, but I do realize both are still used and your tool works with both as it should.
Very nice readme! And nice to see it has a man page. I would leave out the "It's simple:" line because that tends to make less confident people (like new people just learning) blame themselves if they have problems, and then instead of giving you feedback they'll give up and move on.
Here is a similar tool all contained in one shell script that only depends on openssl. [1] Albeit, a bit more verbose and doesn't have that nice one page output.
28 comments
[ 4.5 ms ] story [ 81.9 ms ] threadIt's a step up from httpie, which is nice to craft requests, but not to check for security.
Make life a little easier for the user ;)
wget https://github/.../releases/.../stable/htrace.sh
Only gave it a quick look and saw the other comment asking for dependencies. if there are some, why not list them in the README.
I'm really not against installers, but falls under the "small handy tool" category and not "I will spend time automating the install, either it works or it doesn't"
https://github.com/trimstray/htrace.sh/issues/18
Those instructions definitely need to be in the installation section!!
It symlinks from the git cloned directory to /usr/local/bin during installation.
When it runs, it does helpfully tell you which tools it needs, but each of those tools has a different install method:
* two are system packages
* one is a Go executable
* another a php composer package
* another is installed via npm
(that's a lot of extra language dependencies for a single script if you don't already have everything installed)
(good job!)
I'm not a big fan of shell scripts for complicated tasks, but their main benefit is exactly "one file, runs everywhere, it just works" - if you take away all three of those I question if it's the right choice being a shell script. For tools of this scope I really like go. stuff everything together as a static binary and you're good to go.
It's called Swiss Army Knife for SMTP, or "SWAKS" for short.
http://www.jetmore.org/john/code/swaks/
This tool is one of the best tools I've ever seen. It's well thought out, well designed, and the documentation is very usable.
(Full disclosure: I have no affiliation with the author or the tool.)
Why are you using a URL in place of a domain name, in the invocation example? Seems confusing. I would expect to see just a domain name there. Although I wouldn't complain if it works with both a domain and a full URL, automatically stripping off the parts it doesn't need. Also seeing http:// instead of https:// is starting to feel strange these days, but I do realize both are still used and your tool works with both as it should.
Very nice readme! And nice to see it has a man page. I would leave out the "It's simple:" line because that tends to make less confident people (like new people just learning) blame themselves if they have problems, and then instead of giving you feedback they'll give up and move on.
[1] - https://github.com/drwetter/testssl.sh
Thank you for your support!