More, less, and a story of typical Unix fossilization | Hacker News Reader

More, less, and a story of typical Unix fossilization

utcc.utoronto.ca

195 pointszdw123 comments

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 see what you did there. I think.

The problem is less that we have fossilization and pointless cruft around basic utilities, it's more that the replacements are written by people with a sense of humor, and their sense of humor is distinctly punny.

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

I hereby award you a "Useless use of cat" award [1]

more < /etc/passwd | less

http://porkmail.org/era/unix/award.html#cat

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

cat /etc/passwd | head -n X | tail -n Y

Print lines X-Y to X of a file. :D

Why so complicated?

sed -ne 'X,Yp' /etc/passwd

Because that's what I came up with in first year uni and nobody ever said "hey, that's too complicated, you should learn to use sed properly."

I should learn to use sed properly.

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

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 love that the same set of people who like to wax poetic about the elegance of pipes and composable single-purpose tools are the most pedantic about not doing all that when a single tool happens to have all the features you strictly need, monolithically built in. Never mind that STDIN works the same on all processes, while the file argument is highly inconsistent! Never mind that the expansion of single tools to encompass common tasks is widely regarded as a pox on the cleanliness of UNIX! You must learn all the options! Minimize the number of processes! You have 16 GB of RAM but that unnecessary 'cat' is UNACCEPTABLE!

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?

    <input-file grep stuff

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

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.

And then, of course, there is most: http://www.jedsoft.org/most/

reading the phrase "Why settle for less?" made me laugh :-)

I have to say that when it comes to pagers, I more or less prefer most.

One advantage I find of more over less, is that it doesn't clear the terminal on exit. It's often nice to see what you have looked at above the command prompt. There is a "-X" option for less, but this also breaks mouse wheel scrolling.

Those horrid alt-buffer init and exit strings in terminfo and termcap are the bane of my existence. I almost never want that behavior, particularly when I've got a relevant section of a man page on the screen and want it to STAY THERE when I quit out of the pager. I use -X in less, but I really want a more universal solution, so I use a terminal type that doesn't have those strings, usually xterm-noapp. But it's not always available.

I'm not sure what you mean about -X and mouse scrolling.

Put something like this into your .Xresources:

For URxvt:

! Ctrl-Shift-A will show alternate screen URxvt.keysym.C-S-A: command:\033[?47h ! Ctrl-Shift-Z will return to regular screen URxvt.keysym.C-S-Z: command:\033[?47l

For XTerm:

! Ctrl-Shift-Z will toggle alternate screen VT100translations: #override \n\ Ctrl Shift <KeyPress> z: set-altscreen(toggle)

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 peculiarities of "old more" could be pinned to use a "private" old version of the binary, while new ones would by default use the "new more". Then, the backwards tools could be gradually updated, until no one imported the "old more" and it could be safely removed from the nixpkgs repository. (While any external, non-nixpkgs package definitions could still backport the "old more" definition should they really need it.)

Does this reasoning have any holes?

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.

I'd be asking the question of wether anything depended on `more` that couldn't depend on `less` already, but instead depends on more because more is not less.

Or, in other words, maybe the issue is cultural instead of technical, which would in practice, result in new users going to either more (the relic) or less (the bloated), depending on their views, instead of all new users going to less

edit: reading through the rest of the comments here, it seems a lot of people prefer more, for various reasons!

> 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 'more' binary around is really breaking the bank.

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 they should use?

Plus, `more` as a pager command at least makes a tiny bit of sense, but `less` is a ridiculously obscure command name for beginners.

Display less at once on the screen, and make it scrollable instead, worked perfectly fine for me as an analogy. I actually find "more" less logical, because I can't find a similar analogy for it...

Matter of taste, I like the image of scroll to see more

I don't think it's that bad. This is one of the cases where your usual ignorance towards new/different things is pretty effective.

At least for me personally, 'less' was what I always saw everywhere being used, and had used myself many times before I discovered that 'more' was a thing.

And when I discovered 'more', it took me maybe a minute to figure out that it's pretty much exactly like 'less', but that I didn't like it as much, and with everyone else seemingly agreeing on that, I didn't put any further thought to it.

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

ls, mv, cp, rm are kind of ok but in this day and age they should definitely be list, move, copy, remove by default (with aliases if need be). Heck, 99% of Unix commands are too short for their own sake.

cron -> "Chronos". Really?, third edition. It should be "scheduler" or something.

I mean, at this point we've all moved on and have memorized all these commands and parameters, but a lot of brain cells have died for no real benefit to humanity.

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.

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.

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

There is another pager, less advanced than more http://www.unix.com/man-page/linux/1/pg/

There's "most" pager discussed here a week or so ago, too.

(Incidentally that link returns a blank page for me on FF mobile.)

I missed most, I'll look for it.

The link to pg works on my FF Android. I'm using uBlock origin. Are you using some other adblocker or add on?

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 </table> and </tr>. 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...?

Posting this here, too, for visibility:

The page works for me when I tell my browser to request the desktop site.

Ops, I realized that I configured my mobile browsers to request the desktop sites. It's more convenient on a tablet.

    curl -A 'Mozilla/5.0 (Linux; Android 4.0.4; Galaxy Nexus Build/IMM76B) AppleWebKit/535.19 (KHTML, like Gecko) Chrome/18.0.1025.133 Mobile Safari/535.19' http://www.unix.com/man-page/linux/1/pg/

returns nothing so it's definitely a mobile unfriendly site.

I think pg came from System V.

I applaud all distributions that include the simplest tools. Sometimes - always the worst times - they're the ones that still work.

I prefer less. Incidentally, the other day I was on a CentOS system where I wanted to paginate a log file and typed in "less". Turns out, unlike more, less isn't installed by default. Was a bit surprised because I was under the impression that most Linux systems would have had it in their default install.

Debian doesn't install it by default either - agree, surprising. On another note, even more surprising is less's behavior with colored output (you have -r and -R switches, which are almost, but not completely, alike; and in neither of them does page-up render properly).

I was pretty sure this is incorrect for at least Debian 8 / Jessie based on recollection. And now I'm 100% sure it's false -- sigh https://www.xkcd.com/386/ -- having just installed it in a VM with only "standard system utility" selected (it is selected by default), and verified that less is installed.

I don't see it:

  $ docker run --rm debian:jessie less -V
  docker: Error response from daemon: Container command 'less' not found or does not exist..

while more is present:

  $ docker run --rm debian:jessie more -V                                                  1 ↵
  more from util-linux 2.25.2

https://github.com/tianon/docker-brew-debian/blob/c2882c541f...

It's using debootstrap --variant=minbase, which (from the man page) "...only includes essential packages and apt." It makes sense that docker would want only the bare minimum. And to be fair, but getting into nit-picking territory, minbase is the default for debootstrap, but debootstrap is not the default method of installing Debian: debian-installer is. So docker's Debian image doesn't install less, but they're not doing a default install, as in invoking debian-installer, and keeping the preselected choices as much as possible.

> neither of them does page-up render properly

Huh? "less -R" has always been working like a charm for me, for scrolling in both directions. Maybe it's related to your terminal emulator? (I use Konsole.)

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.

cmd.exe starts in a second, powershell takes 5 and then another 10 to actually be interactive.

So it's still useful to me.

And then 5 mins while you google how to enable scripts

Plus who would use these weird script language. Common! Even bash scripting it's more easy that powershell!

Err. Bash scripting is awful. Trying to figure out what chain of commands you need to pull out that one particular piece of data from the output of that command... I've seen a dozen lines to manage it in some cases before, or calling out to a script in Awk or Perl. And then it won't work when you update your system because somebody decided to update a command's output format just slightly.

Powershell is an object-oriented scripting language along the lines of something like Python, just with different syntax and more of a focus on managing services. It also has reasonable syntax for applying one command to the result of another - the pipe operator. And it's reasonable to use it in day-to-day usage as a command line.

I've written a Powershell script to change an Exchange server setting we needed to change ever so often, faster than I could ever write a bash script to do the same. Under Linux, I'd likely have given up trying to use bash to edit a config, and just started writing an m4 file which generates the config as part of a cron job.

This was exactly my reason for ignoring powershell for a long time. Just tested it and it seems to start much quicker now.

Contrary to less, PowerShell is definitely not backwards-compatible with cmd. Microsoft has changed cmd a select few times, most notably adding command extensions around NT 4, I think. But those changes were very careful not to break existing scripts (which means delayed expansion is always disabled by default). If vi acts a little bit different, or more accepts other keys that don't scroll a whole page, it's also not a big deal because those are tools people interact with, not programs. People are a bit more flexible with change. And Microsoft certainly changed a lot of things in our around its user interfaces.

cmd is still around for the same reason sh is still around. For compatibility.

I disagree; would it be Unix/Linux without a bourne/csh/bash/whatever shell? Would Win3.x/NT/Win10 be the same without CMD.EXE? I have built, developed in both, heavily, and I say that Unix/Linux without a shell is not really Unix. But the Windows without a shell may disadvantage admins, but wouldn't be missed by the vat majority of users.

Not sure, but the default install of HP-UX, Solaris, Aix, Tru64, ... are pretty bare bones.

The last time I used one of those UNIXes (around 2006) everything seemed just like when I used UNIX for the first time in 1994.

Actually my first step after a successful installation when doing Solaris administration in 2000 was to visit http://www.sunfreeware.com

cmd.exe is not so fossil, it even get bugfixed from itme to time. But Windows still includes COMMAND.COM!

    Microsoft(R) Windows DOS
    (C)Copyright Microsoft Corp 1990-2001.
    
    C:\USERS\USER>ver
    
    Microsoft Windows [Version 6.1.7601]
    
    C:\USERS\USER>

Disclaimer: Only the 32-bit x86 versions of Windows. Ones that include the NTVDM ;)

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.

There was never, to my knowledge, a command.exe .

I preferred 'more' over 'less' only in situations where I just wanted to see the first couple of many pages of output from something (for example compilation errors where the root cause is at the beginning and the rest is meaningless). 'less' would then block user interaction while reading all input (interruptible with ^G), while 'more' would display the first page immediately and stop reading from stdin.

For all other use cases, 'less' seemed clearly superior.

On thing the article misses on is that, at least in Linux, less is not a line by line pager, it controls the whole terminal screen area, so for example if you pipe output to a file that has terminal instructions (bold, color, cursor moves etc) and try to use less to read the file it will not give such good output. More just outputs the ctrl chars and lets the terminal emulator deal with them, so they are visible, Thus highlighting the benefit of simplicity over cruft.

Sometimes, because more does less, more > less.

The "-r" option to less will allow the "raw" control characters to pass through. "less -r" will do what you want.

That's great to know but you still need to make sure the process generating the output isn't trying to outsmart you.

For instance ag (silver surfer) needs you to specify `ag --color` otherwise it will detect you are piping it and disable colors.

And if I remember correctly, grep needs a `grep --color=always` to achieve the same.

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 if you don't like Microsoft or .NET, if you care about shells I'd recommend trying out PowerShell Core for an hour or two. It's only when you use it for a bit that you start to realize that you can guess commands based on the rules and actually be right and how big an improvement that actually is, rather than the current UNIX method of having to memorize more and more obscure trivia in order to get the computer to do what you want. I'm not sure if PowerShell itself is a long-term answer because of the .NET and Microsoft dependencies, but it gets lot of things right.

It's time we dropped the "Bash is good enough" arguments. There are now new Linux users starting every day, and asking them to learn that less is better than more is not funny.

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 with sensible names that can the be shortened and a really useable HELP system was a major plus and I've not seen anything match that since.

To me, the main advantage of Powershell is filename handling.

I know that if I do everything just right, then my scripts will handle filenames with spaces/newlines/other crazy characters, but I always mess up somehow. Nowadays if I ever want a script I'll distribute to people who might have spaces in directories, I write it in python even if it would be a 4 line bash script, just to avoid the issue.

I've never really had a problem with spaces in path names.

You should be quoting variables when they're used though, there is a shell style guide put out by google that deals with this stuff.

https://google.github.io/styleguide/shell.xml?showone=Quotin...

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 from scratch, everything is special cases, so the whole experience is peering at man pages and slowly rote-learning commands and options. The only commonality is that if you try to guess, you'll probably be wrong. My patience with the philosophy of independent tools hit breaking point a while ago, when I had to start learning the different CLI tools from rival cloud providers - so much to learn, and no consistency at all.

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.

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.

> I dunno, I'm a long term NIX person (Solaris 1994-2011, Linux on and off 1994-2006, Linux mostly 2006-now)

But I think this is the point. PowerShell (or the spirit of it) would be more useful for new users because they don't need to spend time memorizing every single command and can start being productive earlier. It probably makes less of a difference if the commands are already part of your muscle memory.

Though to be fair, CMD is a lot more quirky and inconsistent than modern bash. So before the advent of PowerShell, I think you could have made the same argument on favor of ...nix and against windows.

Using powershell left a really sour taste in my mouth. I felt I was promised that objects and types would prevent errors, but it just feels like everything is harder and mistakes are just as easy.

For example, 'diff (cat a.txt) (cat b.txt)' does something very different from what you'd expect, but works OK for most inputs. The perfect combination for putting bugs into production.

I still like that powershell exists. Especially on Windows where they needed it most. On Linux, though, I'd rather stick with the devil I know.

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

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.

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.

Thanks, I didn't know about the packaging system. So the idea is that the ecosystem is made of PowerShell (i.e. the shell itself and PowerShell scripting language) + .NET + 3rd party packages, am I right?

Oh I actually did know about the package manager, but I didn't know that that's coming to *NIX through PowerShell. For reference: https://blogs.technet.microsoft.com/packagemanagement/2015/0...

If I remember well, some time ago MS announced that on Windows you would be able to use Chocolatey as an additional source, which I thought was interesting.

PowerShell itself now has a packaging system and public repository for modules: http://www.powershellgallery.com/

PowerShell for Windows got this earlier in the year, and it's part of PowerShell Core. So with PS Core, you should be able to start a freshly installed copy of PS on whatever OS you are using, and add the AWS modules with this command:

Install-Module AWSPowerShell.NetCore

(Warning: this command does not work on the alpha release due to a bug - you need a workaround as described on the AWS blog: https://blogs.aws.amazon.com/net/post/TxTUNCCDVSG05F/Introdu...)

Nothing very impressive to anybody that has used any modern programming language, but now your shell has this too (if you use PS).

Thanks, I had a look and it's interesting, do you know if the Power Shell Library is just a distribution channel based on the Win 10 package management system that I linked in my previous comment, or is it a completely separate product?

AIUI, PackageManagement really is literally just a convenience API for providing a consistent set of calls for driving arbitrary package management systems, and has no package management capabilities at all itself. It's actually not Windows-specific.

The actual package management system for PowerShell modules is PowerShellGet.

On Mac, PowerShell Core includes PackageManagement, and two "providers" - an adapter for PowerShellGet and one for NuGet, so you seem to be able to do either:

Find-Module AWSPowerShell.NetCore

(to use PowerShellGet directly)

Or:

Find-Package AWSPowerShell.NetCore

(to go through PackageManagement)

Urgh, double-post and no edit or delete options - thanks, HN.

Thanks for the (double :-) ) explanation! This kind of capability in PowerShell is definitely interesting.

The actual package management system for PowerShell modules is PowerShellGet. AIUI, PackageManagement really is just a convenience for providing a consistent set of PowerShell commands for driving arbitrary package management systems, and has no package management capabilities at all itself. It's not Windows-specific, and seems to have been made cross-platform with PowerShell itself.

On Mac, PowerShell Core includes PackageManagement, and two "providers" - an adapter for PowerShellGet and one for NuGet, so you appear to be able to do either:

Find-Module AWSPowerShell.NetCore

(to use PowerShellGet directly)

Or:

Find-Package AWSPowerShell.NetCore

(to go through PackageManagement)

I didn't know most of this until I started poking around, so thanks for asking!

doing simple "df" "du" "find -exec" it still complex/verbose TODAY using powershell , I find disgusting that you compare bash to powershell (I'm not even talking about speed)

even tho the commands mentioned above aren't bash built-ins

> There are now new Linux users starting every day, and asking them to learn that less is better than more is not funny.

I think the article was more critical of commercial Unix vendors than Linux. From the article:

> Oddly, FreeBSD has done the most sensible thing; they've outright replaced more with less. There is a /usr/bin/more but it's the same binary as less and as you can see the more manpage is just the less manpage. OpenBSD has done the same thing but has a specific manpage for more instead of just giving you the less manpage.

> On Linux, more is part of the util-linux package but its manpage outright tells you to use less instead

The Free/OpenBSD choice seems sensible; presumably there are Linux distros which do the same. I imagine that if, say, Ubuntu or Debian makes a choice like this, it would propagate quite quickly to other distros; it would presumably be less of a breaking change than switching /bin/sh from bash to dash.

> It's time we dropped the "Bash is good enough" arguments.

I've rarely heard anyone claim "Bash is good enough". I do agree with the argument that bash is overused, and anything more than a trivial script should be done in a "proper" language (e.g. Python, which is installed by default on pretty much all Linux distros and OSX).

I'm not sure if there's a clear winner(s) for interactive use (i.e. a pareto improvement). Many use zsh, but I don't think it goes far enough. More radical alternatives like fish, ipython, etc. seem too fragmented at the moment. Maybe there needs to be momentum from a high-profile distro shipping such a shell as its default (while maintaining /bin/sh, /usr/bin/env bash, etc. for compatibility with existing scripts)

After using Xonsh and PowerShell, I'd be pretty happy if a Linux distribution did break from the pack and ship a radical alternative as the default, with a legacy bash installation as you describe.

Incremental changes probably won't spread uniformly - when Ubuntu switched to dash, the Fedora developers explicitly decided that they would not ship dash and would continue with bash, because they have to maintain total compatibility.

In discussions of the new PowerShell release I've seen quite a few comments that boil down to "PowerShell is fine for Windows, but we don't need it on Linux", and I feel that, yeah, we do need a much better shell because what we have is nowhere near the best that can be done. Everybody that's used *NIX for a long period of time has to adapt to the classic shell way of doing things, but we shouldn't be pushing this mess on the next generation.

I kind of feel like Linux people have gotten used to using Python (or similar?) for anything that is complex enough that shell is not enough. Which is also not perfectly suited to the domain, but enough that learning a third thing to do sysadmin-type scripting is not appealing.

> There are now new Linux users starting every day, and asking them to learn that less is better than more is not funny.

When do you even need to tell them this? Does it fundamentally change how they use the tool somehow? No, they'll see that you pipe stuff through less and that's it. Heck, I've been using Linux for 15+ years, and about 10 of those full time. The first I ever heard that "less is more" was probably ~3 years ago. It just doesn't matter.

What you're complaining about is esoteria (that is still littered all over the Windows ecosystem, e.g. the fingerprints of 8.3 file names still persist, long after it ceased to be a thing)

The Linux command-line experience is mostly composed of esoterica, and less vs. more is actually one of the least bad of a thousand paper cuts. I just couldn't resist taking a dig at the pun.

One thing that this thread has really brought into focus for me is that we treat the *NIX shells differently, because we are used to them, but IMO we ought to hold the shell to the same standards that we'd apply to any programming environment. If a new programming language with a REPL shipped today that was the quality of the shell experience that we've currently got, we'd think that it was ridiculous.

Or maybe we are observing an OS that is allowed to evolve with the needs and wants of its environment, rather than something created by decree.

>On Linux, more is part of the util-linux package but its manpage outright tells you to use less instead

On minimal distros (say, Debian in the minbase configuration), more is more likely to be included than less. I haven't used any other small distros for a while but is util-linux normally there instead of other packages (actually, I wonder why minbase doesn't just use busybox).

Not a debootstrap or any sort of Debian developer, but I assume minbase is expected to be strictly a subset of the packages one would find on a regular Debian system, which would imply having bash, dash, util-linux and so on, rather than attempting to use busybox (which is Priority: optional).

There's still a need to at least include the hard/sym-link to less, and if you do that you should probably communicate why.

(E.G. so that when someone digs out a floppy disk from who knows how long ago with a recently deceased relative's old scripts on it they'll still work.)

Also, that more's features are more likely to end up in something seriously constrained (busybox) means that if you're ever stuck on a really low end system you can still use more to get some critical things done (like page through a file or result set too large to read correctly otherwise).

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' -\""

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 their PAGER to it. In fact, I do the exact same thing in my OS builds of Solaris and SmartOS. It's called system engineering.

illumos has the entire GNU userland in /usr/gnu and it's packed with new features under the hood, but those will almost never be introduced such that they break someone else's stuff; it's the very advantage differentiator illumos provides over anyone else! And it's good engineering, adding new funtionality while not breaking existing one.

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

I see this as a necessary consequence of being human. Sometimes, a genius comes along and gets the design and implementation right for years to come. Most of the time, people try their best. But nobody can really see into the future.

I'm happy enough if people say "okay, we didn't get this quite right, but we learned and we've made it better". And if the new approach isn't compatible, well okay. The short-term pain is usually worth moving forward in the long-term.

And when this happens, it's usually not a technical issue anymore, but a communication issue, which is a way harder problem to solve. If your solution to the communication problem is technical, i.e. let's always maintain backwards compatibility, then there's still the issue of communicating what the new, preferred method is. So I feel that if you have great communication with the people who care, it shouldn't impact them badly in the first place.

The danger of backwards compatibility is maintenance cost, and stifling new ideas to solve an existing problem better - people won't bother, because the effort of making something new would be overshadowed by the effort to retro-fit old behaviour.

Still though, I get the point of changing stuff just for the sake of change is bad. I'll ignore the hyperbole about illumos though.

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.

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,

...The only way that could ever work without breaking existing software running in the wild would be for that superior tooling to be backwards compatible. SunOS (illumos) does this all of the time. For example, GNU options like -C have been added to SVR4 tar(1) on illumos, thereby enhancing, but not breaking existing functionality.

Otherwise, how would you determine whether someone isn't using something, and that on every Solaris / illumos system on the planet?

Have they optimized grep the way GNU did?

I don't know about grep(1) in particular, we have fgrep(1) on illumos for that, which comes all the way from AT&T's SVR4. We also have egrep(1) in addition to grep(1). HP-UX for example, being a SVR4 system, has fgrep(1) and egrep(1) in addition to grep(1) as well. I use fgrep(1) every day; only when I need to use regular expressions do I use grep(1).

I know cat(1)'s been optimised. If you're curious enough, you can check out Solaris's grep(1) code here:

https://github.com/illumos/illumos-gate/tree/master/usr/src/...

Lupus in fabula: you can also see that the -H option has been added to grep(1), which illustrates my point that illumos does this all of the time[1].

I mean, it's not like Solaris still has ptrace or /dev/poll.

  % ls -l /dev/poll
  lrwxrwxrwx   1 root     root          29 Jul 24  2013 /dev/poll -> ../devices/pseudo/poll@0:poll
  % man ptrace
  Standard C Library Functions                           ptrace(3C)

  NAME
       ptrace - allows a parent process to control the execution of
       a child process

  SYNOPSIS
       #include <unistd.h>
       #include <sys/types.h>

       int ptrace(int request, pid_t pid, int addr, int data);
  ...
  ...
  ...
  % uname -srpmi
  SunOS 5.10 i86pc i386 i86pc

...so I'm baffled by your statement. Did you mean to write the opposite? What were you actually trying to say?

[1] https://github.com/illumos/illumos-gate/commit/41599e9fdccb4...

Huh. Yeah, no, they're still there. Okay. I have no idea what I meant. Could have sworn somebody axed ptrace, though.

My main point was that if you have a superior utility that doesn't break compatability, like less, than why ship the original? Less is better than more, and it doesn't break compatability in any way I know. That's why setting it as $PAGER works.

The fact is, a lot of superior tooling is backwards compatible. PCRE (although superior is up for debate) is fairly compatible with extended regex, GNU tar is compatible with posix tar, both syntactically, and semantically with the aid of -H. Heck, it's compatible with the v7 archive format.

On plan9 the "terminal" window pages by itself (it is not a tty) but there is also p(1) [1] which does even less than more or less.

[1] https://swtch.com/plan9port/man/man1/p.html

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.

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.

TL;DR: less has better specs and replaced more for non-philosophically inclined sysads.

Well, at least Yngwie Malmsteen doesn't agree with this nonsense: https://www.youtube.com/watch?v=QHZ48AE3TOI

I don't believe more is the first Unix pager - doesn't pg predate it? IIRC pg is the only pager required by POSIX.

pg and the System 5 side of things are notable by their absence from M. Siebenmann's article. But pg appeared in System 5 release 2 or (more probably) 3 whereas more was 3.0BSD.

So to sum up, more had more features than more but less features than less.

Reply on news.ycombinator.com