Hacker News Reader

Comment by ajross | Hacker News Reader

You don't attack coreutils. You attack the scripts. In this case it was an update script that failed because of an incompatibility. It's not too hard at all to imagine one failing in an exploitable way.

Honestly, Rust-related hilarity aside, this project was a terrible, terrible idea. Unix shell environments have always been ad hoc and poorly tested, and anything that impacts compatibility is going to break historical code that may literally be decades old.

See also the recent insanity of GNU grep suddenly tossing an error when invoked as "fgrep". You just don't do that folks.

View on HN

> See also the recent insanity of GNU grep suddenly tossing an error when invoked as "fgrep". You just don't do that folks.

The 'fgrep' and 'egrep' didn't throw errors, it would just send a warning to standard error before behaving as expected.

Those commands were never standardized, and everyone is better off using 'grep -F' and 'grep -E' respectively.

> didn't throw errors, it would just send a warning to standard error

Noted without comment. Except to say that I've had multiple scripts of my own break via "just" discovering garbage in the output streams.

> Those commands were never standardized

"Those commands" were present in v7 unix in 1979!

I think he means POSIX. Didn’t check but in some cases posix only covers some options a tool provides not all. It’s a hard lesson I learned while keeping shell scripts portable between Linux and macOS.

Yep. I was slightly incorrect in my original message, though. SUSv2 (1997) specified egrep and fgrep but marked them LEGACY. POSIX.1-2001 removed them.

The only place that that doesn't support 'grep -E' and 'grep -F' nowadays is Solaris 10. But if you are still using that you will certainly run into many other missing options.

[1] https://pubs.opengroup.org/onlinepubs/007908775/xcu/egrep.ht... [2] https://pubs.opengroup.org/onlinepubs/007908775/xcu/fgrep.ht...

"GNU grep implemented a change that breaks pre-existing scripts using a 46 year old API, but it's OK because the required workaround works everywhere but Solaris 10" seems like not a great statement of engineering design to me.

"GNU grep added a warning to inform you of the deprecation which happened 28 years ago, but only to stderr, and still works like you expect", does to me.

Meh. Look, it broke code. "Still works like you expect" is 100% false.

The deprecation argument is at least... arguable. It was indeed retired from POSIX. But needless deprecation is itself a smell in a situation where you can't audit all the code that uses it. Don't do that. It breaks stuff. It broke the updates in the linked article too. If you have an API, leave it there absent extremely strong arguments for its removal.

and yet coreutils continues to receive updates in ways that could break things.

This is not a rousing endorsement of the Unix shell environment. Maybe that should be rewritten in something else too (probably not Rust, Rust is probably not a good choice for this - but something that is designed in such a way that it is easy to test would be nice!).

There's nothing about rust that makes things hard to test. Actually the embedded test framework makes it easier than C. But what really matters is the public interface of those tools and that's got an extensive test suite available. It doesn't matter which language is used internal for those tests to run.

I meant that Rust is probably not a good choice for a new shell scripting environment, not that Rust is hard to test. I was responding to the claim "Unix shell environments have always been ad hoc and poorly tested", which is a bad thing and is worth fixing in and of itself.

> not a good choice for a new shell scripting environment

Why?

> This is not a rousing endorsement of the Unix shell environment.

It's surely not. The question wasn't how to rewrite the shell environment to be more "endorseable", though.

The point is that we have a half century (!) long history of writing code to this admittedly fragile environment, with no way to audit usage or even find all the existing code (literally many of the authors are retired or dead).

So... it's just not a good place to play games with "Look Ma, I rewrote /usr/bin/date and it's safe now!" Mess with your own new environments, not the ones that run the rest of the world please.

Maybe it's more important to rewrite half a century of poorly documented and specified shell scripts that are so embedded that their existence gets in way of rewriting fundamental Unix command line utilities, than it is to rewrite those utilities themselves. Any time someone makes the claim "we shouldn't touch this code, it's fragile" that state of affairs is itself bad. Our free software source code shouldn't be some poorly understood black box that we're afraid to touch for fear of breaking something, and if it is that is something we should fix.

> Maybe it's more important to rewrite half a century of poorly documented and specified shell scripts

Sounds like a plan. Let me know when you're done, and then we can remove fgrep.

Reply on news.ycombinator.com