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

The useful use of cat

mrmr.io

Post reply on HN
Print view View original

111–113 of 113 posts

Re: The useful use of cat

#111

Post by xelxebar »

Brian_K_White wrote: post #110
xelxebar wrote: post #88

Speaking of redirections... Here's another fut bit of lesser-known shell: f(){ cat;} I.e. You can bind redirections to function definitions that end up applying at call time.

what is a use of that vs f () { cat file; } Why make the shell open and read the file and pipe in to the cat process when cat would open and read the file itself directly? I guess the point is not cat but the redirection itself. ie, if the contents of f() were not simply cat, and maybe there was no handy place to put the filename within. Though, I think I still struggle to think up an example even then.

In this example? It's clearly useless and somewhat tongue-in-cheek. Redirecting stdout has some straightforward uses, e.g.

    log(){
        foo "$1"
        bar "$2"
     } >>logfile
Redirecting stdin is a little more subtle:

    contents(){
        maybeReadStdinA
        maybeReadStdinB
    }
where the first command to read stdin gets the contents of input and subsequent commands see nothing.

Re: The useful use of cat

#113

Post by oktoberpaard »

crdrost wrote: post #78
oktoberpaard wrote: post #75

Earlier quoted context omitted.

So `abc | ` would write the stdout of `abc` to the file? Meaning that if you forgot to mark your script as executable, you’ve now lost all your work? I think `abc > ` works perfectly fine and pipes don’t need to substitute this behavior.

That's the point is that it's up to the shell to make sure that you don't use your work if you do the wrong thing. Could be as simple as prompting you to make sure -- "Overwrite ? [yn]: " -- or could be something where the old inode is still available under some magic path for a few more commands, or could be that you use special syntax for the command, like "@ " is the stdin/stdout command form for the path... or it…

> That's the point is that it's up to the shell to make sure that you don't use your work if you do the wrong thing.

And how do you envision this would work inside a non-interactive Bash script? A shell option or environment variable that removes the confirmation step? With alternative syntax this would indeed work, because then it’s explicit.

> this one command says "I'm going to make your pipeline terminate, this step will be un-pipeable."

And your method would work like tee and not only write to the file, but also pass it on to the next step in the pipe? If not, the pipe still terminates at that point.

Post reply on HN