(Red Hat's) 5 useless Linux commands | Hacker News Reader

(Red Hat's) 5 useless Linux commands

redhat.com

14 pointsazalemeth51 comments

I feel slightly dumber for having read this article. There is so much history woven into Unix that I think one could write a a number of interesting articles about the vestigial parts: why they're there, how they ended up not mattering, why the fell out of fashion, what in the bowels of the OS still uses it for historical reasons. But this article is definitely not that.

In particular: arch, uname, and bc are all examples of commands I actually use still today.

They're a bit more useless if you're running Ubuntu/rhel/fedora on standard desktop hardware, but unix is everywhere. And even on desktop in popular distros on standard architectures, removing arch and uname from distros would probably break a lot of install scripts.

I don't feel dumber, I feel sad that this showed up on Red Hat's web site.

I use bc multiple times every day, and uname -a occasionally.

I used bc multiple times today. I used it on two calls and multiple chats. I actually don't know if any better calculator for the command line.

This article ought to generate a bit of well-deserved flak concerning `bc`

Edit: And `uname` geeez. All-in-all, not a great article.

I never expected to find bc on such a list.

It's actually a simple programming language with user defined functions, conditionals, loops, etc.

Also, dc was the math engine for the old RSA in five lines of perl. http://www.cypherspace.org/rsa/pureperl.html Clearly a powerful tool.

I’ve seen uname used many times to easily grab a package for your specific kernel, usually kernel headers, without having to look it up and type the entire package manually.

i.e. `sudo apt install linux-headers-$(uname -r) `

as well as, yum install "kernel-devel-uname-r == $(uname -r)"

When I see articles like this from Red Hat, I get worried. Does that me they will stop including these commands in newer releases ? Already RCS is gone and I had to compile it on RHEL 8 at work.

If bc(1) and uname(1) dissapers then I will say RHEL isdefinitely heading straight to Windows land. These 2 commands are used a lot. Need to add a long list of numbers, nothing better than bc(1). Plus much easier to use than the pointy/clicky calculators out there.

I think that it won't happen.

There are reasons for the tools to be there. When writing scripts, one often relies on the easiest way of producing information. This is something that the author doesn't understand or ignores.

`uname` is indeed very often used in scripts, which is considerably more convenient than parsing `/proc/version` manually; removing it would very likely break a lot of programs.

I don't know about how frequently `bc` is used in scripts, however, bash does not support floating point operations, so I assume it's the typical first choice.

The article seems to be the equivalent of a tabloid piece, especially considering the author's previous posts¹ ("Cyber Week 2020: 13 ideas for what to buy the sysadmin in your life"). I'm baffled by how Red Hat can employ such writers.

[¹] https://www.redhat.com/sysadmin/users/khess - need to click on "Load More" multiple times.

Even the ideas are completely useless. Nobody wants something for their hobby picked out by a nonexpert. It's one of the most common mantras on the reddit gift giving threads.

It really seems like redhat is on the way out.

Over half of those aren't Linux commands. They are Unix commands. Apparently the author is unaware that Linux strives to be Unix-compatible in user space for the most part.

Here's what happens when I use the article's suggestion for finding out the architecture of my Unix but not Linux system:

  $ cat /proc/version
  cat: /proc/version: No such file or directory

Using "arch" works:

  $ arch
  i386

Similar for "uname".

"here are 5 things I don't use"

"Those who do not understand Unix are condemned to reinvent it, poorly." [Henry Spencer]

Sounds more like an entry in `5 useless RedHat articles` to me.

Unix philosophy of 'do one thing well' is why things like `arch` exist. And I've used `arch` in plenty of scripts. Same with `uname`.

I'll admit that `arch` was more important during the early days of x64 introduction than now, but anyone who deals with legacy hw or embedded platforms is more likely to see it.

No mention of `mt`? It's been a while since I needed to seek or eject a tape in earnest, yet there it is on all of my cloud instances.

Ironically - neither `uname -r` or `cat /proc/version` return an architecture on my laptop, but `arch` works just fine.

   $ uname -r
   5.8.0-50-generic

   $ arch
   x86_64

uname -m works though:

   $ uname -m
   x86_64

`uname -m` is POSIX; `/proc/version` is not. And `uname -s` will tell you whether you're on a system that is likely to have `/proc/version`.

Just to be clear, you're saying "uname -s == Linux" => "/proc exists" right? Not trying to be pedantic; just having a TIL moment.

‘Mostly true’, as they say. If `uname -s` is not 'Linux', then it's quite unlikely there will be a Linux-style /proc with assorted non-process things in it. If it is Linux, it's probably there; technically as it's a mounted file system it might not be present, but I've never even seen an embedded Linux without it.

There is so much bullshit in this article. Or is it just sarcasm? It's credibility is lost for me the moment he mentions /proc/version.

/proc/ may or may not work. It's not a secret that now we have weird solutions like WSL that is actually a linux from users perspective, but some things are a lie. Like load is just a constant string, because there is no kernel that can calculate it properly.

Or look at the mentioned commands in article, but in WSL: host:~$ (WSL): cat /proc/version Linux version 4.4.0-17763-Microsoft (Microsoft@Microsoft.com) (gcc version 5.4.0 (GCC) ) #1217-Microsoft Mon May 05 16:09:00 PST 2020 host:~$ (WSL): arch x86_64

So it DOES provide additional information. Some commands are not used much but in unix-land I can take a book from 1988 and use most of it successfully even on modern weird distributions and projects that are not exactly Linux. But the author suggests I can "ask the source". Well, I can also edit /etc/passwd or sudoers directly, but I won't.

If this is not sarcasm in that article, I am lost how this got published by redhat.

I hope you had as much fun reading this article as I had writing it. These five useless commands will now forever be associated with me. I'm also sure the hate mail will come pouring in to tell me how absolutely essential these commands are to all the inhabitants of Clipperton Island. I'm good with that.

This article is good bait if I ever seen one.

We'll continue with our RH decoupling in the meantime.

I feel this is a particularly bad article, especially coming from an official Red Hat sysadmin blog.

That said it’s definitely worth talking about. Last time I looked into it, Red Hat still ship software using many of those commands in their scripts.

I think the author missed an opportunity to discuss why these tools are still used, their history and where specifically they’re still used.

https://twitter.com/mbbroberg/status/1392190437213999113

The reception has been so bad they emergency retitled the blog entry "5 Linux commands I never use"

https://twitter.com/kenhess/status/1391833179170947078

> Indeed. I'm sad to see that it's gotten to the point where @RedHat allows avowedly ignorant cruft like this to get published. Have you ever thought about portability across releases and operating systems? E.g. /proc is not standardized or universal.

> /proc is universal on Red Hat-based Linux systems. That's my perspective on this. I'm not writing from a perspective of all distributions.

... the article doesn't have the word "Red Hat" or "RHEL" anywhere except the code blocks for output of commands, and uses the generic term "Linux" in the title.

Every single one of these commands are used on a daily basis. And “reverse Polish notation” is most definitely not politically incorrect.

Shame on RedHat for this article.

Holy shit, I missed that. Wow, I'm beginning to feel like this author didn't even _think_ about doing research for this article.

I know many an engineer and physicist that swear by RPN. I actually used it for a while, and totally see their love for it, but couldn't quite get it to stick in my head.

Reading this felt like that Apple keynote in 2016 when they said no one uses the function keys. Hmm, me? all the time?

I saw the comments but read the "article" anyway. I use 4/5 of those commands. How to downvote a post?

Write an angry letter to IBM?

I use bc all the time. Just me I guess.

No, you're not alone. bc is a not quite a life-saver, but it's always around and I can reliably do what I have to using the tool. OP is shortsighted, "I don't use these tools, therefor they are useless and stupid and should be banished".

> But soon after I discovered /proc/version, back in 1996, I realized that uname had no value.

Wow, decades of experience in being a dolt?

uname is in POSIX. It works all over the place. It's based on the uname library function, also standard.

M1 Mac:

  kaz@minimac ~ % uname -a         
  Darwin minimac 20.3.0 Darwin Kernel Version 20.3.0: Thu Jan 21 00:06:51 PST 2021; root:xnu-7195.81.3~1/RELEASE_ARM64_T8101 arm64
  kaz@minimac ~ % uname -m 
  arm64
  kaz@minimac ~ % cat /proc/version
  cat: /proc/version: No such file or directory

arch is useless only because it's not in POSIX; scripts should probably be using uname -m when they want arch.

Them -m option is very useful, because if you are after "arm64" there is no way you should be writing shell script code to extract it out of the "uname -a" or /proc/version output.

/proc/version could deceive you, even if you're on Linux. Suppose you're in a chrooted cross-compilation environment, like an ARM QEMU environment on an Intel x86_64 machine. In that sandbox, you want *uname -m" to report arm, not Intel.

But if you mount the /proc filesystem into it, I think it will be the host one kernel one with no translation for /proc/version or other telltale entries.

A script that accesses /proc/version could be hostile to cross-compiling in an emulated chroot.

That's just something that occurs to be due to stuff I have learned since 1996.

Now let's talk bc: one reason that is useful because it has bignum arithmetic. And it is specified by POSIX, which spells out this feature in the very name:

    bc - arbitrary-precision arithmetic language

Let's see:

  bc 1.07.1
  Copyright 1991-1994, 1997, 1998, 2000, 2004, 2006, 2008, 2012-2017 Free Software Foundation, Inc.
  This is free software with ABSOLUTELY NO WARRANTY.
  For details type `warranty'. 
  2 ^ 300
  20370359763344860862684456884093781610514683936659362506361404493543\
  81299763336706183397376

Shell arithmetic cannot do it. Here is bash:

  $ echo $((2 ** 3))
  8
  $ echo $((2 ** 300))
  0

GNU Awk can do it today, if its compiled with GNU GMP, and invoked with the -M option. POSIX requires no such thing from awk.

When I was taking a number theory course in 1994, I used bc for some of the studying and homework due to the bignum support. Today I'd use Lisp; but that's not a commonly installed utility you can count on to be there in a random Unix-like system.

bc doesn't do rational numbers, but it does scaled arithmetic. This is useful for money.

  scale = 2
  1.13 + 1.14 + 3.19
  5.46
  5.46 * 1.12
  6.11

It can work in bases other than decimal and has a separate input/processing base (ibase register) and output base.

What do you mean "bc is useless". I use it all the time!!

Me too, although R has become my command-line calculator of choice for most tasks. Being able to calculate things without moving my hands over to a calculator or calculator app is convenient.

Classic example of "I can't think of a use, so it must be useless". bc is very useful, and I can think of several times one might need a command line calculator.

Commands like 'arch' might provide a limited amount of data from a different command. However, to extract just the data from the larger response would then require a string of grep/sed/awk. or call the one command to give you the output you specifically need. This also holds true for the 'uname' section.

I use dc all the time, which the article denounced as even worse. dc gets more usage on my machines than most other commands, except for perhaps ls, cd, and vi. Whenever I need to make quick calculations on my computer, it is much more efficient for me to open up a terminal window and type dc than it is for me to use a GUI calculator or to grab my HP-48 graphing calculator. I suppose I could use a Python or Common Lisp REPL, but I love Reverse Polish Notation: less typing!

Yeah that one was really weird. I mean I personally usually start python or some other repl when I need to calculate something but I have reached for bc/dc sometimes aswell. And what's with the jab against RPN? The author should probably try some FORTH to learn how nice and minimal code in postfix notation can be. I'm guessing he doesn't like LISP either...

“Almost everyone, even a long time ago, had handheld calculators at their disposal.”

Can't pipe the input and output of a handheld calculator.

“The only date I could find in the man pages is 2006”

`bc` was in 6th edition Unix, so 1974 or 1975.

I strongly feel like this author hasn't written a shell script in a while... Maybe ever?

To be fair, most weeks I don't use bc.

I did use it earlier today, though, because I was already at a terminal, so why go elsewhere?

I feel like saying that I submitted this article in part to highlight how far redhat has fallen. None of the commands linked are particularly esoteric, and all are useful.

Most people use bc because the shell does not do floating-point. If bc is harmful, then write ‘echo | awk “END { print $expression }”’ on the back of your hand.

ksh does floating point. bash started out imitating ksh, but then got distracted and wandered off.

I stand corrected. POSIX apparently never wanted it, but yash, the “most POSIX-compliant in the world” has allowed it as an extension. Also looks like zsh does it—-does that mean bc is obsolete on Mac?

I use `bc` all of the time. `uname` as well.

Dc is something I use almost daily.

I like uname -a, maybe it is just me... But either way, I wonder why this post was flagged

I used bc today. Very useful util. Useless article.

I have never used any of these commands and I thought the article was fun :)

Reply on news.ycombinator.com