@EliahKagan I actually could not figure it out -_-

@Zanna Can you elaborate?

@Zanna (unrelated to my previous message) What had the actual problem been asking? Was it asking how long it would take for two periodically recurring events that had happened at the same time to happen at the same time again?

yes, sorry! It was "Two model trains go around on adjacent tracks. One takes 40 seconds to go all the way round its track, one takes 55 seconds. They set off at the same time. How long, in minutes and seconds, will it be until they both arrive at the starting point at the same time?"

@EliahKagan I didn't find anything that helped me to understand, but I'm awful at reading manuals. Maybe if you explained how you managed to understand which usages were portable I would get it. But you definitely don't have to do that

I'm going afk again but I should be able to reply more later. But I think the actual issue is that there are just way fewer portable uses than I had made it sound like. That is, I suspect that you did not really miss much, but instead that I had previously wrongly suggested that semicolons are safe in portable sed scripts in more situations than they really are.

Any use of semicolons in a sed script, whose correctness cannot be demonstrated by reference to the parts of that document that talk about <semicolon>, is nonportable.

well that helps :)

@EliahKagan I got it ^_^

command_not_found is pulled in by this code in /etc/bash.bashrc

# if the command-not-found package is installed, use it
if [ -x /usr/lib/command-not-found -o -x /usr/share/command-not-found/command-not-found ]; then
	function command_not_found_handle {
	        # check because c-n-f could've been removed in the meantime
                if [ -x /usr/lib/command-not-found ]; then
		   /usr/lib/command-not-found -- "$1"
                   return $?
                elif [ -x /usr/share/command-not-found/command-not-found ]; then
		   /usr/share/command-not-found/command-not-found -- "$1"

but at the top of /etc/bash.bashrc we have

# If not running interactively, don't do anything
[ -z "$PS1" ] && return

so emptying PS1 by running PS1= causes the rest of the file to be ignored

but we get our normal prompt, because .bashrc doesn't rely on that way of checking the shell is interactive, but instead has

# If not running interactively, don't do anything
case $- in
    *i*) ;;
      *) return;;
esac

so the part of .bashrc that sets PS1 is run

hmm is that right?

@Zanna Yes. :)

:)

Note that it is specifically setting PS1 to the empty value and exporting it into the environment of the new bash shell that achieves this result. When PS1 is not in the environment of an interactive bash shell, it sets it to a default nonempty value before any startup scripts run. That's why this doesn't always happen, even though there is normally no PS1 environment variable for an interactive bash shell that is just starting.

I was thinking that /etc/bash.bashrc will be run first, so PS1 must have some value before it is run, that was my doubt

I see how you demonstrated that bash won't always reset PS1 - if it has been set to any value (even if it's empty), it won't be reset in this case

@Zanna Do you mean, that's why you weren't sure if you should include information in your other question about what happens with PS1 is/isn't inherited from the caller?

Yeah, PS1 almost always does have a value before /etc/bash.bashrc is sourced, because it is automatically given one by an interactive Bash shell that doesn't find it in its environment, before any startup scripts are run.

The situations where PS1 doesn't have a value even before /etc/bash.bashrc are when the shell is nonninteractive but /etc/bash.bashrc is sourced for some other reason. The Debian/Ubuntu default /etc/profile sources /etc/bash.bashrc, and as we discovered, bash sources it automatically when it thinks it is an initial non-interactive non-login shell of a remote connection.

no, the reason I didn't explain in my answer why PS1 is set in .bashrc and isn't an environment variable was because I didn't understand enough about how Bash treats PS1. When I said "that was my doubt" just now, I meant that was my doubt that I understood the behaviour you demonstrated correctly

Oh.

In your answer you say

> Conversely, if you unset PS1 and run an interactive Bash shell, even if you prevent it from running commands from startup scripts by passing --norc, it will still automatically set PS1 to a default value. Running env -u PS1 bash --norc gives you an interactive Bash shell with PS1 set to \s-\v\$

Is that unclear? (Or wrong?)

So, now I understand. I am just slow to catch up

Maybe I should reword it to say:

> PS1 shouldn't typically be an environment variable, but even if you use env to ensure that it is unset when you run an interactive Bash shell...

@EliahKagan no, that explains that PS1 has some value before /etc/bash.bashrc is sourced

Sorry, I'm independently worried it's unclear. I haven't interpreted what you've said as saying it is.

Sorry, I guess I'm explaining your answer back to you at ELI5 level XD

But I'm worried that making the wording more complicated will make a post that may already be challenging for many readers to understand even more inscrutable.

I mean, you wrote it, so you understand it, but I am thinking my way through it cluelessly out loud

which is probably quite annoying and unhelpful

I don't think it's unclear at all...

The current wording, or the wording I'm thinking of changing that part to, or both?

the current wording... was the proposed wording going to replace all or just part of the part I quoted?

I was going to replace this with it and leave it otherwise the same:

> Conversely, if you unset PS1 and run an interactive Bash shell

But actually I think that's not a good idea.

I think it is easier to understand in its current state

I'll leave it.

Or at least it won't change it to that particular wording.

So, I don't know if the Debian maintainer(s) deliberately intended for PS1= bash to work this way or not.

what could be useful about that behaviour?

It lets users opt out of the systemwide /etc/bash.bashrc.

The comment does not make it seem like this was intended:

# If not running interactively, don't do anything

But maybe it was introduced unintentionally and kept when the feature was seen as valuable. I haven't found anything about it yet.

# If not running interactively, or if the user has sneakily emptied PS1 to avoid sourcing this file, don't do anything

I am somewhat disinclined to think it was intentional. Bash provides a way to override which startup scripts are used. From the heavily hyphenated way the manpage is displayed in my terminal:

   --init-file file
   --rcfile file
          Execute commands from file instead of the system  wide  initial‐
          ization file /etc/bash.bashrc and the standard personal initial‐
          ization file ~/.bashrc if the shell is interactive (see  INVOCA‐
          TION below).

it does not seem intentional to me. The files should probably use a more reliable way to check that the shell is interactive, if possible

Should a bug be reported for this, then?

Also, should I avoid writing a Q&A about it here; would that get closed as a bug report?

I have never been a developer or maintainer, so, I don't know, but it seems reasonable to report it as a bug, since the code is not doing what it seems to be trying to do

It's not very clear cut to me when questions should be considered bug reports and closed as such. I doubt I would vote to close that question, because it will be useful to know about. But if you think it is likely to be considered off-topic for that reason, you could post it on Unix & Linux instead, right?

Should the corresponding test be changed in /etc/profile as well?

is there any reason why it might be intended there?

Well any Bourne-style shell may source that when it is started as a login shell. Perhaps some treat an empty PS1 the same as an unset one.

Oh.

-i is not listed there as an option accepted by set. Does that mean i is not guaranteed to appear in the expansion of $- in an interactive POSIX-compliant shell?

All my Bourne-style shells have it.

That's what I was wondering - whether there is a completely shell-agnostic and infallible way to tell if the shell is interactive

Well I thought the method used in Debian and Ubuntu's default per-user .bashrc fit that bill.

# If not running interactively, don't do anything
case $- in
    *i*) ;;
      *) return;;
esac

For shells that aren't bash, as one may have with /etc/profile, it is not always reliable to assume it's interactive just because PS1 is set and nonempty.

ek@Io:~$ PS1=foo ksh93 -c 'echo "$PS1"; echo "$-"'
foo
chsB

hmm

the shell didn't reset PS1 XD

I am trying to test if maybe it does reset it when it's a login shell. ksh93 accepts an -l option and it appears in the expansion of $-... but it appears to be undocumented, so I cannot tell if that is really making it a login shell.

Neither -l nor -i is listed in the ksh93 manpage, in the list of options accepted by set.

I cannot use set -l.

I can only pass -l as an argument to ksh93 when I start the shell.

Which is the same as bash's behavior.

bash doesn't accept an argument of -l to set either, and does also accept it as an argument to bash when the shell is started, but unlike ksh93, bash does not include l in the expansion of $-. In bash, you can run shopt login_shell to find out if you're in a login shell.

I upvoted that. But where is it actually documented that $- must include i when the shell is interactive?

The comments on this other answer seem relevant:

I don't know what Stéphane Chazelas means by "your own variant" though. I have the Schily tools installed on my 16.04 system, and both the sh and bosh it provides do show i when I have them expand $- in an interactive shell, even if I did not (attempt to) pass -i an argument to the shell itself.

ek@Io:~$ /opt/schily/bin/sh
$ echo "$-"
ims
$ exit
ek@Io:~$ /opt/schily/bin/bosh
$ echo "$-"
ims
$ exit
ek@Io:~$

Oh, and he (Schily) says that too.

I should try to find this posting and its replies:

So that must be the mailing list for opengroup.org/austin.

Now I can just search mail-archive.com/austin-group-l@opengroup.org/maillist.html for the letter i and get my answer!

Darn. The thread would've been about a year before those archives seem to start.

aww

sorry for my inattention. I was editing my answer about PS1!

I could subscribe. But I doubt the list commands would offer access to older messages.

No problem!

@EliahKagan wow, so many interesting comments on this page

It's way past my bedtime now. I'll be back in a decent number of hours, hopefully

I have a question about your answer but you can just as well answer it tomorrow. I can even just as well ask it tomorrow. Shall I ask it now though? Even if you say yes, I still will not expect an answer tonight.

oh yes, please ask it

Sorry, I was briefly afk.

no worries!

You show:

zanna@toaster:~$ PS1='\t -> '
22:55:04 -> bash --norc
22:55:09 ->

Then you say:

> Note that export is not needed here. Bash treats PS1 specially by preserving its value if set.

Are you sure you hadn't already exported it, though? Perhaps it was exported initially into the environment of the shell that you then ran PS1='\t -> ' in?

ek@Io:~$ PS1='\t -> '
18:38:13 -> bash --norc
bash-4.3$

^ That's what I get.

omg

If your description there is correct, then I think either mine is wrong or there is a bug.

no you are right

I had already exported it

sigh I'm so silly

it didn't even make sense anyway

thank you for checking!

now definitely sleep time