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

91–100 of 127 posts

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

#91

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

#92

Post by a_thro_away »

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"…

Actually, you are wrong. In the 1972 2nd version of Bell Labs Unix the cat source code says "cat -- concatinate files"(sic). And, in the Bell Labs "Unix Programmers Manual", Second Edition, 1972 it is "Concatenate (or print) files". There goes those them "elitists" trying to be accurate again... And where do you get the idea what it's "supposed" to be anything? Approachable, or not approachable, it is what its founders made it; not what you decide it should be. Talk about arrogance.

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

#93

Post by josuah »

Do one thing and do it well, but...

- If more and less are split in two: more does not page well (no scrollback), and less does two jobs: paging and blocking the scrolling.

- If more gets dropped in favor of less: less is a rather good pager, and serve only its own purpose of paging lines of text in different way.

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

#94

Post by jjnoakes »

knz42 wrote: post #53
ChuckMcM wrote: post #3

Now all we need is someone to modify less to recognize that its standard in is connected the output of more so that if you type `cat /etc/passwd | more | less` it could output something which, more or less, looked like the input.

It actually works already :) (more does not page if its stdout is not a terminal)

That only gets you half way. You also need less to not page its input to its output if it detects "more" is on stdin (much harder).

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

#96

Post by wiredfool »

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"…

Join is a pretty cool utility -- it's the text file equivalent of a sql join.

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

#97

Post by sjellis »

pjc50 wrote: post #65
sjellis wrote: post #55

Earlier quoted context omitted.

Well, once you know that PowerShell uses the verb "Get" for fetching data, and the noun "Content" for file contents then those are reusable bits of knowledge that slot together with other verbs and nouns. It's easy to hold in your head and build your knowledge over time, and better yet, the third-party add-ons obey the common conventions, so you can experiment with confidence. When you learn the *NIX command-line fro…

I think this is one of those "familiarity" and "expectation" issues that are very subjective. Rather like python's divisive significant whitespace. I've tried to like powershell, but when I wanted "grep" I ended up having to do: Select-String "str" -Path foo.txt | ForEach-Object { Write-Output $_.Line } | Out-File t.txt .. because it has broken defaults such as truncating output to terminal width even when written to…

My first brushes with PowerShell were deeply frustrating, because I kept trying to write things the way that I expected them to work (from Bash). After a while I gave in and sat through a tutorial, and found that once I did things the way PowerShell wanted, I found it enjoyable to work with. That's just my personal experience.

FWIW, the script execution thing was dropped for the latest versions of Windows, and PowerShell Core (thankfully). I agree that the remoting is not much fun - SSH for Windows is currently due in October, so I presume that PowerShell will get SSH support around then.

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

#98

Post by freehunter »

Infernal wrote: post #74
SixSigma wrote: post #58

Earlier quoted context omitted.

I hereby award you a "Useless use of cat" award [1] more http://porkmail.org/era/unix/award.html#cat

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 :)

I do the same thing. It fits with how I think. I want to print out this file. Oh, it's too long to parse by hand, I'll search for something. Up-arrow, pipe less.

Sure I could use "<something.txt grep something", but that requires me to decide to use grep right off the bat, something I hardly ever do. Usually I want to look at it first.

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

#99

Post by sjellis »

fps wrote: post #81
sjellis wrote: post #63

Earlier quoted context omitted.

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. Fo…

The fact that PowerShell needs modules to fully work with something is definitely an issue - we'll have to see whether people start writing the modules to make PowerShell fully functional on *NIX. You can call existing command-line tools, or methods from the underlying .NET Core installation, but those are really just work-arounds.

To be fair, every programming or automation platform has that issue: Python and Ansible succeeded because people did like the basic systems enough to write code to extend their usefulness.

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

#100

Post by gpm »

expression wrote: post #86
arbitrage wrote: post #79

Earlier quoted context omitted.

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.

What if you just want to view the contents of input-file, unpaged. `<input-file` doesn't print anything unfortunately (curiously it doesn't error either).
Post reply on HN