131–140 of 179 posts
GREAT: find / -type f -print0 |xargs -0 grep heythere
I tried some sub-shells, and seemed to not work so well. $() and `` would be nice.
ps -fp $(pgrep -d, krb5kdc)
ps -fp `pgrep -d, krb5kdc`
http://explainshell.com/explain?cmd=ps+-fp+%24%28pgrep+-d%2C...
edit: newlines
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…
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...
Arguments to xargs do appear to be parsed, example below:
http://explainshell.com/explain?cmd=find+%2F+-type+f+-print0...
Earlier quoted context omitted.
How long does it take you to type a character???
Assume I type 80 wpm A word is standardized as 5 keystrokes 80 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…
for word in foo bar baz; do echo $word; done
COLUMNS=20 lsGorgeous. 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…
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, the…
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!
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.