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.
Yeah. And if you're on IT support over phone/chat it's easier to ask them to write arch than something really strange and then ask them to find the right information in the mumbo jumbo it spits out.
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...
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) `
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.
‘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.
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".
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.
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.
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.
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.
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
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.
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.
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?
> 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.
> 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.
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.
53 comments
[ 5.0 ms ] story [ 100 ms ] threadCommands 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.
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 did use it earlier today, though, because I was already at a terminal, so why go elsewhere?
Edit: And `uname` geeez. All-in-all, not a great article.
It's actually a simple programming language with user defined functions, conditionals, loops, etc.
i.e. `sudo apt install linux-headers-$(uname -r) `
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 use bc multiple times every day, and uname -a occasionally.
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.
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.
It really seems like redhat is on the way out.
Shame on RedHat 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.
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.
Here's what happens when I use the article's suggestion for finding out the architecture of my Unix but not Linux system:
Using "arch" works: Similar for "uname".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.
<lists things that lots of scripts use, which this person probably uses without knowing they've used them e.g. if they ever run ./configure>
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:
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:
Let's see: Shell arithmetic cannot do it. Here is bash: 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.
It can work in bases other than decimal and has a separate input/processing base (ibase register) and output base.> 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.
This article is good bait if I ever seen one.
We'll continue with our RH decoupling in the meantime.