Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

cat mario.nes | nc play-nes.org 4444

github.com

Post reply on HN
Print view View original

61–70 of 76 posts

Re: cat mario.nes | nc play-nes.org 4444

#61

Post by ilyt »

__forward__ wrote: post #52
spyremeown wrote: post #46

Earlier quoted context omitted.

That's like those objected-oriented programming examples you get in college, from professors who learned in the 90s and literally think in terms of "modelling" real objects with OOP.

To be fair they may actually know there stuff but from a didactic point-of-view it is very difficult introduce a `FactoryProvider` (or to a lesser extent even an `HTTPClient`) alongside basic OOP concepts.

Use real useful code example

Have Logger with StdoutLogger as basic example of it

Then FileLogger that extends it with few functions related to files

Then DBLogger with few functions related to logging to database

Then TestLogger for integrating with test framework

Re: cat mario.nes | nc play-nes.org 4444

#62

Post by ilyt »

jeremy_wiebe wrote: post #37
bityard wrote: post #16

Earlier quoted context omitted.

I was sincerely hoping I wouldn't be the first person to notice the useless use of cat. https://en.m.wikipedia.org/wiki/Cat_(Unix)#Useless_use_of_ca...

I’ve run across comments regarding useless use of cat twice today. However, after reading the linked Wikipedia entry, it feels more like a way to give someone an ego trip than a truly more useful alternative. The Wikipedia article even concedes that cat might be better: > A cat written with UUOC might still be preferred for readability reasons, as reading a piped stream left-to-right might be easier to conceptualize.…

I often write cat as a first element of a pipeline, then replace it with head/tail, or grep when I need to narrow it down.

"oh but you can save one character" (one coz requires shift) yeah fuck that, if I was bothered with it I'd alias cat to c

Re: cat mario.nes | nc play-nes.org 4444

#63

Post by ilyt »

chungy wrote: post #23
user3939382 wrote: post #18

Earlier quoted context omitted.

It’s not useless because it’s able to accomplish the same without having to memorize yet another syntax trick. - Someone who knows the trick

It's a basic shell feature that every terminal user should know from day 1. Hardly a "trick".

Hardly "basic", natural assumption after knowing what say

    date > file
does is assuming "there needs to be data source on left side, and target file on the right side

Similiar with

   wc
"There needs to be receiver program on the left side, and file on the right"

The assumption from seeing it is "program on left, data on right"
breaks that assumption completely.

Honestly I don't think that in 15+ years I ever saw that in the wild in any shell script

Re: cat mario.nes | nc play-nes.org 4444

#64

Post by ilyt »

benatkin wrote: post #47
t-3 wrote: post #41

Earlier quoted context omitted.

It requires forethought in many cases. Cat-initiated pipelines can be built iteratively in a natural fashion.

What's natural about cat on only one file? > Briefly, here's the collected wisdom on using cat: > The purpose of cat is to concatenate (or "catenate") files. If it's only one file, concatenating it with nothing at all is a waste of time, and costs you a process. The fact that the same thread ("but but but, I think it's cleaner / nicer / not that much of a waste / my privelege to waste processes!") springs up virtuall…

> What's natural about cat on only one file?

It's about building the query, really. Here is example:

    cat file.log
"Oh, it's too big, I only care about these messages"

    cat file.log |grep error_name
"don't care about old stuff, show me the new one"

    cat file.log |grep error_name | tail
"hmm, show me when it started, and let's ignore monitoring checks"

    cat file.log |grep error_name | grep -v 'user: mon'| head
"okay, but maybe log was rotated ? Let's see last week"

    zcat file.log.1 |grep error_name | grep -v 'user: mon'| head
"hmm, it's some old error, let's search some more logs"

    zcat file.log.{10..1} |grep error_name | grep -v 'user: mon'| head
(zcat will auto add .gz if not passed)

You can't for example do

Re: cat mario.nes | nc play-nes.org 4444

#65

Post by t-3 »

benatkin wrote: post #47
t-3 wrote: post #41

Earlier quoted context omitted.

It requires forethought in many cases. Cat-initiated pipelines can be built iteratively in a natural fashion.

What's natural about cat on only one file? > Briefly, here's the collected wisdom on using cat: > The purpose of cat is to concatenate (or "catenate") files. If it's only one file, concatenating it with nothing at all is a waste of time, and costs you a process. The fact that the same thread ("but but but, I think it's cleaner / nicer / not that much of a waste / my privelege to waste processes!") springs up virtuall…

Catenating a file with the output stream is quite useful in many circumstances. Paged data isn't always wanted, and it's not generally known if filters are needed before the file is seen. Cat is the standard way to print to stdout.

Re: cat mario.nes | nc play-nes.org 4444

#66

Post by benatkin »

ilyt wrote: post #64
benatkin wrote: post #47

Earlier quoted context omitted.

What's natural about cat on only one file? > Briefly, here's the collected wisdom on using cat: > The purpose of cat is to concatenate (or "catenate") files. If it's only one file, concatenating it with nothing at all is a waste of time, and costs you a process. The fact that the same thread ("but but but, I think it's cleaner / nicer / not that much of a waste / my privelege to waste processes!") springs up virtuall…

> What's natural about cat on only one file? It's about building the query, really. Here is example: cat file.log "Oh, it's too big, I only care about these messages" cat file.log |grep error_name "don't care about old stuff, show me the new one" cat file.log |grep error_name | tail "hmm, show me when it started, and let's ignore monitoring checks" cat file.log |grep error_name | grep -v 'user: mon'| head "okay, but…

That's a lot of extra processes!

There's also zgrep: https://man.openbsd.org/OpenBSD-5.9/grep.1

Re: cat mario.nes | nc play-nes.org 4444

#67

Post by [deleted] »

t-3 wrote: post #65
benatkin wrote: post #47

Earlier quoted context omitted.

What's natural about cat on only one file? > Briefly, here's the collected wisdom on using cat: > The purpose of cat is to concatenate (or "catenate") files. If it's only one file, concatenating it with nothing at all is a waste of time, and costs you a process. The fact that the same thread ("but but but, I think it's cleaner / nicer / not that much of a waste / my privelege to waste processes!") springs up virtuall…

Catenating a file with the output stream is quite useful in many circumstances. Paged data isn't always wanted, and it's not generally known if filters are needed before the file is seen. Cat is the standard way to print to stdout.

[deleted]

Re: cat mario.nes | nc play-nes.org 4444

#68

Post by raverbashing »

benatkin wrote: post #47
t-3 wrote: post #41

Earlier quoted context omitted.

It requires forethought in many cases. Cat-initiated pipelines can be built iteratively in a natural fashion.

What's natural about cat on only one file? > Briefly, here's the collected wisdom on using cat: > The purpose of cat is to concatenate (or "catenate") files. If it's only one file, concatenating it with nothing at all is a waste of time, and costs you a process. The fact that the same thread ("but but but, I think it's cleaner / nicer / not that much of a waste / my privelege to waste processes!") springs up virtuall…

> What's natural about cat on only one file?

What's natural about using tar to create .tar.gz files instead of using them to archive files to tape?

"cat is to catenate" sounds like an argument from people that need to get out and smell the flowers once in a while

From 'man cat'

> cat – concatenate and print files

So if I want to print a file to stdout, I'll use cat, thanks.

Re: cat mario.nes | nc play-nes.org 4444

#69

Post by chungy »

ilyt wrote: post #63
chungy wrote: post #23

Earlier quoted context omitted.

It's a basic shell feature that every terminal user should know from day 1. Hardly a "trick".

Hardly "basic", natural assumption after knowing what say date > file does is assuming "there needs to be data source on left side, and target file on the right side Similiar with wc "There needs to be receiver program on the left side, and file on the right" The assumption from seeing it is "program on left, data on right" breaks that assumption completely. Honestly I don't think that in 15+ years I ever saw that in…

> Honestly I don't think that in 15+ years I ever saw that in the wild in any shell script

I've done it in shell scripts, very rarely interactively. In scripts, it sometimes just looks better defining that part first.

Wait until you see the redirect in the middle of program arguments. That's where it gets confusing. At least the redirect at the very beginning or very end of the line is easy. :)

Re: cat mario.nes | nc play-nes.org 4444

#70

Post by csdvrx »

pxc wrote: post #35
csdvrx wrote: post #33

Earlier quoted context omitted.

> I couldn't exactly say 'why now', but one guess is that macOS' explosion in popularity among developers and the relatively high popularity of desktop Linux within the developer community in particular have produced a generation of developers who appreciate the power and flexibility of the Unix command line but have also grown up with rich graphics on their computers from the start This so much! I mostly have 2 apps…

> I use notebooks for literate programming. It seems new? (as in, I don't think it was done in the 80s) I've done a bit of the same with Emacs via Org-mode and Babel, and I want to do more! Literate programming (and even literate DevOps!) is great. If it's picking up these days, I think that's wonderful. But the idea is indeed from 1984 (via Knuth)! So in that way, the resurgence of literate programming is the result…

> But the idea is indeed from 1984 (via Knuth)

Today I Learned :)

> I think some day more of a clean slate could be more flexible or easier to hack on. (Which is, for me, just a hunch— I've never worked on a terminal emulator myself.)

Not really. Please understand the old protocols (ex: sixels) as making you handle a required subset of the problems the new protocols (ex: kitty, etc) will also require you to handle (like storing the bitmap, invalidation, scrollback)

> But even then, I think that 'escape' would still be as much about doing justice to old ideas as being able to let go of old implementation details.

As long as I can get videos and plots along text in my terminal, I don't care if it's old or new: it just enables me to do more :)

Post reply on HN