On Sun, Jun 16, 2024 at 06:13:36PM +1000, Keith Bainbridge wrote: > 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.
