Subject: Re: FVWM: fvwm2/twm losing PS1 (environment experiment results)

From: /users/domivogt <[email-masked]>
Date: Mon, 2 Nov 1998 13:28:51 +0100

This workaround should work for your problems:
----------------------------------------------

- Remove all lines from your .bashrc, /etc/bashrc,
  /etc/profile that set PS1 or PROMPT_COMMAND.

- Put these lines in your .bashrc:

    PS1='$MY_PS1'
    export MY_PS1

  The quoting is important here.

- Verify that the promtvars bash option is set with

    shopt promptvars

  If not, put this line in your .bashrc:

    shopt -s promptvars

- Now whenever you would have set PS1, set MY_PS1 instead.
  You will have to change all your scripts, but at least
  this works.

Background:
-----------

1) Unlike most (probably all) other shells, bash *deletes*
   the contents of PS1 if it is non-interactive (i.e. if
   you run a script with bash). This is documented
   behaviour however.

2) Under Linux, /bin/sh is a link to bash.

3) The startx, xinitrc and xserverrc use /bin/sh = bash as
   their executing shell and fvwm (and probably twm) execute
   commands with /bin/sh.

4) When you start X11 with startx, the startx script strips
   the contents of PS1. If you use xserverrc or xinitrc they
   do the same as does fvwm.

What you should do:
-------------------

Write a bug report to the bash developers. It may be a good
idea to not set PS1 to the default in a non-interactive bash,
but deleting an already set PS1 is a bad idea. Nobody has
noticed before because nearly everyone sets the prompt in
some configuration file. The effect is that when a non-interactive
bash starts a new interactive bash, the new shell does not get
the exported prompt. I have tested tcsh, zsh and pdksh on my
Linux, and all of these work well.

The 'bug' or feature (remember it is documented on the manpage)
can be verified with the following command:

  echo 'echo PS1 = $PS1' | bash

The reasons to change this are:

 - No noteworthy gain by deleting PS1 this saves only a few
   bytes.

 - Better compatibility with other shells (ksh and probably
   posix sh)

If there are problems to communicate this bug to the bash
developers, please contact me again and I will explain it
in detail. I do not want to make the report myself since
I have no time for that if it is not necessary.

Bye

Dominik
-- 
Dominik Vogt, Hewlett-Packard GmbH, Dept. BVS
Herrenberger Str.130, 71034 Boeblingen, Germany
phone: 07031/14-4596, fax: 07031/14-3883, [email-masked]
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].

---

From: /users/domivogt <[email-masked]>
Date: Mon, 2 Nov 1998 13:41:32 +0100

> Dominik, please, just for my sanity, could you move your dot-files out of the
> way and try it? I mean, just to hear that someone had reproduced exactly 
> what I have done and *didn't* get the same results would at least give me
> the confidence to keep struggling with it.

You are completely sane (at least concerning you problem ;-) ). In fact
it is very easy to reproduce your problem (see my other posting for a
solution).

Bye

Dominik

---

From: Alexis Huxley <[email-masked]>
Date: Mon, 2 Nov 1998 14:20:41 +0000

>    the contents of PS1 if it is non-interactive (i.e. if

Yes, I came to the same conclusion about bash after receiving an email
from list-reader Michael Tiefenback <[email-masked]>. Unfortunately
he was getting PS1 being *the same* in .xinitrc-spawned and fvwm-spawned
xterms, but this gave me a tremendous impetus to keep digging.

>    you run a script with bash). This is documented

Hmm ... I checked the documentation beforehand and couldn't see any
mention of this. Re-reading this on the bash man page:

       An interactive shell ....  PS1 is set
       and $- includes i if bash is interactive, ...

you can't infer that a non-interactive shell has PS1. Although just the
mention of this is 'suspicious' :-)

You suggested I should change all my scripts, but that isn't terribly
portable or graceful. I see fvwm2 has an 'ExecUseShell' configuration
command. I think it would be neater to use it to explicity specify an
alternative shell for fvwm2 to use - in light of /bin/sh being bash
under most Linux distributions.

it the name of a script that simply prepends '-i' to the argument 
list and exec's bash?

>   echo 'echo PS1 = $PS1' | bash

Yes, I eventually strace'd an already-running fvwm2 proess and found
how it was exec'ing menu items, and simulated the problem with this
bit of code a bit closer to how fvwm2 is doing it as follows:

PS1="newprompt> "
export PS1
/bin/bash -c 'echo $PS1'                <-- PS1 lost
/bin/bash -i -c 'echo $PS1'             <-- PS1 not lost

The implication being that if bash is invoked with command line parameters
which do not suggest it's an interactive shell (e.g. with a script
or -c <command>) then it presumes *incorrectly* that it's *never* going to
'give rise to' an interactive. Which is *too* presumtious.

> Write a bug report to the bash developers. It may be a good

I will shortly - I'd like to hear the results of a little test I asked
Michael to do first though.

[ Michael, you might as well post them back on the list I think, even
though it's becoming apparent it's a shell problem rather than an fvwm2
problem - at least it will go into the mailing list archive and become
searchable - which is where I tried before posting here (and after
checking newsgroup FAQs and posting to newsgroups). ]

> You are completely sane (at least concerning you problem ;-) ). In fact

I was going nuts! Thanks very much for the reassurance! :-)

Alexis

---

From: "Jose' Manuel Pereira" <[email-masked]>
Date: Tue, 3 Nov 1998 01:30:26 +0000 (WET)

Forget about my earlier, wide off target post about this. Can't cancel e-mail,
sorry...

"d" == domivogt  <users> writes:

  d> 1) Unlike most (probably all) other shells, bash *deletes* the contents
  d> of PS1 if it is non-interactive (i.e. if you run a script with bash).
  d> This is documented behaviour however.

Well, of course this one wins the prize. This rang a bell (a cathedral-sized
one). Not sure about the "documented" bit, however. But the recommended bash
trick for detecting a non-interactive shell is '[ -z "$PS1" ]'!! It does leave 
one suspicious...

Redhat even distributes an /etc/bashrc containing the following pearl:
"...
# For some unknown reason bash refuses to inherit
# PS1 in some circumstances that I can't figure out.
# Putting PS1 here ensures that it gets loaded every time.
PS1="[\u@\h \W]\\$ "
..."

Argh.

Sorry about that.
Cumprimentos,
-- 
 Jose' Pereira				 		Tel. +351.1.841 9340
 DEEC - Dep. of Electrical and Computer Engineering	Fax. +351.1.841 7499
 Instituto Superior Tecnico - Technical University of Lisboa
 Av. Rovisco Pais - 1049-001 Lisboa - Portugal
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].

---

From: [email-masked] (Paul D. Smith)
Date: 02 Nov 1998 22:52:00 -0500

%% "Jose' Manuel Pereira" <[email-masked]> writes:

  jmp> But the recommended bash trick for detecting a non-interactive
  jmp> shell is '[ -z "$PS1" ]'!!

Recommended by whom? :)

The _correct_, always completely accurate, way to test for interactivity
in ksh, bash, and zsh is to test the $- option variable to see if it
contains "i" or not.

  case "$-" in
    *i*) echo "Interactive!" ;;
    *)   echo "Not interactive!" ;;
  esac

See the man page.

The _only_ reason to use PS1 is if you must maintain backward
compatibility with older Bourne shells.  This should really never be
much of a concern in places where you'd expect to see this type of test.

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <[email-masked]>         Network Management Development
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
   These are my opinions---Nortel Networks takes no responsibility for them.
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].

---

From: "Jose' Manuel Pereira" <[email-masked]>
Date: Thu, 5 Nov 1998 05:04:29 +0000 (WET)

"PDS" == Paul D Smith <[email-masked]> writes:

  PDS> The _correct_, always completely accurate, way to test for
  PDS> interactivity in ksh, bash, and zsh is to test the $- option variable
  PDS> to see if it contains "i" or not.

  PDS> The _only_ reason to use PS1 is if you must maintain backward
  PDS> compatibility with older Bourne shells. This should really never be
  PDS> much of a concern in places where you'd expect to see this type of
  PDS> test.

Helas, unfortunately, I tend to step into such vanilla Bourne shells daily...
Mostly at login time. To be "always completely accurate" you _have_ to use it.

And that's for login shells. Now, /bin/sh != /bin/bash, mostly (only in
Linux). zsh, never saw it. ksh, only in my Solaris (since I'm in charge).
Sigh.

(Not to mention the places where you are stuck with a *csh;
 "if ($?prompt == 0)", anyone?)

Now, where's that fvwm 2.1.0 someone mentioned? I missed the announcement.

---

From: [email-masked] (Paul D. Smith)
Date: 05 Nov 1998 00:44:55 -0500

jmp> Helas, unfortunately, I tend to step into such vanilla Bourne
  jmp> shells daily...  Mostly at login time. To be "always completely
  jmp> accurate" you _have_ to use it.

Don't get it: if you're using sh, then you can use the PS1 test safely.
If you're using bash, you can use the $- test in .bashrc (which won't be
read by sh anyway).

  jmp> And that's for login shells. Now, /bin/sh != /bin/bash, mostly
  jmp> (only in Linux). zsh, never saw it. ksh, only in my Solaris
  jmp> (since I'm in charge).  Sigh.

  jmp> (Not to mention the places where you are stuck with a *csh;
  jmp>  "if ($?prompt == 0)", anyone?)

Obviously.  But the point is, the login scripts for shells are almost
never really portable, anyway.  For bash (and ksh and zsh--zsh is also
free like bash, you have to go get it and compile and install it) you
can use the $- test.  For Bourne use PS1, and it works.

Maybe I missed the point of what you wanted to do.

  jmp> Now, where's that fvwm 2.1.0 someone mentioned? I missed the
  jmp> announcement.

Fvwm development has moved to a release numbering scheme like Linux,
where odd releases are betas.  The first in a series which will
hopefully culminate soon in the Fvwm 2.2 stable release is 2.1.0.  It's
being announced and discussed on the fvwm-workers list; if you want to
use it you'll need to join the workers list and follow along... :)

---

From: "Jose' Manuel Pereira" <[email-masked]>
Date: Thu, 5 Nov 1998 06:28:43 +0000 (WET)

PDS> Don't get it: if you're using sh, then you can use the PS1 test safely.
  PDS> If you're using bash, you can use the $- test in .bashrc (which won't
  PDS> be read by sh anyway).

Indeed, but...

  PDS> ... But the point is, the login scripts for shells are almost
  PDS> never really portable, anyway. For bash (and ksh and zsh--zsh is also
  PDS> free like bash, you have to go get it and compile and install it) you
  PDS> can use the $- test. For Bourne use PS1, and it works.

But PS1 does work in ALL of them, except for that bash nonsense. BTW, zsh
doesn't nuke PS1... Probably the safest thing for everyone is to make /bin/sh
-> zsh (it's designed to work like that, too). Except if you have inflicted a
Redhat Linux distrib. on your machine. You can't even upgrade bash from 1.14.7
there. I know, I tried it. Not sure about zsh, though...

  PDS> Maybe I missed the point of what you wanted to do.

Ok. The point is that I try to have a nice portable shell setup. Probably
silly, but it mostly, let's say 99%, works. The 1% left, like Alexis' problem,
isn't usually visible -- unless you really _need_ it (such as in his case).

Now, to get that 1%, I really would have to (*shiver*) clean up some 5-6 years
of accumulated *sh dust... (Let's see, I got this "portable sh" stuff started
in 1993... From a package called "Elfshell", by Christopher North-Keys,
Talisman Group).

  PDS> Fvwm development has moved to a release numbering scheme like Linux,
  PDS> where odd releases are betas. The first in a series which will
  PDS> hopefully culminate soon in the Fvwm 2.2 stable release is 2.1.0. It's
  PDS> being announced and discussed on the fvwm-workers list; if you want to
  PDS> use it you'll need to join the workers list and follow along... :)

I see. Fine, I'll lurk there :-)
(unfortunately, I don't have much time right now to be of any help, sorry. And 
there are a couple things I think still missing in this fine WM...)

Cumprimentos,