`cat file` vs `vim file`

ReDress · 2024-12-01 06:32:37

Kindly excuse the lame topic. Just couldn't come up with anything better :-(

Having read through the rules, regulations, recommended way of conducting yourself and the privacy policy then it seems like time to try this discussion. Frankly not exhaustively, though but maybe just familiarising myself will be good enough.

And, yes:

date -u +%V$(uname)|sha256sum|sed 's/\W//g'

(Could have made a mistake there typing this out, GNU isn't so much on my finger tips).

But, well, checking my kernel version, inspired by that command, surprising it's the latest!

Anyways, onto the post.

It seems Arch Linux keeps the kernel config file at /proc/config.gz. Maybe these are some global changes to the kernel and not related to Arch Linux but yeah, last time the file was somewhere in /lib? And wasn't compressed? But that was obviously not on Arch Linux so it's quite possible this has always been the location of the file on Arch.

Opening the file with `cat` seems to give garbage which is not surprising since the file extension indicates that it is compressed. Being able to open the file with `cat` would however allow someone to just pipe to `grep` especially when searching for a config variable which happens a lot and in fact is probably the primary use of this file beyond compiling.

But, well, it seems like `vim` does open the file without issues. It also seems like `vim` does open the patch files at kernel.org(with .xz in the file extension).

This leaves me wondering, does `vim` has built-in file decompression or is this about something else?

Allan · 2024-12-01 06:36:05

ReDress wrote:

Opening the file with `cat` seems to give garbage which is not surprising since the file extension indicates that it is compressed. Being able to open the file with `cat` would however allow someone to just pipe to `grep` especially when searching for a config variable which happens a lot and in fact is probably the primary use of this file beyond compiling.

zcat

seth · 2024-12-01 07:19:32

`cat` would however allow someone to just pipe to `grep`

https://porkmail.org/era/unix/award#cat
"man zgrep"

ReDress · 2024-12-01 07:39:40

Allan wrote:

ReDress wrote:
Opening the file with `cat` seems to give garbage which is not surprising since the file extension indicates that it is compressed. Being able to open the file with `cat` would however allow someone to just pipe to `grep` especially when searching for a config variable which happens a lot and in fact is probably the primary use of this file beyond compiling.
zcat

seth wrote:

`cat` would however allow someone to just pipe to `grep`
https://porkmail.org/era/unix/award#cat
"man zgrep"

Beyond using vim(which already works), my goto route would have been something like

$gunzip(unzip ??) < /proc/config.gz | grep 'CONFIG_VARIABLE'

seth · 2024-12-01 07:45:24

And your new gotos will be to use zcat/zgrep and not pipe cat into grep or other things that can read files themselves

gunzip(unzip ??) < /proc/config.gz

will just get you an error and like w/ the above, it'd be

gunzip -c /proc/config.gz | less

except: "man zless"

ReDress · 2024-12-01 07:52:30

seth wrote:

And your new gotos will be to use zcat/zgrep and not pipe cat into grep or other things that can read files themselves

They do sound convenient, though, switching between tools for no apparent reason doesn't sound very much inorder.

seth · 2024-12-01 08:09:17

You did not read the porkmail cat abuse?
You can do whatever you want - there're many ways to skin a cat.
Some are just way more clumsy and cringeworthy than others.

ReDress · 2024-12-01 08:17:03

Obviously, it hasn't been possible to do more than combing over the article in the short timeframe.

Technically speaking, this doesn't explain why piping to a process that can read from file itself is a bad idea. It seems like pipes are supposed to offer convenience but it turns out it is a bad idea to use them?

seth wrote:

Some are just way more clumsy and cringeworthy than others.

The whole essence of GNU is to hack.

Last edited by ReDress (2024-12-01 08:23:06)

Head_on_a_Stick · 2024-12-01 08:26:42

vim /usr/bin/zgrep

Seems like a good idea to make use of other people's hacks, at least to me.

ReDress · 2024-12-01 08:36:14

Head_on_a_Stick wrote:

vim /usr/bin/zgrep
Seems like a good idea to make use of other people's hacks, at least to me.

It's hard making good use of a hack if you don't appreciate it first and foremost.

However, someone else probably does :-).

Awebb · 2024-12-01 08:45:33

"Useless use of cat" refers to the practice of cat'ing a text file and then piping it into some sort of processor, even though the processor is fully capable of opening the file on its own:

cat some.file | grep pattern
grep pattern some.file

Wile it's not particularly wrong on its own, it used to waste everyone's time and performance on shared systems, where every process call was a dip into the shared resources. It's being viewed as bad practice in shell scripting, because it introduces complexity to simple things. Is the processor able to read from stdin? Does it need special handing, like "cat file | processor -" to read from stdin? Does the processor have clever methods of reading the file that do not require the whole file to be read?

cat some.file | tail -5
tail -5 some.file

You might want to read zcat, though, it's just a shell script. "cat /us/bin/zcat", you'll see it's just a gzip wrapper that probably could live a happy life as a shell alias in most cases.

ReDress · 2024-12-01 08:53:50

The bottomline to every hack usually is : what problem does it solve?

If this hack doesn't solve a problem for this individual or the other then it doesn't count as a hack to them. There's nothing to appreciate, unfortunately.

Just noting, this is more common than you would think. It is well known that for instance, a lot of people write books simply for self -entertainment and the enjoyment it begets them. Consequently, these books have no real-life value but you would spend a few months reading one.

In this context, the above would imply something else :-(

ReDress · 2024-12-01 11:02:17

Awebb wrote:

Wile it's not particularly wrong on its own, it used to waste everyone's time and performance on shared systems, where every process call was a dip into the shared resources. It's being viewed as bad practice in shell scripting, because it introduces complexity to simple things. Is the processor able to read from stdin? Does it need special handing, like "cat file | processor -" to read from stdin? Does the processor have clever methods of reading the file that do not require the whole file to be read?

While your argument about resource usage would sound valid, even by today's standards where computers typically have a lot of resources given there's no excuse for resource *waste-age* there idea of complexity sounds a bit wanting.

Complexity heavily depends and varies for people with different backgrounds. To put it in other words, something that is seemingly complex to one person might turn out very simple to another person.

Arch Linux

#1 2024-12-01 06:32:37

`cat file` vs `vim file`

#2 2024-12-01 06:36:05

Re: `cat file` vs `vim file`

#3 2024-12-01 07:19:32

Re: `cat file` vs `vim file`

#4 2024-12-01 07:39:40

Re: `cat file` vs `vim file`

#5 2024-12-01 07:45:24

Re: `cat file` vs `vim file`

#6 2024-12-01 07:52:30

Re: `cat file` vs `vim file`

#7 2024-12-01 08:09:17

Re: `cat file` vs `vim file`

#8 2024-12-01 08:17:03

Re: `cat file` vs `vim file`

#9 2024-12-01 08:26:42

Re: `cat file` vs `vim file`

#10 2024-12-01 08:36:14

Re: `cat file` vs `vim file`

#11 2024-12-01 08:45:33

Re: `cat file` vs `vim file`

#12 2024-12-01 08:53:50

Re: `cat file` vs `vim file`

#13 2024-12-01 11:02:17

Re: `cat file` vs `vim file`

Board footer