Linked by Thom Holwerda on Tue 30th Aug 2016 16:29 UTC
General Unix

In a sane world, Unix vendors would have either replaced their version of more with the clearly superior less or at least updated their version of more to the 4.3 BSD version. Maybe less wouldn't have replaced more immediately, 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 around more; no one was willing to outright replace more and even updating it to the 4.3 BSD version was a slow thing (which of course drove more and more people to less). Eventually the Single Unix Specification came along and standardized more with more features than it originally had but still with a subset of less's features (which had kept growing).

This entire history has led to a series of vaguely absurd outcomes on various modern Unixes.

Order by: Score:
And yet...
by grat on Tue 30th Aug 2016 17:46 UTC
grat
Member since:
2006-02-02

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?

Reply Score: 4

RE: And yet...
by panzi on Tue 30th Aug 2016 18:00 UTC in reply to "And yet..."
panzi Member since:
2006-01-22

Most of the them when I use less I scroll around, so it makes a difference to me.

Reply Score: 7

RE[2]: And yet...
by grat on Tue 30th Aug 2016 19:44 UTC in reply to "RE: And yet..."
grat Member since:
2006-02-02

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.

Reply Score: 2

RE[3]: And yet...
by DeadFishMan on Wed 31st Aug 2016 16:06 UTC in reply to "RE[2]: And yet..."
DeadFishMan Member since:
2006-01-09

Most versions of more these days allow backscrolling, which is why I said "ctrl-b".


I guess it really depends on which OS we're talking about and how modern the userland is. On AIX, without any of the GNU goodies installed, 'more' is decidedly ancient and does not allow one to scroll using arrow keys.

It does, of course, allows scrolling back and forth beyond the typical space-to-scroll-down-one-page-at-a-time using vi keys (H,J,K,L) and standard vi commands (Ctrl-B, Ctrl-F, line-numberG, /pattern, etc.) but it is easy to see why most Linux users don't like it.

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

Reply Score: 4

RE[4]: And yet...
by FlyingJester on Wed 31st Aug 2016 21:24 UTC in reply to "RE[3]: And yet..."
FlyingJester Member since:
2016-05-11

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.

Reply Score: 3

Comment by ddc_
by ddc_ on Tue 30th Aug 2016 18:22 UTC
ddc_
Member since:
2006-12-05

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?

Reply Score: 2

RE: Comment by ddc_
by WorknMan on Tue 30th Aug 2016 19:09 UTC in reply to "Comment by ddc_"
WorknMan Member since:
2005-11-13

Whining. Most Unix-like systems either have the same executable for less and more commands, or at least suggest to use less.


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.

Reply Score: 5

RE[2]: Comment by ddc_
by grat on Tue 30th Aug 2016 19:41 UTC in reply to "RE: Comment by ddc_"
grat Member since:
2006-02-02

That's why the most terrifying word in the IT industry is "heterogeneous".

:)

Reply Score: 4

RE[2]: Comment by ddc_
by ddc_ on Tue 30th Aug 2016 20:02 UTC in reply to "RE: Comment by ddc_"
ddc_ Member since:
2006-12-05

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.

You can't expect older servers to grow new features retrospectively.

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.

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

Reply Score: 6

RE[3]: Comment by ddc_
by leech on Tue 30th Aug 2016 21:08 UTC in reply to "RE[2]: Comment by ddc_"
leech Member since:
2006-01-10

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

You can't expect older servers to grow new features retrospectively.

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.

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.

Reply Score: 2

RE[4]: Comment by ddc_
by ddc_ on Tue 30th Aug 2016 21:56 UTC in reply to "RE[3]: Comment by ddc_"
ddc_ Member since:
2006-12-05

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


The ridiculous thing here is that it's not just Bash you can't rely on, but pretty much any scripting language.
"

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

Reply Score: 2

RE[4]: Comment by ddc_
by ssokolow on Wed 31st Aug 2016 00:59 UTC in reply to "RE[3]: Comment by ddc_"
ssokolow Member since:
2010-01-21

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


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)

Reply Score: 2

RE[4]: Comment by ddc_
by Flatland_Spider on Wed 31st Aug 2016 01:06 UTC in reply to "RE[3]: Comment by ddc_"
Flatland_Spider Member since:
2006-09-01

The ridiculous thing here is that it's not just Bash you can't rely on, but pretty much any scripting language.


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.

Reply Score: 5

RE[5]: Comment by ddc_
by Bill Shooter of Bul on Wed 31st Aug 2016 13:45 UTC in reply to "RE[4]: Comment by ddc_"
Bill Shooter of Bul Member since:
2006-07-14

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.

Reply Score: 4

RE: Comment by ddc_
by FlyingJester on Wed 31st Aug 2016 22:38 UTC in reply to "Comment by ddc_"
FlyingJester Member since:
2016-05-11

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.

Reply Score: 1

RE[2]: Comment by ddc_
by ddc_ on Fri 2nd Sep 2016 22:24 UTC in reply to "RE: Comment by ddc_"
ddc_ Member since:
2006-12-05

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.

Reply Score: 2

Re:
by kurkosdr on Wed 31st Aug 2016 02:13 UTC
kurkosdr
Member since:
2011-04-11

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

Reply Score: 3

RE: Re:
by rleigh on Thu 1st Sep 2016 20:15 UTC in reply to "Re:"
rleigh Member since:
2014-11-15

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

Reply Score: 1

less is more
by Soulbender on Wed 31st Aug 2016 06:19 UTC
Soulbender
Member since:
2005-08-18

on OpenBSD

Reply Score: 3

dog - better than cat
by cjcoats on Wed 31st Aug 2016 11:32 UTC
cjcoats
Member since:
2006-04-16

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

Reply Score: 4