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

More, less, and a story of typical Unix fossilization

utcc.utoronto.ca

Post reply on HN
Print view View original

81–90 of 127 posts

Re: More, less, and a story of typical Unix fossilization

#81

Post by fps »

sjellis wrote: post #63
mastazi wrote: post #24

Earlier quoted context omitted.

> I've never totally loved the shell I don't understand your point, PowerShell is a shell too, just like Bash or Zsh. When you call less, more or any other tool from Powershell, you still retain all the problems that are mentioned in the article. I think the article was focusing more on the ecosystem than anything.

The ecosystem creates problems that don't exist with PowerShell, which is more like a cross-platform programming language that sits above the OS than the traditional *NIX arrangement of an OS-specific collection of a shell (with some built-ins) plus a grab-bag of third-party tools. Like Python, Node.js etc., PowerShell has one development team that will now be delivering one implementation across all of the operating…

The UNIX philosophy of "do one thing, well" and "write many programs that work together" is contrary to powershell's idea of having all the tools you need as built-ins to your shell. The minute you need something that the "one development team" hadn't thought of, or decided wasn't important enough to ship, you have to either port it to powershell as a plugin or write something more complex to handle your workflow. For all it's cruft and baggage, the fact that there's not "one way to do things" and is continually expandable is part of what endears UNIX to it's users.

Re: More, less, and a story of typical Unix fossilization

#82

Post by arbitrage »

oblio wrote: post #77
hughperkins wrote: post #45

Earlier quoted context omitted.

yeah, calling it less may have been fun at the time, but its poor ui design. if you call a method 'add_one', having it multiply by three might be what you intend, but its not very intuitive.

Heh, all the basic UNIX tools reek of geek design and bad UX. cat -> from the obscure verb "catenate". A regular user would never, ever find the connection unless someone points it out. It should be "join" or "merge" or "unify" or something. dd -> "data description". Really? It should be "blockcopy" or something. grep -> "globally search a regular expression and print". Again, really? It should be "find" or "search".…

concatenate: link (things) together in a chain or series.

This is a word that perfectly describes exactly what cat does. Cat doesn't merge; that's ambiguous. Is a merge an interleaving? Sometimes yes. What does unify even mean in the sense of chaining data streams? Join? Close, but still unclear what it does. Does it operate on files? And what would happen to the already widely deployed join command that does something completely different?

Concatenate is a great word. Great words deserve to be used. I'm sorry that some of us haven't seen the crushing need to reduce our vocabulary to the double plus good amount of words in the newspeak lexicon.

What I'm not sorry about is that new users have to spend time to learn the system they're mucking around in before they can be useful with it. That's not a design flaw; that's a feature.

Re: More, less, and a story of typical Unix fossilization

#83

Post by zeveb »

akavel wrote: post #75

Interestingly, it occurred to me that NixOS might be in perfect position to enable painless "gradual migrations" of tooling. Imagine alternative history of UNIX, where NixOS was invented really long time ago, before 'less' was created. Now, imagine we're Mark Nudelman and we want to add fancy features to 'more' (instead of creating a new tool named 'less'). We could do this freely, and all tools depending on peculiar…

I can imagine, though, that more(1) in that case would eventually fork, so that some software depended on my-more and others on his-more and still others on her-more.

And that-other-dude's-more would have a security vulnerability, and no-one would update it, and we'd all get pwned, oh the embarrassment.

Re: More, less, and a story of typical Unix fossilization

#84

Post by oblio »

arbitrage wrote: post #82
oblio wrote: post #77

Earlier quoted context omitted.

Heh, all the basic UNIX tools reek of geek design and bad UX. cat -> from the obscure verb "catenate". A regular user would never, ever find the connection unless someone points it out. It should be "join" or "merge" or "unify" or something. dd -> "data description". Really? It should be "blockcopy" or something. grep -> "globally search a regular expression and print". Again, really? It should be "find" or "search".…

concatenate: link (things) together in a chain or series. This is a word that perfectly describes exactly what cat does. Cat doesn't merge; that's ambiguous. Is a merge an interleaving? Sometimes yes. What does unify even mean in the sense of chaining data streams? Join? Close, but still unclear what it does. Does it operate on files? And what would happen to the already widely deployed join command that does somethi…

Such a nice comment, shame it's wrong: https://kb.iu.edu/d/abnd

I'd mind "concat" less than I mind "cat".

Oh, and by the way, some of the people who use these commands are not native English speakers. "catenate" is definitely not a word they'd learn early on (most likely not even later on). This is not about "dumbing down the language" it is about "making it accessible to more people, avoiding unnecessary complexity".

These are supposed to be basic OS commands, not poetry.

Oh, and to add insult to injury, cat covers at least two different usages which IMO should be split up, at least through aliases.

There should be a "display" or "show" or "view" command which does what it says on the tin: it displays/shows the file.

And the second command would be the "join"/"merge"/whatever command that does the merging.

Regarding join, I'm pretty sure cat predates join.

> What I'm not sorry about is that new users have to spend time to learn the system they're mucking around in before they can be useful with it. That's not a design flaw; that's a feature.

I used to wear a T-shirt with this: http://dilbert.com/strip/1995-06-24

It's a cute joke, but it does contain a nugget of truth, seen in the elitist remark you made.

Re: More, less, and a story of typical Unix fossilization

#85

Post by ianai »

SixSigma wrote: post #60
frederikvs wrote: post #8

I can see the fossilization, but I don't see what's so typical Unix of that phenomenon. Windows still includes cmd.exe with all its broken, retarded features, while it has powershell, which is supposedly (no experience myself) a little less retarded.

But that was originally command.com, to command.exe to cmd.exe There is no "edit" or "edlin" any more or "ftp" or "telnet" or "tr" :(

There's telnet. You have to install it though.

Re: More, less, and a story of typical Unix fossilization

#86

Post by expression »

arbitrage wrote: post #79
Infernal wrote: post #74

Earlier quoted context omitted.

Somehow when I was learning Linux/UNIX 13 years ago, my default way of grepping for something in a file became `cat foo | grep bar`. I've tried, a bit, to break this habit, but can never stick with it. The only time it slows me down is when I'm trying to show someone something and they interrupt to ask why I do it that way :)

It's not a bad idiom to use. You can keep retrieving the last command, and change the grep term quickly with ^w . When the search argument to grep is in the middle of the line, you can't easily iterate over a bunch of search terms by hand.

Did you know you can start the command with the redirection operator?
Unless you are concatenating stuff, I see no reason to use cat.

Re: More, less, and a story of typical Unix fossilization

#87

Post by catena »

oblio wrote: post #84
arbitrage wrote: post #82

Earlier quoted context omitted.

concatenate: link (things) together in a chain or series. This is a word that perfectly describes exactly what cat does. Cat doesn't merge; that's ambiguous. Is a merge an interleaving? Sometimes yes. What does unify even mean in the sense of chaining data streams? Join? Close, but still unclear what it does. Does it operate on files? And what would happen to the already widely deployed join command that does somethi…

Such a nice comment, shame it's wrong: https://kb.iu.edu/d/abnd I'd mind "concat" less than I mind "cat". Oh, and by the way, some of the people who use these commands are not native English speakers. "catenate" is definitely not a word they'd learn early on (most likely not even later on). This is not about "dumbing down the language" it is about "making it accessible to more people, avoiding unnecessary complexity"…

Cat seems fine to me, since for most usages the con- is not necessary, and is redundant. Which makes it unfortunate that concatenate is the de-facto standard term, over catenate.

http://english.stackexchange.com/questions/125416/concatenat...

Re: More, less, and a story of typical Unix fossilization

#88

Post by [deleted] »

arbitrage wrote: post #79
Infernal wrote: post #74

Earlier quoted context omitted.

Somehow when I was learning Linux/UNIX 13 years ago, my default way of grepping for something in a file became `cat foo | grep bar`. I've tried, a bit, to break this habit, but can never stick with it. The only time it slows me down is when I'm trying to show someone something and they interrupt to ask why I do it that way :)

It's not a bad idiom to use. You can keep retrieving the last command, and change the grep term quickly with ^w . When the search argument to grep is in the middle of the line, you can't easily iterate over a bunch of search terms by hand.

[deleted]

Re: More, less, and a story of typical Unix fossilization

#89

Post by oblio »

catena wrote: post #87
oblio wrote: post #84

Earlier quoted context omitted.

Such a nice comment, shame it's wrong: https://kb.iu.edu/d/abnd I'd mind "concat" less than I mind "cat". Oh, and by the way, some of the people who use these commands are not native English speakers. "catenate" is definitely not a word they'd learn early on (most likely not even later on). This is not about "dumbing down the language" it is about "making it accessible to more people, avoiding unnecessary complexity"…

Cat seems fine to me, since for most usages the con- is not necessary, and is redundant. Which makes it unfortunate that concatenate is the de-facto standard term, over catenate. http://english.stackexchange.com/questions/125416/concatenat...

You're probably right but English, as well as UNIX, has conventions which are widely used. Going against them requires a lot of work and I'm not sure that the benefits are worth it.

"concatenate" is a lot more known than "catenate". And I'm pretty sure that even "concatenate" is quite low in usage compared to a more common verb (or set of verbs) which could be used to describe what cat does ("show", "join", "merge", "unify", etc).

Anyway, I was mostly ranting since at this point both "concatenate" as a de-facto standard term and "cat" as a default UNIX tool will probably outlive me and most likely my descendants as well :)

Re: More, less, and a story of typical Unix fossilization

#90

Post by josuah »

Fortunately, `more` may be a very small piece of software and may not clutter the /bin too much. Moreover it may already be used by some scripts displaying long output they want user to read briefly.

But there may be (much) larger softwares superseded by more modern versions, both present on the os.

Post reply on HN