Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Explain Shell

explainshell.com

Post reply on HN
Print view View original

101–110 of 179 posts

Re: Explain Shell

#101

Post by ChuckMcM »

gahahaha wrote: post #87
ChuckMcM wrote: post #85

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.

Re: Explain Shell

#102

Post by JonnieCache »

idank wrote: post #86
brandall10 wrote: post #81

Earlier quoted context omitted.

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 ;).

Weight them by a power of their age or something like that.

Re: Explain Shell

#103

Post by b0rsuk »

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.

Re: Explain Shell

#104

Post by jff »

mturmon wrote: post #100
jff wrote: post #98

Earlier quoted context omitted.

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.

Re: Explain Shell

#105

Post by emeraldd »

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.

Re: Explain Shell

#106

Post by idank »

b0rsuk wrote: post #103

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 spec…

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.

Re: Explain Shell

#107

Post by staunch »

jeroenjanssens wrote: post #54
staunch wrote: post #4

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

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 expla…

Sounds like a job for a little statically compiled Go program :-)

Re: Explain Shell

#108

Post by cheeseprocedure »

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.

Re: Explain Shell

#110

Post by idank »

drothlis wrote: post #93
idank wrote: post #79

Earlier quoted context omitted.

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 li…

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.

[0]: http://git.savannah.gnu.org/cgit/bash.git/tree/parse.y

[1]: https://github.com/zsh-users/zsh/blob/master/Src/parse.c

[2]: http://www.gentoo.org/proj/en/libbash/

Post reply on HN