8 ms·

I think people here need to lighten up. I know we are all programmers, and we are sometimes portrayed as snobby and entitled, but we don't have to live up to th

by craigc 9y ago

I think people here need to lighten up. I know we are all programmers, and we are sometimes portrayed as snobby and entitled, but we don't have to live up to those stereotypes. I understand it's frustrating when a tool you use is expected to work a certain way and it doesn't. I understand it's even more frustrating when the output could change depending on the time of day. That doesn't mean it is our place to gang up on an open source tool that is designed to make our lives easier. I think we should be allowed to have some fun every once in a while, and this "gimme gimme gimme" easter egg is awesome. It seems the maintainers didn't realize that this easter egg was affecting a command that was designed to have a predictable output so that is the real issue here. Just a simple bug. If this was output on some help screen or something like that then no one would be complaining.

fhood 9y ago
BUT IT IS 12:30 AT NIGHT, THE CLIENT WAS PROMISED DELIVERY OF THIS FEATURE TWO WEEKS AGO, AND I CAN"T FIGURE WHY TF STDERR KEEPS OUTPUTTING GIMME GIMME GIMME!
- tener 9y ago
  Grep source code buddy.
- jacalata 9y ago
  This is a great example of a time when you should go home, get some sleep, and everything will work in the morning :)
  - azernik 9y ago
    Sometimes your servers are set to UTC.
bluesmoon 9y ago
The exit value is always 0 regardless of what's printed on stderr. If code parses stderr to determine error state instead of looking at the exit code, then it's doing unix wrong.
- fhood 9y ago
  Yeah, but you may be parsing standard error regardless.
  - scj 9y ago
    If evaluating stderr, the first step should be determining if a line is of a known format before treating it as an input. I'm not sure how well that'd work due to the lack of buffering. But I wouldn't want to go anywhere near stderr in production code.
    - deleted 9y ago
      [deleted]
a_lieb 9y ago
Maybe command line tools should have a --no-fun flag to disable all easter eggs. I'm only half kidding. It could be undocumented, but at least it gives you a way to ensure consistent output for tests if you stumble into a problem like this.
- jks 9y ago
  It could just check if the POSIX_ME_HARDER environment variable is defined. http://wiki.wlug.org.nz/POSIX_ME_HARDER http://wiki.wlug.org.nz/POSIX_ME_HARDER
cgmg 9y ago
I just don't see a reason to modify important program functionality for the sake of a joke. There are so many other ways to show a sense of humor without doing that.
- lomnakkus 9y ago
  Indeed and those ways have way less chance of causing accidental issues later down the road. Same deal with profanity, excessive vulgarity or calling out named persons, etc. in error messages. It's just unprofessional and it can cause all sorts of unforeseen "upstream" issues. (Even really surprising things like profane class names can cause issues because of things like reflection, etc.)
- Jedd 9y ago
  The obvious counter to this is to ask what software you've written that many of us use several times a day, every day, and that you refrained from adding any humour to. Free software almost always has the 'this is provided as is' caveat, and offers access to the source for you to review to ensure it's fit for purpose, so the whole 'This did something I don't approve of' complaint is a bit weak. Further, the 'important program functionality' may not apply in the case of running the program in an atypical way - that is, without parameters - at a certain time of day.
rapind 9y ago
"we are sometimes portrayed as snobby and entitled" Huh? That's not at all the stereotype I see associated with programmers. More like the opposite. In fact, a gag like this is much more in line with the stereotype I'm familiar with.
- azhenley 9y ago
  Exactly what I was thinking when I read the stackexchange post. This is just enforcing the stereotype that programmers can't be taken seriously ("bro culture"?).
  - rapind 9y ago
    I wouldn't accuse them of being "brogrammers" though either. This just sounds like an appreciation for obscure references, play on words, maybe a bit of mild mischief? Not at all what I picture when I hear "bro culture". I'd call it "nerd humour" maybe (being a nerd myself, I feel like I can get away with the insult)?
deleted 9y ago
[deleted]

by craigc 9y ago

fhood 9y ago

BUT IT IS 12:30 AT NIGHT, THE CLIENT WAS PROMISED DELIVERY OF THIS FEATURE TWO WEEKS AGO, AND I CAN"T FIGURE WHY TF STDERR KEEPS OUTPUTTING GIMME GIMME GIMME!

tener 9y ago
Grep source code buddy.
jacalata 9y ago
This is a great example of a time when you should go home, get some sleep, and everything will work in the morning :)
- azernik 9y ago
  Sometimes your servers are set to UTC.

bluesmoon 9y ago

The exit value is always 0 regardless of what's printed on stderr. If code parses stderr to determine error state instead of looking at the exit code, then it's doing unix wrong.

fhood 9y ago
Yeah, but you may be parsing standard error regardless.
- scj 9y ago
  If evaluating stderr, the first step should be determining if a line is of a known format before treating it as an input. I'm not sure how well that'd work due to the lack of buffering. But I wouldn't want to go anywhere near stderr in production code.
  - deleted 9y ago
    [deleted]

a_lieb 9y ago

Maybe command line tools should have a --no-fun flag to disable all easter eggs. I'm only half kidding. It could be undocumented, but at least it gives you a way to ensure consistent output for tests if you stumble into a problem like this.

jks 9y ago
It could just check if the POSIX_ME_HARDER environment variable is defined. http://wiki.wlug.org.nz/POSIX_ME_HARDER http://wiki.wlug.org.nz/POSIX_ME_HARDER

cgmg 9y ago

I just don't see a reason to modify important program functionality for the sake of a joke. There are so many other ways to show a sense of humor without doing that.

lomnakkus 9y ago
Indeed and those ways have way less chance of causing accidental issues later down the road. Same deal with profanity, excessive vulgarity or calling out named persons, etc. in error messages. It's just unprofessional and it can cause all sorts of unforeseen "upstream" issues. (Even really surprising things like profane class names can cause issues because of things like reflection, etc.)
Jedd 9y ago
The obvious counter to this is to ask what software you've written that many of us use several times a day, every day, and that you refrained from adding any humour to. Free software almost always has the 'this is provided as is' caveat, and offers access to the source for you to review to ensure it's fit for purpose, so the whole 'This did something I don't approve of' complaint is a bit weak. Further, the 'important program functionality' may not apply in the case of running the program in an atypical way - that is, without parameters - at a certain time of day.

rapind 9y ago

"we are sometimes portrayed as snobby and entitled" Huh? That's not at all the stereotype I see associated with programmers. More like the opposite. In fact, a gag like this is much more in line with the stereotype I'm familiar with.

azhenley 9y ago
Exactly what I was thinking when I read the stackexchange post. This is just enforcing the stereotype that programmers can't be taken seriously ("bro culture"?).
- rapind 9y ago
  I wouldn't accuse them of being "brogrammers" though either. This just sounds like an appreciation for obscure references, play on words, maybe a bit of mild mischief? Not at all what I picture when I hear "bro culture". I'd call it "nerd humour" maybe (being a nerd myself, I feel like I can get away with the insult)?

deleted 9y ago

[deleted]