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

61–70 of 127 posts

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

#61

Post by Annatar »

guitarbill wrote: post #51
Annatar wrote: post #17

From the article: I am not a fan of Solaris's long standing refusal to touch anything. This is what people often deeply misunderstand about traditional UNIX operating systems: one of Solaris' greatest features, in stark contrast to GNU/Linux, is the insistence on not breaking backward compatibility. Solaris has however delivered less(1) as standard since Solaris 8, so there is nothing stopping one from configuring th…

> one of Solaris' greatest features Features are use-case specific. One person's feature is another person's bloat. (Personally, I side with the article author on this.)

Do you deliver any software for the platform you use, and if so, do you not mind when things suddenly stop working?

Or, are you responsible for delivering any services, and if so, do you not mind when someone else's changes cause you an outage?

Perhaps you have some private automation in place; do you not mind if your automation breaks because of someone else?

Apropos bloat, illumos is the only operating system codebase which gets faster and more efficient with every commit. If there are others out there, I have yet to see such a thing.

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

#62

Post by tambourine_man »

I've recently been using Vim as a pager and it's great.

  :help manpager
Suggests

  export MANPAGER="env MAN_PN=1 vim -M +MANPAGER -"
Which doesn't work for me, but this does:

  export MANPAGER="/bin/sh -c \"col -b | vim -c 'set ft=man ts=8 nomod nolist nonu noma' -\""

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

#63

Post by sjellis »

mastazi wrote: post #24
sjellis wrote: post #15

I've used Linux for a decade-and-a-half, but I've never totally loved the shell, because of the need to learn this sort of pointless arcana. PowerShell was a massive step forward, and I had hoped that an Open Source, cross-platform equivalent would develop so that we could get past the current local maxima of 1970s-era design. It's rather weird that the Open Source equivalent of PowerShell is now...PowerShell. Even i…

> 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 systems. There's a packaging system included, so that third-party modules can also be uniformly deployed. The first-party and third-party stuff all has to follow the same rules and end up as modules in the same PowerShell installations, which avoids the long-running inconsistencies between tools, like man vs. info and different styles of option parsing.

At the moment, different versions of Windows do ship with different versions of PowerShell, which is annoying, but it's the same product and you can install new PowerShell versions on older systems to get a consistent environment across your machines.

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

#64

Post by Sylos »

pmontra wrote: post #49
amavisca wrote: post #43

Earlier quoted context omitted.

The link is similarly a white screen on Android Chrome for me.

Hopefully this works http://man.he.net/?topic=pg&section=all The page source is as simple as it could have been in 1996 :-) The original link has a broken table layout with some unbalanced and . Maybe that breaks rendering on your browsers, but why not on my Firefox?

For me, not only the page is completely empty, but also the page-source, so I don't think that it's a rendering problem and rather the server sending a 0-long HTML-file or something like that.

It also finishes loading rather quickly, so it would only make sense that it's not even downloading anything.

And neither Firefox, nor Lightning Browser (WebView-based), nor CyanogenMod's Gello Browser (Chromium-based) show any form of error and just happily render a completely empty page.

Also, I do get the favicon displayed, so at least some form of connection to the server seems to be possible.

Edit: Just had another idea. It works for me when I tell Firefox to request the desktop site. So, maybe the server just gets confused by a mobile useragent-string...?

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

#65

Post by pjc50 »

sjellis wrote: post #55
rollthehard6 wrote: post #18

Earlier quoted context omitted.

I dunno, I'm a long term *NIX person (Solaris 1994-2011, Linux on and off 1994-2006, Linux mostly 2006-now) I am now involved in more Powershell scripting on Windows than I have ever done before. I don't see - Get-Content -Tail 10 FILE as an improvement on - tail -10 FILE I think when it comes to the combination of intuitive command names and terseness when required, VMS' DCL is still unsurpassed. Having commands wit…

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 a file.

Then there's the weirdness around enabling script execution (rather more complicated than +x) and the remote execution system is much stranger than ssh.

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

#66

Post by qwertyuiop924 »

Annatar wrote: post #17

From the article: I am not a fan of Solaris's long standing refusal to touch anything. This is what people often deeply misunderstand about traditional UNIX operating systems: one of Solaris' greatest features, in stark contrast to GNU/Linux, is the insistence on not breaking backward compatibility. Solaris has however delivered less(1) as standard since Solaris 8, so there is nothing stopping one from configuring th…

Well, what about new features that don't break compat? Have they optimized grep the way GNU did?

And the fact is, when there's a piece of core that nobody uses, and has since been replaced by superior tooling, The Right Thing to do is to rip it out, and link to said superior tooling if it has a compat mode. I mean, it's not like Solaris still has ptrace or /dev/poll.

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

#67

Post by mudetroit »

SixSigma wrote: post #58
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.

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

or just more /etc/passwd | less ¯\_(ツ)_/¯

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

#68

Post by a_thro_away »

CJefferson wrote: post #25
taneq wrote: post #21

> In a sane world, Unix vendors would have either replaced their version of more with the clearly superior less But that's just the thing - 'less' isn't "clearly superior" to 'more'. It is (or was, maybe this has changed) heavier weight and offers more functionality that may not be needed. Having both commands lets script writers use exactly the tool they need for the job. And it's not like the extra 35KB of keeping…

The problem isn't the 35k, the problem is now we all have to spend a little bit of extra brain capacity, remembering the difference between 'more' and 'less', and how while you would imagine 'more' is better (based on the traditional English meaning of the words), actually, 'more' is the lesser product. I wonder how many hours have been wasted altogether on people learning, and misunderstanding, which of more or less…

You present a false argument. I have never "needed" nor used less, ever, and I suffered no concussion. Imagine having just one tool; you had better like it. If you hit upon a time when your chosen tool needs more functionality, that is when you go looking for a different tool. Luckily, that is what makes the Unix ecosystem strong and flexible and personal. All I have been seeing lately the want to dumb things down at the expense of flexibility. I have been building and admin'ing diverse Unix systems (and uVax, Win), well, 1980s forever, on very large and very small sites.

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

#69

Post by yk »

SixSigma wrote: post #58
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.

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

Clearly cat is used for clarity in the joke, such that the more or less pun is more obvious. I therefore consider the use of cat in this instance good programming praxis. (Of course good programming praxis in bash is a bit like safe driving in formula one.)

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

#70

Post by theoh »

CJefferson wrote: post #25
taneq wrote: post #21

> In a sane world, Unix vendors would have either replaced their version of more with the clearly superior less But that's just the thing - 'less' isn't "clearly superior" to 'more'. It is (or was, maybe this has changed) heavier weight and offers more functionality that may not be needed. Having both commands lets script writers use exactly the tool they need for the job. And it's not like the extra 35KB of keeping…

The problem isn't the 35k, the problem is now we all have to spend a little bit of extra brain capacity, remembering the difference between 'more' and 'less', and how while you would imagine 'more' is better (based on the traditional English meaning of the words), actually, 'more' is the lesser product. I wonder how many hours have been wasted altogether on people learning, and misunderstanding, which of more or less…

If you know that it's a reference to the phrase "less is more", both the similarity and intended capability is humourously conveyed...
Post reply on HN