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

Making Hard Things Easy

jvns.ca

Post reply on HN
Print view View original

61–70 of 202 posts

Re: Making Hard Things Easy

#61

Post by osmsucks »

strangesmells02 wrote: post #45
jks wrote: post #10

Earlier quoted context omitted.

This is because && and || are often used as conditionals: [ -e README ] && cat README avoids an error if the file README doesn't exist, and [ -e README ] || echo "You should write a README!" works the opposite way. What's more pernicious is that pipelines don't cause the shell to exit (assuming set -e) unless the last command fails: grep foo README | sort does not fail if README doesn't exist, unless you've also used…

so what happens?? it just hang up on the foo??

`grep` should terminate with an empty output on `stdout` and an error message on `stderr`, then `sort` will successfully sort the empty contents of `stdout`

Re: Making Hard Things Easy

#62

Post by syadegari »

The point Julia makes about `grep` resonate with me alot! I have the same (call it problem if you want) issue with `ps`. There is only one variation of ps I know of (`ps aux`) and if I want to change that I have to either look for the options in the man page or google it.

Re: Making Hard Things Easy

#63

Post by Joker_vD »

syadegari wrote: post #62

The point Julia makes about `grep` resonate with me alot! I have the same (call it problem if you want) issue with `ps`. There is only one variation of ps I know of (`ps aux`) and if I want to change that I have to either look for the options in the man page or google it.

Oh, that's a nice one, thanks for mentioning it. I'm personally used to "ps afx", but the "u" does give out some quite useful info... and it's compatible with "f"! So I guess I'll add "ps aufx" to my repertoire.

Re: Making Hard Things Easy

#64

Post by ustad »

fiddlerwoaroof wrote: post #36
asicsp wrote: post #3

Earlier quoted context omitted.

I maintain a file with commands that I don't use often (ex: increase volume with ffmpeg, add a border to an image with convert, etc). I even have a shortcut that'll add the last executed command to this file and another shortcut to search from this file.

If you’re already putting them in a file, you might as well put them in a shell script on $PATH: at a certain point I started writing shell scripts and little utilities for relatively infrequently used commands and other tasks (e.g. clone this repo from GitHub to a well-known location and cd to it)

Wait, how do you “cd to it” from within the script? Doesn’t exiting the script take you back to where you were?

Re: Making Hard Things Easy

#65

Post by jwkane »

Joker_vD wrote: post #63
syadegari wrote: post #62

The point Julia makes about `grep` resonate with me alot! I have the same (call it problem if you want) issue with `ps`. There is only one variation of ps I know of (`ps aux`) and if I want to change that I have to either look for the options in the man page or google it.

Oh, that's a nice one, thanks for mentioning it. I'm personally used to "ps afx", but the "u" does give out some quite useful info... and it's compatible with "f"! So I guess I'll add "ps aufx" to my repertoire.

faux is easier to remember

Re: Making Hard Things Easy

#66

Post by lcnPylGDnU4H9OF »

jroseattle wrote: post #55

I both agree and disagree with her sentiments here. Not in a right/wrong sense, but just what I found works for me. I agree with having helpers to understand how tooling works. Any resources that increase understanding of how to use a tool to it's full capability is productively beneficial. (Hat-tip to anything that unpacks all the `curl` switches.) Here's where I have disagreement: an old boss of mine once said "don…

> Here's where I have disagreement: an old boss of mine once said "don't worry about the tricks of the trade; learn the trade." That's very contextual, but sometimes understanding the core first makes the rest of it easy.

Seems like you might agree more than you realize! From TFA:

> And much like when debugging a computer program, when you have a bug, you want to understand why the bug is happening if you're gonna fix it.

It sounds a lot like "don't worry about how to fix the bug; learn what the bug is."

Re: Making Hard Things Easy

#67

Post by Sakos »

kristopolous wrote: post #59
zoogeny wrote: post #34

I have no idea why but I wanted to hate this article. Maybe jvns shows up on HN too often and I was in a bad mood. But this is a great article and as someone with 20 years of development experience is about as true as any meta-level discussion on programming could be. The selective vision thing is so true, both for `dig` and for `man` pages. I can't count the number of times have I `man ` and just felt overwhelmed by…

https://cheat.sh is your lifeline Also I made https://github.com/kristopolous/mansnip

There's also tldr: https://github.com/tldr-pages/tldr

It lets you check the most commonly used options from your terminal, for example "tldr badblocks".

Re: Making Hard Things Easy

#68

Post by tepitoperrito »

dgb23 wrote: post #54
zoogeny wrote: post #34

I have no idea why but I wanted to hate this article. Maybe jvns shows up on HN too often and I was in a bad mood. But this is a great article and as someone with 20 years of development experience is about as true as any meta-level discussion on programming could be. The selective vision thing is so true, both for `dig` and for `man` pages. I can't count the number of times have I `man ` and just felt overwhelmed by…

> I'm also a bit sad to hear that Strange Loop is now finished? I only found them last year or so and it seemed like so many of the talks were exceptional quality. You might want to watch Alex Miller's talk that has been uploaded recently: https://www.youtube.com/watch?v=suv76aL0NrA And yes, it's sad that it ended! However he made a very good case for why sometimes it's good for things to end. If you watch the whole…

Subtitles courtesy of DownSub (poor formatting my own). https://pastebin.com/isDPeBQd

Re: Making Hard Things Easy

#70

Post by marcosdumay »

norir wrote: post #14

I really disagree strongly with the take on bash. The best solution is not to add tooling on top of bash or memorize its idiosyncrasies. It is to not use bash. That is the only way to escape its pitfalls.

So, you never use bash?

That's not a very practical hill to die on. But well, you get to decide what fight you engage on.

Post reply on HN