[0xeeeeeeee]

A lot of people are talking about revamping these old programs. I don't see what the problem is with less, cat, vim, etc...

I've never been using a program and wished for better functionality. Even when this was all new to me, it was never a problem figuring these out, using them, and I was always satisfied with them..

So...here's the question. I don't think these are broken, so what are you fixing?

[coldtea]

>So...here's the question. I don't think these are broken, so what are you fixing?

First, it's not just about something not working. It's about creating tools that are extensible and understandable and hackable. Open Source is not just about "working", it's about being modifiable by the end user. All this cruft (a mess of 200 obsolete architectures, dead code and deprecated library support that nobody used since 1988) works against that goal.

Second, there are things that would be essential for some people, like international users (e.g proper multibyte support) that cannot be added due to dependancy of some custom methods of handling encodings. That's not some wishy washy magical unicorn feature request, it's essential for the main operation of what less does for those that have to deal with these encodings.

Third, there's nothing wrong in taking pride and crafting finely your tools. UNIX is supposed to be made of things that "do one thing and do it well". Less having its own utf-8 support breaks this division of responsibility. We have libaries for that. Same for getopts vs it's custom options parsing.

[clarry]

What's the library for UTF-8?

[_delirium]

At least for programs written in C, most (all?) modern Unix-like platforms should include the functionality in the base install. On the language side, C89 requires support for wide and multibyte characters in a conforming libc implementation. And POSIX furthermore requires a locales/iconv system to specify and convert between encodings. Neither of those strictly require that UTF-8 be one of the supported encodings (C89 predates Unicode), but any reasonably modern implementation will include Unicode locales. And if it doesn't, I think at this point you can just consider that to be the system's problem: the current assumption for POSIXy programs is that they will use the system locales, not try to implement their own encoding machinery.

[coldtea]

Well, ICU http://site.icu-project.org/ would be a good start.

[reubenmorais]

Did you read the blog post? Here's what he fixed:

>So, now it:

>Speaks terminfo (X/Open Curses) instead of ancient BSD termcap

>Uses glob(3C) instead of a hack involving the shell and a helper program (lessecho, which I've removed from my tree.)

>Functions properly as /usr/bin/more, both with and without -e (even on broken xterms)

>Is fully ANSI C (or ISO C, if you prefer)

>Passes illumos' cstyle code style checks

>Is lint(1) clean

[paddyoloughlin]

One thing I have noticed is that less's filtering ('&<pattern>') is sloooooooooow compared to grep.

If that were improved I'd never have to use tail -f ever again.

Someday, I'll look into it.

[noselasd]

>I don't think these are broken, so what are you fixing?

This is what the post talks about. But in short, Iluminos (An operating system derived from OpenSolaris) needed a posix compliant pager(/usr/bin/more), ported the less program to their OS and in the process found many issues which they cleaned up and fixed.

[pyre]

> So...here's the question. I don't think these are broken, so what are you fixing?

I know many people that never got a BSOD on Windows. Does this mean that there is nothing that could be fixed about Windows? Or is it possible that different people have different experiences?