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

91–100 of 179 posts

Re: Explain Shell

#91

Post by vram22 »

brandall10 wrote: post #81
idank wrote: post #76

Earlier quoted context omitted.

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…

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 :)

> Also a "shell command of the day" type of mailer service would be amazing :)

See:

https://mobile.twitter.com/climagic

http://www.commandlinefu.com/commands/browse

Re: Explain Shell

#92

Post by mturmon »

w1ntermute wrote: post #26
jff wrote: post #11

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.

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.

Re: Explain Shell

#93

Post by drothlis »

idank wrote: post #79
jfasi wrote: post #5

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 "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?

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?

Re: Explain Shell

#94

Post by idank »

StavrosK wrote: post #29
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

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.

Re: Explain Shell

#95

Post by Aissen »

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.

I think you mean cp -a. cp -R doesn't preserve permissions and other goodies of tar.

Re: Explain Shell

#96

Post by idank »

tieTYT wrote: post #88
idank wrote: 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!

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.

Re: Explain Shell

#97

Post by jff »

w1ntermute wrote: post #26
jff wrote: post #11

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".

Re: Explain Shell

#98

Post by jff »

mturmon wrote: post #92
w1ntermute wrote: post #26

Earlier quoted context omitted.

If you're just trying to locate a file in the current directory, you should probably be using find.

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!

Re: Explain Shell

#99

Post by idank »

scott_karana wrote: post #55

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

Re: Explain Shell

#100

Post by mturmon »

jff wrote: post #98
mturmon wrote: post #92

Earlier quoted context omitted.

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!

Post reply on HN