Re: difference in seconds between two formatted dates ...
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 throughout. What difference would that make when all I need is a time difference? The way I understand such time format issues is that it needs to just be the same in the two dates. >> ANyway, my hack around it wasn't effortful at >> all. > > I don't know whether you're referring to something already posted, > or some new script written in the wake of what you've read here. That silly hack which lousy bash script I posted within its test case lbrtchx
Re: difference in seconds between two formatted dates ...
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 instructions to use certain options > (including cobbling them together to your heart's content) and you are > telling them you are using their format and how, they should be able > to parse that string. You can prettyprint a timedate with date any way you care to, but scanning a timedate with --date requires care. It's safest if you give it a string in one of its own built-in formats. You appear to be expecting your second date command to somehow guess the format you used in the first command, which obviously can't happen. 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 throughout. > ANyway, my hack around it wasn't effortful at > all. I don't know whether you're referring to something already posted, or some new script written in the wake of what you've read here. Cheers, David.
Re: Why is /var/lib/apt/lists not in /var/cache?
>> That was a typo. it's `/var/cache/plocate/plocate.db`, sorry. > My plocate.db is in /var/lib/plocate/, as is bookworm's. > Is that changing in the future? Hmm... I could swear that I saw it in /var/cache but every machine I look at has it in /var/lib, indeed. [ GNU locate puts its DB in `/var/cache/locate/`, apparently, OTOH. ] Anyway, thanks for all the suggestions. From what I can tell, there is no strong reason to put the lists in `/var/lib` rather than `/var/cache`. I suspect this is mostly a historical accident (at some point, erasing `/var/lib/apt/lists` caused problems because that dir wasn't automatically recreated if missing, so you'd have to `mkdir` manually as well as create the lock inside of it). Stefan
Re: Problem with /var/cache/apt/archives/
On Sun, Dec 17, 2023 at 09:42:19PM -0500, Cindy Sue Causey wrote: > dpkg-deb: error: failed to read archive > '/var/cache/apt/archives/dpkg_1.22.1_amd64.deb': Too many levels of > symbolic links > dpkg: error: parsing file '/var/lib/dpkg/status' near line 2 package 'dpkg': > 'Version' field value '': version string is empty > > Too many levels of symbolic links... I've seen that over the years > while breaking my system. So I visually inspected the apt/archives > directory. Whatever debootstrap is seeing as too many symlinks is not > visually apparent. Well, why not *show us*? Here's one way to produce that error message: unicorn:~$ mkdir /tmp/subdir unicorn:~$ ln -s link /tmp/subdir/link unicorn:~$ ls /tmp/subdir/link/foo ls: cannot access '/tmp/subdir/link/foo': Too many levels of symbolic links unicorn:~$ ls -ld /tmp/subdir/link lrwxrwxrwx 1 greg greg 4 Dec 17 22:00 /tmp/subdir/link -> link For your error message, you'd want to look at ls -ld /var /var/cache /var/cache/apt /var/cache/apt/archives I think we can assume that / isn't a circular symlink, but if you want to throw in / as well, it wouldn't hurt. You mentioned debootstrap, so it's not clear to me whether the error is coming from your regular directories, or from a /var/cache/apt/archives that's inside a chroot somewhere. If it's coming from a chroot, then that's where you'll want to look.
Re: Problem with /var/cache/apt/archives/
On 12/16/23, Pocket wrote: > > On 12/16/23 08:45, Stephen P. Molnar wrote: >> I am running Bookworm on my Debian computer. When I installed the OS I >> selected the option for separate /var etc, and selected the default >> sizes of the partitions. >> >> When I ran sudo apt update this morning I received the error message: >> >> E: You don't have enough free space in /var/cache/apt/archives/ >> >> Can I increase the size of the /var partition on the ssd without >> having to reinstall the system? >> >> Thanks in advance. >> > You can bind mount more space from another partition or create a directory > on another file system and sylmink it to /var/cache/apt/archives/ > > Maybe something like this > > On a volume that has sufficient space > > where is some where on your filesystem > > mkdir /archives > > cp -var /var/cache/apt/archives/ /archives/ > > or > > mv -v /var/cache/apt/archives/ /archives/ > > then clean up /var/cache/apt/archives > rm -rf /var/cache/apt/archives > > ln -vs /archives /var/cache/apt/archives > > or > |mount --bind |/archives /var/cache/apt/archives > > Add the bind mount to the end of /etc/fstab > > /var/cache/apt/archives||/archives|none bind,nofail| tl;dr I've stuck with this a couple hours now purely k/t less than optimal brain functioning. I've been comparing symlink versus "mount -B" on apt/archives during debootstraps because I've had bad fails in the past. Ultimately, it finally boiled down to debootstrap(dot)log documenting: dpkg-deb: error: failed to read archive '/var/cache/apt/archives/dpkg_1.22.1_amd64.deb': Too many levels of symbolic links dpkg: error: parsing file '/var/lib/dpkg/status' near line 2 package 'dpkg': 'Version' field value '': version string is empty Too many levels of symbolic links... I've seen that over the years while breaking my system. So I visually inspected the apt/archives directory. Whatever debootstrap is seeing as too many symlinks is not visually apparent. In the past, I've seen directories present an infinitum linear path if you keep clicking that same named directory each time you open the next one. That is not the case today. I've debootstrapped a few times today. The various failed logs changed slightly. Diff showed that several /bin packages are missing (see further below if bored). Cpio is one. One log but not all show a weird problem that looks like something inserted an extra "/" in front of debootstrap's /var directory during download (which implies a symlink tie-in): 2023-12-17 18:02:24 URL:http://http.us.debian.org/debian/pool/main/c/cpio/cpio_2.13+dfsg-7.1_amd64.deb [245036/245036] -> "/home/candycane/deboot-apt-symlink//var/cache/apt/archives/partial/cpio_2.13+dfsg-7.1_amd64.deb" [1] That same (error or no?) reference does not occur in all debootstrap(dot)log files across the multiple debootstraps that were run using symlink instead of "mount -B" today. All of that now melds in with the rest of my original email which is Apologies, I didn't know where to cull above, grin. A couple years ago, I posted on Debian-User that I tripped over a BAD problem when only symlinking apt/archives for my debootstraps. I just super quick ran two comparative debootstraps, and the same issue still stands. $ sudo LANG=C.UTF-8 chroot deboot-apt-symlink /bin/bash I have no name!@northpole:/# $ sudo LANG=C.UTF-8 chroot deboot-apt-mount-bind /bin/bash root@northpole:/# The "mount -B" debootstrap ends short and sweet with: I: Base system installed successfully. Go, Team! The symlink version lost its mind this time. It used to say something very different and much shorter. The previous concluding message was so short that I missed it multiple times over and just assumed the debootstraps were successfully completing as expected. Nope. Today's (terminal CLI) message popped big time: W: Failure trying to run: chroot "/home/candycane/deboot-apt-symlink" dpkg-deb -f /var/cache/apt/archives/dpkg_1.22.1_amd64.deb Version W: See /home/candycane/deboot-apt-symlink/debootstrap/debootstrap.log for details I: Installing core packages... W: Failure trying to run: chroot "/home/candycane/deboot-apt-symlink" dpkg --force-depends --install /var/cache/apt/archives/base-passwd_3.6.3_amd64.deb W: See /home/candycane/deboot-apt-symlink/debootstrap/debootstrap.log for details DISCLAIMER: Yes, that's referencing chroot, but that is NOT me chrooting in. That's debootstrap running through the last lines of its to-do list. When I chroot in afterward, I only see the first lines I typed further above (e.g. "I have no name!"). With respect to deciphering what happens, I just thought to run "diff" on the two different debootstrap directories from today. Nothing's been done to those directories. It's only the initial download and install step. A LOT of feedback came back for that diff command. Top of the diff query results showed a sizable list of "only in" the "mount -B" debootstrap's /bin. So I compared total sizes: 239.3MB for
Re: difference in seconds between two formatted dates ...
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 https://gist.github.com/timvisee/fcda9bbdff88d45cc9061606b4b923ca and how does my paranoia relate to that wall of itemized statements which could be reduced to just a few? Sources are given below that wall and they may be more pleasant to read. There are a lot of blog posts describing various pitfalls related to date and time. 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 give incorrect results.
Re: difference in seconds between two formatted dates ...
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 heart's content) and you are telling them you are using their format and how, they should be able to parse that string. ANyway, my hack around it wasn't effortful at all. lbrtchx
Re: Why is /var/lib/apt/lists not in /var/cache?
On Sun 17 Dec 2023 at 15:33:30 (-0500), Stefan Monnier wrote: > >> That seems similar to things like `locate` failing if you remove > >> `/var/log/plocate/plocate.db` (until that DB is rebuilt). > > > > It's tricky to discern your point as /var/log/ is not involved. > > That was a typo. it's `/var/cache/plocate/plocate.db`, sorry. My plocate.db is in /var/lib/plocate/, as is bookworm's. Is that changing in the future? $ ls -l /var/lib/*locate/ /var/lib/mlocate/: total 19344 -rw-r- 1 root mlocate 19807421 Aug 28 07:43 mlocate.db /var/lib/plocate/: total 20632 -rw-r--r-- 1 root root 183 Nov 17 2021 CACHEDIR.TAG -rw-r- 1 root plocate 21121629 Dec 16 16:06 plocate.db $ Cheers, David.
Vem aí a MiniDebConf Belo Horizonte 2024
Olá pessoal, Antes de 2023 acabar, estamos trazendo boas notícias para o próximo ano! De 27 a 30 de abril acontecerá a MiniDebConf Belo Horizonte 2024 no Campus Pampulha da UFMG - Universidade Federal de Minas Gerais. Após 4 edições que aconteceram em Curitiba (2016, 2017 e 2018) e em Brasília (2023), chegou a vez de Belo Horizonte sediar a 5a edição nacional do principal evento da Comunidade Debian no Brasil. Ainda não é possível realizar envio de propostas de atividades e a inscrição de participante porque estamos finalizando alguns ajustes no sistema, mas já estamos divulgando o site do evento para que todas as pessoas interessadas possam começar a se programar para vir a Belo Horizonte. E claro, a inscrição será gratuita e aberta a qualquer pessoa, independente do seu nível de conhecimento sobre o Debian. Estamos tentando viablizar bolsas patrocinadas pelo Debian para ajudar com passagens e/ou hospedagem e/ou alimentação a vinda de contribuidores(as) que moram em outras cidades. Fique atento(a) porque em breve divulgaremos a chamada de atividades e a abertura das inscrições. Visite o site e veja todas as informações: https://bh.mini.debconf.org Organização: - Comunidade Debian Brasil - Comunidade Debian MG - DCC/UFMG - Departamento de Ciência da Computação da UFMG Abraços, -- Paulo Henrique de Lima Santana (phls) Belo Horizonte - Brasil Debian Developer Site: http://phls.com.br GPG ID: 0443C450 OpenPGP_signature.asc Description: OpenPGP digital signature
Re: difference in seconds between two formatted dates ...
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 my paranoia relate to that wall of itemized statements > which could be reduced to just a few? I understood the paranoia related to your earlier post, outlining "exposed" and "private" modes and why you require all this date processing to support them. > 2) coreutils date is not quite true to itself when it comes to en- > and decoding its own formatting options Which of its own formatting options does it not support? $ date -Ins | tee /tmp/d-ins 2023-12-17T18:29:38,909648062-06:00 $ date -d "$(cat /tmp/d-ins)" Sun Dec 17 18:29:38 CST 2023 $ date --rfc-email | tee /tmp/d-ema Sun, 17 Dec 2023 18:29:47 -0600 $ date -d "$(cat /tmp/d-ema)" Sun Dec 17 18:29:47 CST 2023 $ date --rfc-3339=ns | tee /tmp/d-rns 2023-12-17 18:29:54.724220949-06:00 $ date -d "$(cat /tmp/d-rns)" Sun Dec 17 18:29:54 CST 2023 $ date | tee /tmp/d-dat Sun Dec 17 18:30:01 CST 2023 $ date -d "$(cat /tmp/d-dat)" Sun Dec 17 18:30:01 CST 2023 $ All correct. When you write dt00=$(date +%Y%m%d%H%M%S) that's /your/ format, not coreutils'. Cheers, David.
Re: difference in seconds between two formatted dates ...
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 paranoia relate to that wall of itemized statements which could be reduced to just a few? No the earth doesn't revolve around the sun in exactly 356 days, ... and the adoption of the Gregorian calendar already caused quite a fuss in the history of humankind, which, believe me, didn't have to do at all with my paranoia. All my paranoia is talking about is that: 1) for historical reasons going back to the Sumerian/Babylonian civilization, the date format we use is not 10-based 2) coreutils date is not quite true to itself when it comes to en- and decoding its own formatting options 3) since time is a scalar magnitude, a time difference will be constant regardless of my paranoia and the statements on that link you posted. 4) contrary to what happens with floating point numbers (which, in general, you can't represent truthfully as binary), a time difference in seconds is whole number which you can exactly represent as binary. Even people who are not paranoid and know their sh!t would easily see my points. I would say it is primary school Arithmetic. lbrtchx
Re: difference in seconds between two formatted dates ...
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:
https://www.gnu.org/software/coreutils/manual/html_node/Date-conversion-specifiers.html
which made me think of how/why did I start using my "coblesome"
formatting, but there is nothing really that homely about it. Those
formatting options are listed right on:
date --help
$ date --version 2>&1 | head -n 1
date (GNU coreutils) 8.32
Based on to...@tuxteam.de's suggestions I worked around a downright
simple hack around those formatting problematics with coreutils date:
s00=$(date +%s)
dt00=$(date +%Y%m%d%H%M%S)
dttm00ISeks="${dt00:0:4}-${dt00:4:2}-${dt00:6:2}T${dt00:8:2}:${dt00:10:2}:${dt00:12:2}+00:00"
ISeks00=$(date -d"${dttm00ISeks}" +%s)
if [[ $s00 -eq $ISeks00 ]]; then
echo "// __ \$ISeks00: |$ISeks00|, \$dttm00ISeks: |${dttm00ISeks}|
conversion OK!"
else
echo "// __ \$s00: |$s00|, \$dt00: |${dt00}|"
echo "// __ \$ISeks00: |$ISeks00|, \$dttm00ISeks: |${dttm00ISeks}|
conversion NOT OK!"
fi
# 63 weeks 5 days 11 hours 0 minutes et 43 seconds later
s02=$(( s00 + 63*7*24*60*60 + 5*24*60*60 + 11*60*60 + 0*60 + 43))
dt02=$(date --date @${s02} +%Y%m%d%H%M%S)
echo "// __ \$s02: |$s02|, \$dt02: |${dt02}|"
dttm02ISeks="${dt02:0:4}-${dt02:4:2}-${dt02:6:2}T${dt02:8:2}:${dt02:10:2}:${dt02:12:2}+00:00"
ISeks02=$(date -d"${dttm02ISeks}" +%s)
if [[ $s02 -eq $ISeks02 ]]; then
echo "// __ \$ISeks02: |$ISeks02|, \$dttm02ISeks: |${dttm02ISeks}|
conversion OK!"
_diffs=$(( s02 - s00 ))
_diffISeks=$(( ISeks02 - ISeks00 ))
if [[ $_diffs -eq $_diffISeks ]]; then
echo "// __ differences also OK!"
else
echo "// __ differences NOT OK! \$_diffs: |$_diffs|, \$_diffISeks:
|${_diffISeks}|"
fi
else
echo "// __ \$s02: |$s02|, \$dt02: |${dt02}|"
echo "// __ \$ISeks02: |$ISeks02|, \$dttm02ISeks: |${dttm02ISeks}|
conversion NOT OK!"
fi
thank you,
lbrtchx
Debian en HP Envy
Saludos a todos. He heredado una HP Envy con I7 SSD y varios chiches más, gracias a que al dueño se le quebró parte del monitor y ya no la quiere. En fin, la consulta es la siguiente: estuve buscando en la web qué tal va la compatibilidad con debian (es el SO que uso hace años y no quisiera cambiarme) y encontré muy poco. Lo que leí es que con Arch va bien. La probé con un live cd de Ubuntu y funciona. Alguien tiene Debian instalado en alguna máquina similar? Me serviría mucho si pueden orientarme. Muchas gracias. -- Martín Ayos === https://ayos.com.ar Linux User # 481475 === "Caute" ===
Re: Why is /var/lib/apt/lists not in /var/cache?
>> That seems similar to things like `locate` failing if you remove >> `/var/log/plocate/plocate.db` (until that DB is rebuilt). > > It's tricky to discern your point as /var/log/ is not involved. That was a typo. it's `/var/cache/plocate/plocate.db`, sorry. Stefan
Re: Why is /var/lib/apt/lists not in /var/cache?
On Sun 17 Dec 2023 at 01:06:28 (-0500), Stefan Monnier wrote: > > Some packages will stay the same for years, but in the past week > > I can see four occasions when changes in list contents have occurred > > on oldstable. So there's little similarity. > > The question is not really whether "apt/lists" is similar to > "apt/archives", but whether the content of "apt/lists" is appropriate > for `/var/cache`. I didn't bring up apt/archives, but my first words posted were: "This may not answer your question". > AFAIK nothing bad will happen to your system if you delete > `/var/lib/apt/lists`. It will still run as before and you can still > install packages as before. As you said. > The only thing that seems to be impacted is > that some APT operations will temporarily work in a kind of "degraded" > mode until the next `apt update`. As I said. On how significant that difference is, we beg to differ. > That seems similar to things like `locate` failing if you remove > `/var/log/plocate/plocate.db` (until that DB is rebuilt). It's tricky to discern your point as /var/log/ is not involved. Cheers, David.
Re: difference in seconds between two formatted dates ...
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 utility provides, then you should be able to decode it > using the same options that same utility provides, no? ... and then > get "seconds since 1970-01-01" which wouldn't matter when you are > computing the difference between two 10-based whole numbers which can > be represented exactly in binary Arithmetic. date -d expects "mostly free format human readable", which means it won't work with arbitrary fixed formats, unless they conform to certain standards … > > If you could live with a datetime format which date can understand > > (instead of your cobbled-up pseudo numeric monster above) ... > > Thank you. I learned something out of it, but I used such "cobbled-up > pseudo numeric monster" because, in kind of a poor-man's "measured" > way, I use size, line count, last mod and sha256 metadata in file > names baselining the system's state. I avoid spaces and any other > characters you can't use in most fs' and/or may be interpreted by > shells or OSs in their own ways. Perhaps add five characters (- - T : :) to your poor-man's format, and stick to UTC. If the colons are an embarrassment, sed them to hyphens for filenames and back again for date -d. If that's too much lengthening, just use sed alone to insert/remove those five characters appropriately. Something like: $ LC_ALL=C TZ=UT date -d "$(sed -E 's/()(..)(..)(..)(..)(..)/\1-\2-\3T\4:\5:\6/' <<<'19631122183000')" +'%s' -192778200 $ LC_ALL=C TZ=UT date -d '@-192778200' +'%Y%m%d%H%M%S' 19631122183000 $ Cheers, David.
Re: difference in seconds between two formatted dates ...
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 elapsed since dt00
> >
> > Are you working in bash, or sh?
>
> bash
>
> > Bash offers some alternatives, to avoid having to fork two date(1)
> > processes, light as those are. The first is:
> >
> > unicorn:~$ printf -v dt00 '%(%s)T' -1
> > unicorn:~$ echo "$dt00"
> > 1702821082
>
> but this is not what I meant and I am sure you can once again impress
> everyone here with your bash skills/wisdom. Is there such a thing as:
>
> dt00=$(date +%Y%m%d%H%M%S)
> printf -(whatever the formatting for seconds would be) "${dt00}%Y%m%d%H%M%S"
No, there is nothing in bash which scans date/time strings. You'd need
to use an external tool for this. GNU date is one such tool.
> I dealing with my "exposed mode" kinds of states ;-). I use a
> computer which initial state is kept as part of the file name as I
> explained, then as part of another ("exposed" or "private") reboot I
> want to check that file, so I would not be able to then simply do $((
> dt02 - dt00 ))
You've moved the goalposts. Now the state is not being kept WITHIN
a script, but in a FILE that's used by two separate scripts (one that
writes it, and one that has to interpret it).
This is a very different kind of problem.
You'll need to choose a tool or a language that can parse your chosen
storage format. This might be GNU date. This might be Perl, Python,
Tcl, or some other language that has appropriate facilities for parsing
date/time strings.
You'll also be strongly encouraged to choose a storage format that
facilitates such parsing. You might even want to work backwards --
figure out how you're going to parse the string, then choose the
format that works best with that specific parser.
Re: difference in seconds between two formatted dates ...
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 in computer time you trust? Falsehoods programmers believe about time https://gist.github.com/timvisee/fcda9bbdff88d45cc9061606b4b923ca Thanks, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting
Re: Problem with /var/cache/apt/archives/
On 2023-12-17, Max Nikulin wrote: > On 16/12/2023 22:46, Stephen P. Molnar wrote: >> >> I'll add 'sudo apt-get autoclean to' my update bat file. > > I have > > APT::Keep-Downloaded-Packages "false"; I thought that was the default now for apt. But then he said "sudo apt" in the OP and "apt-get" in the post you're responding to. Anyway. > in a file inside "/etc/apt/apt.conf.d/". However I use apt-cacher-ng. In > you case this settings may be excessively aggressive. > > --
Re: difference in seconds between two formatted dates ...
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 utility provides, then you should be able to decode it > using the same options that same utility provides, no? Template expansion (printf is kind of that) is usually much easier than parsing. Parsing might even lead to ambiguities unless you have been super careful when "designing" your "language". Just imagine variable-length items (there are none in your case, but how should the parser know that?) This is also why "scanf" is much less useful than "printf". Cheers -- t signature.asc Description: PGP signature
Re: difference in seconds between two formatted dates ...
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 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}|"
> >
> > [...]
> >> because bash Arithmetic is 10-based.
> >
> > You wouldn't expect bash to intuit such a crooky arithmetic as
> > Gregorian datetime (and then, based on what? The number beginning
> > with 2023? Sounds kind of exciting).
>
> Actually, my basic idea is if you can encode a date using formatting
> options this utility provides, then you should be able to decode it
> using the same options that same utility provides, no? ... and then
> get "seconds since 1970-01-01" which wouldn't matter when you are
> computing the difference between two 10-based whole numbers which can
> be represented exactly in binary Arithmetic.
>
> > If you could live with a datetime format which date can understand
> > (instead of your cobbled-up pseudo numeric monster above) ...
>
> Thank you. I learned something out of it, but I used such "cobbled-up
> pseudo numeric monster" because, in kind of a poor-man's "measured"
> way, I use size, line count, last mod and sha256 metadata in file
> names baselining the system's state. I avoid spaces and any other
> characters you can't use in most fs' and/or may be interpreted by
> shells or OSs in their own ways.
>
> > น 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.
>
> No calendar issue here. All is needed is turning dates into seconds
> to get the time diff in seconds. I am not trying to start a
> sub-thread, but how on earth would that not always produce an accurate
> duration?
>
> lbrtchx
>
https://xkcd.com/2867/ refers,
Andy
(amaca...@debian.org)
Re: difference in seconds between two formatted dates ...
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 since dt00, like
>> this:
>>
>> dt02=$(date +%Y%m%d%H%M%S)
>> echo "// __ \$dt02: |${dt02}|"
>
> [...]
>> because bash Arithmetic is 10-based.
>
> You wouldn't expect bash to intuit such a crooky arithmetic as
> Gregorian datetime (and then, based on what? The number beginning
> with 2023? Sounds kind of exciting).
Actually, my basic idea is if you can encode a date using formatting
options this utility provides, then you should be able to decode it
using the same options that same utility provides, no? ... and then
get "seconds since 1970-01-01" which wouldn't matter when you are
computing the difference between two 10-based whole numbers which can
be represented exactly in binary Arithmetic.
> If you could live with a datetime format which date can understand
> (instead of your cobbled-up pseudo numeric monster above) ...
Thank you. I learned something out of it, but I used such "cobbled-up
pseudo numeric monster" because, in kind of a poor-man's "measured"
way, I use size, line count, last mod and sha256 metadata in file
names baselining the system's state. I avoid spaces and any other
characters you can't use in most fs' and/or may be interpreted by
shells or OSs in their own ways.
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 elapsed since dt00
>
> Are you working in bash, or sh?
bash
> Bash offers some alternatives, to avoid having to fork two date(1)
> processes, light as those are. The first is:
>
> unicorn:~$ printf -v dt00 '%(%s)T' -1
> unicorn:~$ echo "$dt00"
> 1702821082
but this is not what I meant and I am sure you can once again impress
everyone here with your bash skills/wisdom. Is there such a thing as:
dt00=$(date +%Y%m%d%H%M%S)
printf -(whatever the formatting for seconds would be) "${dt00}%Y%m%d%H%M%S"
I dealing with my "exposed mode" kinds of states ;-). I use a
computer which initial state is kept as part of the file name as I
explained, then as part of another ("exposed" or "private") reboot I
want to check that file, so I would not be able to then simply do $((
dt02 - dt00 ))
After rebooting (separately for "exposed" or "private" mode):
a) those kinds of name measured files are checked,
b) if everything is fine you would keep some basic statistics (last
difference; as well as, incrementally, average, stddev, skewness and
kurtosis of differences so far)
c) delete the file(s) previous to the latest one
...
and, no, I am not expecting for bash to do that kind of statistics
for me, but I would love to see once again how wrong I am.
On 12/17/23, 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.
No calendar issue here. All is needed is turning dates into seconds
to get the time diff in seconds. I am not trying to start a
sub-thread, but how on earth would that not always produce an accurate
duration?
lbrtchx
Re: Finding i386 After Support Ends (Was: differences among amd64 and i386)
Hello, On Sun, Dec 17, 2023 at 09:16:49AM -0500, Cindy Sue Causey wrote: > That points you to an amazingly long list of Debian releases: > > https://linuxcollections.com/products/debian/debian.htm Though if I wanted an image for an old Debian release I'd just download it from: https://cdimage.debian.org/mirror/cdimage/archive/ for free… Thanks, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting
Finding i386 After Support Ends (Was: differences among amd64 and i386)
On 12/17/23, Andy Smith wrote: > On Sun, Dec 17, 2023 at 06:10:49AM -0500, Timothy M Butterworth wrote: >> On Sat, Dec 16, 2023 at 7:45 PM Tixy wrote: >> > Just announced today [1] it looks like Debian will drop i386 installs >> > for the next release. >> > >> > [1] >> > https://lists.debian.org/debian-devel-announce/2023/12/msg3.html >> > >> Goodbye i386, you had a good run. > > I expect it to be decades before it's gone! 32-bit binaries will > keep on being run under amd64. There's always some place like Linux Collections out there, too. This isn't an ad, it's a happy customer gush. My CDs and DVDs from them are 4 years old, and all still work great when emergency access is needed. Wasn't a random purchase. I test drove LC because they're listed here: https://www.debian.org/CD/vendors/#us That points you to an amazingly long list of Debian releases: https://linuxcollections.com/products/debian/debian.htm Some poking around finds this which moves away from being solely Debian: https://linuxcollections.com/products/buildcollection.htm DISCLAIMER: My very old i386 CDs used to work on everything. The ones I purchased from them did not. It's possible that the difference is that I'm using much more modern hardware these many years later, but I won't swear to that being the only difference in that equation. That "build collection" option is how I picked out my stack of about 15 CDs and DVDs for maybe $35 four years ago. Prices are still within my range with some looking like they haven't changed any from before. Yeah, you can still SOMETIMES find similar archive files to download and burn your own.. but not always, especially if you're seeking an operating system's entire history while waxing nostalgic. For example, Linux Collections lists ArtistX whose online presence is disappearing. ArtistX has a PHENOMENAL number of visual and audio creator type programs. A lot of them may not exist anymore. I LOVED that DVD literally to its death so a heartfelt thank you to the diehard fans who keep very old projects accessible today. Wandering off now remembering that stack of 31 Debian CDs I bought from that guy who also used to be referenced on Debian dotORG but who closed his business a few years ago. Never even got CD #1 to work because I was so brand new to Linux at the time. That thought caused me to roll down the page to the bottom of Linux Collections' Debian offerings. There is a "donate" option that I forgot they have. I fully trust their promise to pay it forward... because I can still find them listed on that Debian dotORG webpage. Beyond that, they sure are not gouging on those prices... $2.39 still.. wow. PS No, I didn't find specifics about them shipping international. While test driving their "Add To Order" button, I ended up at their shopping cart. That page does reference international orders so that's hopeful. PPS When playing with old distros, don't forget their security support shut down sometimes decades ago. PPPS They got DSL, Damn Small Linux. That's the distribution that triggered my addiction to minimalist debootstrap. When I encountered those 3 years or so of permanent GPT-induced GRUB boot fails recently, I tried to find a replacement operating system because others were still booting just fine from LiveDVDs. Never stumbled on anything as cognitively friendly as debootstrap.. and so here we still are. Thank you, Developers! Cindy :) -- Talking Rock, Pickens County, Georgia, USA * runs with her Happy New Year's Linux wishlist champing at the bit *
Re: difference in seconds between two formatted dates ...
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 "date +%s" (a GNU extension) to get epoch time, twice, and then subtracting those. That should be good enough for most purposes, and it'll work in sh, as long as you have GNU date. (This is the *only* way that works in sh, apart from using the "time" builtin on a function call, and parsing its output, which I would not recommend.) Bash offers some alternatives, to avoid having to fork two date(1) processes, light as those are. The first is: unicorn:~$ printf -v dt00 '%(%s)T' -1 unicorn:~$ echo "$dt00" 1702821082 This requires GNU libc(*) and bash 4.2 or higher; as an added bonus, if you use bash 4.3 or higher, you can omit the -1 argument. Another poster mentioned EPOCHSECONDS. This is available in bash 5.0 or higher. You can grab copies of this twice, and then subtract your copies. This has the advantage of working on systems without GNU libc or GNU date. Finally, there's the SECONDS variable. You can use this in two different ways. The first way is to treat it like EPOCHSECONDS -- capture copies of it twice, and subtract them. The second way is to set it to 0 and the start of your interval, and then capture its value at the end of your interval. SECONDS=0 sleep 5 echo "$SECONDS sec elapsed" This works in every version of bash I've got available, so let's call it 2.05b or higher just to be safe. It also works without needing GNU date or GNU libc. If you're using bash, this is *the* most portable option. (*) It requires GNU libc because bash uses the system's strftime(3) for interpretation of the format specifier. Therefore, %s only works on systems where libc has that, which means GNU and BSD are good, but typically not legacy Unixes.
En Debian ya piensan en abandonar la arquitectura i386 (x86)
Hola, Pues eso... no hay fecha pero cuando el río suena, llega el torrente :-/ Debian Likely Moving Away From i386 In The Near Future https://www.phoronix.com/news/Debian-Plans-Cease-i386 Personalmente pienso que ni un plazo de 5-8 años me parecería razonable para abandonar los 32 bits, lo siento, aún sigue siendo una arquitectura relevante en ciertos sectores, circunstancias... sin olvidar el plano educativo o los sistemas virtuales. Saludos, -- Camaleón
Re: differences among amd64 and i386
Hello, On Sun, Dec 17, 2023 at 06:10:49AM -0500, Timothy M Butterworth wrote: > On Sat, Dec 16, 2023 at 7:45 PM Tixy wrote: > > Just announced today [1] it looks like Debian will drop i386 installs > > for the next release. > > > > [1] https://lists.debian.org/debian-devel-announce/2023/12/msg3.html > > > Goodbye i386, you had a good run. I expect it to be decades before it's gone! 32-bit binaries will keep on being run under amd64. Thanks, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting
Re: difference in seconds between two formatted dates ...
* 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 e.g. "date +%s" and > then you can subtract one from the other¹. Also, Bash has variable EPOCHSECONDS which expands to the current Unix epoch time. $ echo $EPOCHSECONDS; sleep 5; echo $EPOCHSECONDS 1702812641 1702812646 -- /// Teemu Likonen - .-.. https://www.iki.fi/tlikonen/ // OpenPGP: 6965F03973F0D4CA22B9410F0F2CAE0E07608462 signature.asc Description: PGP signature
Re: differences among amd64 and i386
On Sat, Dec 16, 2023 at 7:45 PM Tixy wrote: > On Thu, 2023-12-14 at 18:19 -0500, Greg Wooledge wrote: > > https://en.wikipedia.org/wiki/Sandy_Bridge > > > > Instruction set x86-64 > > Instructionsx86, x86-64 > > > > You could run amd64 on this machine. Right now, you have a choice > > between the two, but some distributions have already dropped support > > for i386. amd64 would be the more future-proof choice. > > Just announced today [1] it looks like Debian will drop i386 installs > for the next release. > > [1] https://lists.debian.org/debian-devel-announce/2023/12/msg3.html > > -- > Tixy > > Goodbye i386, you had a good run. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system ⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/ ⠈⠳⣄⠀⠀
Re: difference in seconds between two formatted dates ...
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. They can now rant at two :-) Cheers -- t signature.asc Description: PGP signature
Re: difference in seconds between two formatted dates ...
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 +%Y%m%d%H%M%S)
> echo "// __ \$dt02: |${dt02}|"
[...]
> because bash Arithmetic is 10-based.
You wouldn't expect bash to intuit such a crooky arithmetic as
Gregorian datetime (and then, based on what? The number beginning
with 2023? Sounds kind of exciting).
If you could live with a datetime format which date can understand
(instead of your cobbled-up pseudo numeric monster above), you might
harness date to do the work for you.
To wit
date -I
=> 2023-12-17
(alternatively, if you want a finer resolution):
date -Iseconds
=> 2023-12-17T11:48:28+01:00
Now date can "read" those (option -d):
date -d $(date -Iseconds)
=> Sun Dec 17 11:49:46 CET 2023
With all of this, you can do:
d1=$(date -Iseconds) ; sleep 5 ; d2=$(date -Iseconds)
echo "$d1 $d2"
=> 2023-12-17T11:51:43+01:00 2023-12-17T11:51:48+01:0
and now:
echo $(( $(date -d"$d2" +"%s") - $(date -d"$d1" +"%s") ))
=> 5
... the "%s" format indicator telling date to print "seconds since
1970-01-01". Instead of -Iseconds you can do -Ins. See the date man
page for all the gory details.
Me? I'd keep internal results always as "seconds since 1970-01-01"
and only transform on display.
Cheers
--
t
signature.asc
Description: PGP signature
Re: difference in seconds between two formatted dates ...
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:
>
> dt02=$(date +%Y%m%d%H%M%S)
> echo "// __ \$dt02: |${dt02}|"
>
> 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 e.g. "date +%s" and
then you can subtract one from the other¹.
You can also take a copy of the contents of /proc/uptime twice and
subtract one from the other.
Thanks,
Andy
¹ 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.
--
https://bitfolk.com/ -- No-nonsense VPS hosting
Re: System getting slower and slower (debian Testing)
Hi, please ignore the previous message It seems that upgrading from 6-0-1 to 6-0-5 fix the problem (that or autoremove) regards, Laurent Le dim. 17 déc. 2023 à 10:44, Laurent Debian a écrit : > Dear All, > I am running debian Testing, > I did two things recently, upgrading the debian and changing my graphic > cards (radeon RX 570 -> radeon RX 7600). > Before that my desktop was in good shape, quite reactive and so on. > For a few days I have experienced a super slow system with a lot of lag. > I first thought of not enough free space but it does not seem to be the > case > I can't even play an audio files, without having it stutter, not to > mention videos or audio online. > A lot of problems seem to show in the dmesg output related to the graphic > driver but I don't know what to do :/ > Any help would be appreciated ! > > Regards, > Laurent >
difference in seconds between two formatted dates ...
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 then the difference. You can't
go: $(( dt02 - dt00 )) because bash Arithmetic is 10-based.
I am pretty sure there is such a thing in bash, but I can't find it in
my scripts.
lbrtchx
