Explain Shell 1372 points by auton1 on Dec 2, 2013 | hide | past | web | favorite | 171 comments

 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 connect the different options to the various explanations[0], since there are so many lines and they frequently have similar colors and you have to keep scrolling up and down the page. Being able to do something like click on a command/option and have the page jump to the corresponding explanation would be very helpful.  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, though.  Hi, I love this. I bookmarked it and plan to use this often.Possible additions:- Something that users of the service could add commands to and the community could up vote for grading on technical difficulty.- Also a "shell command of the day" type of mailer service would be amazing :)  I can scan the access logs for the top explained commands, and show those on the home page (although that will probably only further increase their popularity ;).  You can also count how often they are requested from the links on the home page. Granted, the additional popularity will probably cause people to share those more often.  Weight them by a power of their age or something like that.  > Also a "shell command of the day" type of mailer service would be amazing :)See:https://mobile.twitter.com/climagic  Put the command in a sticky header.  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 :)  A friend and I are working on a project that not only does what you just described but also allows to go from any programming language to any spoken language (not just shell to english). We will accomplish much of it with the help of the community who can both add natural language representations of code and also help write programs that will enable more programming languages to be explained. It should be released in the coming weeks...(hopefully)  Oh sweet! How can I stay in the loop? I can't wait to see this in action once you have a release :)  Hopefully when we post it on HN it will get similar kind of popularity as this post. Otherwise you can follow me on twitter https://twitter.com/RoryDHughes  Maybe add the ability to expand and minimize explanations like the ones used in code editors to minimize blocks of code. Love the tool  Very cool - but support for xargs seems to be broken. find . -type f | xargs wc -l  http://explainshell.com/explain?cmd=find+.+-type+f+%7C+xargs...  I would expect xargs to stop processing arguments strictly after the first non-flag argument.Arguments to xargs do appear to be parsed, example below:  Right, but in this example it's not telling me what the "grep" is doing. Admittedly xargs is a weird case where the arguments to the program are invoked as a program, but I'd say it shows pretty frequently in these type of "what does this long freaking command do?" situations. Maybe worth adding a special case for.  Or you could have the command itself be statically positioned and only have the explanations scroll.  Or you may shorten your command ps -C someScript.sh -o pid= | xargs -I % /bin/kill -TERM -- -%  avoiding two pipes is also 1 femtosecond faster, and as an added bonus HN doesn't trigger the dreaded code scrollbars too!  This is the two best arguments I have ever seen comparing two piece of code! You totally convinced me.  You can shorten it even further with pkill or killall:pkill ^someScript.sh$ --signal TERMEither way pgrep is a nice command to learn about.
 Is this paralipsis(http://prevaricate.me/?p=451) or meta-paralipsis?
 I don't know if I'd term it paralipsis, but I do get what you're saying about the weird contrast between praise followed by criticism. It does seem off, or maybe two faced, when interpreted at face value.The thing is, I do mean both of the sentiments I shared. I do think it's a fabulous and original idea. I also felt that in one particular use case, it's presentation was a little confusing. Because I'm not the best writer/speaker, it probably came across more insensitively than I was hoping for though.
 Gorgeous. Amazing. Absolutely fantastic. Easy the coolest and most useful thing I've seen on hacker news in a while.Enough gushing, now some bug reports:"read -r random_line < <(sort -R file)" yields "syntax: expecting filename or fd (position 22)""nc HOST PORT | tee movie.mp4 | mplayer -" I can hover over movie.mp4, but I can't scroll down the see the description without losing the emphasis on that path. I'd suggest letting the user click on the portion, or perhaps a long-hover effect?
 (I have no relationship with OP or the submitter/submission).>Gorgeous. Amazing. Absolutely fantastic. Easy the coolest and most useful thing I've seen on hacker news in a while.>Enough gushing, now some bug reports:I like the way you wrote your comment! It could stand as an example to everyone. Yours might have had enough gushing, but I think every "negative" comment should start with as high praise as it can muster.If the whole thing isn't as good, then it should first be "damned with faint praise" and then specific constructive criticisms shown. Obviously the praise doesn't have to be as strong as your comment.I just want to point out how awesome a comment like yours is - it is incredibly hard to put together and share something. We could all do well to remember that when we point out how to improve it.
 Thanks, that's really fun to hear.ACK on the command substitution not working, with the current lexer that I have in place fixing this isn't easy and might take a while. But it's definitely up there on my todos.Yeah, long pipelines are somewhat of a problem. You can currently navigate the commands with the buttons at the top, maybe they're not visible enough.But I like the idea of being able to pin a particular line by pressing it, but I fear it might be a bit subtle and easy to miss.
 Do you have any thoughts, or writings that you could point me to, regarding shell's parseability? For example, is it possible to parse a shell script without running it? Would it be possible to extract Bash's lexer+parser into a stand-alone library to be used by IDEs?
 Yes, you can parse without executing. I think shell is easier to parse than it seems, there are definitely some nuances that might be tricky to emulate, but I guess it's a matter of effort and how far you're willing to go. For syntax highlighting in IDEs, you probably don't need much, and maybe even a few regexs can get you close enough.I actually spent a considerable amount of time going over bash's parser [0], and also zsh's [1]. Bash uses lex/yacc with some custom code. zsh seems to have a custom written lexer/parser.Unfortunately none of them were written to be used as a library, as evident by global state, and a lot of hooks for prompts while parsing, etc. It might be possible to somehow make it work, but it seems like a lot of work to me. You might have an easier time looking at the parser I wrote, and extending that, or rewriting it in another language (as it's fairly small compared to the ones you find in shells). There's also libbash [2], haven't looked closely though.
 Yeah, the buttons are not visible enough IMO. I didn't even notice them (nor connect them to the output) until you mentioned it. Also, maybe hook them up to the arrow keys on the keyboard? Same problem with scrolling for large lists.
 I liked one idea submitted: having the command pin to the top of the screen on scroll down. It would be tricky to make happen with the hover effect for the boxes, though.
 Yes, I had this suggested on numerous occasions and gave it a go a while ago and it's indeed not trivial.If a JS wiz would like to hack on this I'll gladly help and accept it.
 > I can hover over movie.mp4, but I can't scroll down the see the description without losing the emphasis on that path. I'd suggest letting the user click on the portion, or perhaps a long-hover effect?What if the command was simply pinned to the top of the screen as you scroll down? This would require some trickiness to make the atoms remain connected to their documentation as the documentation slides under the command, but would allow you to view any documentation on the same screen as the command itself.EDIT: On the other hand, I just noticed that there are buttons to only show the documentation for specific subcommands, so you can always use those to cycle until the documentation you want to see is visible.
 The wiring is sexy, but this is a textbook cases where tabbed panes would be perfect: just have each command segment be a tab, and the corresponding docs be in a pane underneath.
 The first bug is acknowledged in the page: "support for (...) command substitutions will be added later on"
 The UI with the svg "wiring" is awesome. You should consider abstracting away that functionality so that it can be reused by other projects.Right now I'm imagining explainphys ;) where each term in a physics equation is explained e.g. The magnetic force felt by a particle of charge q moving with velocity \vec{v} in a magnetic field \vec{B} is \vec{F}_B = q \vec{v} × \vec{B} | | | | |______magnetic field magnetic force | | | | | cross charge | prod. | velocity of particle
 Or maybe cdecl [0].[0]: Online version: http://cdecl.org/.
 Agreed. I would love to see this UI on a RegEx parser too.
 Check out http://www.regexper.com/
 I've used that but I think OP's UI is sexier. Thanks though.
 Very well done. Now I just wish this was a shell program! user@server:~$explain iptables -A INPUT -i eth0 -s ip-to-block -j DROP  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.
 Thanks for the incentive, but it's not needed and if I do get around to it, it'll of course be open source.The main difficulty I had with writing a command line utility is figuring out the UI in a console. Suggestions are welcome of course.Also, there are two possibilities for a client: the first queries an API on explainshell.com by sending it a command line. This has the advantage of the client being thin, and using the centralized man page database which is probably more accurate. But this means that you're potentially not explaining the exact command you're running locally, which may be confusing.The second option is to run the man page parser, matcher, etc. locally against the man page on your machine.
 One advantage of a local repository is that it is more likely to match the software versions on the local machine.However, perhaps the best thing would be to allow both local and remote queries :-)
 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)
  #!/usr/bin/env python import sys import urllib import webbrowser url = "http://explainshell.com/explain?cmd=" + urllib.quote(' '.join(sys.argv[1:])) webbrowser.open_new(url)  (webrowser.open_new doesn't seem to be always working for me, not sure why, I've never used it before)
 At least you didn't try to do that in bash! ;)One suggestion though: If there are no command line parameters, then read a line from stdin, so you don't have to play the game of trying to properly escape all of your punctuation in the command line to get it into sys.argv[1:] without any corruption, and can just copy and paste it into stdin.Hmm, that raises the question of what should happen if you pipe an entire shell script into it, like "./configure"? That might be considered a denial of service attack on explainshell.com.
 I've definitely written a URL escaping routine in bash before :)
 It exists, though does rely on the central service: http://schneems.com/post/61514247453/explain-shell-from-your...
 See https://github.com/jeroenjanssens/data-science-toolbox/blob/... for a bash script that interfaces with explainshell.com.I wrote this script a while ago. I just needed to update the request because the API had changed a bit since then. Please note that it depends on the scrape tool in the same repository, which in turn depends on the python packages lxml and cssselect. But once you have that set up, you can explain commands from the shell! :-)
 The trouble with that approach is that you have to escape special characters:$explain cat filename | sort # won't work$ explain 'cat filename | sort' # presumably would workI wonder if the best approach is to make explain behave like a prompt. If there was some way it could inherit bash's command history, even better$explainexplain> cat filename | sort  Sounds like a job for a little statically compiled Go program :-)  I thought of quickly writing one, but it doesn't have an API. Something like this would work well:POST your query, e.g.: tar zcf - some-dir | ssh some-server "cd /; tar xvzf -"Returns: [ ["tar(1)": "explanatory text"], ["z": "explanatory text"], ["x": "explanatory text"], ["f file": "explanatory text"], ]  etc.  I had something similar in mind. But this format means that repeated arguments that aren't adjacent will have their help text repeated.Feel free to open a bug and we can discuss the options there.  Um... the output wouldn't be interesting for that iptables command -- it's simply a single program with arguments; no shell syntax involved.I suspect what you really want is an iptables demuddler tool that explains the insane "chains" metaphor and explains how individual packets are going to behave. I'd like that too, but it's not this tool.  If all it did was parse program arguments and display usage info it would be super useful. Bash syntax is mostly trivial while there are thousands of arguments across hundreds of programs.  You can run the web server locally. See the source code readme:https://github.com/idank/explainshellIt should be trivial to whip something up that will generate the right URL for a set of arguments, running either on your local web server or against explainshell.com  This is a great idea!  there's this: https://github.com/schneems/explain_shell  This is pretty cool but what I found annoying was matching the snippet of code and the description together. Take this for example: http://explainshell.com/explain?cmd=true+%26%26+%7B+echo+suc...The command is: true && { echo success; } || { echo failed; }But the top box description is for echo parameters. The next one is for echo. Why can't it go from top to bottom in order of the command? EG: Start with true, then &&, then {, then echo, etc.The way it is, I spend a lot of mental energy matching things up.  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 scrolls down far enough, display the query at the top of the page with fixed position so that it is always on screen. Then topmost displayed explanation box will get highlighted, along with the relevant portion of the query; unless the mouse is hovering over a certain box or portion of the query, in which case that command/box pair becomes highlighted instead.If a user tries to scroll with the mouse wheel or keyboard, but there is no more content to display on the page, then the scrolling causes the highlighted box to change instead.If a portion of the query is highlighted which is not on the page, then clicking that portion will cause the page the jump so that the corresponding box appears and becomes highlighted.  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)  Maybe I'm missing some point, but I don't think you need the lines if it goes top to bottom. Or, maybe you'd only need one line to show up if you highlighted a snippet/description: To point back to what you're hovering over.  I think it'll be hard to match portions of the command to their boxes if there were no lines at all. How would you know that the v in tar xzvf foo matches the 4th box?Having a single line when you hover could help, but sounds confusing for new users that are unaware of this feature.  That's a fair point. What if you put the snippet and the description side by side so you don't even need the arrows? Perhaps like this: tar description1 x description2 z description3 ...  This is a wonderful idea and an upstanding social service, in the same vein of giving heroin addicts access to free clean needles, pure heroin, and a safe place to shoot up.There is no perfect solution -- in the ideal world, everyone would use safe healthy programming languages, and nobody would be addicted to shell scripting.But in the real world, many people still choose to use shell scripting as a quick and easy short term solution to their problems.Like the unhealthy temptation to use regexps for parsing html, shell scripting just causes more problems, which snowball out of control until you have the dire situation we're in today, with a whole generation of urban hipsters who learned cargo-cult cut-n-paste shell scripting by typing "more ./configure".So it's much better to treat shell scripting as a health problem rather than a criminal problem.My only suggestion is that you should sponsor links to "recovery programs," where people can learn to solve their problems with safe healthy programming languages instead of shell scripts. For the popular rube-goldbergesque shell incantations, you could show how to accomplish the same thing more comprehensibly in Python, Ruby, JavaScript, Lisp, Forth, Mathematica, Quartz Composer, etc. ;)  So I fed it : cat ./trunk/.config |awk ' /CONFIG_TARGET_BOARD/ { gsub(/\"/,""); split($0,a,"="); print a[2] }'A little one-liner I worked up a few days ago to quickly show me which architecture my OpenWRT trunk was last built with. I'd really like it to explain in much more detail what each of the terms inside the awk command do. Perhaps make "explain" modular so that people can add more detail to the gazillion things that can happen inside awks, seds, greps, etc?Fabulous idea. This should have been in unix all along as part of the man system.
 That'd be brilliant.We should have a wtf? command, used like so: wtf? yes | sudo apt-get install libpq-dev  Results would be ncurses, top line of screen is command with current subcommand highlighted, and rest of screen is less'ed explanation.
 It's definitely doable to add dedicated parsers for options of awk, sed, et al. But it's a lot of work... I doubt someone will go through the trouble of writing a parser for awk, just for this..What is possible and quite easy is creating links for things that are explained in other tools, such as linking the regex argument of grep to some site that explains regular expressions, or somehow integrate it into the existing UI.
 It unfortunately can't decode :(){ :|:& };:, a classic unintelligible forkbomb. I suppose it's only lack of function support that's the issue!Really neat program, nonetheless!
 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.
 It could just compare the literal string and have static explanation just for this command.
 See halting problem
 It's the halting problem, not the parsing problem.
 It's what git's man page says: https://www.kernel.org/pub/software/scm/git/docs/
 This is quite impressive.I'd love to see the argument explanations narrow down sub-arguments. For instance, "find -type f" ought to just show the top-level description for -type and the description for 'f', not all the other type characters.
 Source https://github.com/idank/explainshellThis is truly stunning. It's a small thing, and what it does is not stupendous. But the design, aesthetics, ease of use, in a word elegance makes the combined whole a superlative tool.
 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.
 Really cool. A suggestion. For long explains, it'd be great to be able to click on the part to jump to that part of the explanation, and then offer some way to "jump back to top".Alternatively, I was thinking there might be a nice "swipe" or "carousel" interface applicable here. e.g. you hit left/right arrows and it explains every individual atom of the command-line.That said, very nice as it is now. You deserve major kudos simply for bringing most manpages online in a searchable, good-looking interface! Instantly added as a "dev" bookmark for me.
 Lots more where that came from (great resource btw!): http://pineapple.io/resources/tagged/bash+terminal
 It's surprisingly good, overall, but there are some glaring omissions. For instance:sudo apt-get install tree Only sudo is explained. I understand apt-get is distro-specific, but it's widespread enough to deserve a special case. Interestingly, apt-get install tree (without sudo) works better.Common, widely known system configuration files like /etc/issue, /etc/hosts, /etc/hostname, /etc/fstab ... deserve to be special-cased, too. Many of them actually have their man pages, so it's possible to script.
 True, it doesn't figure out that some commands should be matched recursively since their arguments are other commands, xargs is also in the same boat. There might be an open bug for this already.I only scanned sections 1 and 8 of the man page archive, so that's why files are missing.. but they can be added.
 This is brilliant. (I've forwarded it to novices and pros alike, and everyone else's response has been much the same.)If you were to open up donations to support development, I would HAPPILY contribute.
 Thanks!I work full-time right now, so money isn't really an issue. I'll gladly accept commits though! ;)
 I agree it's beautiful, and a really great idea. I'll also add my vote that this would make an even better commandline tool.It had difficulty with:find . -name ".cpp" | xargs -i grep -His "oops" "{}"http://explainshell.com/explain?cmd=find+.+-name+%22*.cpp%22...It seems to think the -His belongs to xargs rather than grep.
 It's a nice toy, but seems to break down with more interesting stuff. For instance: for FILE in ls; do echo $FILE ; done  http://explainshell.com/explain?cmd=+for+FILE+in+%60ls%60%3B...That's a simpler equivalent of something I cooked up which probably didn't belong in a single line of shell anyhow.  You've hit the two top things on my to do list.. command substitution and control flows. It says on the top of the home page that they're not implemented yet.  That's what I get for trying to play with a new site after Thanks Giving weekend! You already have a solid tool, that will make it even better ;)  This is amazing! It's great for someone like me who, while knowing their way around the shell, isn't as well versed as some of my more veteran co-workers. While it's great to hear explanations of some of the more dense lines they give me to run, that's not always possible and can be a bit annoying. This could help take some of the pressure off of them to drag me through. :P  I don't know what I was expecting, but one of my most-used command lines, "du -a | grep foo" is pretty uninformative.  If you're just trying to locate a file in the current directory, you should probably be using find.  I remain convinced that "find" also contains a text editor and a Pacman game, but I've never cared enough to read the damn enormous man page. Also, not every system has "find", but everything I've used has "du" and "grep".  Just for definiteness, the equivalent "find" idiom would be: % find . -path '*foo*'  You need -path, not just -name, to match the whole name as du does.  I'll point out that the find command is 21 characters, while mine is only 17. Efficiency!  Yes, you have a point (plus, those stars, they burn the eyes).But, your detractors will say yours is two processes and theirs is one. Efficiency!  The kernel could start 100 processes in the time it takes me to type those extra four characters. We won't run out of processes. I did a test, finding .txt files in /usr/share, it took about .25 seconds longer with du and grep, which seems like less than it takes to type 4 more characters.  How long does it take you to type a character???  Assume I type 80 wpmA word is standardized as 5 keystrokes80 wpm is therefore 400 keystrokes per minute.Divide by 60 to get about 6.6 keystrokes per second, or about 0.15 seconds per keystroke.Therefore it would take about 0.6 seconds to type the four extra characters, giving a net savings to use du+grep instead.And 80 wpm is probably a rather fast estimate; I'd guess that I type slower when I'm writing commands than when I'm entering English text.  I must've read it wrong, or you fixed it, 'cause I read it as 25 seconds, hence my question! :)  This is all moot, because you can just alias either command to a single letter if you use it that much.  I will switch immediately! ;-)  "grep searches the named input FILEs (or standard input if no files are named..." Important bit being "or standard input."Also, what an odd one-liner. What's the use case for this that makes it such a common command: file names and sizes for all files matching a pattern beneath the current subdirectory (and all subdirectories and files within subdirectories matching that same pattern)? Genuinely curious.  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" as the filename, because the site doesn't include the actual grep syntax.It doesn't really explain what the command line is doing. It does seem to do a decent job of telling someone who's already fluent in shell usage the specific meaning of all options given. That's actually pretty important these days where any given GNU util will have flags for every single letter of the alphabet in both upper and lower case.  That's not really solvable in this case, though. All explainshell has are the man pages of the commands. It cannot know how they will interact with each other. It should be at least semi-possible in PowerShell (because you have output type information and parameter type information), but I hit a roadblock with ExplainPS a while ago and haven't had the time to resurrect it.  Perhaps you should go for find . / -name filename instead. Using du -a | grep filename works for sure, but it a bit of hack.  I think I can one-up you. (while :; do cat ; sleep 2 ; done)  How is that not "tail -f file"?  I'm curious why this is one of your most-used commands. If you want to know the sizes of all files matching 'foo', this is a horribly inefficient way of going about it.  Amazing tool for beginners, but also helpful for advanced users.GREAT: find / -type f -print0 |xargs -0 grep heythereI tried some sub-shells, and seemed to not work so well.$() and  would be nice.ps -fp $(pgrep -d, krb5kdc)ps -fp pgrep -d, krb5kdchttp://explainshell.com/explain?cmd=ps+-fp+%24%28pgrep+-d%2C...edit: newlines  Very nice. It was challenged by my go to command: tar cf - . | (cd /dest/dir ; tar xvf -)  Which uses tar to copy a directory tree. It didn't know '.' stood for the current directory, it missed out that 'f -' was the file "standard in" / "standard out"  Why do you use that instead of cp -R ? I would normally only use your version if I was copying a directory tree over ssh.  Generally tar to tar transfers have a couple more options, one being not to step across file systems, one being to keep symlinks intact (or not), and one being to avoid filling in 'holey' files.Of course those things might not be true any more, basically I got habituated to using it when I was Sun and it continues to work, so my fingers haven't tried to learn a new pattern.  I think you mean cp -a. cp -R doesn't preserve permissions and other goodies of tar.  I give out this link to all my developers that are just getting a feel for the terminal. Thanks so much for this!A nice to have: Having the command that was originally entered follow you down at the top of the window so when I'm looking at a long piped command, it makes it easier to follow  Hey, very nice! What about allowing users to take notes and tags on the search results? I have a bunch of bash commands I run I always forget, this would help me a lot to keep track of things (like all the ssh-ing stuff that I can't seem to fit in my memory...).  Very cool! It would be great if you would provide common usages for a given command if the user didn't provide any switches. That could be links like the ones you have in the "examples" section on the landing page.  Holy moly, this might be one of the best things I've seen on HN in a long time.  I am new to command line - but this is awesome! VERY helpful. Thanks and congrats!  vpenis.sh also has trouble explaining. It's a bit of a challenge for anyone, though.echo uptime|grep days|sed 's/.up $$[0-9]$$ day.*/\1\/10+/'; cat \ /proc/cpuinfo|grep '^cpu MHz'|awk '{print$4"/30 +";}';free|grep \ '^Mem'|awk '{print $3"/1024/3+"}'; df -P -k -x nfs | grep -v \ 1k | awk '{if ($1 ~ "/dev/(scsi|sd|md)"){ s+= $2} s+=$2;} END \ {print s/1024/50"/15+70";}'|bc|sed 's/$$.$$/.\1cm/
 You can use man test for [ ] which it currently reports no man page for.
 Great tool. Would have preferred to use it locally without all of those dependencies on a machine without networking. But OTOH having it online means that it is easier to centrally manage and update.
 This is incredible.One small change request: the longer commands make me scroll down the page, and I can no longer see what each block is pointing to. Maybe you could fix the command to a top-bar as you scroll down?
 This is beautiful! It will come in handy for filling in the vast holes in my knowledge. I think it would also make a great resource for those just starting to work with shell. Very well done indeed!
 Wow. I've only tried a few queries but they worked well! This could be great for breaking down some of the "copy paste to install this" commands you see from open-source projects.
 It fails to parse the command if you start with a redirect.
 I'd like it if hovering on a parsed item moved it's explanation to the top rather than just highlighting it. Not so much scrolling required if any.
 Doesn't seem to support backquotes? For example for x in ls ~/foo; do echo $x; done  doesn't yield anything remotely interesting.  New style subshells aren't supported (yet) either: for x in$(ls ~/foo); do echo $x; done  This is fantastic. Even with simple examples like ls -la it shows the documentation and other flag synonyms for all of the passed flags. Very impressed.  Its cool and good but gets into the syntax too quickly. To explain "tar xzvf archive.tar.gz" I would say "extract the archive".  Nothing useful said for: for word in foo bar baz; do echo$word; done  Seems to think COLUMNS is a command in: COLUMNS=20 ls
 Very neat!I did choke at the end of this little favorite: find -name "*.[hc]" -o -name "*.[hc]pp"|xargs grep -siP 'apa'
 Good: it understands &>, which some Unix old-timers don't get.To improve: it didn't provide any context to what $IFS is used for.  You know you're on the right track when people are saying, "But why isn't this in there already?"  Doesn't yield anything particularly useful for: [[ -f /tmp/foo ]] && echo yes  First of, I love the functionality and clean design.Why are you using bootstrap if the site isn't responsive?  It says that -h in shutdown stands for help, not halt. Otherwise, seems as a useful tool! :)  The site doesn't mention the !! command.The !! command is used to repeat the previously issued command.  Great! This could serve as an example for help sites about other shell-like environment.  Found a minor defect.cat fil*.dat | head -100 | tail -20. Does not explain -100 in head and -20 in tail.  Yup, just shared with my whole office. Super useful for all levels. Thanks for this.  :(){ :|:& };: or GTFO :)  I tried that as well. It says "Missing man page" :(  I started learning Shell last week. This couldn't have been better timed :)  Awesome tool. Now can we have one that does the same thing for a regexps?  Check out http://regex101.com/  Awesome, Thanks!  Really cool project! I can already see myself using this a lot.  This is awesome. Best post I've seen on HN in a while.  Beautiful. Can't describe with words...  Very interesting project, already using it!  this is great - i have had a hard time learning shell and this is a huge help. thank you!!!  # this command fails to explain:: abc$(xclock) def
 Straight to my bookmark bar!
 It's like shellgenius.
 Fantastic tool, kudos!!!!
 Haha! This is brilliant!
 Very useful. Good job.
 Really liking this.
 This is super cool
 Totally awesome!
 Stuff of dreams!
 Nice. Very nice.
 Insane stuff!
 Nice!!!!!
 WOW!

Search: