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

The most surprising Unix programs

minnie.tuhs.org

Post reply on HN
Print view View original

101–110 of 182 posts

Re: The most surprising Unix programs

#101

Post by loeg »

nicoburns wrote: post #38
thaumasiotes wrote: post #15

Earlier quoted context omitted.

> On the surface it sounds a lot like it would produce error messages like “expected ‘;’” that most beginner programmers come to hate Do people really come to hate these? I'd expect the opposite -- that people would start off hating messages like "expected ';'", but fairly quickly become accustomed to what they almost always mean. As long as you can look at the message and have a good idea of what's wrong, it's not a…

Once you've used a compiler like Rust or Elm that actually provides suggestions for common solutions to these errors (effectively building the tribal knowledge of what the error "really means" into the compiler itself), it's hard to tolerate these cryptic errors that only really make sense to machines.

I often found Rust's errors completely confusing, even after chasing down the '--explain CrypticNNNNN' follow-up explainer. This was in 2019 — not some ancient version of Rust.

Re: The most surprising Unix programs

#102

Post by loeg »

projektfu wrote: post #87
thaumasiotes wrote: post #15

Earlier quoted context omitted.

> On the surface it sounds a lot like it would produce error messages like “expected ‘;’” that most beginner programmers come to hate Do people really come to hate these? I'd expect the opposite -- that people would start off hating messages like "expected ';'", but fairly quickly become accustomed to what they almost always mean. As long as you can look at the message and have a good idea of what's wrong, it's not a…

They were frustrating in pascal because of its original ;-as-separator philosophy. Lightspeed/Think pascal would give you those errors and guide you to a compilable program, but it was still too easy to make that mistake in the first place. On the other hand, a missing semicolon in Microsoft C would often give a litany of unrelated errors.

Some versions of GCC, as well (like, mid 2000s 3.x or 4.x).

Re: The most surprising Unix programs

#103

Post by loeg »

zamadatix wrote: post #70
nunoferreira wrote: post #35

What about "comm" - compare two sorted files line by line. You can easily get occurrences only in file 1, in both files, only in file 2. Super powerful and saved me hours of work.

Comm is perfect for scripting usage but you might find diff better for human usage. Added bonus diff also does binary. Plus diff was in part written by the author of the linked content :).

Comm operates on sets. Diff is a patch generator. They serve different needs. They're both useful!

Re: The most surprising Unix programs

#104

Post by JdeBP »

Someone wrote: post #51
saagarjha wrote: post #7

And people say theoretical computer science isn’t useful in “the real world”… I am curious about this one, though, has anyone used it? > The syntax diagnostics from the compiler made by Sue Graham's group at Berkeley were the mmost helpful I have ever seen--and they were generated automatically. At a syntax error the compiler would suggest a token that could be inserted that would allow parsing to proceed further. No…

I would guess the most useful part of that is that would allow parsing to proceed further . I used an Algol compiler that had messages such as: Semicolon missing after end (inserted) Undeclared identifier ‘foo’ (assumed integer) Both of these hugely improved the compiler output, as far fewer utterly useless error messages would be produced (yes, I know I didn’t declare ‘foo’. You told me so the previous 12 times I us…

MetaWare was producing a C/C++ compiler that did much the same thing, in the 1980s.

Re: The most surprising Unix programs

#105

Post by ruslan »

bonzini wrote: post #10
ruslan wrote: post #8

I would add bc to the list, very useful to make occasional calculations from command line using "human readable" syntax.

Fun fact, the first version of bc was just a frontend to dc. It converted the structured input to dc's stack-based form and let dc do the math.

Did not know that, thanks. I searched for dc inside bc and could find a reference to /usr/bin/dc, so I think bc still is just a wrapper.

% uname -a

FreeBSD skyrocket 9.3-RELEASE FreeBSD 9.3-RELEASE #1: Fri Nov 27 20:28:19 UTC 2015

Re: The most surprising Unix programs

#106

Post by bonzini »

ruslan wrote: post #105
bonzini wrote: post #10

Earlier quoted context omitted.

Fun fact, the first version of bc was just a frontend to dc. It converted the structured input to dc's stack-based form and let dc do the math.

Did not know that, thanks. I searched for dc inside bc and could find a reference to /usr/bin/dc, so I think bc still is just a wrapper. % uname -a FreeBSD skyrocket 9.3-RELEASE FreeBSD 9.3-RELEASE #1: Fri Nov 27 20:28:19 UTC 2015

GNU bc isn't though they share the bignum code, I am not surprised that the BSDs are following the older implementation more closely!

Re: The most surprising Unix programs

#107

Post by JdeBP »

abetusk wrote: post #71

For me, the most surprising one was paste. paste allowed me to interleave to streams or to split out a single stream into two columns. I'd been writing custom scripting monstrosities before I discovered paste: $ paste I wonder what other unix gems I've been missing...

I would guess, from experience of people doing things the hard way, at:

* John A. Kunze's jot and rs

* John Kerl's mlr ("Miller")

* jq

* join and comm, as mentioned

* fmt

* ex

And, given what you just wrote:

* printf

Re: The most surprising Unix programs

#109

Post by banana_giraffe »

pjc50 wrote: post #43
amelius wrote: post #37

Earlier quoted context omitted.

The problem with these methods is that you exclude everybody that deviates from the norm. Yes, it might make your life (as a developer) a little bit easier, but it makes the lives of some of the applicants a lot harder.

I think the "manual review" phase makes this OK, in a way that simply autobanning Mr Null from your system isn't.

Often not in practice. These sort of tools to triage input data for human review generally means the humans will just auto-approve what the computer tells them to.

Yes, they'll catch some extreme cases, but anything that looks like the normal bad case will go by unnoticed generally more so than if the human is doing all of the review work.

Post reply on HN