>What do you need Savedday and prevday for? checking if the day has changed? what do you mean? I don't need to store anything in memory to check if day has changed? ...being a script that you prolly want to change the second (or at least close to) you set the pollinterval to a second or smth close... you really dont want to run the whole loop every run?
the test for padding being the test if I have to prepend a "0" to the day?
Youre right about not calling date too much... Let's see if I can make sense of your thinking
Wrong way thinking - instead of calling the script every second to check whether sth. changed (just launching bash and opening the file has considerable overhead) you could fire the script once a day (using at, cron or the crippled systemd mechanism) or run it in an infinite loop and sleep yourself (hour, then minute and finally secondwise) towards the daybreak.
> the test for padding being the test if I > have to prepend a "0" to the day? Yes, not required if you pass a dash separated format to date.
Btw: you know "cal", do you? (though it prints in a matrix)
Sth. else you could do to improve performance is to not ask "date" about every day in the month. You basically have to do that once to get the localized weekday strings but then (oh sursprise there's a pretty constant development which you could apply on a loop
01 WD[1] 02 WD[2] 03 WD[3] 04 WD[4] ... where WD is an array (Mon Tue Wed ...) and WD[1] is Tue because Jan 1. 2013 is a tuesday
Hmmm, well, the text will still have to be changed exactly at 00:00:00 to the next date... and afaik there is no way to inform the shell from outside to 'please update this label atm'?
I too figured for some time about a actual sane way to do this but gave up.
>>Sth. else you could do to improve performance is to not ask "date" about every day in the month. That is true... I guess I could try and see if bash don't drive me insane before I have something better
Yes, I know cal... so we should bring in cal and date now?
I know I could calculate the weekdays... however, that would require I first have the exact number of days in that month for the loop... right now I just run it 31 times and check if there is a valid weekday for that date...............as this code is only run once a day I really didn't think it had to be that optimized
...however as you said even opening a file for reading every second causes too much overhead, well, *shrugs*, I think a script like this is stupid anyways, should be clear from the comments
> and afaik there is no way to inform the shell from outside to 'please update this label atm'?
A FiFo driven label will update with the fifo. You write into that file, you get an update. Cron, anacron or at can perform the update "on the spot", a damon script can use a shrinking sleep loop "towards the spot"
> Yes, I know cal... so we should bring in cal and date now? No, was just a suggestion for a prefabbed calendar (but not being horizontal)
> require I first have the exact number of days in that month 31 special 31 30 31 30 31 31 30 31 30 31
special: !(year % 1000) -> 29 (1000, 2000, 3000 - frankly, you can skip that !(year % 100) -> 28 (1900, 2000, 2100 - frankly, ... --> year % 4 ? 28 : 29
> I think a script like this is Welcome in poor little Robbies iHateMyselfLand ... People seem to like it, so just twist your mind to tweak it a bit. I know that you can do that - and that you just want to hear such by your self insulting :-P
> I can make no sense outta that special case Feb has usually 28 days, except when the year is dividably by 4, then it's 29 - that's not very complex
However, the system also says that if the year is dividable by 100 (thus also by 4) it's only 29days if it is also dividable by 400 (ie Feb 2000 had 29 days, Feb 2100 will have only 28, despite 2100 is dividable by 4 - it however does not matter for we're all dead then
date --date="today"
date --date="yestergay"
and also:
date --date="4 days ago"
date --date="next week" ... and whatnot
Also try to avoid process calls ("date") by eg:
DATE="`date +%e:%m::%Y`"
YEAR="${__DATE##*:}"
DAY="${__DATE%%:*}"
MONTH=${__DATE#*:}
MONTH=${MONTH%:*}
If you pass
date --date="${YEAR}-${MONTH}-${I}" +%a
you can omit the [test] for padding demands
checking if the day has changed? what do you
mean? I don't need to store anything in
memory to check if day has changed?
...being a script that you prolly want
to change the second (or at least close to)
you set the pollinterval to a second or
smth close... you really dont want to
run the whole loop every run?
the test for padding being the test if I
have to prepend a "0" to the day?
Youre right about not calling date too
much... Let's see if I can make sense
of your thinking
> the test for padding being the test if I
> have to prepend a "0" to the day?
Yes, not required if you pass a dash separated format to date.
Btw: you know "cal", do you? (though it prints in a matrix)
Sth. else you could do to improve performance is to not ask "date" about every day in the month.
You basically have to do that once to get the localized weekday strings but then (oh sursprise
01 WD[1] 02 WD[2] 03 WD[3] 04 WD[4] ...
where WD is an array (Mon Tue Wed ...) and WD[1] is Tue because Jan 1. 2013 is a tuesday
exactly at 00:00:00 to the next date... and afaik
there is no way to inform the shell from outside
to 'please update this label atm'?
I too figured for some time about a actual sane
way to do this but gave up.
>>Sth. else you could do to improve performance is to not ask "date" about every day in the month.
That is true... I guess I could try and see if
bash don't drive me insane before I have something
better
Yes, I know cal... so we should bring in cal
and date now?
I know I could calculate the weekdays... however,
that would require I first have the exact number
of days in that month for the loop... right now
I just run it 31 times and check if there is a
valid weekday for that date...............as this
code is only run once a day I really didn't think
it had to be that optimized
...however as you said even opening a file for
reading every second causes too much overhead,
well, *shrugs*, I think a script like this is
stupid anyways, should be clear from the comments
to 'please update this label atm'?
A FiFo driven label will update with the fifo. You write into that file, you get an update.
Cron, anacron or at can perform the update "on the spot", a damon script can use a shrinking sleep loop "towards the spot"
> Yes, I know cal... so we should bring in cal and date now?
No, was just a suggestion for a prefabbed calendar (but not being horizontal)
> require I first have the exact number of days in that month
31 special 31 30 31 30 31 31 30 31 30 31
special:
!(year % 1000) -> 29 (1000, 2000, 3000 - frankly, you can skip that
!(year % 100) -> 28 (1900, 2000, 2100 - frankly, ...
--> year % 4 ? 28 : 29
> I think a script like this is
Welcome in poor little Robbies iHateMyselfLand ...
People seem to like it, so just twist your mind to tweak it a bit.
I know that you can do that - and that you just want to hear such by your self insulting :-P
If you got questions, just ask.
label and see what I get.
well I can make no sense outta that special
case atm (well, it's 9 in tha morning).
Häh?!?! You actually think this script was
/MY/ idea? nononononono... plus, I really
really really dislike bash
fkn 9000 ways to write a if....
Feb has usually 28 days, except when the year is dividably by 4, then it's 29 - that's not very complex
However, the system also says that if the year is dividable by 100 (thus also by 4) it's only 29days if it is also dividable by 400 (ie Feb 2000 had 29 days, Feb 2100 will have only 28, despite 2100 is dividable by 4 - it however does not matter for we're all dead then
I btw took a look at 'advanced usage' in
the wiki... I now understand where you where
coming from w/ all the optimization
well, I guess I at some point fix it up
to work w/ fifo when I begin to understand
it more.
What I dislike is the name of it and your discriptions in it!
it's not.