Live data from Hacker News

Explain Shell

explainshell.com

141–150 of 179 posts

Re: Explain Shell

#142
post #99

Earlier quoted context omitted.

I'm tempted to add a place holder for all the variations of this forkbomb, until I teach the parser about functions. You'll be amazed how many people try this (or other 'malicious' commands), presumably thinking I'm executing the queries. ;)

I tried this, but not because I believed that you would execute it, but because a very important use of such a tool would be to explain potentially dangerous commands and their implications.

I searched the classic sudo rm -rf /, too. Just to see if it would adequately explain it.

Re: Explain Shell

#143
Impressive but I agree with all who said you can't read the callouts below the 2nd or 3rd, because you have to scroll, which loses the focus on the item. I think it might work better if you just pop up one explanation box at a time, directly below the command, as the mouse sweeps across.

Also missing some obvious things like on this basic zip command [0]. It can't explain -9, probably because that's not in the man page as itself but as "-n". But also has nothing to offer about the zip file target or the input folder, which are in the man page as symbolic arguments.

[0] http://explainshell.com/explain?cmd=zip+-vr9+foo.zip+somefol...

Re: Explain Shell

#146
post #76

I totally love this, it's already incredibly helpful! It's super-functional, and frankly it's very, very nice looking. To Mr. Idan Kamara, the creator of this, I have nothing but the highest praise! Now, I hate to get side-tracked, but for much larger commands, like this one: ps x -o "%r %c " | grep "someScript.sh" | awk -F' ' '{print $1}' | xargs -I % /bin/kill -TERM -- -% that has a lot of parts, it can be hard to…

Hi! Happy to see explainshell on HN again, thanks for all the compliments! I agree about large commands being hard to follow. I tried solving this by adding the ability to navigate between commands. Right now clicking the command takes you to a page that displays that command options, but I can change it to the equivalent of navigating to it with the arrows at the top. There might be something better to do UI wise, t…

You made ExplainShell? If so great job. I tried some of my favorites `$ du -sh | sort -nr` and `$ grep -nr` and found the output very smart.

I second the idea in here that the command should somehow stay visible on screen as you scroll down, but is had an even crazier idea: what if you translated a command into paragraph form at the top as a summary?

I might explain `$ grep -nr` to another person as: "search recursively within all files and subdirectories in the current folder and display the results with line numbers" or I might describe `$ du -sh | sort -nr` as ”display the disk used by files and folders in the current directory using human-readable file sizes and sort the output from largest to smallest"

Your tool provides all of this information already, I wonder what it would take to get it that final step to put it into laymans terms while still showing the breakdown of the actual command (which is truly the only way to learn to use it).

Congrats on making such a great tool, I can't wait to tell my friends tomorrow :)

Re: Explain Shell

#147
post #82

Earlier quoted context omitted.

I agree it's a little counter-intuitive. But if it's top to bottom then all the lines would cross each other which would ruin the UI. If there's a way to make it top to bottom while keeping the UI useful, I'd love to hear!

> If there's a way to make it top to bottom while keeping the UI useful, I'd love to hear! I understand that the UI looks very nice, but at least for me, having the explanation boxes be in order would make it a lot easier to use. So here is my suggestion: You can keep everything looking exactly like it is now, except get rid of the lines altogether, and display all of the explanation boxes in order. When the user scr…

I know I'll be lynched for suggesting an extraneous JavaScript library like Bootstrap here on HN, but what if the command stayed visible at the top of the screen once you scrolled past it on the page (just like how Bootstrap's Affix plugin works) and the relevant part of the command you were reading about became highlighted as you scroll down the description (just like Bootstrap's ScrollSpy plugin).

That would be an intuitive UI without relying on wires to connect the content to the sections of the command and it lends itself to responsive layout as well because the command can easily wrap to multiple lines without losing clarity as you read the explanation (where the wires might start to eat into screen real estate at phone width and become much less clear if the command had to be split to multiple lines to stay visible)

Re: Explain Shell

#148
post #21

Earlier quoted context omitted.

I'll donate $100 if the author wants to build this and open source it. [Ed: As a shell application locally] A new "explain" command could help me, my team, and save us an enormous amount of time getting up to speed on some of our org's long-term system maintenance scripts.

How about an API where you can POST your script with curl -X and a unique link is returned that explains the script when you hit it with a browser? #shutupandtakemymoney (DevOps is fun, teaching not always)

I would never install this in this format. I'm not going to POST my bash history!

I'd prefer a model where you download a definition file (if it needs to be "updated" at the start frequently)

Re: Explain Shell

#149
post #20
post #16

Earlier quoted context omitted.

Tried it. The explain read-out seemed reasonable. Care to elaborate how it wasn't informative?

The explanation for "du" and its -a flag make it sound like I'm trying to find out how much disk space my files are using. Fine, that's the usual usage, but the point here is that it lists out every file under the current directory. The bigger problem is grep. We're told that grep prints lines matching a pattern, great. But then the explanation of the arguments makes it sound, to the uninitiated, like I'm giving "foo…

Perhaps you should go for find . / -name filename instead. Using du -a | grep filename works for sure, but it a bit of hack.
Post reply on HN