I have a simple shell script set up to capture images every X seconds. For some reason the value of X seems to double each time through the loop.
#!/bin/bash
# basic setup for time-lapse
SECONDS=1
while true
do
DATE=$(date +"%Y-%m-%d_%H%M%S")
filename=${DATE}_img.jpg
# fswebcam -r 1280x720 --timestamp "%a %Y-%b-%d %H:%M (%Z)" /home/pi/JPGS/$filename
date
echo "pausing for ${SECONDS} seconds"
sleep $SECONDS
date
echo "====="
done
This is the output I get. The value of SECONDS is not manipulated inside the loop, so I'm confused with what is happening here. Also, the original interval was 30 seconds, I changed it to 1 seconds for testing purposes, and the date calls are for testing/debugging too.
Sun Mar 3 17:51:57 CST 2019
pausing for 1 seconds
Sun Mar 3 17:51:58 CST 2019
=====
Sun Mar 3 17:51:58 CST 2019
pausing for 2 seconds
Sun Mar 3 17:52:00 CST 2019
=====
Sun Mar 3 17:52:00 CST 2019
pausing for 4 seconds
Sun Mar 3 17:52:04 CST 2019
=====
Sun Mar 3 17:52:04 CST 2019
pausing for 8 seconds
Sun Mar 3 17:52:12 CST 2019
=====
Sun Mar 3 17:52:12 CST 2019
pausing for 16 seconds
Sun Mar 3 17:52:28 CST 2019
=====
Sun Mar 3 17:52:28 CST 2019
pausing for 32 seconds
Sun Mar 3 17:53:00 CST 2019
=====
Sun Mar 3 17:53:00 CST 2019
pausing for 64 seconds
Sun Mar 3 17:54:04 CST 2019
=====
Sun Mar 3 17:54:04 CST 2019
pausing for 128 seconds
What am I missing here?
This is under a Raspberry Pi
Pick a different name for $SECONDS.
$SECONDS is a built-in shell variable. It expands to the number of seconds since the shell was started.
From the Bash manual:
'SECONDS'
This variable expands to the number of seconds since the shell was
started. Assignment to this variable resets the count to the value
assigned, and the expanded value becomes the value assigned plus the
number of seconds since the assignment.
$SECONDS is actually a special Bash Variable for timing the number of seconds a script has been running. Because it's a timer, it increments automatically every second without the script doing anything. Just change the variable name to something else and you should be fine.
Related
Basically, I want to take a time, and day of the week, in UTC+8, and adjust the datetime object to a given UTC offset, within bash, I don't have any code to show because I'm not sure how to start attempting this in the first place honestly
(I'm writing a custom script for a friend who lives in UTC+8 and want to make the input as easy as possible for them, basically they just give it a time in their timezone, and a day of the week, and it'll tell them what date and time that'll be in a different timezone, for an overarching purpose)
For a reference, look at the section 1 of the manual page for "date":
In your shell, just type: man 1 date
or see the online man page:
https://man7.org/linux/man-pages/man1/date.1.html
One way is to parse the date into the number of seconds since epoch (since 1970), and then convert that number of seconds into the format you want:
For example:
$ date +%s --date='2022-12-27 11:30:17 +008'
1672140137
$ date +%c --date='#1672140137'
Tue 27 Dec 2022 06:22:17 AM EST
or you could also convert to ISO format then back to local time
$ date -Iseconds --date='TZ="GMT" 2022-12-22 11:33:44 +08'
2022-12-21T22:33:44-05:00
$ date --date='2022-12-21T22:33:44-05:00'
Wed 21 Dec 2022 10:33:44 PM EST
I hope this helps you get started with some ideas for converting to/from different timezones.
Also, to help with user input, you can show the current month calendar using cal
$ cal
December 2022
Su Mo Tu We Th Fr Sa
1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30 31
$ date --date='Fri 08:30'
Fri 30 Dec 2022 08:30:00 AM EST
In the above example, I specified "Fri 08:30" which gets set to the next Friday at 08:30 in the morning for my local timezone.
I have a log file that contains output from
/bin/df -h| /usr/bin/grep p_log|/usr/bin/awk -v date="$(date)" '{print date,$4,$5}'
which is later sent out using mailx. It arrives in my PC's Outlook as desired with a line per entry and displays with a line end in cat -A:
Wed Mar 16 10:29:01 EDT 2022 291G 95%$
Wed Mar 16 11:29:01 EDT 2022 290G 95%$
Wed Mar 16 12:29:02 EDT 2022 290G 95%$
Adding an additional field to the awk - $6 happens to be the last field in the df output - still displays the same with cat:
Wed Mar 16 11:29:01 EDT 2022 290G 95%$
Wed Mar 16 12:29:02 EDT 2022 290G 95%$
Wed Mar 16 13:29:01 EDT 2022 290G 95% /.p_log$
Wed Mar 16 14:29:02 EDT 2022 290G 95% /.p_log$
But lines are now concatenated when read in Windows/Outlook:
Wed Mar 16 10:29:01 EDT 2022 291G 95%
Wed Mar 16 11:29:01 EDT 2022 290G 95%
Wed Mar 16 12:29:02 EDT 2022 290G 95%
Wed Mar 16 13:29:01 EDT 2022 290G 95% /.p_log Wed Mar 16 14:29:02 EDT 2022 290G 95% /.p_log
I found another post at explains that cat -e (which I have tried, and is encompassed by -A) "displays Unix line endings (\n or LF) as $ and Windows line endings (\r\n or CRLF) as ^M$". Why then are two lines that display the same control characters in cat being displayed differently in Windows/how best to get the line feed back when printing $6 without messing up the formatting of the log? I presume there are more hidden control characters that cat -A does not display, i.e. that 'all' does not actually mean all.
Further testing: There are header and footer lines - all ending in the same "$"- that do not get concatenated. I tried attaching the content from the end of one of the concatenated lines to a header line and that would indicate that it's the "/" that's causing the problem, but only for mailx.
Looks like I've been barking up the wrong tree; not sure if I should delete this question and open a new one for mailx?
Adding two spaces to the start of each line - https://stackoverflow.com/a/22098987/8823709 - resolved the issue. I don't know why, but it did.
I have 4 tmux sessions present. When I use
tmux list-sessions
It shows the sessions with some numbers in the brackets. That is:
t128_1: 1 windows (created Thu Jul 19 12:20:44 2018) [71x38]
t128_2: 1 windows (created Thu Jul 19 12:20:54 2018) [71x38]
t3: 1 windows (created Thu Jul 19 12:19:59 2018) [143x40]
t6: 1 windows (created Thu Jul 19 12:20:27 2018) [71x38]
What does the number [AxB] mean? And why t3 session has a different value than the others? Thanks for any explanation.
That's the size of the terminal (143 columns, 40 rows) the last time a client attached to the session.
I am using git-bash on a Windows system.
The Windows clock shows local time, but inside git-bash everything is in GMT time:
$ date
Mon Mar 31 16:08:57 GMT 2014
Also setting TZ will not change things:
$ TZ="Europe/Berlin" date
Mon Mar 31 16:09:01 GMT 2014
Similarly all times it git log are GMT only.
Is there a way to set the correct timezone in git-bash?
On Windows the TZ variable seems to work differently.
To get the German timezone you have to write:
TZ=GST-1GDT date
If you set it to some "invalid" value like "Europe/Berlin" it will default to GMT.
The same seems to happen on my system when TZ is not set at all.
With the above setting I get Thu Apr 17 16:23:23 GDT 2014 which is not exactly the same as Thu Apr 17 16:23:23 CEST 2014, but at least the time looks right.
Same problem here in my script. Windows was showing 15:47 and the "date" command in gitbash was answering 13:47.
export TZ="CEST-2"
This fixed the problem for me. I wanted Paris time.
I want to detect if I'm in winter or summer time. My current approach is:
if date +%Z | grep -e CET -e EST; then
# I'm in winter time
else
# I'm in summer time
fi
which have obvious drawback as you have to know all the timezone names.
I don't now if this exactly answers your question, but it gives you some tools to help you better understand and test whats going on.
You can use date and environment-var TZ to help you.
So for example I live in Sweden so my timezone location is Europe/Stockholm. So in the winter date +%Z reports CET and in the summer CEST. The nice thing is that you could specify timezone for the environment of a specific command, then you could specify what date the date command should present. So by summing up this you could do any of the following:
TZ=Europe/Stockholm date +%Z # CET or CEST depending of when its run
TZ=Europe/Stockholm date --date=20170101 +%Z # CET
TZ=Europe/Stockholm date --date=20170601 +%Z # CEST
TZ=CET date --date=20170101 +%Z # CET
TZ=CET date --date=20170601 +%Z # CEST, note that its auto adjusted to CEST
If you instead want the time difference to UTC you could use lowercase-z:
TZ=Europe/Stockholm date +%z # +0100 or +0200 depending of when its run
TZ=Europe/Stockholm date --date=20170101 +%z # +0100
TZ=Europe/Stockholm date --date=20170601 +%z # +0200
TZ=CET date --date=20170101 +%z # +0100
TZ=CET date --date=20170601 +%z # +0200
NOTE: You can not use TZ=CEST or TZ=ULFR since that is not a valid TZ:
TZ=CEST date --date=20170101 +%z # +0000
TZ=ULFR date --date=20170101 +%z # +0000
crontab example:
We run our servers on UTC but some of the jobs run by crontab needs to be run at a specified wallclock (CET/CEST) time. So since we want the jobs to be run one hour later in the winter (the clock is put one hour forward in the summer witch makes it reach a specified UTC-time one hour earlier in the summer than in the winter) we do sleep before the actual job is executed in the winter.
We want the job /whatever/bin/foobar to be run at 04:15 wallclock time every day. But since cron runs on UTC the job needs to be set one hour earlier for CET and two hours earlier for CEST. That would be the same as always running the command two hours earlier but sleeping for an hour during winter-time. Ex crontab row:
15 2 * * * [ `TZ=CET date +\%Z` = CET ] && sleep 3600; /whatever/bin/foobar
If you have a nicer solution to this issue, then please feel free to advice me!
Perl to the rescue:
if perl -e 'exit ((localtime)[8])' ; then
echo winter
else
echo summer
fi
In the northern hemisphere, in regions with daylight savings, then it's active when the offset is greater than the offset is in January. In southern hemisphere time zones, daylight savings is active when the offset is greater than that in July.
You can discover the offsets in January and July, as well as now:
OFF_1=$(date -d '1 Jan' +%z)
OFF_7=$(date -d '1 Jul' +%z)
OFF_NOW=$(date +%z)
If your zone doesn't have daylight savings, all three will be the same (this year). In any case, we can make two comparisons, one for the northern hemisphere and one for the southern; if the current offset is greater than either one of those, then the current zone is in daylight savings time:
if test $OFF_NOW -gt $OFF_1 || test $OFF_NOW -gt $OFF_7
then
# I'm in summer time
else
# I'm in winter time
fi
The assumption here is that all regions that observe daylight savings have their transition somewhere between July and January. That's true in all zones, as far as I know. The only case where this might fail is in a year where the winter offset changes (such 1940 in the UK, when the subsequent winter was on GMT+1).
for info :
zdump -v Europe/Paris | grep 2020
gives this :
Europe/Paris Sun Mar 29 00:59:59 2020 UT = Sun Mar 29 01:59:59 2020 CET isdst=0 gmtoff=3600
Europe/Paris Sun Mar 29 01:00:00 2020 UT = Sun Mar 29 03:00:00 2020 CEST isdst=1 gmtoff=7200
Europe/Paris Sun Oct 25 00:59:59 2020 UT = Sun Oct 25 02:59:59 2020 CEST isdst=1 gmtoff=7200
Europe/Paris Sun Oct 25 01:00:00 2020 UT = Sun Oct 25 02:00:00 2020 CET isdst=0 gmtoff=3600