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

Cronic - A cure for Cron's chronic email problem

habilis.net

Post reply on HN
Print view View original

11–20 of 47 posts

Re: Cronic - A cure for Cron's chronic email problem

#11

Post by gcr »

there wrote: post #5

In a dozen or so years of administrating many different Unix machines, I've never had cron email be a problem and I get a few (useful) emails from various cron scripts every day. This interacts badly with many unix commands, which often send status info to standard out. Some commands have a quiet options, but that can turn off all error output too. Maybe it's that I've mostly been administrating BSD machines, and so…

I think it's an OSX-ism.

Most OSX devs I've seen treat their command-line utilities like their GUI utilities, with nice looking albeit chatty output.

These utilities then get released into the Linux world, where they often work without any modification.

Re: Cronic - A cure for Cron's chronic email problem

#12

Post by zobzu »

there wrote: post #5

In a dozen or so years of administrating many different Unix machines, I've never had cron email be a problem and I get a few (useful) emails from various cron scripts every day. This interacts badly with many unix commands, which often send status info to standard out. Some commands have a quiet options, but that can turn off all error output too. Maybe it's that I've mostly been administrating BSD machines, and so…

I don't quite think that its a "gnuism" to do that. They generally take a --color option which of course is off by default.

They did sometimes put the license everytime, a long time ago, but I don't see that anymore unless you ask the version or help.

Re: Cronic - A cure for Cron's chronic email problem

#13

Post by enneff »

there wrote: post #5

In a dozen or so years of administrating many different Unix machines, I've never had cron email be a problem and I get a few (useful) emails from various cron scripts every day. This interacts badly with many unix commands, which often send status info to standard out. Some commands have a quiet options, but that can turn off all error output too. Maybe it's that I've mostly been administrating BSD machines, and so…

You're bang on. Commands should do what you tell them and say nothing unless something unexpected occurred. (or, if you asked them to say something)

Cron isn't broken. It's chatty programs that are broken.

Re: Cronic - A cure for Cron's chronic email problem

#14

Post by jcampbell1 »

Since this is hackernews, can someone explain the rational behind putting the 2>&1 after the > ?

I know it works, but this reads to me: command > file.txt 2>&1 "write the output of command to file.txt and then map the error output to stdout"

It makes so much more sense to write: command 2>&1 > file.txt

There is clearly something in my brain that is confused about how redirection works.

Re: Cronic - A cure for Cron's chronic email problem

#16

Post by bodyfour »

jcampbell1 wrote: post #14

Since this is hackernews, can someone explain the rational behind putting the 2>&1 after the > ? I know it works, but this reads to me: command > file.txt 2>&1 "write the output of command to file.txt and then map the error output to stdout" It makes so much more sense to write: command 2>&1 > file.txt There is clearly something in my brain that is confused about how redirection works.

Think of it as saying "take fd 2 (stderr) and send it to the same place fd 1 is going now" So:

  $ command >file.txt 2>&1
first redirects fd=1 to file.txt and then has fd=2 go the same place. Where:

  $ command 2>&1 >file.txt
first has fd=2 go the original place stdout was and then redirect fd=1 only to file.txt. Usually not what you want. If you really wanted file.txt to get only the stdout while simultaneously sending what used to be stderr to stdout I think you'd have to use another file descriptor like:

  $ command 3>&1 >file.txt 2>&3
That is, save the original stdout as fd=3, redirect stdout, then make stderr go the same place fd=3 is going.

Re: Cronic - A cure for Cron's chronic email problem

#17

Post by jrockway »

jcampbell1 wrote: post #14

Since this is hackernews, can someone explain the rational behind putting the 2>&1 after the > ? I know it works, but this reads to me: command > file.txt 2>&1 "write the output of command to file.txt and then map the error output to stdout" It makes so much more sense to write: command 2>&1 > file.txt There is clearly something in my brain that is confused about how redirection works.

&1 refers to file descriptor 1. a>&b calls dup2(2) with oldfd=b and newfd=a. So ordering matters. STDOUT starts out attached to fd=1, but if you dup something else to fd=1, the association "fd 1 is STDOUT" is forgotten.

And that's exactly what usually happens; we replace fd 1 with one open to /dev/null, and then when we say 2>&1, that means to replace fd 2 (stderr) with whatever's at fd 1 (now /dev/null). When you write "command 2>&1 >/dev/null" that means something else, it means "send fd 2's output to what's currently at fd 1 (stdout)", and then "send what's currently at fd 1 to /dev/null". In other words, the source of a redirection is "by reference", but the destination of a redirection is "by value". If that makes any sense...

Re: Cronic - A cure for Cron's chronic email problem

#18

Post by tedunangst »

jcampbell1 wrote: post #14

Since this is hackernews, can someone explain the rational behind putting the 2>&1 after the > ? I know it works, but this reads to me: command > file.txt 2>&1 "write the output of command to file.txt and then map the error output to stdout" It makes so much more sense to write: command 2>&1 > file.txt There is clearly something in my brain that is confused about how redirection works.

Your second example puts stderr into the old stdout, then makes a new stdout go into the file. You have to redirect the files in the proper sequence to get the desired behavior. It is quirky if you don't expect it.

Re: Cronic - A cure for Cron's chronic email problem

#19

Post by shabble »

jcampbell1 wrote: post #14

Since this is hackernews, can someone explain the rational behind putting the 2>&1 after the > ? I know it works, but this reads to me: command > file.txt 2>&1 "write the output of command to file.txt and then map the error output to stdout" It makes so much more sense to write: command 2>&1 > file.txt There is clearly something in my brain that is confused about how redirection works.

I think this[1] is probably what you're looking for. If I'm understainding you correctly, the 2nd example will have mapped 2/stderr to &1 (stdout), before pointing stdout to the file, so you end up with both in the file.

[1] http://wiki.bash-hackers.org/syntax/redirection#multiple_red...

Post reply on HN