Re: Future shell work - comments reqyuested

[maya%netbsd.org@localhost]

There are systems that have followed this policy of not touching basic
tools, it looks really ugly after 20 years of being done. You have to
explain to a newcomer that his command isn't working because rm can't
delete files over 2GB, and people will rationalize it saying that 'maybe
someone's scripts rely on >2GB files not being deleted'.

There is such a system that kept up with its 'completed' shell for the
longest time, and in pkgsrc we make it call ksh rather than sh because
stuff breaks down randomly.

I imagine without the magical replacements of pkgsrc, people who are just
building programs spend countless hours trying to figure out why a build
system in a project they are trying to use is not working for them.

sh follows a standard and if you stick to it, you don't need to worry
much about whether it will break down. If anything, kre is making our sh
more POSIX-compatible than before.

Why should we restrict ourselves to just POSIX sh and never allow
improvements? even POSIX is also not set in stone, and it has been
extended when something turned out to be a really good idea and lots of
people adopted it.

I don't think kre is making sh into a bash-sized beast, and still runs
fine on really weak machines.

I know people like NetBSD for its stability, but the reason for that
stability isn't because stuff is left alone, but because most developers
run -current on their machines and discover the bugs before they hit
releases (and to some extent, because we don't intentionally break
compatibility). I complain about -current breakage, but that isn't a
sign that NetBSD is about to have a broken release.

I prefer writing sh over python, because sh is the language that lets me
use tools I'm already familiar with, in their usual syntax. I
reluctantly use something else when I need to have a pretense of
security and untrusted input, because using sh for such purposes has a
reputation for being a minefield for security bugs.