Maximum size .bash_aliases file

[Keith Bainbridge]

Good evening Folk

Some of my aliases stopped working after months of working as I
expected. And udating the .bash_aliases kept giving me an error
referring to an end of file before the matching ' in one of the last
aliases. So I did some searching.

(An aside is that a function started failing but see later.)

I found this summary using search.brave.com:

linux maximum bash aliases

Bash aliases are a powerful way to customize your command-line
experience. While there is no strict limit on the number of aliases you
can define, there are some practical limitations to consider.

Practical Limitations

Environment Variables: Bash has a limit on the number of
environment variables it can store, which is typically around 32,000. If
you define too many aliases, you may exceed this limit, causing issues
with your shell.
Shell Scripting: Bash scripts have a limit on the number of
commands they can execute, which is typically around 64,000. If you
define too many aliases, you may exceed this limit, causing issues with
your shell scripts.
/// summary ends

So, is an alias a form of variable? I had about 150 plus 4 functions

So I re-did my .bash_aliases file with only the bits I NEED; and all is
back to normal.

Further searching suggested I could have a .bash_functions file, opened
by .bashrc like .bash_aliases. Guess I could call them anything? but
that only means I have to remember something I do differently from norm.

When I got my aliases working, I checked the size of the old file - 17K.
The new .bash_aliases is 2.5K with .bash_functions at 490B.

The errant function that failed after a little satisfactory use was to
mount a USB and back it up to my system. It is used to run portable apps
at a volunteer job - yes windows. I noticed that the sample functions on
the web didn't have && for each line, so I removed them and performance
is now back to what I expected. The errant line was the mount cmd.
Originally if I had already mounted the USB, the function kept going.
I don't recall adding the &&, so it didn't dawn on me to try removing
them. (I worked around it by unmounting it (an alias) and trying the
back-up again.)

So a question and mybe something related that may help somebody else.
--
All the best

Keith Bainbridge

***@gmail.com
***@gmail.com
[phone]

UTC + 10:00

[Richard]

"And udating the .bash_aliases kept giving me an error
referring to an end of file before the matching ' in one of the last
aliases."

This doesn't refer to a size limitation, but a syntax error. As in: the end
of the file was reached before the matching ' was found. Either you mixed "
and ' or you simply forgot to close an opened '. Ideally the error message
will tell you the affected line.

Richard

[Keith Bainbridge]

Post by Richard
"And udating the .bash_aliases kept giving me an error
referring to an end of file before the matching ' in one of the last
aliases."
the end of the file was reached before the matching ' was found. Either
you mixed " and ' or you simply forgot to close an opened '. Ideally the
error message will tell you the affected line.
Richard

Thanks Richard

I believe David raised very similar suggestions
--
All the best

Keith Bainbridge

***@gmail.com
***@gmail.com
[phone]

UTC + 10:00

[Greg Wooledge]

Environment Variables: Bash has a limit on the number of environment
variables it can store, which is typically around 32,000. If you define too
many aliases, you may exceed this limit, causing issues with your shell.

This is not strictly true. There is no limit imposed by bash; but
there is a limit imposed by the *kernel* on the total size of the
environment plus the argv[] argument vector passed to a process.

<https://www.in-ulm.de/~mascheck/various/argmax/> documents this
extremely thoroughly.

In most cases, when a problem arises with hitting this limit, it's
because the argument list is too long, not the environment. You seem
to be hitting it from the other direction, though.

Solution: "don't do that".

Shell Scripting: Bash scripts have a limit on the number of commands
they can execute, which is typically around 64,000.

Well... that sounds like you're filling up the table of exit statuses
that have been reaped internally. I think there might have been some
bugs in older versions of bash concerning this issue as well.

Some people have reported this issue when they run an infinite loop with
an external command inside it (e.g. sleep).

I don't recall off the top of my head how to work around this issue, if
you're writing "daemon scripts" that run forever and spawn external
commands within a loop. You might need to Google it. It's a bit
esoteric.

If you define too many
aliases, you may exceed this limit, causing issues with your shell scripts.

Huh? I have no idea what this means. Bash doesn't have a limit on the
number of aliases you can define, as far as I know.

Aliases do not work in shell scripts, by default. You would have to turn
them on with a shopt. I recommend not doing that. They're disabled
because they suck. Use functions instead of aliases, when writing scripts.
They're far more sensible and flexible.

[Keith Bainbridge]

It was late afternoon on 16Jun2024 that I wrote this. Possibly 18:13:36
when I pressed send. I'd reckon it would likely have been 08:13:36 UTC
What's wrong with my system clock. I've not really looked at the time
on my originals before. I'll try to remember to enter my local time as
I press send

Post by Greg Wooledge

Environment Variables: Bash has a limit on the number of environment
variables it can store, which is typically around 32,000. If you define too
many aliases, you may exceed this limit, causing issues with your shell.

This is not strictly true. There is no limit imposed by bash; but
there is a limit imposed by the *kernel* on the total size of the
environment plus the argv[] argument vector passed to a process.
<https://www.in-ulm.de/~mascheck/various/argmax/> documents this
extremely thoroughly.
In most cases, when a problem arises with hitting this limit, it's
because the argument list is too long, not the environment. You seem
to be hitting it from the other direction, though.
Solution: "don't do that".

Shell Scripting: Bash scripts have a limit on the number of commands
they can execute, which is typically around 64,000.

Thanks Greg

Your comments on the summary provided by the search engine will make me
read them with a bigger grain of salt.

Post by Greg Wooledge
Well... that sounds like you're filling up the table of exit statuses
that have been reaped internally. I think there might have been some
bugs in older versions of bash concerning this issue as well.

Ummm could I be doing this without knowing what it means?

Post by Greg Wooledge
Some people have reported this issue when they run an infinite loop with
an external command inside it (e.g. sleep).

I have 1 sleep line in what is now a function. It was added in an effort
to get the USB to unmount after the back-up process and cd to~. I did
get a command prompt back, but the USB was still mounted according to df

Post by Greg Wooledge
I don't recall off the top of my head how to work around this issue, if
you're writing "daemon scripts" that run forever and spawn external
commands within a loop. You might need to Google it. It's a bit
esoteric.

And I'd suggest beyond me

Post by Greg Wooledge

If you define too many
aliases, you may exceed this limit, causing issues with your shell scripts.

Huh? I have no idea what this means. Bash doesn't have a limit on the
number of aliases you can define, as far as I know.

This is again part of the search engine synopsis

Post by Greg Wooledge
Aliases do not work in shell scripts, by default. You would have to turn
them on with a shopt. I recommend not doing that. They're disabled
because they suck. Use functions instead of aliases, when writing scripts.
They're far more sensible and flexible.

You are re-enforcing other stuff I read last night.
I hope this and my several other responses find you bright and bubbly on
a Monday morning. I'm home from a day of cryptic crossword class, and
minding 2 month old grand daughter etc. I hope my responses aren't too
short.

the time is ***@18:25:58
--
All the best

Keith Bainbridge

***@gmail.com
***@gmail.com
[phone]

UTC + 10:00

[gene heskett]

Post by Keith Bainbridge
It was late afternoon on 16Jun2024 that I wrote this. Possibly 18:13:36
when I pressed send. I'd reckon it would likely have been 08:13:36 UTC
 What's wrong with my system clock. I've not really looked at the time
on my originals before.  I'll try to remember to enter my local time as
I press send

You are not running an ntp client? I do, and in turn I am a stratum 2
server for most of my other machines here. So my system is withing a
millisecond of the atomic clocks in Colorado Springs. It's no big deal.
use ntpsec if up 24/7, or chrony if you shut down. ntpsec works if
already in time but can't slam to the correct time if not synchronized,
chrony can sync after long downtimes.

Cheers, Gene Heskett, CET.

[Greg Wooledge]

It was late afternoon on 16Jun2024 that I wrote this. Possibly 18:13:36 when
I pressed send. I'd reckon it would likely have been 08:13:36 UTC What's
wrong with my system clock. I've not really looked at the time on my
originals before. I'll try to remember to enter my local time as I press
send

What does "date" say? Paste the entire output.

What does "cat /etc/timezone" say? Paste the entire output.

What does "ls -l /etc/localtime" say? Paste the entire output.

Have you set the TZ environment variable? If so, what did you set it to?

What time zone are you *actually* in? Like, what country, and what major
city is nearest to you?

Which NTP client are you running? Have you checked up on it, to make
sure it's actually running, properly configured, and not spewing errors?

[Keith Bainbridge]

Post by Greg Wooledge

It was late afternoon on 16Jun2024 that I wrote this. Possibly 18:13:36 when
I pressed send. I'd reckon it would likely have been 08:13:36 UTC What's
wrong with my system clock. I've not really looked at the time on my
originals before. I'll try to remember to enter my local time as I press
send

I'm back. The kitchen clock says 18:05. the sun has set. I have no
reason to doubt the clock. So I'll answer Greg's questions

Post by Greg Wooledge
What does "date" say? Paste the entire output.

$>   date
Tue 18 Jun 2024 18:06:31 AEST

Post by Greg Wooledge
What does "cat /etc/timezone" say? Paste the entire output.

cat /etc/timezone
Australia/Melbourne

is as close as I can specify for my regional city

Post by Greg Wooledge
What does "ls -l /etc/localtime" say? Paste the entire output.

ls -l /etc/localtime
lrwxrwxrwx 1 root root 39 Mar  4 21:00 /etc/localtime ->
/usr/share/zoneinfo/Australia/Melbourne

Post by Greg Wooledge
Have you set the TZ environment variable? If so, what did you set it to?

Not that I'm aware of

Post by Greg Wooledge
What time zone are you *actually* in? Like, what country, and what major
city is nearest to you?

UTC +10:00

Australia, Geelong Our capital is Melbourne

Post by Greg Wooledge
Which NTP client are you running? Have you checked up on it, to make
sure it's actually running, properly configured, and not spewing errors?

No, but why, when I believe everything I have answered is correct.

If it helps, I have the date as part of my command prompt, always
appears right time after an enter; aliases and desktop short-cuts that
give me the date and time reliably so far.

Greg, if there is something not right with my answer, please let me know.
Again thanks greatly for your help.


I saw another response about how the MUA deals with the senders date
when replying. So fired up claws and sent myself a brief note. when
replying to myself, the reply quoted


On 18/6/24 17:56, Keith Bainbridge wrote:

When forwarding that same note, the forward quoted



-------- Forwarded Message --------
Subject: test sent date details
Date: Tue, 18 Jun 2024 17:56:41 +1000
From: Keith Bainbridge <***@gmail.com>
To: ***@gmail.com

I'll forward this asap, to confirm the detail. Guess I could also alter
address in a reply to send it here as well. Look for it shortly as well.

This makes me think that I need to adjust my MUA settings; thunderbird
for this mail and my normal mail use; and claws for some use. claws has
reply and forwarding templates with place holders for date formats
amongst other items. I'll play around there as it's easier to start
with. Item 1 will be change the date to read as it does in the forward
Tue 18Jun2024.


Thanks all for your responses. I'll go through them all later tonight
--
All the best

Keith Bainbridge

***@gmail.com
***@gmail.com
[phone]

UTC + 10:00

[Greg Wooledge]

I'm back. The kitchen clock says 18:05. the sun has set. I have no reason to
doubt the clock. So I'll answer Greg's questions

Post by Greg Wooledge
What does "date" say? Paste the entire output.

$>   date
Tue 18 Jun 2024 18:06:31 AEST

Post by Greg Wooledge
What does "cat /etc/timezone" say? Paste the entire output.

cat /etc/timezone
Australia/Melbourne
is as close as I can specify for my regional city

Post by Greg Wooledge
What does "ls -l /etc/localtime" say? Paste the entire output.

ls -l /etc/localtime
lrwxrwxrwx 1 root root 39 Mar  4 21:00 /etc/localtime ->
/usr/share/zoneinfo/Australia/Melbourne

Post by Greg Wooledge
Have you set the TZ environment variable? If so, what did you set it to?

Not that I'm aware of

Post by Greg Wooledge
What time zone are you *actually* in? Like, what country, and what major
city is nearest to you?

UTC +10:00
Australia, Geelong Our capital is Melbourne

So, everything looks fine here.

Greg, if there is something not right with my answer, please let me know.
Again thanks greatly for your help.

In a previous message, you thought that your system clock or your time
zone was set wrong, because you read one of the attribution lines of
one of my replies, and you thought it said you had sent your message
at the wrong time.

As it turns out, I'm fairly certain you misread the attribution line,
which was reporting time in a 12-hour format, with "PM". You saw the
06:... and thought it was saying you had sent your email at 6 AM, but
you missed the "PM" at the end.

As far as I know, it was a simple misread on your part, and nothing is
actually wrong.

In fact, things should be even better now, because you provoked me into
reading about mutt's attribution and date_format variables, and changing
the silly default format to a more sensible format. You'll note that
this reply uses an attribution with a 24-hour format.

[Keith Bainbridge]

Post by Greg Wooledge
In a previous message, you thought that your system clock or your time
zone was set wrong, because you read one of the attribution lines of
one of my replies, and you thought it said you had sent your message
at the wrong time.
As it turns out, I'm fairly certain you misread the attribution line,
which was reporting time in a 12-hour format, with "PM". You saw the
06:... and thought it was saying you had sent your email at 6 AM, but
you missed the "PM" at the end.
As far as I know, it was a simple misread on your part, and nothing is
actually wrong.

Absolutely correct Greg. I like your date/time line. The addition of
the offset fro UTC without some explanation confused me.

And started 2 debates.
--
All the best

Keith Bainbridge

***@gmail.com
***@gmail.com
[phone]

UTC + 10:00

[David Wright]

Post by Keith Bainbridge
It was late afternoon on 16Jun2024 that I wrote this. Possibly
18:13:36 when I pressed send. I'd reckon it would likely have been
08:13:36 UTC What's wrong with my system clock. I've not really
looked at the time on my originals before. I'll try to remember to
enter my local time as I press send

All the mail clients I've used apply the timestamp when you press
Send. You live in eastern Australia, I assume, and if you observe
DST at all, it won't be now.

Your attribution could benefit from having some indication of the
timezone that /it/ uses: Greg was writing in the morning, not near
midnight. But your clock is OK, as shown by the headers in your
postings:

sending: Date: Sun, 16 Jun 2024 18:13:36 +1000
processing: Received: from mail-oi1-x233.google.com …
by bendel.debian.org …
Sun, 16 Jun 2024 08:13:48 +0000 (UTC)

You asked after your /system/ clock. I don't think I can tell whether
it's set to UTC or Local Time, but only that it is correct, whichever
it it on. Likewise the hardware RTC. The third line of /etc/adjtime
says what the RTC is on; /etc/timezone says what the system is on;
$ date says what your user is on.

Post by Keith Bainbridge
I hope this and my several other responses find you bright and bubbly
on a Monday morning. I'm home from a day of cryptic crossword class,
and minding 2 month old grand daughter etc. I hope my responses aren't
too short.
[phone]
UTC + 10:00

Looks fine to me. Mobile numbers are a separate sequence like in the
UK, aren't they, and unlike in the US.

Cheers,
David.

[Greg Wooledge]

Post by David Wright
You asked after your /system/ clock. I don't think I can tell whether
it's set to UTC or Local Time, but only that it is correct, whichever
it it on. Likewise the hardware RTC. The third line of /etc/adjtime
says what the RTC is on; /etc/timezone says what the system is on;
$ date says what your user is on.

/etc/timezone is only used by some legacy programs. All the current
ones should be using /etc/localtime instead, which is a symlink to a
binary zoneinfo file, rather than a text file containing a timezone name.

I wonder if Keith's confusion is simply due to my MUA using "AM" and "PM"
in its attribution line, and Keith not seeing the "PM". Maybe I should
look into configuring that differently.

[David Wright]

Post by Greg Wooledge

Post by David Wright
You asked after your /system/ clock. I don't think I can tell whether
it's set to UTC or Local Time, but only that it is correct, whichever
it it on. Likewise the hardware RTC. The third line of /etc/adjtime
says what the RTC is on; /etc/timezone says what the system is on;
$ date says what your user is on.

/etc/timezone is only used by some legacy programs. All the current
ones should be using /etc/localtime instead, which is a symlink to a
binary zoneinfo file, rather than a text file containing a timezone name.

You're right of course, but confirming its value does involve using
a command that's probably not at the front of one's mind.

BTW what's the relationship between "current programs" and TZ nowadays?

Post by Greg Wooledge
I wonder if Keith's confusion is simply due to my MUA using "AM" and "PM"
in its attribution line, and Keith not seeing the "PM". Maybe I should
look into configuring that differently.

Along with 350M Americans! They even use just A and P over here. And a
mere dot on digital clocks. (I see you've changed it already!)

Cheers,
David.

[Greg Wooledge]

Post by David Wright

Post by Greg Wooledge
/etc/timezone is only used by some legacy programs. All the current
ones should be using /etc/localtime instead, which is a symlink to a
binary zoneinfo file, rather than a text file containing a timezone name.

You're right of course, but confirming its value does involve using
a command that's probably not at the front of one's mind.
BTW what's the relationship between "current programs" and TZ nowadays?

Do you mean the TZ variable? That overrides the system default.

hobbit:~$ date; TZ=Europe/Paris date
Mon Jun 17 11:40:59 EDT 2024
Mon Jun 17 17:40:59 CEST 2024

If you're asking about programs that still use /etc/timzeone, I don't know
of any off hand. I'd be interested in hearing about any that still do,
though probably less so than the Debian libc6 maintainers are.

[e***@gmx.us]

Post by David Wright

Post by Greg Wooledge
I wonder if Keith's confusion is simply due to my MUA using "AM" and "PM"
in its attribution line, and Keith not seeing the "PM". Maybe I should
look into configuring that differently.

Along with 350M Americans! They even use just A and P over here. And a
mere dot on digital clocks.

And I can never remember if the dot means AM or PM. I suspect it changes
between implementations, or maybe I'm just very slow.

Worse(?), some clocks that don't deal with date or alarms (e.g. microwave,
car, some watches) are 12h only.

--
Given the correlation between insufficient nookie and the high rate of
unemployment among recent college graduates coupled with high college
debts, I propose to kill two birds* with one stone: A new government
program called "Ameriwhore". -- Arty in AFC-A

[Keith Bainbridge]

And I can never remember if the dot means AM or PM.  I suspect it changes
between implementations, or maybe I'm just very slow.

Probably only really meant to show us when we are setting an alarm at
night, for the morning, that the dot is on one and off on the other.
Else we'll wake a little late.

Remember the joke about going to bed at 8 and setting the alarm on a
wind-up clock for 9 - we wouldn't get much sleep.
--
All the best

Keith Bainbridge

***@gmail.com
***@gmail.com
[phone]

UTC + 10:00

[Keith Bainbridge]

Post by David Wright
Along with 350M Americans! They even use just A and P over here. And a
mere dot on digital clocks. (I see you've changed it already!)

I've been using 24 hour time and dMMMyyyy for a long time. I used send
international cheques as part of my work, and decided that spelling the
month was simple basics.
--
All the best

Keith Bainbridge

***@gmail.com
***@gmail.com
[phone]

UTC + 10:00

[t***@tuxteam.de]

On Mon, Jun 17, 2024 at 09:14:38AM -0500, David Wright wrote:

[...]

Post by David Wright
You asked after your /system/ clock. I don't think I can tell whether
it's set to UTC or Local Time, but only that it is correct, whichever
it it on. Likewise the hardware RTC. The third line of /etc/adjtime
says what the RTC is on; /etc/timezone says what the system is on;
$ date says what your user is on.

No: /etc/timezone just says what time zone a _user_ will "get" unless
they state otherwise. I.e. a user's default time zone.

The "system" being "on" a timezone is something that, under Unix,
doesn't make sense.

Cheers

[Greg Wooledge]

Post by t***@tuxteam.de
[...]

Post by David Wright
You asked after your /system/ clock. I don't think I can tell whether
it's set to UTC or Local Time, but only that it is correct, whichever
it it on. Likewise the hardware RTC. The third line of /etc/adjtime
says what the RTC is on; /etc/timezone says what the system is on;
$ date says what your user is on.

No: /etc/timezone just says what time zone a _user_ will "get" unless
they state otherwise. I.e. a user's default time zone.
The "system" being "on" a timezone is something that, under Unix,
doesn't make sense.

Time zones are not in effect for users, either; they're in effect for
processes. A given user's login session, which is a collection of
processes, would typically all be using the same time zone, for
consistency, but this isn't necessary. They might choose to run two
clocks, one in their local time zone, and one in another time zone,
where a family member lives, or where they're about to take a vacation.

/etc/localtime points to the time zone that a process will use if it
doesn't specify one via the TZ environment variable. And /etc/timezone
is the legacy version of /etc/localtime.

[t***@tuxteam.de]

On Mon, Jun 17, 2024 at 01:20:53PM -0400, Greg Wooledge wrote:

[...]

Post by Greg Wooledge

Post by t***@tuxteam.de
The "system" being "on" a timezone is something that, under Unix,
doesn't make sense.

Time zones are not in effect for users, either; they're in effect for
processes [...]

Right you are.

Cheers

[David Wright]

Post by t***@tuxteam.de

Post by Greg Wooledge

Post by t***@tuxteam.de

You asked after your /system/ clock. [ … ]
[ … ] /etc/timezone says what the system is on;
$ date says what your user is on.

No: /etc/timezone just says what time zone a _user_ will "get" unless
they state otherwise. I.e. a user's default time zone.
The "system" being "on" a timezone is something that, under Unix,
doesn't make sense.

Time zones are not in effect for users, either; they're in effect for
processes [...]

Right you are.

So it comes down to nomenclature.

What should I call the timezone of my computer when it's booted up and
no users are logged in?

It's fine to say that the linux kernel is counting seconds since the
epoch, and doesn't have need of a timezone (ignoring UTC and TAI for
the moment), but there are many processes already running as root, and
they have timezones (hopefully one and the same).

You seem to be telling me that "system timezone" isn't the correct
collective noun for all these processes' timezone.

Saying it's the contents of /etc/timezone is now a legacy concept,
but at least it's less cumbersome than saying it's the name of the
file in /usr/share/zoneinfo/ that's the target of /etc/localtime.
It's fine for systemd to call it "Local time" in the context below,
but it's certainly /not/ the local timezone in KS, where it's nearly
midnight.

$ date; timedatectl status
Mon Jun 17 23:51:43 CDT 2024
Local time: Tue 2024-06-18 04:51:43 UTC
Universal time: Tue 2024-06-18 04:51:43 UTC
RTC time: Tue 2024-06-18 04:51:43
Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
NTP service: active
RTC in local TZ: no
$

I notice that man timedatectl says:

set-timezone [TIMEZONE]
Set the system time zone to the specified value.
Available timezones can be listed with list-timezones.
If the RTC is configured to be in the local time, this
will also update the RTC time. This call will alter
the /etc/localtime symlink. See localtime(5) for more
information.

Cheers,
David.

[t***@tuxteam.de]

[...]

Post by David Wright

Post by t***@tuxteam.de

Post by Greg Wooledge
Time zones are not in effect for users, either; they're in effect for
processes [...]

Right you are.

So it comes down to nomenclature.
What should I call the timezone of my computer when it's booted up and
no users are logged in?

[...]

Most processes don't need one. When they display datetimes to a user
timezone becomes relevant.

Post by David Wright
$ date; timedatectl status
Mon Jun 17 23:51:43 CDT 2024
Local time: Tue 2024-06-18 04:51:43 UTC
Universal time: Tue 2024-06-18 04:51:43 UTC
RTC time: Tue 2024-06-18 04:51:43
Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
NTP service: active
RTC in local TZ: no
$
set-timezone [TIMEZONE]
Set the system time zone to the specified value.
Available timezones can be listed with list-timezones.
If the RTC is configured to be in the local time, this
will also update the RTC time. This call will alter
the /etc/localtime symlink. See localtime(5) for more
information.

I cringe a bit when I see that.

Cheers

[Jeffrey Walton]

Post by t***@tuxteam.de

Post by David Wright
[...]
$ date; timedatectl status
Mon Jun 17 23:51:43 CDT 2024
Local time: Tue 2024-06-18 04:51:43 UTC
Universal time: Tue 2024-06-18 04:51:43 UTC
RTC time: Tue 2024-06-18 04:51:43
Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
NTP service: active
RTC in local TZ: no
$
set-timezone [TIMEZONE]
Set the system time zone to the specified value.
Available timezones can be listed with list-timezones.
If the RTC is configured to be in the local time, this
will also update the RTC time. This call will alter
the /etc/localtime symlink. See localtime(5) for more
information.

I cringe a bit when I see that.

Yeah.. on Linux, it is recommended to keep the RTC clock in UTC.
Unless Windows has contaminated the machine. See
<https://wiki.debian.org/DateTime>.

Jeff

[David Wright]

Post by Jeffrey Walton

Post by t***@tuxteam.de

Post by David Wright
[...]
set-timezone [TIMEZONE]
Set the system time zone to the specified value.
Available timezones can be listed with list-timezones.
If the RTC is configured to be in the local time, this
will also update the RTC time. This call will alter
the /etc/localtime symlink. See localtime(5) for more
information.

I cringe a bit when I see that.

Yeah.. on Linux, it is recommended to keep the RTC clock in UTC.
Unless Windows has contaminated the machine. See
<https://wiki.debian.org/DateTime>.

Here's your subthread for discussing the RTC, as it's a separate
issue from the system's time zone.

(I believe I'm correct in saying that Windows has long been able,
by means of a registry key setting, to run with the RTC set to UTC.)

Cheers,
David.

[Nicholas Geovanis]

Post by David Wright

Post by Jeffrey Walton

Post by t***@tuxteam.de

Post by David Wright
[...]
set-timezone [TIMEZONE]
Set the system time zone to the specified value.
Available timezones can be listed with list-timezones.
If the RTC is configured to be in the local time, this
will also update the RTC time. This call will alter
the /etc/localtime symlink. See localtime(5) for more
information.

I cringe a bit when I see that.

Yeah.. on Linux, it is recommended to keep the RTC clock in UTC.
Unless Windows has contaminated the machine. See
<https://wiki.debian.org/DateTime>.

Here's your subthread for discussing the RTC, as it's a separate
issue from the system's time zone.

Reading the link that Walton sent, the only case where RTC clock in UTC is
recommended is in the linux/windows dual-boot case. There's no statement
that RTC should be set to UTC besides that. And they say right there why it
isn't mentioned: your Debian machine might move around geographically. But
if it doesnt....

Servers in data centers don't move around, they just sit there :-) So in my
experience servers running anything non-windows have RTC set to local time.
That's been on Red Hat/CentOS, Debian, Ubuntu.

(I believe I'm correct in saying that Windows has long been able,

Post by David Wright
by means of a registry key setting, to run with the RTC set to UTC.)

That is also my understanding but Windows 95 is the last release I've been
an admin on.

Cheers,

Post by David Wright
David.

[Greg Wooledge]

Post by Nicholas Geovanis

Post by Jeffrey Walton
<https://wiki.debian.org/DateTime>.

Reading the link that Walton sent, the only case where RTC clock in UTC is
recommended is in the linux/windows dual-boot case. There's no statement
that RTC should be set to UTC besides that. And they say right there why it
isn't mentioned: your Debian machine might move around geographically. But
if it doesnt....
Servers in data centers don't move around, they just sit there :-) So in my
experience servers running anything non-windows have RTC set to local time.
That's been on Red Hat/CentOS, Debian, Ubuntu.

If your system only boots one operating system, and never changes its
default time zone, then it makes no difference whether the RTC is set
to UTC or local time. The OS will use the same assumptions when reading
and writing to the RTC, so everything will remain correct.

If you boot multiple operating systems, or if you ever change your
default time zone, then keeping the RTC in UTC gives you a much better
chance of things remaining correct.

And of course, if your system is configured to retrieve the correct time
from NTP servers immediately after booting, then the RTC's contents don't
really matter much in the first place. You'd only "use" the RTC for the
brief time between boot and NTP synchronization, or if for some reason
you can't reach your NTP servers (Internet is down or whatever).

[Stefan Monnier]

Post by Greg Wooledge
If your system only boots one operating system, and never changes its
default time zone, then it makes no difference whether the RTC is set
to UTC or local time. The OS will use the same assumptions when reading
and writing to the RTC, so everything will remain correct.

Of course, the famous exception is if your machine is OFF during the
switch to/from DST. IIUC there are hacks in Windows to try and handle
it "correctly", but I believe they can also misfire in some cases.
Don't know if GNU/Linux bothers with it: it's just a lot simpler and
more sane to use UTC so you never need to worry about it.
And of course, NTP is your friend: several of my machines don't even
have an RTC and I haven't really felt like they are missing something.


Stefan

[Max Nikulin]

Post by Nicholas Geovanis
Servers in data centers don't move around, they just sit there :-) So in
my experience servers running anything non-windows have RTC set to local
time. That's been on Red Hat/CentOS, Debian, Ubuntu.

My experience with Ubuntu is that its installer is able to guess
timezone (GeoIP?) and it properly sets /etc/localtime symlink while RTC
is in UTC. Try "timedatectl" or hwclock. Setting RTC to local time
increases a chance of some mess due to DST or an administrative time jump.

[Keith Bainbridge]

Post by Max Nikulin

Post by Nicholas Geovanis
Servers in data centers don't move around, they just sit there :-) So
in my experience servers running anything non-windows have RTC set to
local time. That's been on Red Hat/CentOS, Debian, Ubuntu.

My experience with Ubuntu is that its installer is able to guess
timezone (GeoIP?) and it properly sets /etc/localtime symlink while RTC
is in UTC. Try "timedatectl" or hwclock. Setting RTC to local time
increases a chance of some mess due to DST or an administrative time jump.

My experience is that most installers do pretty well at guessing where I am
--
All the best

Keith Bainbridge

***@gmail.com
***@gmail.com
[phone]

UTC + 10:00

[Michael Stone]

Post by Nicholas Geovanis
Reading the link that Walton sent, the only case where RTC clock in UTC is
recommended is in the linux/windows dual-boot case. There's no statement that
RTC should be set to UTC besides that. And they say right there why it isn't
mentioned: your Debian machine might move around geographically. But if it
doesnt....
Servers in data centers don't move around, they just sit there :-) So in my
experience servers running anything non-windows have RTC set to local time.

Which is great, except that for some reason we still have daylight
saving time...which screws everything up. So the real answer is that
keeping RTC in local time is great for servers which never move around
and don't have DST *or never turn off*. In which case it doesn't really
matter. Except for that corner case where it suddenly does, at which
point you'll regret not having used UTC (which works reliably regardless
of what the politicians have decided to do to local time, and regardless
of how long a server has been turned off).

[David Wright]

Post by t***@tuxteam.de
[...]

Post by David Wright

Post by t***@tuxteam.de

Post by Greg Wooledge
Time zones are not in effect for users, either; they're in effect for
processes [...]

Right you are.

So it comes down to nomenclature.
What should I call the timezone of my computer when it's booted up and
no users are logged in?

[...]
Most processes don't need one. When they display datetimes to a user
timezone becomes relevant.

… which, as well as ignoring the minority that do, doesn't give me
an answer.

Post by t***@tuxteam.de

Post by David Wright
$ date; timedatectl status
Mon Jun 17 23:51:43 CDT 2024
Local time: Tue 2024-06-18 04:51:43 UTC
Universal time: Tue 2024-06-18 04:51:43 UTC
RTC time: Tue 2024-06-18 04:51:43
Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
NTP service: active
RTC in local TZ: no
$
set-timezone [TIMEZONE]
Set the system time zone to the specified value.
Available timezones can be listed with list-timezones.
If the RTC is configured to be in the local time, this
will also update the RTC time. This call will alter
the /etc/localtime symlink. See localtime(5) for more
information.

I cringe a bit when I see that.

See what, exactly? I can see three things, potentially.

Cheers,
David.

[t***@tuxteam.de]

On Tue, Jun 18, 2024 at 11:02:58PM -0500, David Wright wrote:

[...]

Post by David Wright

Post by t***@tuxteam.de

Post by David Wright
set-timezone [TIMEZONE]
Set the system time zone [...]

[...]

Post by David Wright

Post by t***@tuxteam.de
I cringe a bit when I see that.

See what, exactly? I can see three things, potentially.

Especially that bit with the "system timezone". Reminds me of some
remote past, where a system actually had a timezone (and changed its
clock twice a year). Back then we used to set all our networked
Windows boxen to a time zone without summer time change (ISTR it
was Monrovia/Liberia) to avoid having our Makefiles freaking out
twice a year.

Cheers

[Greg Wooledge]

Post by David Wright
What should I call the timezone of my computer when it's booted up and
no users are logged in?

Daemons will almost always use the system's default time zone (the one
specified by /etc/localtime or /etc/timezone).

It's *theoretically* possible for some daemons to be configured to use
a different time zone, or to be hard-coded to use UTC. I've never seen
this, but it could be done.

Usually a daemon's time zone will only affect log messages that it
writes. It's uncommon for a daemon process to use a time zone for
anything other than timestamping messages. Of course, it depends on
the individual daemon.

[David Wright]

Post by Greg Wooledge

Post by David Wright
What should I call the timezone of my computer when it's booted up and
no users are logged in?

Daemons will almost always use the system's default time zone (the one
specified by /etc/localtime or /etc/timezone).
It's *theoretically* possible for some daemons to be configured to use
a different time zone, or to be hard-coded to use UTC. I've never seen
this, but it could be done.

In view of that, I think it's reasonable to drop the "default",
and go with "system time zone", ie the time zone that the system
clock it set to.

Post by Greg Wooledge
Usually a daemon's time zone will only affect log messages that it
writes. It's uncommon for a daemon process to use a time zone for
anything other than timestamping messages. Of course, it depends on
the individual daemon.

Well, it's anything related to time, I suppose, like cron, systemd
timers, clock displays, and so on. I just don't understand the idea
of a computer not having a system time in a time zone.

(And I'm leaving aside any connected devices, filesystems, etc
that might handle times, but only in a single, local time.)

Cheers,
David.

[Greg Wooledge]

Post by David Wright

Post by Greg Wooledge

Post by David Wright
What should I call the timezone of my computer when it's booted up and
no users are logged in?

Daemons will almost always use the system's default time zone (the one
specified by /etc/localtime or /etc/timezone).
It's *theoretically* possible for some daemons to be configured to use
a different time zone, or to be hard-coded to use UTC. I've never seen
this, but it could be done.

In view of that, I think it's reasonable to drop the "default",
and go with "system time zone", ie the time zone that the system
clock it set to.

I strongly disagree. The system clock is kept on "epoch time", which
is the number of seconds since midnight, January 1, 1970 UTC.

The system clock doesn't have a time zone of its own. It just gets
converted to a time and date within any given time zone on demand.

Whatever process wants to perform such a conversion will either use UTC,
or the system's default time zone, or a user-specified time zone.

The date(1) command has the ability to do all three:

hobbit:~$ date; date -u; TZ=Europe/Moscow date
Wed Jun 19 07:06:00 EDT 2024
Wed Jun 19 11:06:00 UTC 2024
Wed Jun 19 14:06:00 MSK 2024

In order, those are the system's default time zone (America/New_York
in my case), UTC, and a user-specified time zone.

If you want the raw epoch time, it can do that as well:

hobbit:~$ date +%s
1718795213

The epoch time does not change when you use the -u option or the TZ
variable, either. It's independent of those.

[Jeffrey Walton]

Post by Greg Wooledge

Post by David Wright

Post by Greg Wooledge

Post by David Wright
What should I call the timezone of my computer when it's booted up and
no users are logged in?

Daemons will almost always use the system's default time zone (the one
specified by /etc/localtime or /etc/timezone).
It's *theoretically* possible for some daemons to be configured to use
a different time zone, or to be hard-coded to use UTC. I've never seen
this, but it could be done.

In view of that, I think it's reasonable to drop the "default",
and go with "system time zone", ie the time zone that the system
clock it set to.

I strongly disagree. The system clock is kept on "epoch time", which
is the number of seconds since midnight, January 1, 1970 UTC.
The system clock doesn't have a time zone of its own. It just gets
converted to a time and date within any given time zone on demand.

++.

The sharp edge is how the RTC clock is set - UTC or localtime. Also
see <https://wiki.debian.org/DateTime>.

Jeff

[t***@tuxteam.de]

[...]

Post by Jeffrey Walton

Post by Greg Wooledge
I strongly disagree. The system clock is kept on "epoch time", which
is the number of seconds since midnight, January 1, 1970 UTC.
The system clock doesn't have a time zone of its own. It just gets
converted to a time and date within any given time zone on demand.

++.
The sharp edge is how the RTC clock is set - UTC or localtime. Also
see <https://wiki.debian.org/DateTime>.

Please don't mix those three things, that makes them just more confusing.

The original topic was the system's time zone. This hasn't anything
to do with the RTC clock, and only peripherally with "the system's
time zone" (of which some, me included, say "there's no such thing",
and others disagree :)

You have

- the RTC clock. This is *only* looked at at boot time, to init
the system clock (and when you, as an admin, do "hwclock").
During those operations, it's important to know which timezone
the RTC is in, since this one /is/ in "human format. It was
intended to be read and set by humans, like your kitchen clock,
back then.

- the system clock: it boringly counts seconds. Since Epoch.
Since it has't hours or minutes, let alone weeks or months,
time zones don't even make sense to it. Sometimes it does
a leap second, but experts are torn on whether this was a
good idea at all. Have a look at [1] for an entrance to yet
another deep time rabbit hole.

- timezones and stuff: those happen whenever you want to convert
the system clock to hours, minutes, days, and other human
related stuff and back.

(if you have good net connectivity, reading the RTC at boot can
be shunned completely, you don't need it anymore).

Please, keep those three at a safe distance.

Cheers

[1] https://en.wikipedia.org/wiki/International_Atomic_Time

[Jeffrey Walton]

Post by t***@tuxteam.de
[...]

Post by Jeffrey Walton

Post by Greg Wooledge
I strongly disagree. The system clock is kept on "epoch time", which
is the number of seconds since midnight, January 1, 1970 UTC.
The system clock doesn't have a time zone of its own. It just gets
converted to a time and date within any given time zone on demand.

++.
The sharp edge is how the RTC clock is set - UTC or localtime. Also
see <https://wiki.debian.org/DateTime>.

Please don't mix those three things, that makes them just more confusing.
The original topic was the system's time zone. This hasn't anything
to do with the RTC clock, and only peripherally with "the system's
time zone" (of which some, me included, say "there's no such thing",
and others disagree :)
You have
- the RTC clock. This is *only* looked at at boot time, to init
the system clock (and when you, as an admin, do "hwclock").
During those operations, it's important to know which timezone
the RTC is in, since this one /is/ in "human format. It was
intended to be read and set by humans, like your kitchen clock,
back then.
- the system clock: it boringly counts seconds. Since Epoch.
Since it has't hours or minutes, let alone weeks or months,
time zones don't even make sense to it. Sometimes it does
a leap second, but experts are torn on whether this was a
good idea at all. Have a look at [1] for an entrance to yet
another deep time rabbit hole.
- timezones and stuff: those happen whenever you want to convert
the system clock to hours, minutes, days, and other human
related stuff and back.
(if you have good net connectivity, reading the RTC at boot can
be shunned completely, you don't need it anymore).

Don't forget boottime and the delta between boottime and the monotonic
clock. You'll need them to explain this:

$ TZ=America/New_York dmesg -T | head -1
[Wed Jun 19 01:50:14 2024] Linux version 6.9.4-200.fc40.x86_64 (***@d372fa
1a67e347178b7bd422ead09b96) (gcc (GCC) 14.1.1 20240607 (Red Hat 14.1.1-5), GNU l
d version 2.41-37.fc40) #1 SMP PREEMPT_DYNAMIC Wed Jun 12 13:33:34 UTC 2024

$ TZ=America/California dmesg -T | head -1
[Wed Jun 19 05:50:14 2024] Linux version 6.9.4-200.fc40.x86_64 (***@d372fa
1a67e347178b7bd422ead09b96) (gcc (GCC) 14.1.1 20240607 (Red Hat 14.1.1-5), GNU l
d version 2.41-37.fc40) #1 SMP PREEMPT_DYNAMIC Wed Jun 12 13:33:34 UTC 2024

Post by t***@tuxteam.de
Please, keep those three at a safe distance

I'm not sure how you can disgorge them given they contribute to a
human readable time.

Jeff

[t***@tuxteam.de]

[...]

Post by Jeffrey Walton

Post by t***@tuxteam.de
Please, keep those three at a safe distance

I'm not sure how you can disgorge them given they contribute to a
human readable time.

I wasn't arguing to disgorge anything -- actually I tend towards
non-violence most of the time :)

Perhaps I should have added "... from each other" to my phrase
above to make that clearer.

Cheers

[Max Nikulin]

Post by t***@tuxteam.de
"the system's
time zone" (of which some, me included, say "there's no such thing",
and others disagree 🙂

What term is appropriate in your opinion do describe the setting stored
as the /etc/localtime symlink? localtime(5)

Post by t***@tuxteam.de
Especially that bit with the "system timezone". Reminds me of some
remote past, where a system actually had a timezone (and changed its
clock twice a year). Back then we used to set all our networked
Windows boxen to a time zone without summer time change (ISTR it
was Monrovia/Liberia) to avoid having our Makefiles freaking out
twice a year.

I recall a checkbox do disable DST in Windows 95 or Windows 98, so
perhaps searching for a timezone without DST was not necessary. By the
way, <https://stackoverflow.com/tags/timezone/info> describes another
style of identifiers in the Microsoft TZ DB. At certain point I have
realized that "time zone" and "timezone" have a bit different meaning in
the case of the IANA database <https://data.iana.org/time-zones/theory.html>

[Greg Wooledge]

Post by t***@tuxteam.de
"the system's
time zone" (of which some, me included, say "there's no such thing",
and others disagree 🙂

What term is appropriate in your opinion do describe the setting stored as
the /etc/localtime symlink? localtime(5)

I've been using "system default time zone", for lack of a better phrase.
I feel it's important to convey that this is *not* a global setting that
affects "the system" in some universal way. Like, for example, changing
where /etc/localtime points will (probably) *not* change the behavior
of any programs that are already running. Nor will it change the behavior
of any programs that have the TZ environment variable set, or any that
simply ignore time zones and write everything in UTC or TAI64 or whatever.

It's just a default that many, but not all, programs may use when they run.

[t***@tuxteam.de]

[...]

Well, that's a mouthful. And what am I to call the time that a system
issues using that system default time zone? If I boot up two computers
and they display different times, what term is appropriate in your
opinion to describe the time displayed?

The first step would be to realize that it's not the "computers" doing
the time display, but some processes running on them, and *those* are
the ones with the time zone (either default or explicitly set).

Cheers

[David Wright]

Post by t***@tuxteam.de
[...]

Well, that's a mouthful. And what am I to call the time that a system
issues using that system default time zone? If I boot up two computers
and they display different times, what term is appropriate in your
opinion to describe the time displayed?

The first step would be to realize that it's not the "computers" doing
the time display, but some processes running on them, and *those* are
the ones with the time zone (either default or explicitly set).

Yes, I realise that. The times are being displayed by the gettys,
controlled by the /etc/issue format string. Jobs are being run
by cron, logs written by rsyslogd, and so on. And the term is … ?

Cheers,
David.

[Stefan Monnier]

Post by David Wright
Yes, I realise that. The times are being displayed by the gettys,
controlled by the /etc/issue format string. Jobs are being run
by cron, logs written by rsyslogd, and so on. And the term is … ?

Maybe there simply isn't such a term. The subject is sufficiently
complex/delicate that there can't be a term for every single situation.


Stefan

[Nicholas Geovanis]

Post by Stefan Monnier

Post by David Wright
Yes, I realise that. The times are being displayed by the gettys,
controlled by the /etc/issue format string. Jobs are being run
by cron, logs written by rsyslogd, and so on. And the term is 
 ?

Maybe there simply isn't such a term. The subject is sufficiently
complex/delicate that there can't be a term for every single situation.

I think we are losing sight of the fact that all of timekeeping is an
abstraction and over-generalization. Time zones were created to help
regularize railroad schedules over wide areas. Timezones are an abstraction
that permit us to _pretend_ that it is (physical) noon at the same clock
time over an extended area. When in fact physical high-noon, determined by
the sun's position in the sky, cannot be at the exact same time just a few
centimeters west or east of my eyeballs.

Stefan

[Keith Bainbridge]

Post by David Wright
Yes, I realise that. The times are being displayed by the gettys,
controlled by the /etc/issue format string.  Jobs are being run
by cron, logs written by rsyslogd, and so on. And the term is … ?

Maybe there simply isn't such a term.  The subject is sufficiently
complex/delicate that there can't be a term for every single situation.
I think we are losing sight of the fact that all of timekeeping is an
abstraction and over-generalization. Time zones were created to help
regularize railroad schedules over wide areas. Timezones are an
abstraction that permit us to _pretend_ that it is (physical) noon at
the same clock time over an extended area. When in fact physical high-
noon, determined by the sun's position in the sky, cannot be at the
exact same time just a few centimeters west or east of my eyeballs.
        Stefan

I can't resist.

Have you ever pondered why the 'international date line' is so convoluted?

I reckon it would have been (almost) straight if UTC was set about 11°
west of it's current position.

Any chance of fixing it? Probably even less now that UK has left the EU.

As for odd time zones, we have a narrow one, somewhere between the West
Australian border (with Sth Aust) and the first notable town on the road
West - Norseman. It's 45 mins different from Sth Aust and the a further
45 mins to main stream West Aust. There might be 10,000 people live
within it. I think that somewhere is Baledonia. I'll check next time
I drive over, but that'll be sometime next year, if I'm lucky.
--
All the best

Keith Bainbridge

***@gmail.com
***@gmail.com
[phone]

UTC + 10:00

[David Wright]

Post by Keith Bainbridge
Have you ever pondered why the 'international date line' is so convoluted?

Only on the odd occasion when an area decides to cross it, for
whatever reason. Like Samoa recently. And before that, the
creation of Pacific/Kiritimati (+14:00), which became a press
story at the start of the new millennium.

Post by Keith Bainbridge
As for odd time zones, we have a narrow one, somewhere between the
West Australian border (with Sth Aust) and the first notable town on
the road West - Norseman. It's 45 mins different from Sth Aust and the
a further 45 mins to main stream West Aust. There might be 10,000
people live within it.

$ TZ=Pacific/Kiritamati date; TZ=Australia/Eucla date
Sun Jun 23 04:24:54 Pacific 2024
Sun Jun 23 13:09:54 +0845 2024
$

Cheers,
David.

[Keith Bainbridge]

Post by David Wright

Post by Keith Bainbridge
Have you ever pondered why the 'international date line' is so convoluted?

Only on the odd occasion when an area decides to cross it, for
whatever reason. Like Samoa recently. And before that, the
creation of Pacific/Kiritimati (+14:00), which became a press
story at the start of the new millennium.

+14:00?? I've only ever heard of maxima of +/- 12:00. But see below

Post by David Wright

Post by Keith Bainbridge
As for odd time zones, we have a narrow one, somewhere between the
West Australian border (with Sth Aust) and the first notable town on
the road West - Norseman. It's 45 mins different from Sth Aust and the
a further 45 mins to main stream West Aust. There might be 10,000
people live within it.

$ TZ=Pacific/Kiritamati date; TZ=Australia/Eucla date
Sun Jun 23 04:24:54 Pacific 2024
Sun Jun 23 13:09:54 +0845 2024
$

So Eucla: Sun Jun 23 13:09:54 would be UTC: Sun Jun 23 04:24:54
How do we get that time in the middle of the Pacific? Surely it would be
Sat Jun22 18:24:54


And then I see a LOT of discussion on my suggestion about how MUA format
the send time when people reply. I'll get back to that later.

Post by David Wright
Cheers,
David.

--
All the best

Keith Bainbridge

***@gmail.com
***@gmail.com
[phone]

UTC + 10:00

[gene heskett]

Post by David Wright

Post by Keith Bainbridge
Have you ever pondered why the 'international date line' is so convoluted?

Only on the odd occasion when an area decides to cross it, for
whatever reason. Like Samoa recently. And before that, the
creation of Pacific/Kiritimati (+14:00), which became a press
story at the start of the new millennium.

+14:00??   I've only ever heard of maxima of +/- 12:00.   But see below

A attribute the FCC forced on broadcasters as they like to see
transmitter logs kept in 24 hour time. I got so used to it that when I
retired in 2002, I'd been on 24 hour time for 40 years and didn't
convert back to two 12 hour periods a day. The AM/PM convention. So
when I say its 22:30, its 10:30 PM to the neighbors next door.

Post by David Wright

Post by Keith Bainbridge
As for odd time zones, we have a narrow one, somewhere between the
West Australian border (with Sth Aust) and the first notable town on
the road West - Norseman. It's 45 mins different from Sth Aust and the
a further 45 mins to main stream West Aust.  There might be 10,000
people live within it.

$ TZ=Pacific/Kiritamati date; TZ=Australia/Eucla date
Sun Jun 23 04:24:54 Pacific 2024
Sun Jun 23 13:09:54 +0845 2024
$

So Eucla: Sun Jun 23 13:09:54 would be UTC: Sun Jun 23 04:24:54
How do we get that time in the middle of the Pacific? Surely it would be
Sat Jun22 18:24:54
And then I see a LOT of discussion on my suggestion about how MUA format
the send time when people reply.     I'll get back to that later.

Post by David Wright
Cheers,
David.

Cheers, Gene Heskett, CET.

[e***@gmx.us]

A attribute the FCC forced on broadcasters as they like to see transmitter
logs kept in 24 hour time. I got so used to it that when I retired in 2002,
I'd been on 24 hour time for 40 years and didn't convert back to two 12 hour
periods a day.

I started using 24 hour time in junior high school with digital watches. I
just thought it made more sense, especially for setting alarms. Several
decades later I've not seen any reason to change, though it annoys my wife.

--
"Hear Me, for I am The Lord. I have seen your browser history, and am
wroth before it. Thus I shall strike down from the heavens a mighty blast,
and lo, [thou] shalt no longer have access to the naughty pictures."
sudo sudo The Book of Support, Chap 404 -- Osiris32 on TFTS

[gene heskett]

A attribute the FCC forced on broadcasters as they like to see transmitter
logs kept in 24 hour time. I got so used to it that when I retired in 2002,
I'd been on 24 hour time for 40 years and didn't convert back to two 12 hour
periods a day.

I started using 24 hour time in junior high school with digital watches.  I
just thought it made more sense, especially for setting alarms.  Several
decades later I've not seen any reason to change, though it annoys my wife.

Digital watches were much later, not arriving till the later 70's, and
may have bothered my wives. but not enough to start a discussion over.
One could say tongue in cheek, that I've had the ultimate revenge,
outliving 3 of them now. Position open, must be able hold my coffee
while watching something I'm doing.

--
"Hear Me, for I am The Lord. I have seen your browser history, and am
wroth before it. Thus I shall strike down from the heavens a mighty blast,
and lo, [thou] shalt no longer have access to the naughty pictures."
sudo sudo The Book of Support, Chap 404 -- Osiris32 on TFTS
.

Cheers, Gene Heskett, CET.

[Curt]

Post by gene heskett
A attribute the FCC forced on broadcasters as they like to see
transmitter logs kept in 24 hour time. I got so used to it that when I
retired in 2002, I'd been on 24 hour time for 40 years and didn't
convert back to two 12 hour periods a day. The AM/PM convention. So
when I say its 22:30, its 10:30 PM to the neighbors next door.

Here in France I grew used to it very easily, and now the AM PM convention
seems wrought with potential error. I'm sure we've crashed a space vehicle or
two do to the potential for conflating the two, like we did when we
mixed up miles for kilometers (or vice-versa).

When my mom came to visit one time in the nineties she requested I
change my alarm clock to AM PM time (it is now 15:25 here in the Gallic
regions, where the weather has finally turned summery after forty days and
forty nights of rain).

Celsius too is only a matter of habit. 30° is hot; you don't translate
anymore. It is what it is. Like a pomme is an apple and une feuille is a
leaf. You can become confused, though, when filling out US forms where
the birth date is written M/D/Y instead of D/M/Y, and sometimes you have
to be careful not commit the silly mistake that will entrain months
of delay in intricate *dédales* of the administration.

[Curt]

Post by Curt

Post by gene heskett
A attribute the FCC forced on broadcasters as they like to see
transmitter logs kept in 24 hour time. I got so used to it that when I
retired in 2002, I'd been on 24 hour time for 40 years and didn't
convert back to two 12 hour periods a day. The AM/PM convention. So
when I say its 22:30, its 10:30 PM to the neighbors next door.

Here in France I grew used to it very easily, and now the AM PM convention
seems wrought with potential error. I'm sure we've crashed a space vehicle or

fraught!!!

Post by Curt
two do to the potential for conflating the two, like we did when we
mixed up miles for kilometers (or vice-versa).
When my mom came to visit one time in the nineties she requested I
change my alarm clock to AM PM time (it is now 15:25 here in the Gallic
regions, where the weather has finally turned summery after forty days and
forty nights of rain).
Celsius too is only a matter of habit. 30° is hot; you don't translate
anymore. It is what it is. Like a pomme is an apple and une feuille is a
leaf. You can become confused, though, when filling out US forms where
the birth date is written M/D/Y instead of D/M/Y, and sometimes you have
to be careful not commit the silly mistake that will entrain months
of delay in intricate *dédales* of the administration.

--

[Bret Busby]

Post by Curt

Post by gene heskett
A attribute the FCC forced on broadcasters as they like to see
transmitter logs kept in 24 hour time. I got so used to it that when I
retired in 2002, I'd been on 24 hour time for 40 years and didn't
convert back to two 12 hour periods a day.  The AM/PM convention. So
when I say its 22:30, its 10:30 PM to the neighbors next door.

Here in France I grew used to it very easily, and now the AM PM convention
seems wrought with potential error. I'm sure we've crashed a space vehicle or
two do to the potential for conflating the two, like we did when we
mixed up miles for kilometers (or vice-versa).
When my mom came to visit one time in the nineties she requested I
change my alarm clock to AM PM time (it is now 15:25 here in the Gallic
regions, where the weather has finally turned summery after forty days and
forty nights of rain).
Celsius too is only a matter of habit. 30° is hot; you don't translate
anymore. It is what it is. Like a pomme is an apple and une feuille is a
leaf. You can become confused, though, when filling out US forms where
the birth date is written M/D/Y instead of D/M/Y, and sometimes you have
to be careful not commit the silly mistake that will entrain months
of delay in intricate *dédales* of the administration.

AM/PM would not be so strange if between 11AM and 1 PM it was 12 AM ...

The correct format for the 24 hour clock time, does not include a colon
between the hours and the minutes - 10:30pm is 2230 in the 24 hour clock
format.

Regarding the reference to degrees Celsius, as a person who remembers
the switchover (in this region) from degrees Fahrenheit to the "metric"
system, it is easy to remember, using the alternative name for the
temperature units; at the time of the switch, it was used - Centigrade,
as it was based on a 100 degree system, whereby zero degrees Centigrade,
is the freezing point of (pure) water, at standard atmospheric pressure,
and, one hundred degrees Centigrade, is the boiling point of (pure)
water at standard atmospheric pressure.

And, degrees Centigrade (which is the name that I always use, not
Celsius, as Centigrade is a meaningful name), is far more easy to
comprehend, than either Fahrenheit (of the imperial system of units),
or, Kelvin units (which does not include the use of the term "degrees"),
whereby, from memory, zero degrees Centigrade, is 273.15 Kelvin units,
if my memory is correct.

And, methinks that this content is, or, has become, somewhat off-topic...

..
Bret Busby
Armadale
West Australia
(UTC+0800)
..............

[Bret Busby]

On 24/6/24 21:38, Curt wrote:

<snip>

Post by Curt
You can become confused, though, when filling out US forms where
the birth date is written M/D/Y instead of D/M/Y, and sometimes you have
to be careful not commit the silly mistake that will entrain months
of delay in intricate *dédales* of the administration.

This is because the USA is a few hundred years behind the rest of the
world, and, cannot comprehend ISO standards -
the ISO standard for date, is
2024-06-24
YYYY-MM-DD

which is the most efficient way of expressing a date, using the
components of year and month and day of the month

But, for a country that has yet to implement its constitution, it is not
really so surprising.

..
Bret Busby
Armadale
West Australia
(UTC+0800)
..............

[e***@gmx.us]

Post by Bret Busby
<snip>

Post by Curt
You can become confused, though, when filling out US forms where
the birth date is written M/D/Y instead of D/M/Y, and sometimes you have
to be careful not commit the silly mistake that will entrain months
of delay in intricate *dédales* of the administration.

This is because the USA is a few hundred years behind the rest of the world,
and, cannot comprehend ISO standards -
the ISO standard for date, is
2024-06-24
YYYY-MM-DD
which is the most efficient way of expressing a date, using the components
of year and month and day of the month

I use that format where I can because ASCII sorting == date sorting. No
weird mental gymnastics required.

--
AQUARIUS: There's travel in your future when your tongue freezes to the
back of a speeding bus. Fill the void in your pathetic life by playing
Whack-a-Mole 17 hours a day. -- Weird Al, _Your Horoscope for Today_

[Felix Miata]

The USA is a few hundred years behind the rest of the
world, and, cannot comprehend ISO standards -
the ISO standard for date, is
2024-06-24
YYYY-MM-DD
which is the most efficient way of expressing a date, using the
components of year and month and day of the month
But, for a country that has yet to implement its constitution, it is not
really so surprising.

We aren't always forced. Some devices offer only AM/PM time format and schizoid
date format, but not my hand or PCs, and neither our military. Cars and outboard
boat engines made outside the USA come to us with metric fasteners. We have 75mm,
100mm, 200mm and/or 400mm spacing on the backs of most display screens too! :) DPI
for screen densities I think we may be stuck with quite a while longer. :p

[The Wanderer]

AM/PM would not be so strange if between 11AM and 1 PM it was 12 AM
...

Although I don't think anything or anyone actually does it this way, I
think strictly speaking the correct 12-hour notation for that time would
be "12:00 M" - followed by 12:00:01 PM, and preceded by 11:59:59 AM.

AM stands for "ante meridiem", i.e., before the midpoint; PM stands for
"post meridiem", i.e., after the midpoint. The only correct term for the
time that is exactly the midpoint would be "meridiem", and therefore, M.

(Similar logic could be used for 11:59:59 PM, 12:00 M, and 12:00:01 AM,
where the standalone M would stand for "midnight". That does expose one
unfortunate weakness of this system: unless you introduce an additional
layer of complexity, e.g. using "00:00 M", the notations for noon and
midnight would be identical.)

[John Hasler]

Post by The Wanderer
(Similar logic could be used for 11:59:59 PM, 12:00 M, and 12:00:01 AM,
where the standalone M would stand for "midnight". That does expose one
unfortunate weakness of this system: unless you introduce an additional
layer of complexity, e.g. using "00:00 M", the notations for noon and
midnight would be identical.)

12 Noon and 12 Midnight works.

[The Wanderer]

Post by John Hasler

Post by The Wanderer
(Similar logic could be used for 11:59:59 PM, 12:00 M, and 12:00:01 AM,
where the standalone M would stand for "midnight". That does expose one
unfortunate weakness of this system: unless you introduce an additional
layer of complexity, e.g. using "00:00 M", the notations for noon and
midnight would be identical.)

12 Noon and 12 Midnight works.

Except that "noon" doesn't begin with "m", and therefore "12:00 noon"
can't be abbreviated to "12:00 M".

I think that (plus the fact of "ante meridiem"/"post meridiem") was
probably what I was drawing on in coming up with the idea in the first
place.

[Greg Wooledge]

Post by David Wright
creation of Pacific/Kiritimati (+14:00), which became a press
story at the start of the new millennium.
$ TZ=Pacific/Kiritamati date; TZ=Australia/Eucla date
Sun Jun 23 04:24:54 Pacific 2024
Sun Jun 23 13:09:54 +0845 2024
$

Typo there; you misspelled "Kiritimati" in the command.

hobbit:~$ TZ=Pacific/Kiritimati date; TZ=Australia/Eucla date
Mon Jun 24 02:39:17 +14 2024
Sun Jun 23 21:24:17 +0845 2024

The fact that date(1) treats any misspelled or otherwise incorrect TZ
variable as if it were UTC, but then goes on to write the mispelled
time zone name in its *output*, as if it were actually being recognized,
has tripped me up in the past. I really wish it would just throw an
error... but it doesn't.

[David Wright]

Post by Greg Wooledge

Post by David Wright
creation of Pacific/Kiritimati (+14:00), which became a press
story at the start of the new millennium.
$ TZ=Pacific/Kiritamati date; TZ=Australia/Eucla date
Sun Jun 23 04:24:54 Pacific 2024
Sun Jun 23 13:09:54 +0845 2024
$

Typo there; you misspelled "Kiritimati" in the command.
hobbit:~$ TZ=Pacific/Kiritimati date; TZ=Australia/Eucla date
Mon Jun 24 02:39:17 +14 2024
Sun Jun 23 21:24:17 +0845 2024

Yes, I corrected it, but then carelessly pasted the incorrect lines.

Post by Greg Wooledge
The fact that date(1) treats any misspelled or otherwise incorrect TZ
variable as if it were UTC, but then goes on to write the mispelled
time zone name in its *output*, as if it were actually being recognized,
has tripped me up in the past. I really wish it would just throw an
error... but it doesn't.

Yes, In the meantime, a function something like this might help:

$ type whattime
whattime is a function
whattime ()
{
[ -z "$1" ] && msgerr "Usage: ${FUNCNAME[0]} place
prints the present time at place (a filename in the zoneinfo lists).
For today's expiration (AoE), use the legacy name, GMT+12." && return 1;
local Where;
find /usr/share/zoneinfo/ \( -type f -o -type l \) | sed -E 's/^[^A-Z]+//;s/GMT\+12/AoE/' | grep -v [0-9] | sed -E 's/AoE/GMT\+12/' | sort -u | grep -i -e "^$1$" -e "/$1$" | while read Where; do
printf '%s ' "$Where";
TZ="$Where" date '+%Y-%m-%d %T %z %A';
done
}
$ for j in kiritimati eucla comodrivadavia samoa gmt+12 factory; do whattime "$j"; done
Pacific/Kiritimati 2024-06-24 13:54:22 +1400 Monday
Australia/Eucla 2024-06-24 08:39:22 +0845 Monday
America/Argentina/ComodRivadavia 2024-06-23 20:54:22 -0300 Sunday
Pacific/Samoa 2024-06-23 12:54:22 -1100 Sunday
US/Samoa 2024-06-23 12:54:22 -1100 Sunday
Etc/GMT+12 2024-06-23 11:54:22 -1200 Sunday
Factory 2024-06-23 23:54:22 -0000 Sunday
$

Cheers,
David.

[Curt]

Post by Nicholas Geovanis
I think we are losing sight of the fact that all of timekeeping is an
abstraction and over-generalization. Time zones were created to help
regularize railroad schedules over wide areas. Timezones are an abstraction
that permit us to _pretend_ that it is (physical) noon at the same clock
time over an extended area. When in fact physical high-noon, determined by
the sun's position in the sky, cannot be at the exact same time just a few
centimeters west or east of my eyeballs.

Autrement dit, chacun voit midi à sa porte.
--

[Greg Wooledge]

And what am I to call the time that a system
issues using that system default time zone?

If you mean the current time translated into that time zone, "local time"
is the traditional name for it.

If you mean an arbitrary past time, then it's just whatever the time
string says. "Three fifteen PM" or what have you. You're probably
reading log files or something, so it's convenient to have the times
presented in your own local time zone (assuming this matches the system's
default). This lets you align the log messages with any events that
you happen to remember ("hmm, that was about when the lightning storm
started"), or with logs from other computers.

Setting /etc/localtime to *your* time zone, assuming you're the primary
system administrator, just makes your life easier. That's all.

If I boot up two computers
and they display different times, what term is appropriate in your
opinion to describe the time displayed?

They're out of sync. Or, at least one of them is. At this point
you check the NTP settings on both of them to find out which one is
at fault, and how to get it fixed. Maybe you check a wall clock or a
wrist watch or a cell phone as an independent time authority.

Or did you mean "the same time, but in two different time zones"? If
you displayed these times by running "date", which respects both the
TZ environment variable and the /etc/localtime symlink, then you figure
out which of them is set to an undesired value. And then you fix it.
Or, if it's set how you *want* it, then you leave it alone.

[David Wright]

Post by Greg Wooledge

And what am I to call the time that a system
issues using that system default time zone?

If you mean the current time translated into that time zone, "local time"
is the traditional name for it.

That might have worked when computers were big and heavy, but that's
no longer the case. When you travel with your laptop, there could be
two different local times, your one displayed by the computer, and
the real local time that tells you when "last orders" will be called
in the local pub.

Post by Greg Wooledge

If I boot up two computers
and they display different times, what term is appropriate in your
opinion to describe the time displayed?

They're out of sync. Or, at least one of them is.

No, the kernel clocks are all in sync.

Post by Greg Wooledge
Or did you mean "the same time, but in two different time zones"? If
you displayed these times by running "date", which respects both the
TZ environment variable and the /etc/localtime symlink, then you figure
out which of them is set to an undesired value. And then you fix it.
Or, if it's set how you *want* it, then you leave it alone.

Yes, they're set as desired. But now you've used 1.3k in your post,
and I still don't have my adjective. The computers issue different
times, because they're being used by different people for different
purposes like in an internet café. I need to tell these people what
time they're set to. I say to them "this system is on Dubai time, and
that one's on Bahrain time. They know exactly what I mean, but what's
the term for those times? (Other than system time, which is what I'd
call it.) And it's not "local time", because the ferry we're on is
about to leave Karachi, so clocks will be showing PKT.

Cheers,
David.

[Greg Wooledge]

Post by David Wright

Post by Greg Wooledge

If I boot up two computers
and they display different times, what term is appropriate in your
opinion to describe the time displayed?

They're out of sync. Or, at least one of them is.

No, the kernel clocks are all in sync.

Then you were unclear. You said "they display different times". That
means one of them is wrong. The other one may be right, or they may
both be wrong.

Post by David Wright

Post by Greg Wooledge
Or did you mean "the same time, but in two different time zones"? If

The following are the same time, but in two different time zones:

12:00:00 -0500
13:00:00 -0400

The following are different times:

12:00:00 -0500
12:26:00 -0500

Post by David Wright
Yes, they're set as desired.

So you meant "the same time, but in different time zones". You should
have said that.

Post by David Wright
But now you've used 1.3k in your post,

Because I have to write AROUND your errors!!

Post by David Wright
and I still don't have my adjective.

Pick any damned word you want, then. I'm done caring.

Set your computer the way you want to set it.

[David Wright]

Post by Greg Wooledge

Post by David Wright

Post by Greg Wooledge

If I boot up two computers
and they display different times, what term is appropriate in your
opinion to describe the time displayed?

They're out of sync. Or, at least one of them is.

No, the kernel clocks are all in sync.

Then you were unclear. You said "they display different times". That
means one of them is wrong. The other one may be right, or they may
both be wrong.

None of them is wrong. They're both showing the time appropriate for
the nationality of the passengers who are going to be directed to them.

Post by Greg Wooledge

Post by David Wright

Post by Greg Wooledge
Or did you mean "the same time, but in two different time zones"? If

12:00:00 -0500
13:00:00 -0400
12:00:00 -0500
12:26:00 -0500

Post by David Wright
Yes, they're set as desired.

So you meant "the same time, but in different time zones". You should
have said that.

That's how you and I see them, but a passenger from Bahrain, say,
sees things differently. They just want to be directed to a system
on Bahraini time, just like ones at home.

That expression caused consternation in some.

Post by Greg Wooledge
Pick any damned word you want, then. I'm done caring.

Yes, I picked "system", as in Operating System, and not Kernel.

Cheers,
David.

[Jeffrey Walton]

[...]
Well, that's a mouthful. And what am I to call the time that a system
issues using that system default time zone?

The kernel clock counts ticks. The ticks are relative to Epoch, which
is UTC. Ticks are what you see in the output of dmesg. So maybe call
it UTC, GMT or Zulu?

If I boot up two computers
and they display different times, what term is appropriate in your
opinion to describe the time displayed?

The NTP folks call them timekeepers when they are correct, and
falsetickers when they are incorrect. But "them" are timeservers
participating in the NTP protocol. See
<https://www.ntp.org/reflib/papers/ptti.pdf> and RFC 5905,
<https://datatracker.ietf.org/doc/html/rfc5905>.

If the OS is not keeping accurate time, then I would call it a falseticker.

If you only boot two computers, then you cannot be sure which computer
is the falseticker. You need three or more time sources to determine
which is the falseticker. As the saying goes, a person with a watch
knows what time it is. A person with two watches is never sure.

Jeff

[t***@tuxteam.de]

Post by t***@tuxteam.de
"the system's
time zone" (of which some, me included, say "there's no such thing",
and others disagree 🙂

What term is appropriate in your opinion do describe the setting stored as
the /etc/localtime symlink? localtime(5)

The default time zone (i.e. that one which is used when some
process calls for one and hasn't specified one itself).

Post by t***@tuxteam.de
Especially that bit with the "system timezone". Reminds me of some
remote past, where a system actually had a timezone (and changed its
clock twice a year). Back then we used to set all our networked
Windows boxen to a time zone without summer time change (ISTR it
was Monrovia/Liberia) to avoid having our Makefiles freaking out
twice a year.

I recall a checkbox do disable DST in Windows 95 or Windows 98, so perhaps
searching for a timezone without DST was not necessary.

It's a log time ago, but we were a shop with a few pretty knowledgeable folks,
so I guess we first tried something like that.

By the way,
<https://stackoverflow.com/tags/timezone/info> describes another style of
identifiers in the Microsoft TZ DB. At certain point I have realized that
"time zone" and "timezone" have a bit different meaning in the case of the
IANA database <https://data.iana.org/time-zones/theory.html>

It's a complex matter, yes. Food for nerds :)

Cheers

[Max Nikulin]

Post by t***@tuxteam.de

Post by t***@tuxteam.de
"the system's
time zone" (of which some, me included, say "there's no such thing",
and others disagree 🙂

What term is appropriate in your opinion do describe the setting stored as
the /etc/localtime symlink? localtime(5)

The default time zone (i.e. that one which is used when some
process calls for one and hasn't specified one itself).

So you just believe that "system" is confusing. However other
configuration files may be taken into account, e.g.
~/.config/ktimezonedrc for *default* timezone in KDE session of the
specific user. From my point of view, adding "system-wide" to "default
timezone" leaves less room for ambiguity.

It is still important that neither TZ environment nor /etc/localtime
must be respected by all processes. Anyway POSIX and libc are not
designed for applications that need to work with multiple timezones
simultaneously, so any system-wide hints may be disregarded.

I think, you are biased treating "system" as tightly built-in while most
of others assume "system-wide".

[t***@tuxteam.de]

On Sat, Jun 22, 2024 at 10:22:53AM +0700, Max Nikulin wrote:

[...]

I think, you are biased treating "system" as tightly built-in while most of
others assume "system-wide".

Taking your bias out ("you are biased" -- "most of others") I'd
tend to agree :-)

You do have a point. Coming from the UNIX tradition, for me, X,
for example, isn't part of "the operating system". Much less a
desktop environment. For those coming from a Windows tradition
(remember: Microsoft once argued they couldn't remove Internet
Explorer from Windows for "technical reasons"?), it's the other
way around.

Cheers

[t***@tuxteam.de]

[...]

Post by t***@tuxteam.de

I recall a checkbox do disable DST in Windows 95 or Windows 98, so perhaps
searching for a timezone without DST was not necessary.

It's a log time ago, but we were a shop with a few pretty knowledgeable folks,
so I guess we first tried something like that.

HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation\RealTimeIsUniversal
that you could set to 1 for UTC. I don't remember when it was
introduced. And, of course, it might have been present but
undocumented for years.

Possible. I was happy to forget that I had anything to do with
Windows :-)

Cheers

[Keith Bainbridge]

Post by t***@tuxteam.de
Possible. I was happy to forget that I had anything to do with
Windows 🙂

Especially delving into the registry
--
All the best

Keith Bainbridge

***@gmail.com
***@gmail.com
[phone]

UTC + 10:00

[Keith Bainbridge]

Styles change: there's a tendency in
English to evolve towards compound words, sometimes with hyphenation
along the way.

Not to mention some cultures change how words are spelt: colour, odour,
metres to quote a few.

But don't fret. Some people pronounce the word for 1,000 metres as a
measure of kills - kil-ometer. It should be kilo-metre. To support my
agruement, try speedometer, gasometer, odometer.
--
All the best

Keith Bainbridge

***@gmail.com
***@gmail.com
[phone]

UTC + 10:00

[John Hasler]

Due, mainly, to the literacy of the people that moved, rather than any
deliberate choice. That is, spelling was often a 'best guess'.

https://en.wikipedia.org/wiki/Webster's_Dictionary#Noah_Webster's_American_Dictionary_of_the_English_Language

[Stefan Monnier]

Post by David Wright

Post by Greg Wooledge
It's *theoretically* possible for some daemons to be configured to use
a different time zone, or to be hard-coded to use UTC. I've never seen
this, but it could be done.

In view of that, I think it's reasonable to drop the "default",
and go with "system time zone", ie the time zone that the system
clock it set to.

Funny, because I think on the contrary that the word "default" is key:
it conveys the information that this is just the time zone used by
default when converting a time to a human readable form.

You can drop "system" on the other hand, AFAIC. 🙂


Stefan

[d***@howorth.org.uk]

Post by Keith Bainbridge
It was late afternoon on 16Jun2024 that I wrote this. Possibly
18:13:36 when I pressed send. I'd reckon it would likely have been
08:13:36 UTC What's wrong with my system clock. I've not really
looked at the time on my originals before. I'll try to remember to
enter my local time as I press send

I'm confused. Your time displays (Keith) look sensible to me, given
they are in local time for somewhere like Brisbane.

The only confusing display to me is what Greg's MUA showed when quoting
your message. The time is correct but is shown in 12-hr +offset format,
which is a bit weird and is in contrast to the way his own message time
is displayed in 24-hr format.

[Greg Wooledge]

Post by d***@howorth.org.uk

Post by Keith Bainbridge
It was late afternoon on 16Jun2024 that I wrote this. Possibly
18:13:36 when I pressed send. I'd reckon it would likely have been
08:13:36 UTC What's wrong with my system clock. I've not really
looked at the time on my originals before. I'll try to remember to
enter my local time as I press send

I'm confused. Your time displays (Keith) look sensible to me, given
they are in local time for somewhere like Brisbane.
The only confusing display to me is what Greg's MUA showed when quoting
your message. The time is correct but is shown in 12-hr +offset format,
which is a bit weird and is in contrast to the way his own message time
is displayed in 24-hr format.

Mutt uses that 12-hour format by default. I just changed it in my
configuration. This message uses the 24-hour format instead.

[Keith Bainbridge]

Post by d***@howorth.org.uk

Post by Keith Bainbridge
It was late afternoon on 16Jun2024 that I wrote this. Possibly
18:13:36 when I pressed send. I'd reckon it would likely have been
08:13:36 UTC What's wrong with my system clock. I've not really
looked at the time on my originals before. I'll try to remember to
enter my local time as I press send

I'm confused. Your time displays (Keith) look sensible to me, given
they are in local time for somewhere like Brisbane.

Yes - except Brisbane remains in the dark ages and doesn't follow day
light saving; despite the fact that the majority of people want it.
Seems the controlling interests still think the sun will fade the
curtains or the cows won't know when to wake up to be milked. As if!
--
All the best

Keith Bainbridge

***@gmail.com
***@gmail.com
[phone]

UTC + 10:00

[Default User]

Post by Keith Bainbridge

Post by d***@howorth.org.uk

Post by Keith Bainbridge
It was late afternoon on 16Jun2024 that I wrote this. Possibly
18:13:36 when I pressed send. I'd reckon it would likely have been
08:13:36 UTC What's wrong with my system clock. I've not really
looked at the time on my originals before.  I'll try to remember
to
enter my local time as I press send

I'm confused. Your time displays (Keith) look sensible to me, given
they are in local time for somewhere like Brisbane.

Yes - except Brisbane remains in the dark ages and doesn't follow day
light saving; despite the fact that the majority of people want it.
Seems the controlling interests still think the sun will fade the
curtains or the cows won't know when to wake up to be milked. As if!

Hi, Keith. 
I really envy you.

How I wish I lived where Daylight Saving Time did not exist.

I do not intend to start a long "back-and-forth" about the subject, 
but I feel compelled to say that I absolutely despise the very idea of
Daylight Saving Time.

Standard Time, all the time!

:)

[From 2024-06-22, -0400 UTC]

[Keith Bainbridge]

Post by Keith Bainbridge
It was late afternoon on 16Jun2024 that I wrote this. Possibly 18:13:36
when I pressed send. I'd reckon it would likely have been 08:13:36 UTC
 What's wrong with my system clock. I've not really looked at the time
on my originals before.  I'll try to remember to enter my local time as
I press send

Evening folk - not good it seems. I can't find the separate thread that
some wise person kindly started for this topic. Mmmmmm

Thanks for those responses. When I find the thread again, I'll read ALL
the responses and respond better, if this doesn't reply to your general
suggestion.

I reskon that they seem to indicate that the date/time in my original
question are fine. the difficulty is more related to how we humans are
interpreting the information we are reading.

https://manpages.debian.org/bookworm/manpages-dev/strftime.3.en.html

is a list of place names for MANY parts of a date layout. I have set up
the following code in my text substitution app:
"%a %d%b%Y at %H:%M:%S =UTC %Z"

Triggering that give me
Thu 20Jun2024 at 20:51:19 =UTC +10:00

Seems to me that if the code writers of our various MUA would add the
+UTC to the line that prints the various dates, we'd understand what
they mean better.

Meantime, we have to accept what we have.

Thanks again.
--
All the best

Keith Bainbridge

***@gmail.com
***@gmail.com
[phone]

UTC + 10:00

[Greg Wooledge]

Post by Keith Bainbridge
https://manpages.debian.org/bookworm/manpages-dev/strftime.3.en.html
is a list of place names for MANY parts of a date layout. I have set up the
"%a %d%b%Y at %H:%M:%S =UTC %Z"
Triggering that give me
Thu 20Jun2024 at 20:51:19 =UTC +10:00
Seems to me that if the code writers of our various MUA would add the +UTC
to the line that prints the various dates, we'd understand what they mean
better.

Honestly, I have no idea what the =UTC part of your output is intended
to mean, since you've got +10:00 (time zone offset specification in hours
ahead of UTC) overriding it.

Normally, you put either the string UTC to indicate that this date/time
string is in UTC, or a time zone offset indicator that begins with + or -.
Not both.

[The Wanderer]

Post by Greg Wooledge

Post by Keith Bainbridge
https://manpages.debian.org/bookworm/manpages-dev/strftime.3.en.html
is a list of place names for MANY parts of a date layout. I have set up the
"%a %d%b%Y at %H:%M:%S =UTC %Z"
Triggering that give me
Thu 20Jun2024 at 20:51:19 =UTC +10:00
Seems to me that if the code writers of our various MUA would add the +UTC
to the line that prints the various dates, we'd understand what they mean
better.

Honestly, I have no idea what the =UTC part of your output is intended
to mean, since you've got +10:00 (time zone offset specification in hours
ahead of UTC) overriding it.

I parsed it as meaning "[date and time] is equal to UTC plus ten hours",
or in other words, "the time specified is in the UTC+10 time-zone".
Similarly to how I often seen Eastern Standard Time referenced as UTC-4
(that is, UTC minus four hours).

Post by Greg Wooledge
Normally, you put either the string UTC to indicate that this date/time
string is in UTC, or a time zone offset indicator that begins with + or -.
Not both.

It may be notable that he didn't put a +- offset indicator; he put a
format specifier which *expands to* whichever such indicator would
correspond to the active time zone.

[Keith Bainbridge]

Post by The Wanderer

Post by Greg Wooledge

Post by Keith Bainbridge
https://manpages.debian.org/bookworm/manpages-dev/strftime.3.en.html
is a list of place names for MANY parts of a date layout. I have set up the
"%a %d%b%Y at %H:%M:%S =UTC %Z"
Triggering that give me
Thu 20Jun2024 at 20:51:19 =UTC +10:00
Seems to me that if the code writers of our various MUA would add the +UTC
to the line that prints the various dates, we'd understand what they mean
better.

Honestly, I have no idea what the =UTC part of your output is intended
to mean, since you've got +10:00 (time zone offset specification in hours
ahead of UTC) overriding it.

I parsed it as meaning "[date and time] is equal to UTC plus ten hours",
or in other words, "the time specified is in the UTC+10 time-zone".
Similarly to how I often seen Eastern Standard Time referenced as UTC-4
(that is, UTC minus four hours).

Post by Greg Wooledge
Normally, you put either the string UTC to indicate that this date/time
string is in UTC, or a time zone offset indicator that begins with + or -.
Not both.

It may be notable that he didn't put a +- offset indicator; he put a
format specifier which *expands to* whichever such indicator would
correspond to the active time zone.

And doesn't this exchange show that
Sat 22Jun2024 at 18:27:55 +10:00

can be interpreted in two ways?
--
All the best

Keith Bainbridge

***@gmail.com
***@gmail.com
[phone]

UTC + 10:00

[Greg Wooledge]

Post by Keith Bainbridge
And doesn't this exchange show that
Sat 22Jun2024 at 18:27:55 +10:00
can be interpreted in two ways?

I can only read it one way. What other way are you thinking of?

[David Wright]

Post by Keith Bainbridge
It was late afternoon on 16Jun2024 that I wrote this. Possibly
18:13:36 when I pressed send. I'd reckon it would likely have been
08:13:36 UTC  What's wrong with my system clock. I've not really
looked at the time on my originals before.  I'll try to remember
to enter my local time as I press send

Thanks for those responses. [ … ]
I reskon that they seem to indicate that the date/time in my original
question are fine. the difficulty is more related to how we humans are
interpreting the information we are reading.
https://manpages.debian.org/bookworm/manpages-dev/strftime.3.en.html
is a list of place names for MANY parts of a date layout. I have set
"%a %d%b%Y at %H:%M:%S =UTC %Z"
Triggering that give me
Thu 20Jun2024 at 20:51:19 =UTC +10:00
Seems to me that if the code writers of our various MUA would add the
+UTC to the line that prints the various dates, we'd understand what
they mean better.
Meantime, we have to accept what we have.

You could pronounce your time written above as:

"It's Thu 20Jun2024 at 20:51:19 here, where clocks are UTC+10:00"

if that's indeed your intention. But what you've done is invent
some notation of your own, which people will likely misunderstand.

I think it best to look up these references and follow them:

https://en.wikipedia.org/wiki/ISO_8601
https://www.ietf.org/rfc/rfc3339.txt

IMHO I think that email attributions are best presented in and with
the time zone of the sender, and not oneself.

Cheers,
David.

[Keith Bainbridge]

Post by David Wright
"It's Thu 20Jun2024 at 20:51:19 here, where clocks are UTC+10:00"

Excellent. Now how do we get our MUA to do that when replying to mail,
which is where I saw what I thought was a system error - but in fact was
a misinterpretation.

Post by David Wright
if that's indeed your intention. But what you've done is invent
some notation of your own, which people will likely misunderstand.
https://en.wikipedia.org/wiki/ISO_8601
https://www.ietf.org/rfc/rfc3339.txt

Will do

Post by David Wright
IMHO I think that email attributions are best presented in and with
the time zone of the sender, and not oneself.

Maybe that would be achieved if the replyer's MUA inserted the senders
date/time more clearly. I don't mean to harp on, but maybe the coders
just haven't mis-read the dates they are inserting for us.

Post by David Wright
Cheers,
David.

--
All the best

Keith Bainbridge

***@gmail.com
***@gmail.com
[phone]

UTC + 10:00

[Greg Wooledge]

Post by Keith Bainbridge

Post by David Wright
"It's Thu 20Jun2024 at 20:51:19 here, where clocks are UTC+10:00"

Excellent. Now how do we get our MUA to do that when replying to mail,

Depends on your MUA. In mutt, it would be:

set date_format="!It's %a %d%b%Y at %H:%M:%S here, where clocks are UTC%z"

except that this won't put a colon inside the timezone offset. It
would just end with "UTC+1000".

Of course, you probably don't want that exact wording, because it's
used as *part* of the attribution. If you used the above, then the
attribution would come out looking like:

On It's Thu 20Jun2024 at 20:51:19 here, where clocks are UTC+1000, So-and-So wrote:

So, you'd either want to change the attribution variable as well, or
alter that wording slightly. I'd suggest removing "It's" and "here".

[David Wright]

Post by Greg Wooledge

Post by Keith Bainbridge

Post by David Wright
"It's Thu 20Jun2024 at 20:51:19 here, where clocks are UTC+10:00"

Excellent. Now how do we get our MUA to do that when replying to mail,

set date_format="!It's %a %d%b%Y at %H:%M:%S here, where clocks are UTC%z"
except that this won't put a colon inside the timezone offset. It
would just end with "UTC+1000".
Of course, you probably don't want that exact wording, because it's
used as *part* of the attribution. If you used the above, then the
So, you'd either want to change the attribution variable as well, or
alter that wording slightly. I'd suggest removing "It's" and "here".

I think you need to set attribution, not date_format. For example,
set attribution="On %{%a %d %b %Y} at %{%H:%M:%S (%z)}, %n wrote:"
is my own. The %{…} braces indicate using the sender's time zone.

Cheers,
David.

[Greg Wooledge]

Post by David Wright

Post by Greg Wooledge
set date_format="!It's %a %d%b%Y at %H:%M:%S here, where clocks are UTC%z"

I think you need to set attribution, not date_format. For example,
set attribution="On %{%a %d %b %Y} at %{%H:%M:%S (%z)}, %n wrote:"
is my own. The %{…} braces indicate using the sender's time zone.

The default value of attribution contains %d which references the
date_format variable. The "!" in the date_format variable says to
use the C locale when writing the day-of-week and month abbreviations,
rather than whatever your regular locale would call them.

I'm using this:

set date_format="!%a, %b %d, %Y at %H:%M:%S %z"

[David Wright]

Post by Greg Wooledge

Post by David Wright

Post by Greg Wooledge
set date_format="!It's %a %d%b%Y at %H:%M:%S here, where clocks are UTC%z"

I think you need to set attribution, not date_format. For example,
set attribution="On %{%a %d %b %Y} at %{%H:%M:%S (%z)}, %n wrote:"
is my own. The %{…} braces indicate using the sender's time zone.

The default value of attribution contains %d which references the
date_format variable. The "!" in the date_format variable says to
use the C locale when writing the day-of-week and month abbreviations,
rather than whatever your regular locale would call them.
set date_format="!%a, %b %d, %Y at %H:%M:%S %z"

I didn't mean that it won't work.

The attribution format is designed for the benefit of recipients.
The date_format is designed to be available for constructing
strings like indexes and folder lists for the user, as well as
external-facing uses. You might want to add text like "where clocks
are" to the top of a message, but it would be tedious to have a
column of
where clocks are
where clocks are
where clocks are
where clocks are
in an index.

Cheers,
David.

[David Wright]

Post by Keith Bainbridge

Post by David Wright
"It's Thu 20Jun2024 at 20:51:19 here, where clocks are UTC+10:00"

Excellent. Now how do we get our MUA to do that when replying to mail,
which is where I saw what I thought was a system error - but in fact
was a misinterpretation.

I don't see the point. The email has a "Date:" header.

Unless it's significant that your email is like a blog that's been
written over a period of time; chronicling current events, say.

Post by Keith Bainbridge

Post by David Wright
if that's indeed your intention. But what you've done is invent
some notation of your own, which people will likely misunderstand.
https://en.wikipedia.org/wiki/ISO_8601
https://www.ietf.org/rfc/rfc3339.txt

Will do

Post by David Wright
IMHO I think that email attributions are best presented in and with
the time zone of the sender, and not oneself.

Maybe that would be achieved if the replyer's MUA inserted the senders
date/time more clearly. I don't mean to harp on, but maybe the
coders just haven't mis-read the dates they are inserting for us.

They write Date: in the same format, often called RFC822 format,
see RFC 2822.

Cheers,
David.

[David Wright]

Post by Keith Bainbridge
Some of my aliases stopped working after months of working as I
expected. And udating the .bash_aliases kept giving me an error
referring to an end of file before the matching ' in one of the last
aliases. So I did some searching.

All the aliases that lie textually after the one with the missing '
will remain undefined, so you can use bisection to locate where in
the file problem lies.

Post by Keith Bainbridge
So, is an alias a form of variable? I had about 150 plus 4 functions

There's little chance of hitting bash's limits unless you're
generating the aliases or functions programmatically, and they'd
need naming systematically for you to be able to remember them all.

Post by Keith Bainbridge
So I re-did my .bash_aliases file with only the bits I NEED; and all
is back to normal.

It looks like the error was in something that you judged you didn't need,
and you removed it.

Post by Keith Bainbridge
When I got my aliases working, I checked the size of the old file -
17K. The new .bash_aliases is 2.5K with .bash_functions at 490B.

In any case, the bash limits you quoted were concerned with the number
of definitions, not the size of the files containing them.

Interesting that your aliases are on average as big as your functions.
About 90 of my aliases occupy 3.5k, whereas ~350 functions occupy 240k,
so averaging around 40 and 680 characters each, respectively.

Post by Keith Bainbridge
The errant function that failed after a little satisfactory use was to
mount a USB and back it up to my system. It is used to run portable
apps at a volunteer job - yes windows. I noticed that the sample
functions on the web didn't have && for each line, so I removed them
and performance is now back to what I expected. The errant line was
the mount cmd. Originally if I had already mounted the USB, the
function kept going. I don't recall adding the &&, so it didn't dawn
on me to try removing them. (I worked around it by unmounting it (an
alias) and trying the back-up again.)

I don't follow what this is about, particularly each line having (or
not having) a &&.

Cheers,
David.

[Keith Bainbridge]

Post by David Wright

Post by Keith Bainbridge
Some of my aliases stopped working after months of working as I
expected. And udating the .bash_aliases kept giving me an error
referring to an end of file before the matching ' in one of the last
aliases. So I did some searching.

Thanks David,

Post by David Wright
All the aliases that lie textually after the one with the missing '
will remain undefined, so you can use bisection to locate where in
the file problem lies.

If I didn't use a syntax matching editor this may have easily been my
problem.

This is the line that was being reported as the incomplete alias, and a
few that follow it:


alias srb='source /home/keith/.bashrc'
#alias srz='source ~/.zshrc'


alias rcrt='sudo crontab -e '
alias kcrt='crontab -e'

The editor changes the colour of the text from the opening ' to the next
' in the file. If that is the next alias while I am inserting a new one
mid-file, the colour corrects when I type the closing ' That colour
diff doesn't show here, but does in the editor - in the file I re-named
for now.

I can see nothing different in the formatting of the reported error line
from any others. And the supposed error worked from the moment I pasted
it to the new file and ran

source .bashrc

One thing that still puzzles me is that when I #'d the errant line and
source .bashrc the error still reported the same line Number - even
when #'d out.

Post by David Wright

Post by Keith Bainbridge
So, is an alias a form of variable? I had about 150 plus 4 functions

There's little chance of hitting bash's limits unless you're
generating the aliases or functions programmatically, and they'd
need naming systematically for you to be able to remember them all.

As I said to Greg - I don't understand this; so I don't know how I would
have done it.

Post by David Wright

Post by Keith Bainbridge
So I re-did my .bash_aliases file with only the bits I NEED; and all
is back to normal.

It looks like the error was in something that you judged you didn't need,
and you removed it.

No. The alias worked as soon as I activated it

Post by David Wright

Post by Keith Bainbridge
When I got my aliases working, I checked the size of the old file -
17K. The new .bash_aliases is 2.5K with .bash_functions at 490B.

In any case, the bash limits you quoted were concerned with the number
of definitions, not the size of the files containing them.
Interesting that your aliases are on average as big as your functions.
About 90 of my aliases occupy 3.5k, whereas ~350 functions occupy 240k,
so averaging around 40 and 680 characters each, respectively.

To clarify the file sizes. The original 17K was about 150 aliases plus 4
functions. The new aliases file at 2.5k is about 40 aliases plus several
comments and blank lines. The finctions file is new yesterday and has 2
functions (one of them 2 short commands). I'll not likely get my
functions much bigger - in the short term anyhow.

Post by David Wright

Post by Keith Bainbridge
The errant function that failed after a little satisfactory use was to
mount a USB and back it up to my system. It is used to run portable
apps at a volunteer job - yes windows. I noticed that the sample
functions on the web didn't have && for each line, so I removed them
and performance is now back to what I expected. The errant line was
the mount cmd. Originally if I had already mounted the USB, the
function kept going. I don't recall adding the &&, so it didn't dawn
on me to try removing them. (I worked around it by unmounting it (an
alias) and trying the back-up again.)

I don't follow what this is about, particularly each line having (or
not having) a &&.

The only reason I raised this matter was that I had opened saying that
my aliases were working. I originally thought that the function was my
first sign of a problem My ERROR. It became as aside to the question of
env variable limits

Post by David Wright
Cheers,
David.

--
All the best

Keith Bainbridge

***@gmail.com
***@gmail.com
[phone]

UTC + 10:00

[t***@tuxteam.de]

[...]

Post by Keith Bainbridge

Post by David Wright
All the aliases that lie textually after the one with the missing '
will remain undefined, so you can use bisection to locate where in
the file problem lies.

If I didn't use a syntax matching editor this may have easily been my
problem.

I'm still pretty convinced that you're looking at a syntax problem.

Shell syntax is... not always trivial. I wouldn't trust most text editors
100% on that.

One thing you might try is to run your file through "bash -n" which checks
syntax without executing (well: it tries to: with languages like shell,
this is actually practically impossible).

Another thing would be to share your whole script here, but then you'll
want to make sure that there's nothing in there you want to consider
confidential.

Cheers

[Keith Bainbridge]

Post by t***@tuxteam.de
[...]

Post by Keith Bainbridge

Post by David Wright
All the aliases that lie textually after the one with the missing '
will remain undefined, so you can use bisection to locate where in
the file problem lies.

If I didn't use a syntax matching editor this may have easily been my
problem.

I'm still pretty convinced that you're looking at a syntax problem.
Shell syntax is... not always trivial. I wouldn't trust most text editors
100% on that.
One thing you might try is to run your file through "bash -n" which checks
syntax without executing (well: it tries to: with languages like shell,
this is actually practically impossible).
Another thing would be to share your whole script here, but then you'll
want to make sure that there's nothing in there you want to consider
confidential.
Cheers

Good evening Tomas

bash -n on the original file (copied to a different name) through an
error for a different alias from yesterday's efforts. So I added some
blank lines. The error line number increased. Deleted a few lines of
text - ctrl-x to clip board manager - The error line number reduced.
Repeated the delete bit a few more times, with the error moving accordingly.

So I pasted about 5 aliases and some blank space and a function name to
a /tmp/file. bash -n reported an error in a blank line between the
previously reported error and the function name. Added a few more
aliases after the function and 2 syntax errors were report in one of
these additional aliases. Deleted the function name - no errors.

I was checking the /tmp/file in less regularly with no apparent extra
characters appearing.

So pasted the previously 'errant' aliases back to .bash_aliases - no
error. So pasted back the rest of the cut aliases. Still no error.

I know that at some point of my research I noticed that the { on the 2nd
line of the function had moved up -- next to the name () and I
think the first command was also on the first line. Can't say where I
got that idea, but wish I knew, if only to warn folk off the site.

So Tomas, you're correct:Shell syntax is... not always trivial. I
wouldn't trust most text editors 100% on that.

BUT how do we know where to look if the error is reported several lines
above it's true position - admittedly blank lines; but?


So, I put the function name back in the /tmp/file but with no blanks
above it, and got the 2 syntax errors on 1 line as before. Deleted all
text below the function name, and the error line is now in the blank
space below the function name. Delete all blanks after the function ()
and saving the file inserts a blank line - where the error is now reported.

Thanks everyone. Enjoy your Monday. Mines almost over.

***@22:00:38
--
All the best

Keith Bainbridge

***@gmail.com
***@gmail.com
[phone]

UTC + 10:00

[t***@tuxteam.de]

On Mon, Jun 17, 2024 at 10:00:49PM +1000, Keith Bainbridge wrote:

[...]

Post by Keith Bainbridge
Good evening Tomas

[...]

Post by Keith Bainbridge
BUT how do we know where to look if the error is reported several lines
above it's true position - admittedly blank lines; but?

Seems you got it sorted out. Congrats :-)

Cheers

[Greg Wooledge]

Post by Keith Bainbridge

Post by David Wright
All the aliases that lie textually after the one with the missing '
will remain undefined, so you can use bisection to locate where in
the file problem lies.

If I didn't use a syntax matching editor this may have easily been my
problem.

Those aren't trustworthy with shell syntax. Shell syntax is an
absolute nightmare, and *nothing* implements it correctly except the
shell itself, and even then there are often bugs.

Post by Keith Bainbridge
This is the line that was being reported as the incomplete alias, and a few
alias srb='source /home/keith/.bashrc'
#alias srz='source ~/.zshrc'

The error is probably somewhere else.

Do you still *have* the file which contains the error?
Does it still *produce* the error message if you source it?
If so: source the file, and *show us* the error. The whole thing.

And then if you want anyone to help you look for the error, you'll
have to provide a way for us to see your file. Either by attaching
it here (if it's small enough!), or by uploading it to a web server
and providing a URL that lets us download it.

[David Wright]

Post by Keith Bainbridge

Post by David Wright

Post by Keith Bainbridge
Some of my aliases stopped working after months of working as I
expected. And udating the .bash_aliases kept giving me an error
referring to an end of file before the matching ' in one of the last
aliases. So I did some searching.

All the aliases that lie textually after the one with the missing '
will remain undefined, so you can use bisection to locate where in
the file problem lies.

If I didn't use a syntax matching editor this may have easily been my
problem.
This is the line that was being reported as the incomplete alias, and

Once you open, and don't close, a quote, then bash is likely to try
to "bend" everything to suit, as it parses more lines. Frequently
it will only give up at the end of the file. So any reported line
number is likely to be meaningless.

That's why I recommended you source the file from a clean bash shell
and check which alias definitions have become defined, and which
haven't. Those that get "eaten up" in the runaway quote will not
get defined.

Post by Keith Bainbridge

Post by David Wright
There's little chance of hitting bash's limits unless you're
generating the aliases or functions programmatically, and they'd
need naming systematically for you to be able to remember them all.

As I said to Greg - I don't understand this; so I don't know how I
would have done it.

I've seen no evidence of exceeding a limit of aliases or functions.

Post by Keith Bainbridge

Post by David Wright

Post by Keith Bainbridge
So I re-did my .bash_aliases file with only the bits I NEED; and all
is back to normal.

It looks like the error was in something that you judged you didn't need,
and you removed it.

No. The alias worked as soon as I activated it

You don't say which alias, nor all that had been done up to that
point, so that doesn't convey much information to me here. Or by
"activating the alias", do you mean sourcing the aliases file?

I was under the impression that you severely pruned your aliases
file from 17000 to 2500 characters, and that the larger file had an
unmatched ' and the smaller one didn't. It would seem reasonable
to suppose that the unmatched ' was in the prunings, the bits
you said you didn't need.

Post by Keith Bainbridge

Post by David Wright
In any case, the bash limits you quoted were concerned with the number
of definitions, not the size of the files containing them.
Interesting that your aliases are on average as big as your functions.
About 90 of my aliases occupy 3.5k, whereas ~350 functions occupy 240k,
so averaging around 40 and 680 characters each, respectively.

To clarify the file sizes. The original 17K was about 150 aliases plus
4 functions. The new aliases file at 2.5k is about 40 aliases plus
several comments and blank lines. The finctions file is new yesterday
and has 2 functions (one of them 2 short commands). I'll not likely
get my functions much bigger - in the short term anyhow.

Really, I was only interested in the file sizes as an indication of
how long (and possibly complex) your aliases were.

Post by Keith Bainbridge

Post by David Wright
I don't follow what this is about, particularly each line having (or
not having) a &&.

The only reason I raised this matter was that I had opened saying that
my aliases were working. I originally thought that the function was my
first sign of a problem My ERROR. It became as aside to the question
of env variable limits

Fair enough. But I still don't see anything reported that would cause
you to approach bash's limits except by, say, an accidental loop.

Cheers,
David.

[Keith Bainbridge]

Am 16.06.2024 um 10:13 schrieb Keith Bainbridge:> Practical Limitations

Environment Variables: Bash has a limit on the number of environment
variables it can store, which is typically around 32,000. If you define
too many aliases, you may exceed this limit, causing issues with your
shell.

Hi,
while being aware of those limitations, i got curious, as to why i
never ran into them in almpst 10 years of scripting. The answer is
probably, that i do use aliases only occasionally, most of the time i
use bash script files (in my path). And the largest file?
Is actually one, i did not write myself, instead i found it on the
internet: checkbashisms. And even this big file only has 32K
So i am deferring, that you got into the habit to put most of your
scripting in one place, and that may be the wrong one. It's hard to
maintain and error-prone, as you are experiencing right now. Wouldn't it
be feasible to separate some of its volume out into normal bash files?
Just my 2 cents
DdB

Thanks for your suggestion

Most of my aliases are simply simplifying shell commands like
alias llr='ls -lahR --group-directories-first'
or
alias du1='du -hPx --max-depth=1 '

The longer aliases were being converted to functions after I saw that
recommendation here. This stopped when I made an error that stopped the
functions from working as I expected.

I do little scripting as such; and most of that is processes I want done
by cron, when a short one-line won't do.

***@18:49:32
--
All the best

Keith Bainbridge

***@gmail.com
***@gmail.com
[phone]

UTC + 10:00