From: owner-colug-digest@bopper.wcbe.org (colug-digest)
To: colug-digest@bopper.wcbe.org
Subject: colug-digest V3 #283
Reply-To:
Sender: owner-colug-digest@bopper.wcbe.org
Errors-To: owner-colug-digest@bopper.wcbe.org
Precedence: bulk
Reply-To: colug@bopper.wcbe.org
colug-digest Sunday, July 16 2000 Volume 03 : Number 283
Re: [COLUG] grep without blank lines
Re: [COLUG] grep without blank lines
Re: [COLUG] grep without blank lines
programming question
Re: [COLUG] programming question
Re: [COLUG] programming question
leap year calculation ++ danger
Re: [COLUG] leap year calculation detail improvements
Re: [COLUG] leap year calculation ++ danger
Re: [COLUG] Everyone should use CVS for source control, it is easy and it is free
Re: [COLUG] leap year calculation ++ danger
Re: [COLUG] Everyone should use CVS for source control, it is easy and it is free
mo' leap year calculation improvements
----------------------------------------------------------------------
Date: Sat, 15 Jul 2000 23:27:57 -0400
From: Edson Freeman <edson@freeman.net>
Subject: Re: [COLUG] grep without blank lines
... | grep -v "^$"
should get rid of blank lines (^=start of line, $=end of line, so ^$=empty
line)
you might need egrep instead though...
At 06:47 PM 7/15/00 -0400, you wrote:
>Okay, I'm drawing a complete blank here. I want to grep a config file so that
>I leave out all of the comments (lines that begins with "#" ):
>
>more config.file | grep -v ^#
>
>This works fine, but now I get blank lines in addition to the text I'm looking
>for. So how do I exclude blank lines as well? I've tried silly stuff like;
>
>more config.file | grep -v ^# | grep -v ^" "
>
>But that doesn't work... I know I read about this
>somewhere, but for the life of me I can't find it. TIA
>
>Barry
------------------------------
Date: Sun, 16 Jul 2000 01:09:57 -0400 (EDT)
From: Jim Wildman <jim@rossberry.com>
Subject: Re: [COLUG] grep without blank lines
grep -v -e "^#" -e "^$" <filename>
(skip the more and the pipe and do it all at once)
- --------------------------------------------------------------------------
Jim Wildman Senior Consultant, 3X Corporation
jim@rossberry.com jim.wildman@3x.com www.3x.com
(513)587-3647
On Sat, 15 Jul 2000, Edson Freeman wrote:
> ... | grep -v "^$"
>
> should get rid of blank lines (^=start of line, $=end of line, so ^$=empty
> line)
> you might need egrep instead though...
>
------------------------------
Date: Sun, 16 Jul 2000 05:56:42 -0400
From: "Barry J. Grundy" <bgrundy@columbus.rr.com>
Subject: Re: [COLUG] grep without blank lines
Thanks, everyone. The "^$" is what I was looking for. I know I've seen it
before. Sometimes it's hard to get all these details packed into yer brain.
I'm not a sysadmin or anything, so I do alot of reading and learning of Linux
without *general* practical application. Unfortunatley it's like a foreign
language... what you don't use, you lose. Thanks again for the prompt replies.
Edson Freeman wrote:
<<... | grep -v "^$"
should get rid of blank lines (^=start of line, $=end of line, so ^$=empty
line)
you might need egrep instead though...>>
Jim Wildman wrote:
<<grep -v -e "^#" -e "^$" <filename>
(skip the more and the pipe and do it all at once)>>
Barry
On Sat, 15 Jul 2000, Barry J. Grundy wrote:
> Okay, I'm drawing a complete blank here. I want to grep a config file so that
> I leave out all of the comments (lines that begins with "#" ):
<snip>
------------------------------
Date: Sun, 16 Jul 2000 10:41:21 -0400
From: "Todd Fencl" <fencl12@email.msn.com>
Subject: programming question
Does anyone know the math algorithm for leap year?
TIA
- --
Todd Fencl < fencl12@email.msn.com >
Why do I do this? Three reasons:
the pay is good,
the scenery changes,
and they let me use explosives.
------------------------------
Date: Sun, 16 Jul 2000 11:00:24 -0400
From: Judd Montgomery <judd@engineer.com>
Subject: Re: [COLUG] programming question
I have some code that looks like this:
int days_in_month[]={31,28,31,30,31,30,31,31,30,31,30,31
};
if ((date->tm_year%4 == 0) &&
!(((date->tm_year+1900)%100==0) && ((date->tm_year+1900)%400!=0))
) {
days_in_month[1]++;
}
That is, every year divisible by 4 is a leap year, except for centuries
are not leap years, except every 400 years, which is a leap year. Thats
why we had one in 2000.
Judd
Todd Fencl wrote:
>
> Does anyone know the math algorithm for leap year?
> TIA
> --
> Todd Fencl < fencl12@email.msn.com >
>
> Why do I do this? Three reasons:
> the pay is good,
> the scenery changes,
> and they let me use explosives.
>
> -
> COLUG mailing list tag line: =======================================
> Want to know more: http://static.colug.net/
------------------------------
Date: Sun, 16 Jul 2000 15:14:50 +0000
From: jep@columbus.rr.com
Subject: Re: [COLUG] programming question
Todd Fencl asked:
> Does anyone know the math algorithm for leap year?
Thanks for asking a question that I know the answer to!
In English, the algorithm is:
There is a leap year every four years,
except every hundred years,
except every four hundred years.
(Furthermore, as far as which year of four (or a hundred or
four hundred years is in question, we are talking about the
year which is evenly divisible by the cycle)
In C:
#define IsLeap(year) ((year)%4==0 && ((year)%100!=0 ||
(year)%400==0))
This year was the rare once every four hundred years, leap year.
A simpler algorithm which is valid for years 1901 thorugh 2099
inclusive is:
#define IsLeap(year) ((year)%4==0)
This is what I use. It is valid from the beginning of UNIX time,
until long after I will be dead.
For length of month calculation (that you didn't ask for) I use:
int nonLeapYearMonthLength[]={31,28,31,30,31,30,31,31,30,31,30,31};
int leapYearMonthLength []={31,29,31,30,31,30,31,31,30,31,30,31};
((year%4) ? nonLeapYearMonthLength : leapYearMonthLength)[month]
where year is 1901 to 2099 inclusive and
month is 1 (January) through 12 (December) inclusive
Jim Prior
------------------------------
Date: Sun, 16 Jul 2000 15:18:56 +0000
From: jep@columbus.rr.com
Subject: leap year calculation ++ danger
Somebody suggested:
> I have some code that looks like this:
...
> days_in_month[1]++;
Beware the Ides of March and the increment operator.
Jim Prior
------------------------------
Date: Sun, 16 Jul 2000 15:30:23 +0000
From: jep@columbus.rr.com
Subject: Re: [COLUG] leap year calculation detail improvements
Earlier I suggested:
> In C:
>
> #define IsLeap(year) ((year)%4==0 && ((year)%100!=0 ||
> (year)%400==0))
I forgot to mention that the year is the whole year,
e.g., 2000, not just the last two digits, e.g. 00.
> int nonLeapYearMonthLength[]={31,28,31,30,31,30,31,31,30,31,30,31};
> int leapYearMonthLength []={31,29,31,30,31,30,31,31,30,31,30,31};
const ... would have been better and I also had an out and out bug,
forgetting to put in the dummy [0]==0 element for easy
1 through 12 inclusive subscripts:
const int nonLeapYearMonthLength[]={0,31,28,31,30,31,30,31,31,30,31,30,31};
const int leapYearMonthLength []={0,31,29,31,30,31,30,31,31,30,31,30,31};
Jim Prior
------------------------------
Date: Sun, 16 Jul 2000 11:35:02 -0400
From: Judd Montgomery <judd@engineer.com>
Subject: Re: [COLUG] leap year calculation ++ danger
Whats wrong with this? What does it have to do with the ides of March?
jep@columbus.rr.com wrote:
>
> Somebody suggested:
>
> > I have some code that looks like this:
> ...
> > days_in_month[1]++;
>
> Beware the Ides of March and the increment operator.
>
> Jim Prior
>
> -
> COLUG mailing list tag line: =======================================
> Want to know more: http://static.colug.net/
------------------------------
Date: 16 Jul 2000 11:55:43 -0400
From: Bob Koss <koss@objectmentor.com>
Subject: Re: [COLUG] Everyone should use CVS for source control, it is easy and it is free
Yes, CVS is good. We've used it for a 250,000 line C++ project.
The headache we've run into was when you want to move a file to a
different directory. CVS can't track that.
The is important in C++ and Java programming where the
namespace/packge structure of the application follows the directory
structure on the filesystem.
- --
Robert Koss, Ph.D. | Object Mentor, Inc. | Tel: (800) 338-6716
Senior Consultant | 14619 N Somerset Cr | Fax: (847) 918-1023
koss@objectmentor.com | Green Oaks IL 60048 | www.objectmentor.com
------------------------------
Date: Sun, 16 Jul 2000 15:59:35 +0000
From: jep@columbus.rr.com
Subject: Re: [COLUG] leap year calculation ++ danger
Judd Montgomery wrote:
> Whats wrong with this?
Nothing if the code is executed only once.
(It would have been good to document such a limitation.)
However, when such code is borrowed for applications
that use the code more than once, the results could be surprising.
The increments are likely to be cumulative.
In the suggested code:
if ((date->tm_year%4 == 0) &&
!(((date->tm_year+1900)%100==0) && ((date->tm_year+1900)%400!=0))
) {
days_in_month[1]++;
}
after a year leap has been hit, days_in_month[1] is likely to
be >28 for subsequent non-leap year calculations.
It is also likely to be >29 for subsequent leap years.
> What does it have to do with the ides of March?
They are both calendar related dangers.
I was just trying to be witty.
Julius Caesar only died once,
programmers (especially myself) never cease to stop tripping
over calendar calculations.
Jim Prior
------------------------------
Date: Sun, 16 Jul 2000 16:11:30 +0000
From: jep@columbus.rr.com
Subject: Re: [COLUG] Everyone should use CVS for source control, it is easy and it is free
Bob Koss wrote:
> Yes, CVS is good. We've used it for a 250,000 line C++ project.
>
> The headache we've run into was when you want to move a file to a
> different directory. CVS can't track that.
How do you cope with this?
Jim Prior
------------------------------
Date: Sun, 16 Jul 2000 16:23:25 +0000
From: jep@columbus.rr.com
Subject: mo' leap year calculation improvements
Somebody suggested:
> if ((date->tm_year%4 == 0) &&
> !(((date->tm_year+1900)%100==0) && ((date->tm_year+1900)%400!=0))
Where tm_year is the number of years since 1900.
The 400 year cycle indeed needs the +1900 offset for the calculation
to be correct, so (date->tm_year+1900)%400!=0 is fine.
The 4 year cycle doesn't need the +1900,
so date->tm_year%4 == 0 is OK.
The 100 year cycle also doesn't need the +1900 offset.
(date->tm_year+1900)%100==0 is nonetheless correct.
The above code is correct. There can be further improvements
to make it easier for novices to understand.
Consistency aids comprehension.
Neither the %4 or %100 calculation need the +1900 offset,
yet one of them uses the +1900 offset and the other doesn't.
It would be better for both of them to use the +1900 offset
or for both of them to avoid the +1900 offset.
Since the %400 calculation must have the +1900 offset,
for the sake of consistency, it would be best that all of them
use it. I.e.,
if ((date->tm_year+1900)%4==0
&& ((date->tm_year+1900)%100!=0 || (date->tm_year+1900)%400==0))
Having the same calculation repeated over and over is an
opportunity to forget to do it the same way each time.
It also clutters up the essence of the leap year calculation.
Hence
{
int year=date->tm_year+1900;
if (year%4==0 && (year%100!=0 || year%400==0))
...
}
clarifies the code. It probably makes optimization easier
for the compiler, although this is a much much lesser concern.
Clarity of code is mighty important and should be a passion.
Comments anyone?
Improving code is an interative thing. After you THINK you have
it right, set it aside for a while and scrutinize it yet again
later. What improvements have _I_ missed?
We are sitting around a campfire. Someone starts a story.
Everyone takes turns adding to it. It's your turn.
For some REAL fun, given a time in GMT, figure out whether those of us
in the eastern US are in daylight or standard time.
Jim Prior
------------------------------
End of colug-digest V3 #283
***************************
COLUG-digest footer =================================================
Want to know more: http://static.colug.net/