In a sane world, Unix vendors would have either replaced their version of
morewith the clearly superiorlessor at least updated their version ofmoreto the 4.3 BSD version. Maybelesswouldn’t have replacedmoreimmediately, but certainly over say the next five years, when it kept on being better and most people kept preferring it when they had a choice. This would have been Unix evolving to pick a better alternative. In this world, basically neither happened. Unix fossilized aroundmore; no one was willing to outright replacemoreand even updating it to the 4.3 BSD version was a slow thing (which of course drove more and more people toless). Eventually the Single Unix Specification came along and standardizedmorewith more features than it originally had but still with a subset ofless‘s features (which had kept growing).This entire history has led to a series of vaguely absurd outcomes on various modern Unixes.
99.5% of the time, I really can’t tell the difference between more or less, because all I use is [space], ctrl-b, q, or /pattern.
If I need more than that, I use grep, sed, or emacs (if I had a DECWriter, I’d use vi, and be glad, but I don’t, so I don’t, and I’m not).
So less may be more, but if I can’t tell, does it matter?
Most of the them when I use less I scroll around, so it makes a difference to me.
Most versions of more these days allow backscrolling, which is why I said “ctrl-b”.
But I’ve also got this massive scrollback buffer for my terminal windows.
Most terminal emulators have at least 500 to 1000 lines of scrollback buffer so it usually makes this discussion moot. Problem kicks in when you’re using one of those nifty terminal multiplexers such as tmux or GNU screen as each has its own way of handling said scrollback buffer.
In those cases, one has to use either ‘more’ or ‘less’ (or even ‘pg’ for the really old school!) to keep his/her sanity… ^_^
(Although I must confess I’ve grown rather fond of screen’s way of handling its scrollback buffer, copy and paste, etc. over the years…)
Edited 2016-08-31 16:13 UTC
Exactly. GNU more is way different than other versions of more, so you don’t notice as much (although even then, try setting PAGER=more and see how horrible it is to use man in Linux).
If you are using Solaris, OpenBSD, or any other system that isn’t GNU, and you will quickly learn to make sure you are using less rather than more.
Whining. Most Unix-like systems either have the same executable for less and more commands, or at least suggest to use less. That said, after re-reading manuals for both programs I have hard time figuring whether anything of the difference is not plain feature creep. What have happened to the idea of sane defaults?
I think this is indicative of a bigger problem on *nix systems though. (And possibly Windows too, I dunno.) For example, I work for a company that has a lot of *nix servers – some of them brand new, and some of them many years old that are hard to replace in a production environment.
I have found that some of the features of the command-line tools I have used over the years can’t be used on these older machines, including piping commands using xargs. And it’s really frustrating when you can’t count on all of these features to work across the board, because you can’t simply throw a bash script in your /nethome directory and be confident it’ll work on everything.
That’s why the most terrifying word in the IT industry is “heterogeneous”.
🙂
And that is a wonderful reason why you should never rely on bash, less or other tools on the feature creep side of the spectrum. That is why there are standards. (Unfortunately POSIX does a very poor job at it, mostly standardizing GNU and Linux stuff instead of observing common behaviors for the whole ecosystem.)
The ridiculous thing here is that it’s not just Bash you can’t rely on, but pretty much any scripting language. This system has python27 and python34, but this older one has python or python26…
About the only exception to this is perl, which seems to keep it’s backward compatibility all the way to 5.8.8. Ruby is terrible as well.
Sure. Your chances grow if you use more “Unixy” stuff though: Bourn shell, basic Unix utilities (avoiding fancy new flags, particularly –these-ridiculous-long-options), etc. That is still less of a thing on Linux where you have New Big Thing replacing previous New Big Thing every weekend, but on BSDs a lot of stuff works more or less unaltered for ages. And even more so on Solaris with its “long standing refusal to touch anything.” (quote from the article linked in news item)
Edited 2016-08-30 21:59 UTC
I use Python in my server automation because of how much simpler things like os.walk, try/except, and the subprocess module make the tasks I commonly perform.
Given that, I’ve built up a habit of targeting Python 2.6 in my server automation (formerly 2.5) for just the reason you said.
(For my desktop stuff, I target 2.7 and 3.3+ in new projects because omitting 2.6 and 3.0-3.2 greatly simplifies hybrid 2/3 compatibility)
Having a consistent environment to work with is one of the reasons Red Hat freezes software at a specific version. If you’re targeting RHEL6, it doesn’t matter which update of RHEL6 it is; the python version is 2.6.6.
Here are some notes about this thread.
1) System stability takes a back seat to human comfort.
Environmental customization is a luxury when your a sysadmin. When you can touch a bunch of different ecosystems, like totally different ecosystems not individual systems, in one day, get used to working with the bare minimum of tools and knowing the quirks of each of them.
People are surprised when I tell them I have a very stock vim setup. It’s going to work, and I’m not going to get slowed down by missing an extension.
2) Knowing your environment and a little planning will go a long way.
For instance, only use bash for a shell script if the environment, or the targeted systems, have bash; Otherwise use sh.
3) “./configure –prefix=~/.local && make install” to configure the source code, compile the source code, and install the binaries in your home dir.
C89 is the pretty universal among C compilers, and C compilers for Unix/Unix-like systems are pretty prevalent.
Plus a million points on this. Nothing is worse than relying on non standard configs when dealing with multiple servers you can’t change much. I was very lucky in my interview for my current job that I had worked with vanilla vi for years. My custom editor wasn’t useful for an on hand test.
Citation very much needed. Outside Linux this is absolutely not true. Go check out OpenBSD, Solaris, or AIX. Even within Linux this is definitely not universal.
What exactly is absolutely not true? OpenBSD ships less as more. Solaris ships several versions of more and less. I don’t know about AIX, and I couldn’t care les about it.
I never got the point of SUS anyway. It’s not an API documentation (that’s what POSIX is for), what it is is an attempt to take a common subset of the most popular unix systems and standardize it.
The problem is that, unlike the Android Compatibility Definition, there is no single company or even a single consortium to decide what goes into a Unix OS before those OSes are released, so the SUS always plays catch up and tries to find a lowest common denominator between different OSes after they have been released.
In the case of “more” and “less” utilities, some company in the consortium didn’t want to put less into their OS for whatever reason, so the SUS had to bend backwards post-fact and find a lowest common denominator. Hence, “more” it is.
This is a thing I always hate about Unix and GNU/Linux: Every Unix pretends to be compatible with other Unixes and every GNU/Linux with other GNU/Linux while at the same time they are not and don’t want to. At least with Android, you have a single company defining the base before they release the next version of the OS and that’s it. OEMs have no say in it. So, Googley do not have to find lowest-common-denominators post-fact.
This is also why when some GNU/Linux fanboy responds with “yes but Android has fragmentation too but is successful” I know they do not know what they are talking about.
PS: Of course, most GNU/Linux distros have compatibility problems with themselves, aka their previous versions, but this is another rant for another day…
Edited 2016-08-31 02:18 UTC
SUS *is* POSIX.
In the 1990s they were competing standards documents. With the releases of SUSv3 and POSIX.1-2001, they were aligned and are now the same standard.
The difference between the two is their historical origin and focus. POSIX was an IEEE standard. SUS was X/Open, and was also given the rights to the UNIXâ„¢ trademark. SUS defines what it is to be UNIXâ„¢.
Today, both standards are developed by the same people and released together in lockstep and contain the same content, and are totally identical other than in the name on the front page.
Addendum: the other difference is that you have to pay IEEE a small fortune to get the POSIX standard document unless something changed, while you can download the SUS for free. I still have a free SUSv3 copy on CD which was given out at a Linux meeting in the early 2000s. But I downloaded a more up to date SUSv4 since then
See http://pubs.opengroup.org/onlinepubs/9699919799/
You’ll see that it has both the IEEE and Open Group logos, and the copyright at the bottom is held by both groups–this is the result of the unification of the two standards.
Edited 2016-09-01 20:24 UTC
on OpenBSD
See. e.g., https://mydevelopedworld.wordpress.com/2012/06/30/linux-when-a-dog-i…
From “% man dog”:
DESCRIPTION
dog writes the contents of each given file, URL, or the
standard input if none are given or when a file named ‘-‘ is
given, to the standard output. It currently supports the
file, http, and raw URL types. It is designed as a
compatible, but enhanced, replacement of cat(1).