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.
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.
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.
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.)
On 17/6/24 14:20, David Wright wrote:
Just some random thoughts:
On Sun 16 Jun 2024 at 18:13:36 (+1000), Keith Bainbridge wrote:
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.
On 16/6/24 23:50, Greg Wooledge wrote:
On Sun, Jun 16, 2024 at 06:13:36PM +1000, Keith Bainbridge wrote:
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
On 17/6/24 14:20, David Wright wrote:
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'
Good evening Tomas
BUT how do we know where to look if the error is reported several lines
above it's true position - admittedly blank lines; but?
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.
On 16/6/24 23:50, Greg Wooledge wrote:
On Sun, Jun 16, 2024 at 06:13:36PM +1000, Keith Bainbridge wrote:
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 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 17Jun2024@18:25:58
keithrbau@gmail.com
keith.bainbridge.3216@gmail.com
+61 (0)447 667 468
UTC + 10:00
On 17/6/24 14:20, David Wright wrote:
On Sun 16 Jun 2024 at 18:13:36 (+1000), Keith Bainbridge wrote:
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
a few that follow it:
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.
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
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.
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
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.
On Mon, Jun 17, 2024 at 09:14:38AM -0500, David Wright wrote:
[...]
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.
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 [...]
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
What does "date" say? Paste the entire output.Tue 18 Jun 2024 18:06:31 AEST
date
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
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
Have you set the TZ environment variable? If so, what did you set it to?Not that I'm aware of
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
Greg, if there is something not right with my answer, please let me know. Again thanks greatly for your help.
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.
On Thu, Jun 20, 2024 at 21:00:38 +1000, Keith Bainbridge wrote:
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.
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.
On 17/6/24 18:26, Keith Bainbridge wrote:
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
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.
And doesn't this exchange show that
Sat 22Jun2024 at 18:27:55 +10:00
can be interpreted in two ways?
On Sat, Jun 22, 2024 at 18:35:34 +1000, Keith Bainbridge wrote:
On 21/6/24 14:28, David Wright wrote:
You could pronounce your time written above as:
"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".
On 21/6/24 14:28, David Wright wrote:
You could pronounce your time written above as:
"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.
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
Will do
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.
On Sat 22 Jun 2024 at 10:02:43 (-0400), Greg Wooledge wrote:
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.
On Sat, Jun 22, 2024 at 09:51:32 -0500, David Wright wrote:
On Sat 22 Jun 2024 at 10:02:43 (-0400), Greg Wooledge wrote:
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"
On 23/6/24 00:02, Greg Wooledge wrote:
In mutt, it would be:
set date_format="!It's %a %d%b%Y at %H:%M:%S here, where clocks are UTC%z"
I believe UTC%Z will give the :
as I get from my text expander.
Tue 25Jun2024 at 18:34:20 =UTC +10:00
Here's another test:
hobbit:~$ TZ=Australia/Eucla printf '%(%z %Z)T\n' -1
+0845 +0845
Greg Wooledge <greg@wooledge.org> wrote:
Here's another test:
hobbit:~$ TZ=Australia/Eucla printf '%(%z %Z)T\n' -1
+0845 +0845
That seems like a bug. I'd have expected:
+0845 ACWST
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (0 / 16) |
| Uptime: | 169:36:40 |
| Calls: | 10,385 |
| Calls today: | 2 |
| Files: | 14,057 |
| Messages: | 6,416,555 |