at the end of the day I had my cake and ate it, too:
site="www.debian.com"
site="www.google.fr"
###
dt=$(date +%Y%m%d%H%M%S.%N);
whois > "${site}_${dt}_whois.log" 2>&1
sudo strace --output "${site}_${dt}_strace_ping.log" ping "${site}" -c
4 > "${site}_${dt}_ping.log" 2>&1
ls -l
On 27/12/2023 07:45, Greg Wooledge wrote:
Yeah, even on Debian systems where ping isn't setuid root, it still seems
to need special capabilities that strace interferes with, or isn't
allowed to attach to, or something.
$ /usr/sbin/getcap /usr/bin/ping
/usr/bin/ping cap_net_raw=ep
It is still
On 2023-12-25 18:05, Jeffrey Walton wrote:
On Mon, Dec 25, 2023 at 8:43 PM Charlie Gibbs wrote:
On Mon Dec 25 12:01:59 2023 "Andrew M.A. Cater" wrote:
Yes - that's the obvious way. I set my machines to /etc/UTC (or
/etc/GMT) and leave them there. No daylight saving time, no offsets -
all
On Wed, Dec 27, 2023 at 12:39:26AM +, Albretch Mueller wrote:
> I am getting an "Operation not permitted" error while strace tries to
> attach to that pid:
>
> "strace: attach: ptrace(PTRACE_SEIZE, 52527): Operation not permitted"
>
>
> $ ping www.google.fr -c 4 &
> pid=$!
>
On 12/26/23, Greg Wooledge wrote:
> If you want to launch a SIMPLE BACKGROUND PROCESS (note the SIMPLE here,
> this is IMPORTANT), and then strace it while it runs, you'd do it like
> this:
>
> ping www.google.fr -c 4 &
> pid=$!
> strace -p "$pid"
> wait "$pid"
I am getting an
Hello,
On Sun, Dec 24, 2023 at 11:05:53PM +, Albretch Mueller wrote:
> Why would %S be in the range second (00..60), instead of
> (00..59)?:
Remember what seems like years ago in this thread when I said that
if we're being pedantic, this is more complicated than you think,
and you scoffed
On Tue, Dec 26, 2023 at 06:31:19PM +, Albretch Mueller wrote:
> I think I am getting close to where I need to with this (am I?):
>
> $ bash -c 'ping www.google.fr -c 4 &'; echo "Caller PID: $$"; strace -p $$
I don't understand what you're trying to do here. Is this an
oversimplified
On 12/26/23, Greg Wooledge wrote:
> On Tue, Dec 26, 2023 at 02:57:54PM +, Albretch Mueller wrote:
>> 1) how do you set up the process to be straced as a parameter? Something
>> like:
>> prx="echo hello"
>> logfile="file.txt"
>> #
>> strace "${prx}" 2>"${logfile}"
>> ls -l "${logfile}"; wc -l
On Tue, Dec 26, 2023 at 02:57:54PM +, Albretch Mueller wrote:
> 1) how do you set up the process to be straced as a parameter? Something
> like:
> prx="echo hello"
> logfile="file.txt"
> #
> strace "${prx}" 2>"${logfile}"
> ls -l "${logfile}"; wc -l "${logfile}"; cat "${logfile}"
Why? This
On 12/26/23, Thomas Schmitt wrote:
> man strace says:
> -o filename Write the trace output to the file filename rather
> than to stderr.
>
> So strace normally directs its output to stderr. That's file descriptor 2.
> You can redirect it by the "2>file" gesture of the shell:
>
Hi,
Albretch Mueller wrote:
> But how do you strace a program saving the output (of the stracing)
> in a logfile while you also save that program's output without making
> it part of the stracing?
man strace says:
-o filename Write the trace output to the file filename rather
On 12/25/23, Greg Wooledge wrote:
> If you want to see what a process is doing, there's strace. It can
> even be told to follow all the children of a process (strace -f).
But how do you strace a program saving the output (of the stracing)
in a logfile while you also save that program's output
On 26/12/23 10:05, Jeffrey Walton wrote:
I don't know why Z was used instead of UTC or GMT. Probably to save
space, and save some ink if a schedule was printed.
ZULU time is military, primarily NATO. The world is divided up into
alphabetic time zones using the NATO phonetic alphabet with a
Jeff writes:
> I don't know why Z was used instead of UTC or GMT.
https://en.wikipedia.org/wiki/Coordinated_Universal_Time#Time_zones
--
John Hasler
j...@sugarbit.com
Elmwood, WI USA
On Mon, Dec 25, 2023 at 8:43 PM Charlie Gibbs wrote:
>
> On Mon Dec 25 12:01:59 2023 "Andrew M.A. Cater" wrote:
>
> > Yes - that's the obvious way. I set my machines to /etc/UTC (or
> > /etc/GMT) and leave them there. No daylight saving time, no offsets -
> > all logs unambiguous. That's why
On Mon Dec 25 12:01:59 2023 "Andrew M.A. Cater" wrote:
> Yes - that's the obvious way. I set my machines to /etc/UTC (or
> /etc/GMT) and leave them there. No daylight saving time, no offsets -
> all logs unambiguous. That's why (worldwide) radio logkeeping is/was
> in UTC. If you're travelling
On Mon, Dec 25, 2023 at 03:35:04PM +, Albretch Mueller wrote:
> On 12/21/23, Greg Wooledge wrote:
> > So... this is interesting. Apparently timedatectl doesn't simply look
> > at the target of /etc/localtime. There's a DELAY before the value is
> > correctly reported. This tells me that
On 12/21/23, Greg Wooledge wrote:
> So... this is interesting. Apparently timedatectl doesn't simply look
> at the target of /etc/localtime. There's a DELAY before the value is
> correctly reported. This tells me that timedatectl is in communication
> with some process (perhaps PID 1, I don't
On Mon, Dec 25, 2023 at 12:24:55AM +, Albretch Mueller wrote:
> On 12/25/23, David Wright wrote:
> > On Sun 24 Dec 2023 at 23:05:53 (+), Albretch Mueller wrote:
> >> On 12/18/23, Max Nikulin wrote:
> ...
> >> Why would %S be in the range
> >> second (00..60), instead of (00..59)?:
> >
>
On Sun, 2023-12-24 at 23:05 +, Albretch Mueller wrote:
[...]
> Why would %S be in the range second (00..60), instead of (00..59)?:
To support leap seconds [1].
[1] https://en.wikipedia.org/wiki/Leap_second
--
Tixy
On Mon, Dec 25, 2023 at 12:24:55AM +, Albretch Mueller wrote:
> I am trying to use it in an
> obvious human readable way right in the file names.
With that restriction, "always use UTC" is going to be your best path
forward. It should be possible to convert a well-chosen human-readable
On 12/25/23, David Wright wrote:
> On Sun 24 Dec 2023 at 23:05:53 (+), Albretch Mueller wrote:
>> On 12/18/23, Max Nikulin wrote:
...
>> Why would %S be in the range
>> second (00..60), instead of (00..59)?:
>
> Leap seconds—see the example already in the thread:
>
On Sun 24 Dec 2023 at 23:05:53 (+), Albretch Mueller wrote:
> On 12/18/23, Max Nikulin wrote:
> > Timestamp format you have chosen is ambiguous.
> >
> > TZ=Europe/Berlin date -d '@1698539400' '+%Y%m%d%H%M%S'
> > 20231029023000
> >
> > TZ=Europe/Berlin date -d '@1698543000' '+%Y%m%d%H%M%S'
> >
On 12/18/23, Max Nikulin wrote:
> Timestamp format you have chosen is ambiguous.
>
> TZ=Europe/Berlin date -d '@1698539400' '+%Y%m%d%H%M%S'
> 20231029023000
>
> TZ=Europe/Berlin date -d '@1698543000' '+%Y%m%d%H%M%S'
> 20231029023000
>
> You had issues with setting time and timezone, so '+%s' may
On Fri, Dec 22, 2023 at 09:15:27AM +0700, Max Nikulin wrote:
> On 20/12/2023 22:04, Greg Wooledge wrote:
> > The key point here is that you don't STORE these human-readable time
> > strings anywhere. You simply *produce* them on demand, using the
> > epoch time values that you *do* store.
>
>
On Thu, Dec 21, 2023 at 07:31:31PM -0600, David Wright wrote:
> Bear in mind that I was explaining my use of "all-UTC machine".
> Were you to construct such a beast, I think the first thing you
> might set, actively, is the RTC. You wouldn't just assume that
> it was already set to UTC.
>
> What
On 20/12/2023 22:04, Greg Wooledge wrote:
The key point here is that you don't STORE these human-readable time
strings anywhere. You simply *produce* them on demand, using the
epoch time values that you *do* store.
Greg, I agree to almost everything you write, however I believe that
text
On Thu 21 Dec 2023 at 07:15:12 (-0500), Greg Wooledge wrote:
> On Wed, Dec 20, 2023 at 10:52:33PM -0600, David Wright wrote:
> > Sorry for the synecdoche, but I think it expresses the comprehensive
> > setting of UTC across the entirety of the computer and its operating
> > system, from the RTC,
On Thu 21 Dec 2023 at 06:38:55 (+0100), to...@tuxteam.de wrote:
> On Wed, Dec 20, 2023 at 10:52:33PM -0600, David Wright wrote:
> > On Wed 20 Dec 2023 at 08:37:46 (+0100), to...@tuxteam.de wrote:
> > > On Wed, Dec 20, 2023 at 12:00:29AM -0600, David Wright wrote:
> > >
> > > [...]
> > >
> > > >
On 12/21/23 16:31, Greg Wooledge wrote:
On Thu, Dec 21, 2023 at 03:34:49PM -0500, gene heskett wrote:
unforch it does not create them and in my recent experience it may run but
does not work without being able to log.
That would be a bug, given that this stats directory is apparently
On 12/21/23 04:22, to...@tuxteam.de wrote:
I used to work in a shop Back Then (TM) (roughly Windows 3.1). We did
C programs for a living and had a mix of Windows boxes and Linux boxes.
Windows boxes were "naive" and had local time. We had a time zone
with summer and winter time.
On time
to...@tuxteam.de (12023-12-21):
> I've sometimes the impression that desktop environments are losing
> the concept pf multi-user operating systems and are regreding to
> something like Windows 95.
Desktop environment and the “modern” applications designed for them had
already lost the ability to
On Thu, Dec 21, 2023 at 03:34:49PM -0500, gene heskett wrote:
> unforch it does not create them and in my recent experience it may run but
> does not work without being able to log.
That would be a bug, given that this stats directory is apparently
optional. (It logs through syslog just fine
On 12/21/23 15:04, Greg Wooledge wrote:
On Thu, Dec 21, 2023 at 02:51:50PM -0500, gene heskett wrote:
can us see your /etc/ntpsec/ntp.conf? And, do you have a
/var/log/ntpsec subdir ownwd by ntpsec:ntpsec?
unicorn:~$ ls -ld /var/log/ntpsec /etc/ntpsec/ntp.conf
ls: cannot access
On Thu, Dec 21, 2023 at 02:51:50PM -0500, gene heskett wrote:
> can us see your /etc/ntpsec/ntp.conf? And, do you have a
> /var/log/ntpsec subdir ownwd by ntpsec:ntpsec?
unicorn:~$ ls -ld /var/log/ntpsec /etc/ntpsec/ntp.conf
ls: cannot access '/var/log/ntpsec': No such file or directory
On 12/21/23 07:38, Greg Wooledge wrote:
On Thu, Dec 21, 2023 at 06:08:26AM +, Albretch Mueller wrote:
and what would the systemd way to synch the RTC (Real Time Clock) and
UTC?
I don't understand this question at all. The system clock value is
normally written to the RTC as a backup
On Thu, Dec 21, 2023 at 10:36:06PM +0700, Max Nikulin wrote:
> I have another guess. systemd-timedated is activated on demand and reads
> /etc/localtime. It exits a half of a minute later. Perhaps second command
> caused start of new process since the old one was dead already.
Hmm. OK, logs do
On Thu, Dec 21, 2023 at 11:04:35AM -0500, Jeffrey Walton wrote:
[...]
> I think you will find a fair number of Unix & Linux servers set a
> default timezone. I sometimes have to set TZ in my bashrc because of
> an unexpected default timezone. Or that's been my experience at the
> GCC Compile
On Thu, Dec 21, 2023 at 12:51 AM wrote:
>
> On Thu, Dec 21, 2023 at 10:30:42AM +0700, Max Nikulin wrote:
>
> [...]
>
> > See systemd-timedated.service(8) and org.freedesktop.timedate1(5)
> >
> > busctl introspect org.freedesktop.timedate1 /org/freedesktop/timedate1
> > # Values are stripped
> >
On 21/12/2023 19:38, Greg Wooledge wrote:
On Thu, Dec 21, 2023 at 06:08:26AM +, Albretch Mueller wrote:
Why is it I am noticing a 14 seconds difference on my computer
(booted with a Debian Live DVD)?
Have you executed any commands setting time since boot? Does the
difference remain
On Thu, Dec 21, 2023 at 09:08:09AM -0500, Dan Ritter wrote:
> Max Nikulin wrote:
> > I am not going to discuss code posted by Albretch, despite it has serious
> > issues from my point of view. This is a response to Greg.
> >
> > On 20/12/2023 22:04, Greg Wooledge wrote:
> > > The default time
Max Nikulin wrote:
> I am not going to discuss code posted by Albretch, despite it has serious
> issues from my point of view. This is a response to Greg.
>
> On 20/12/2023 22:04, Greg Wooledge wrote:
> > The default time zone has nothing to do with systemd, nor with any other
> > init system
On Thu, Dec 21, 2023 at 06:08:26AM +, Albretch Mueller wrote:
> and what would the systemd way to synch the RTC (Real Time Clock) and
> UTC?
I don't understand this question at all. The system clock value is
normally written to the RTC as a backup when the system shuts down.
Then, the RTC
On Thu, Dec 21, 2023 at 07:15:12AM -0500, Greg Wooledge wrote:
[...]
> Again, there isn't any agency here. The RTC is just a resource that
> the system can use, once per boot, to get things started. It could
> be set correctly, or incorrectly. It could be set to local time, as
> was common
On Wed, Dec 20, 2023 at 10:52:33PM -0600, David Wright wrote:
> Sorry for the synecdoche, but I think it expresses the comprehensive
> setting of UTC across the entirety of the computer and its operating
> system, from the RTC, through /etc/timezone and /etc/localhost, to
> the users' sessions. By
On Thu, Dec 21, 2023 at 06:08:26AM +, Albretch Mueller wrote:
> On 12/21/23, Max Nikulin wrote:
> > as a primary source. For majority using systemd
>
> and what would the systemd way to synch the RTC
https://en.wikipedia.org/wiki/Network_Time_Protocol
> (Real Time Clock)
The "real time
On 12/21/23, Max Nikulin wrote:
> as a primary source. For majority using systemd
and what would the systemd way to synch the RTC (Real Time Clock) and
UTC? Why is it I am noticing a 14 seconds difference on my computer
(booted with a Debian Live DVD)?
$ readlink /etc/localtime
On Thu, Dec 21, 2023 at 10:30:42AM +0700, Max Nikulin wrote:
[...]
> See systemd-timedated.service(8) and org.freedesktop.timedate1(5)
>
> busctl introspect org.freedesktop.timedate1 /org/freedesktop/timedate1
> # Values are stripped
> org.freedesktop.DBus.Properties interface -
[...]
>
On 21/12/2023 11:37, David Wright wrote:
On Wed 20 Dec 2023 at 07:43:51 (+), Albretch Mueller wrote:
$ cat /etc/localtime
TZif2UTCTZif2UTC
UTC0
Take care. That's a binary file. /etc/timezone is the text one.
That is why
readlink /etc/localtime
or
ls -l /etc/localtime
as a
On Wed, Dec 20, 2023 at 10:52:33PM -0600, David Wright wrote:
> On Wed 20 Dec 2023 at 08:37:46 (+0100), to...@tuxteam.de wrote:
> > On Wed, Dec 20, 2023 at 12:00:29AM -0600, David Wright wrote:
> >
> > [...]
> >
> > > Yes, I'm guessing that the OP is in my timezone, as just a few of
> > > their
On Wed 20 Dec 2023 at 08:37:46 (+0100), to...@tuxteam.de wrote:
> On Wed, Dec 20, 2023 at 12:00:29AM -0600, David Wright wrote:
>
> [...]
>
> > Yes, I'm guessing that the OP is in my timezone, as just a few of
> > their previous posts have -5/-6 offsets. But most are +0, and
> > I wonder whether
On Wed 20 Dec 2023 at 07:43:51 (+), Albretch Mueller wrote:
> On 12/20/23, David Wright wrote:
> > To be fair to the OP, there was no official "script", but just some code:
> > https://lists.debian.org/debian-user/2023/12/msg00894.html
> > which I pasted into /tmp/lbrtchx.sh. The filename
I am not going to discuss code posted by Albretch, despite it has
serious issues from my point of view. This is a response to Greg.
On 20/12/2023 22:04, Greg Wooledge wrote:
The selection of the computer's default time zone by its owner is not
in ANY way related to the computer's geographic
Greg Wooledge (12023-12-20):
> Huh? None of this makes any sense.
I salute you for your patience and excellent message.
Just a few remarks:
> Learn how time works. Then rewrite everything.
Fortunately, we do not have to handle relativistic issues à la
“meanwhile at the other side of the
On Wed, Dec 20, 2023 at 01:12:35PM +, Albretch Mueller wrote:
> The only way I see is for the running computer on "exposed mode" to
> check via systemd if the time zone has been changed
Huh? None of this makes any sense. First of all, the system's default
time zone only changes if a user
On Wed, Dec 20, 2023 at 01:12:35PM +, Albretch Mueller wrote:
> On 12/20/23, to...@tuxteam.de wrote:
> > On Wed, Dec 20, 2023 at 07:15:20AM -0500, Greg Wooledge wrote:
> >> On Wed, Dec 20, 2023 at 07:43:51AM +, Albretch Mueller wrote:
> >> > I do see the good in what you are suggesting
On 12/20/23, to...@tuxteam.de wrote:
> On Wed, Dec 20, 2023 at 07:15:20AM -0500, Greg Wooledge wrote:
>> On Wed, Dec 20, 2023 at 07:43:51AM +, Albretch Mueller wrote:
>> > I do see the good in what you are suggesting to me and I will have to
>> > include time zones in the file names as well
On Wed, Dec 20, 2023 at 07:15:20AM -0500, Greg Wooledge wrote:
> On Wed, Dec 20, 2023 at 07:43:51AM +, Albretch Mueller wrote:
> > I do see the good in what you are suggesting to me and I will have to
> > include time zones in the file names as well and deal with the
> > possible cases
On Wed, Dec 20, 2023 at 07:43:51AM +, Albretch Mueller wrote:
> I do see the good in what you are suggesting to me and I will have to
> include time zones in the file names as well and deal with the
> possible cases (someone working at Charles de Gaulle Airport in
> Paris/France boards a
On 12/20/23, David Wright wrote:
> To be fair to the OP, there was no official "script", but just some code:
> https://lists.debian.org/debian-user/2023/12/msg00894.html
> which I pasted into /tmp/lbrtchx.sh. The filename suffix was a mere
> convenience to make emacs colour the code and tidy
On Wed, Dec 20, 2023 at 12:00:29AM -0600, David Wright wrote:
[...]
> Yes, I'm guessing that the OP is in my timezone, as just a few of
> their previous posts have -5/-6 offsets. But most are +0, and
> I wonder whether the OP ran this code on an all-UTC machine.
> (IDK whether their using gmail
On Mon 18 Dec 2023 at 14:12:12 (-0500), Greg Wooledge wrote:
> On Mon, Dec 18, 2023 at 12:35:29PM -0600, David Wright wrote:
> > OK, I tried running it (attached). What should it show?
>
> That the OP is confused about many things.
>
> > # date --help
>
> No shebang. But the script uses bash
On Mon, Dec 18, 2023 at 12:35:29PM -0600, David Wright wrote:
> OK, I tried running it (attached). What should it show?
That the OP is confused about many things.
> # date --help
No shebang. But the script uses bash syntax. When executed FROM BASH,
the script will "work" because bash will
On Mon 18 Dec 2023 at 06:02:48 (+), Albretch Mueller wrote:
> On 12/18/23, David Wright wrote:
> > Another problem in what you posted is that you sometimes run date
> > in your local timezone (generally for the "now" times), but you
> > append +00:00 as the timezone for those --date strings
On Mon, Dec 18, 2023 at 08:17:21AM -0500, Greg Wooledge wrote:
> On Mon, Dec 18, 2023 at 02:07:14PM +0100, to...@tuxteam.de wrote:
> > I'm still amazed the OP hasn't understood that "date" can output
> > custom formats -- and that it's not always possible to parse back
> > a date in some custom
On Mon, Dec 18, 2023 at 02:07:14PM +0100, to...@tuxteam.de wrote:
> I'm still amazed the OP hasn't understood that "date" can output
> custom formats -- and that it's not always possible to parse back
> a date in some custom format into a meaningful timestamp.
unicorn:~$ date +"On this the %dth
On Mon, Dec 18, 2023 at 07:16:25AM -0500, Greg Wooledge wrote:
[...]
> If you wreck this by putting the wrong timezone offset on your
> human-readable times [...]
If you lie about your time zone you might come in too late for
your train :-)
> In addition to that, a case has already been shown
On Mon, Dec 18, 2023 at 06:02:48AM +, Albretch Mueller wrote:
> On 12/18/23, David Wright wrote:
> > Another problem in what you posted is that you sometimes run date
> > in your local timezone (generally for the "now" times), but you
> > append +00:00 as the timezone for those --date strings
On 12/18/23, David Wright wrote:
> Another problem in what you posted is that you sometimes run date
> in your local timezone (generally for the "now" times), but you
> append +00:00 as the timezone for those --date strings that you
> construct from several substrings. You need to use UT
On Mon 18 Dec 2023 at 01:11:26 (+), Albretch Mueller wrote:
> On 12/18/23, David Wright wrote:
> > When you write dt00=$(date +%Y%m%d%H%M%S)
> > that's /your/ format, not coreutils'.
>
> I (erroneously?) thought coreutils was maintaining Linux date, so if
> they tell you on their --help
On 18/12/2023 06:00, Albretch Mueller wrote:
On 12/17/23, Andy Smith wrote:
how on earth would that not always produce an accurate duration?
All this paranoia, but in computer time you trust?
Falsehoods programmers believe about time
On 12/18/23, David Wright wrote:
> When you write dt00=$(date +%Y%m%d%H%M%S)
> that's /your/ format, not coreutils'.
I (erroneously?) thought coreutils was maintaining Linux date, so if
they tell you on their --help instructions to use certain options
(including cobbling them together to your
On Sun 17 Dec 2023 at 23:00:37 (+), Albretch Mueller wrote:
> On 12/17/23, Andy Smith wrote:
> > All this paranoia, but in computer time you trust?
> > Falsehoods programmers believe about time
> > https://gist.github.com/timvisee/fcda9bbdff88d45cc9061606b4b923ca
>
> and how does
On 12/17/23, Andy Smith wrote:
>> how on earth would that not always produce an accurate duration?
>
> All this paranoia, but in computer time you trust?
> Falsehoods programmers believe about time
> https://gist.github.com/timvisee/fcda9bbdff88d45cc9061606b4b923ca
and how does my
Well, yes, "date --date= ..." doesn't work in the way I would wish
("logically" think about it):
https://www.gnu.org/software/coreutils/manual/html_node/General-date-syntax.html
parsing any format allowed by date:
On Sun 17 Dec 2023 at 15:28:58 (+), Albretch Mueller wrote:
> On 12/17/23, to...@tuxteam.de wrote:
> > On Sun, Dec 17, 2023 at 10:12:11AM +, Albretch Mueller wrote:
> >> dt00=$(date +%Y%m%d%H%M%S)
> Actually, my basic idea is if you can encode a date using formatting
> options this
On Sun, Dec 17, 2023 at 03:28:58PM +, Albretch Mueller wrote:
> On 12/17/23, Greg Wooledge wrote:
> > On Sun, Dec 17, 2023 at 10:12:11AM +, Albretch Mueller wrote:
> >> ... after some long processing for which seconds would be exact
> >> enough, then I would like to get the seconds
Hello,
On Sun, Dec 17, 2023 at 03:28:58PM +, Albretch Mueller wrote:
> On 12/17/23, Andy Smith wrote:
> > subtracting one epoch time from another doesn't always produce
> > an accurate duration.
[…]
> how on earth would that not always produce an accurate duration?
All this paranoia, but
On Sun, Dec 17, 2023 at 03:28:58PM +, Albretch Mueller wrote:
> On 12/17/23, to...@tuxteam.de wrote:
[...]
> > You wouldn't expect bash to intuit such a crooky arithmetic as
> > Gregorian datetime [...]
> Actually, my basic idea is if you can encode a date using formatting
> options this
On Sun, Dec 17, 2023 at 03:28:58PM +, Albretch Mueller wrote:
> On 12/17/23, to...@tuxteam.de wrote:
> > On Sun, Dec 17, 2023 at 10:12:11AM +, Albretch Mueller wrote:
> >> dt00=$(date +%Y%m%d%H%M%S)
> >> echo "// __ \$dt00: |${dt00}|"
> >>
> >> ... after some long processing for which
On 12/17/23, to...@tuxteam.de wrote:
> On Sun, Dec 17, 2023 at 10:12:11AM +, Albretch Mueller wrote:
>> dt00=$(date +%Y%m%d%H%M%S)
>> echo "// __ \$dt00: |${dt00}|"
>>
>> ... after some long processing for which seconds would be exact
>> enough, then I would like to get the seconds elapsed
On Sun, Dec 17, 2023 at 10:12:11AM +, Albretch Mueller wrote:
> ... after some long processing for which seconds would be exact
> enough, then I would like to get the seconds elapsed since dt00
Are you working in bash, or sh? It makes a difference here.
Others have already mentioned using
* 2023-12-17 10:58:28+, Andy Smith wrote:
> On Sun, Dec 17, 2023 at 10:12:11AM +, Albretch Mueller wrote:
>> you get seconds in dt00 and dt02 and then the difference. You can't
>> go: $(( dt02 - dt00 )) because bash Arithmetic is 10-based.
>
> Why don't you just get the time as epoch time
On Sun, Dec 17, 2023 at 10:58:28AM +, Andy Smith wrote:
[...]
> ¹ Pedants at this point may feel the need to launch launch into a
> sub-thread about how subtracting one epoch time from another doesn't
> always produce an accurate duration. I can't stop you, but it won't
> be news to me.
On Sun, Dec 17, 2023 at 10:12:11AM +, Albretch Mueller wrote:
> dt00=$(date +%Y%m%d%H%M%S)
> echo "// __ \$dt00: |${dt00}|"
>
> ... after some long processing for which seconds would be exact
> enough, then I would like to get the seconds elapsed since dt00, like
> this:
>
> dt02=$(date
Hello,
On Sun, Dec 17, 2023 at 10:12:11AM +, Albretch Mueller wrote:
> dt00=$(date +%Y%m%d%H%M%S)
> echo "// __ \$dt00: |${dt00}|"
>
> ... after some long processing for which seconds would be exact
> enough, then I would like to get the seconds elapsed since dt00, like
> this:
>
>
dt00=$(date +%Y%m%d%H%M%S)
echo "// __ \$dt00: |${dt00}|"
... after some long processing for which seconds would be exact
enough, then I would like to get the seconds elapsed since dt00, like
this:
dt02=$(date +%Y%m%d%H%M%S)
echo "// __ \$dt02: |${dt02}|"
you get seconds in dt00 and dt02 and
87 matches
Mail list logo
