5 ms·

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

by chungy 4y ago

user3939382 4y ago
There is room for other interpretations, but I'd say if it's super common for people to not know something, which appears to describe this, it doesn't meet the definition of basic. I'd say "basic" shell knowledge is that commands or programs produce output which is where many stop and why it's common to use cat this way. In general I tend to err less on the side of "you're holding it wrong" gatekeeping in tech and when there's a common issue with something, blame the tech rather than the users. Maybe the way shell handles input, output, and redirection isn't intuitive and poorly designed. For those that already know there's an ego thing going on condescending to users who haven't learned as much that prevent honest or productive conversations on these topics.
- jolmg 4y ago
  > In general I tend to err less on the side of "you're holding it wrong" gatekeeping in tech That's not gatekeeping. I'm pretty sure anyone that points out `<` would like anyone that doesn't know it to become familiar with it. That's precisely why they mention it. To gatekeep would be for someone to say that people that aren't familiar with it shouldn't have access to the shell. No one is saying that. > There is room for other interpretations, but I'd say if it's super common for people to not know something, which appears to describe this, it doesn't meet the definition of basic. I'd say "basic" shell knowledge is that commands or programs produce output which is where many stop and why it's common to use cat this way. I feel that's the same bar as saying that knowing how to use a keyboard and mouse is not basic because most people just learn to use their phone's touch interface, given how there's now a lot of people that have a smartphone but not a computer. I don't mean in our circles, but in general. What's probably going on is that the boundary between basic and intermediate probably moves depending on increased adoption with different proportions of motivations. That is, most learners of the shell before were probably motivated to use it as their main interface, later one of their main interfaces, and now maybe there's a lot of people that need to run a command or 2 but don't really want to use it as an interface at all, so they never bother to learn beyond the most absolute minimum they need to. > Maybe the way shell handles input, output, and redirection isn't intuitive and poorly designed. I don't think being intuitive is always the most important criteria to something being well designed. Many things imply trade-offs, and for example if the average potential user values versatility over intuitiveness, and there's a tradeoff to be made between the 2, it's ok to not go for the intuitive option. That said, the redirection operators seem as intuitive as they can be. Arrow from file to command for input, arrow from command to file for output. What's a better alternative? To just remove file redirection features and leave piping? Processes will have inheritable file descriptors. Right now, the easiest and quickest way to make ad-hoc arbitrary arrangements of file descriptors is with the shell's file redirection features. Doing it on anything else (Python, C, whatever) requires more code. That seems like successful design to me.
  - scns 4y ago
    > It's a basic shell feature that every terminal user should know from day 1. Hardly a "trick". > That's not gatekeeping. I'm pretty sure anyone that points out `<` would like anyone that doesn't know it to become familiar with it. Can't see it being pointed out here. No snark intended.
    - jolmg 4y ago
      I'm not that person, so I don't know how they meant themselves to be interpreted. I interpret their comment as correcting the fact that file redirection is not a trick but a basic/core feature and emphasize that with their hyperbole of everyone knowing it from day one. I don't think they mean to dissuade people from using the shell. I don't think they mean their statement in the way of "if you didn't know this, you're not a real terminal user. Get out of here". Maybe I'm wrong and that was their motivation. I don't know. I was also interpreting user3939382's use of gatekeeping in the context of other similar comments not just the one they were directly replying to. That's probably my mistake.
t-3 4y ago
It requires forethought in many cases. Cat-initiated pipelines can be built iteratively in a natural fashion.
- benatkin 4y ago
  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 virtually every time the Award is posted is also Ancient Usenet Tradition. https://porkmail.org/era/unix/award https://porkmail.org/era/unix/award
  - raverbashing 4y ago
    > 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.
  - orra 4y ago
    Of course it's reasonable to use cat on one file. Why should it work for all 𝑛≥2 files, but suddenly fail at 𝑛=1? Despite the dismissive tone of the article you linked, if the overhead of one single process was remotely relevant, shell wouldn't be a good fit.
    - benatkin 4y ago
      Yes, it should and does work for 1. That doesn't mean it's a good use of cat.
  - ilyt 4y ago
    > 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 < file.log.{1..10} zcat
gpderetta 4y ago
I have been aware of this feature for 20 year. I have also 20 years of muscle memory that makes me type the redundant cat. If you are used to it, it is hard to avoid and the benefit as minuscule. Also sometimes it makes it easer to extend the pipeline
raverbashing 4y ago
"from day one", there's a lot of more important stuff to learn on day 1 than one "weird trick" that literally has no tangible benefits other than nerd sniping I have more important things to worry about than making the line less readable and less maintainable
ilyt 4y ago
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 < file "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" < file wc breaks that assumption completely. Honestly I don't think that in 15+ years I ever saw that in the wild in any shell script
- chungy 4y ago
  > 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. :)

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

by chungy 4y ago

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

There is room for other interpretations, but I'd say if it's super common for people to not know something, which appears to describe this, it doesn't meet the definition of basic. I'd say "basic" shell knowledge is that commands or programs produce output which is where many stop and why it's common to use cat this way. In general I tend to err less on the side of "you're holding it wrong" gatekeeping in tech and when there's a common issue with something, blame the tech rather than the users. Maybe the way shell handles input, output, and redirection isn't intuitive and poorly designed. For those that already know there's an ego thing going on condescending to users who haven't learned as much that prevent honest or productive conversations on these topics.

jolmg 4y ago
> In general I tend to err less on the side of "you're holding it wrong" gatekeeping in tech That's not gatekeeping. I'm pretty sure anyone that points out `<` would like anyone that doesn't know it to become familiar with it. That's precisely why they mention it. To gatekeep would be for someone to say that people that aren't familiar with it shouldn't have access to the shell. No one is saying that. > There is room for other interpretations, but I'd say if it's super common for people to not know something, which appears to describe this, it doesn't meet the definition of basic. I'd say "basic" shell knowledge is that commands or programs produce output which is where many stop and why it's common to use cat this way. I feel that's the same bar as saying that knowing how to use a keyboard and mouse is not basic because most people just learn to use their phone's touch interface, given how there's now a lot of people that have a smartphone but not a computer. I don't mean in our circles, but in general. What's probably going on is that the boundary between basic and intermediate probably moves depending on increased adoption with different proportions of motivations. That is, most learners of the shell before were probably motivated to use it as their main interface, later one of their main interfaces, and now maybe there's a lot of people that need to run a command or 2 but don't really want to use it as an interface at all, so they never bother to learn beyond the most absolute minimum they need to. > Maybe the way shell handles input, output, and redirection isn't intuitive and poorly designed. I don't think being intuitive is always the most important criteria to something being well designed. Many things imply trade-offs, and for example if the average potential user values versatility over intuitiveness, and there's a tradeoff to be made between the 2, it's ok to not go for the intuitive option. That said, the redirection operators seem as intuitive as they can be. Arrow from file to command for input, arrow from command to file for output. What's a better alternative? To just remove file redirection features and leave piping? Processes will have inheritable file descriptors. Right now, the easiest and quickest way to make ad-hoc arbitrary arrangements of file descriptors is with the shell's file redirection features. Doing it on anything else (Python, C, whatever) requires more code. That seems like successful design to me.
- scns 4y ago
  > It's a basic shell feature that every terminal user should know from day 1. Hardly a "trick". > That's not gatekeeping. I'm pretty sure anyone that points out `<` would like anyone that doesn't know it to become familiar with it. Can't see it being pointed out here. No snark intended.
  - jolmg 4y ago
    I'm not that person, so I don't know how they meant themselves to be interpreted. I interpret their comment as correcting the fact that file redirection is not a trick but a basic/core feature and emphasize that with their hyperbole of everyone knowing it from day one. I don't think they mean to dissuade people from using the shell. I don't think they mean their statement in the way of "if you didn't know this, you're not a real terminal user. Get out of here". Maybe I'm wrong and that was their motivation. I don't know. I was also interpreting user3939382's use of gatekeeping in the context of other similar comments not just the one they were directly replying to. That's probably my mistake.

t-3 4y ago

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

benatkin 4y ago
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 virtually every time the Award is posted is also Ancient Usenet Tradition. https://porkmail.org/era/unix/award https://porkmail.org/era/unix/award
- raverbashing 4y ago
  > 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.
- orra 4y ago
  Of course it's reasonable to use cat on one file. Why should it work for all 𝑛≥2 files, but suddenly fail at 𝑛=1? Despite the dismissive tone of the article you linked, if the overhead of one single process was remotely relevant, shell wouldn't be a good fit.
  - benatkin 4y ago
    Yes, it should and does work for 1. That doesn't mean it's a good use of cat.
- ilyt 4y ago
  > 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 < file.log.{1..10} zcat

gpderetta 4y ago

I have been aware of this feature for 20 year. I have also 20 years of muscle memory that makes me type the redundant cat. If you are used to it, it is hard to avoid and the benefit as minuscule. Also sometimes it makes it easer to extend the pipeline

raverbashing 4y ago

"from day one", there's a lot of more important stuff to learn on day 1 than one "weird trick" that literally has no tangible benefits other than nerd sniping I have more important things to worry about than making the line less readable and less maintainable

ilyt 4y ago

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 < file "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" < file wc breaks that assumption completely. Honestly I don't think that in 15+ years I ever saw that in the wild in any shell script

chungy 4y ago
> 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. :)