I was going to post an answer that addressed the part about export too, but I learned that Bash doesn't actually work quite the way I thought it did, when you actually export PS1 and run bash, and the draft I wrote is largely wrong. I would have to totally rewrite it to fix that, and perhaps it would be sufficient just for a small amount of information about it to be added to your answer.

Well the answer I wrote was wrong. I should definitely not post that answer.

The combination of Bash's treatment of PS1, when it already exists the environment a shell inherits from its parent process, and the way PS1 is used (and not used) in the default startup scripts in Ubuntu that come from Debian, produces some quite interesting behavior, and I am unsure if it is a bug (of Debian and Ubuntu) or a feature (of Debian and Ubuntu).

I may just post a self-answered question about that specific behavior (because I do understand why it happens, and it's interesting). Aside from that, though, I'm unsure if this should be moved to the island. Perhaps so. It actually related to (another! darn it!!) post of mine about Bash's startup behavior that I need to fix now, but I don't think it's one of the ones that's really difficult to figure out how to fix.

@Zanna Hopefully. So, the specific problem with that post is that it does not correctly describe when PS1 is reset. I thought, wrongly, that Bash shells (besides subshells) always reset PS1, but there are actually circumstances where they do not. Specifically, non-interactive Bash shells always unset it when they start up, and they do so before any startup scripts run. So I was right about that part, but...

Interactive Bash shells check if it is set and they set it to a default value if it is not; that is also done before any startup scripts run. If PS1 is in the environment with any value, even the empty string, then interactive shells will not reset it automatically (though it may of course be reset in startup scripts).

That's probably enough information for you to add something to your answer if you so choose, though I suggest testing bash's behavior yourself to be sure I am not making any further mistakes.

The same thing it always does. So if it is exported, and you run bash, then it will be in that bash subprocess's environment initially. The difference, compared to most other environment variables, is that, under many conditions, bash immediately unsets or resets PS1. Noninteractive bash shells always unset PS1 immediately, whether or not startup scripts are run (i.e., with or without --norc), and before any of them run, so they cannot even consult the value.

By the same token, interactive bash shells will immediately set PS1 to a default value if it is unset. Thus, code in startup scripts are actually resetting the value rather than setting it initially. The default startup scripts for bash, provided by Debian maintainers and thus also in Ubuntu, even check to make sure it is already setbefore proceeding to do things like setting it to the fancy value we're accustomed to.

However, if it's set (even to an empty value), then interactive bash shells do not automatically reset it, though typically one's startup scripts will do so.

I have fixed that answer. So actually, if you feel like it, then you should pretend you didn't read any of what I just said and read that (now highly revised) answer instead, so you can let me know if it makes sense. Also, you might then figure out what's going on with that oddness before I get a chance to post a Q&A about it. :)

Btw, when I asked if you might have meant export in general, I very much hope that did not come across as expressing unconfidence in your shell scripting abilities. Even without taking its various options into account and its behavior when no variable arguments are passed, the export builtin is a lot weirder than we tend to imagine, and I am not actually sure I can correctly state its full behavior.

In particular, I am thinking of how export will export variable that are unset, which remain exported when they are set, but which, like other exported variables, become unexported when unset, even if they were never set. I have heard that it is possible to actually have an environment variable with no value--as opposed to the empty value--which I presume would be achieved by having a null character in its entry in the environment block prior to any =.

But I have not managed to make this happen, and I don't know if there is any way, in any shell, under any combination of shell options, to use export to achieve that. I also don't know what requirements POSIX specifies for export, though I seem to recall something about how it doesn't even have to accept assignments! export weirdness is why I try always to quote text that contains expansions triggered by $ when I assign it to variables.

bash's export, declare, readonly, and local are builtins (like [) and not shell keywords (like [[), so assignments in them behave differently, because globbing and word splitting are performed. I am reasonably sure that there are other differences that I am missing here.

...I think you were right that some of this should be moved to the Island. How do you feel about the idea of me moving all the bash-related messages but keeping the other messages (except the ones that are clearly off-topic for the Downboat, like the ones about phalanx etymology). So the stuff about filesystem encryption would stay, but the bash messages would get to go hang out with their other bash-related friends on the Island? Or do you think the crypto stuff should go too?

It's actually kinda odd that it isn't a login shell, because in other situations where a system runs bash for non-login purposes but when no login shell or anything like a login shell runs, that initial bash instance is often invoked as a login shell. I am thinking of Terminal.app (and other terminal emulators) in macOS, where typically one logs in graphically in a way that doesn't cause ~/.profile to be sourced, and also of Cygwin, MSYS, and MSYS2 on Windows.

(when I was living in London, I was tutoring a lot of rich kids, who always had Macs. Occasionally, in those lessons, I would start Terminal and use Bash as a calculator (or, just for fun, show the tutee how to use Bash as a calculator). This is the extent of my experience with MacOS...)

haha remembering that I found this email I sent to a parent who emailed me while they were on holiday asking me to explain how to do a math problem her 8 y/o had been given

Maybe there's an easier way, but I think the expected approach here is to find the LCM by first breaking the numbers into prime factors
40 55
/ \ / \
4 10 11 5
/ \ / \
2 2 2 5
Then make a venn diagram
________________
| /\ |
| 2 / \ |
| 2 | 5 | 11 |
| 2 \ / |
|_______ \/_______
The LCM is found by multiplying all the numbers that are not duplicated in both numbers (if 55 had a 2 in its factor tree, we would stil…

@Zanna Because programs provided by .app "packages" (not a package in the sense of package management) are typically run from within the default graphical interface on macOS (people often use the term Quartz in connection with that, but I think Aqua is the right term for the desktop environment itself, though I am not totally sure).

A graphical login for that interface, from the graphical login screen, does not involve sourcing any shell scripts. So the work that would typically done once per login is not performed.

Therefore, if such work is needed, and the user wants to use a shell script to do it, and it is not appropriate for repetition each time a shell runs, then it is necessary to have the initial shell in Terminal.app be a login shell so that it sources startup scripts like ~/.bash_profile, ~/.bash_login, and ~/.profile, in accordance with bash's usual startup behavior.

It is for the same reason that Cygwin, MSYS, and MSYS2 on Windows have the initial bash shell be a login shell. Windows does not source shell scripts when you log in graphically. (It not even ship with any mechanism available to run a command from a script that is written in any *nix shell--because it is not a *nix system--which is why things like Cygwin, MSYS, and MSYS2 exist.)

I don't remember what the terminal's behavior is in BeOS and Haiku, which are not *nix systems but which do ship with bash installed and a graphical terminal emulator application that uses it.

So, to be more concrete, consider anything that one might use ~/.profile for. There should be a way to achieve that if one is to run bash interactively in a system where normal logins don't source ~/.profile or anything that one could customize by causing it to source ~/.profile. For example, if you set environment variables in ~/.bashrc, they would keep getting set over and over again.

If you set them based on previous values, they would have a whole bunch of repetitions, which would make it difficult to understand their contents and the output of commands like type -a, and under some circumstances might result in a measurablee decrease in performance.

For the same reason that one shouldn't just use ~/.bashrc for everything, but should use ~/.profile for some kinds of things, it is useful to have the first shell you run in a terminal emulator on a system that does not use ~/.profile (or anything else closely similar to it in function, like ~/.login for csh and tcsh) in the traditional circumstances.

Oh, that's actually directly related to the conversation in the Downboat that should be here. I will take this as a cue to move messages before proceeding! Please do continue posting messages here about that though, at least if you were going to do so.

I was anticipating the other messages being moved here to join this one later, but I wasn't trying to hint... I just didn't want to post it there because it's so long.

I can also move the messages myself, but you know better than me which ones should be moved I think!

(today I finally found a use for the -e option in sed; when you need to suppress all shell expansions in one command and pass variables in another, you can use -e for each command to allow you to use mixed quoting)

@Zanna I think the -e way may be clearer after all, though. It's a bit confusing to have '". I'm not sure people who are hearing about this except in the present here's an example of mixed quoting! context will understand what is going on with that.

hmmm yeah... I think I will use the -e way. I might write something about the need for mixed quoting, which I have avoided so far. But why have I avoided it? I should stop trying to take up as little space as possible

> Also - some operating systems do NOT let you use semicolons. So if you see a script with semicolons, and it does not work on a non-Linux system, replace the semicolon with a new line character. (As long as you are not using csh/tcsh, but that's another topic.

) <-- added by me, just in case jokerdino passes by and gets freaked out. He doesn't like missing parentheses

When I run less on some file, the prompt goes away, and I get the contents of the file on screen. Then when I press q, it goes back to the prompt. I think less does this by saving the current terminal buffer, opening a new buffer, outputting the file into the new one, then when closed, discarding...

@Videonauth Do you want that here, or in AUGR where it's being discussed? I'm happy to leave it here if you like (it might be moved to the Island next time we move messages) but, in case you head meant to post it in AUGR (or/dev/chat, though you didn't seem to have intended that), I think I can move it, because I think I only need write access in the destination room. Anyway, I won't move it to AUGR without your say-so.

However, the answer from that main page is to click "Shell & Utilities" in the top-left frame, then click "Utilities" in the bottom left frame, then click "sed" in that same bottom-left frame. Then the page comes up in the big right frame.