Subject: Re: Exec calling bash script hangs

From: TG <[email-masked]>
Date: Sun, 08 Aug 1999 17:41:57 +0200

Dominik Vogt wrote:
> 
> ----- Forwarded message from Steve Robbins <[email-masked]> -----
> 
> Maybe the original poster's problem is that he/she has something in a
> .bashrc file that stops and waits for input, or does something similarly
> odd.  Changing to #!/bin/sh means that the BASH-specific startup files are
> not run, which explains the change in behaviour.
> 
> Try running the script, then look at 'pstree' to see what is hanging the
> script.  Or check carefully through .bashrc (and maybe something in /etc
> ?).
> 
> P.S.  The way to kill a shell script is with SIGHUP.  I think you have to
> kill off any children, first, though.
> 
> ----- End forwarded message -----
> 
> Might this be the solution for your bash problem?

Hello Dominik,

I just removed the following line from ~/.bashrc and the problem went
away.

---
stty erase ^H
---

BTW, I wasn't able to kill the script using SIGHUP. SIGKILL worked, but
fvwm2 kept waiting. And starting the script in background like "Exec
MyScript.sh &" worked fine too.

Thanks!

Tung
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Dominik Vogt <[email-masked]>
Date: Mon, 9 Aug 1999 07:25:32 +0200

> MyScript.sh &" worked fine too.

Huh? Could you ask at the bash mailing list why this happens? I'm
really interested in this question.

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.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Steve Robbins <[email-masked]>
Date: Mon, 9 Aug 1999 02:13:57 -0400 (EDT)

> I just removed the following line from ~/.bashrc and the problem went

In my .bashrc files, I generally put all the stuff to be executed
in BOTH interactive AND noninteractive shells up front.  Then I put the
following:

	# If this is a non-interactive shell, leave now
	#
	if ! echo "$-" | grep >/dev/null i; then return; fi

And all the stuff for interactive sessions ONLY below this ...

That will avoid your problem.

---

From: Dominik Vogt <[email-masked]>
Date: Mon, 9 Aug 1999 08:09:51 +0200

> That will avoid your problem.

Um, isn't the .login file supposed to be used for interactive
settings?

Bye

Dominik ^_^

---

From: [email-masked] (Paul D. Smith)
Date: 09 Aug 1999 04:05:47 -0400

%% Steve Robbins <[email-masked]> writes:

  sr> In my .bashrc files, I generally put all the stuff to be executed
  sr> in BOTH interactive AND noninteractive shells up front.  Then I put the
  sr> following:

  sr> 	# If this is a non-interactive shell, leave now
  sr> 	#
  sr> 	if ! echo "$-" | grep >/dev/null i; then return; fi

Wow!  Lots 'o processes! :)

What's wrong with the trusty case statement?

  case "$-" in *i*) return ;; esac

I _never_ use if-statements when comparing strings; case is much
faster, and you get globbing for free.  Portable, too! :).

Obviously, this is pretty off-topic ...

-- 
-------------------------------------------------------------------------------
 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.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: [email-masked] (Paul D. Smith)
Date: 09 Aug 1999 04:07:13 -0400

%% Dominik Vogt <[email-masked]> writes:

  dv> Um, isn't the .login file supposed to be used for interactive
  dv> settings?

Unfortunately, .login (or .bash_profile) settings aren't always
propogated everywhere you'd like them to be.

---

From: Dominik Vogt <[email-masked]>
Date: Mon, 9 Aug 1999 10:41:45 +0200

> propogated everywhere you'd like them to be.

?? What kind of settings do you have in mind? For my zsh all my
settings for login shells are these:

  readonly LOGNAME; export LOGNAME
  if [ "$TERM" = "" -o "$TERM" = "unknown" ]; then TERM=linux; fi
  stty hupcl 2> /dev/null

The logname and TERM variables are propagated to all subshells anyway
and the stty setting is needed only once. I never had trouble with this.
(Perhaps I will never understand the daily toild of bash users :-) )

Bye

Dominik ^_^

---

From: Dominik Vogt <[email-masked]>
Date: Mon, 9 Aug 1999 10:49:36 +0200

>   case "$-" in *i*) return ;; esac

Double-Wow! How complicated! With zsh I'd do this:

  [[ -o login ]] && return

or

  [[ -o interactive ]] && return

:-)

Bye

Dominik ^_^

---

From: Julian Gilbey <[email-masked]>
Date: Mon, 9 Aug 1999 10:21:20 +0100 (BST)

> That will avoid your problem.

[ -z "$PS1" ] && return

   Julian

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

  Julian Gilbey, Dept of Maths, QMW, Univ. of London. [email-masked]
        Debian GNU/Linux Developer,  see http://www.debian.org/~jdg
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: [email-masked] (Paul D. Smith)
Date: 09 Aug 1999 11:59:13 -0400

>> propogated everywhere you'd like them to be.

  dv> ?? What kind of settings do you have in mind?

I agree that tty settings should be in the login init file only.  That's
where I have mine set.  Tty settings are useful only on the local host
anyway.

But there are many other kinds of things which should be only set up in
interactive shells, which _aren't_ propogated everywhere.

Functions, aliases, CDPATH settings (think rsh et. al.), etc. etc.

---

From: [email-masked] (Paul D. Smith)
Date: 09 Aug 1999 12:00:59 -0400

PS. Also, currently I'm having a problem where tty settings in my login
    file that are in affect on the console are lost inside
    xterm's/rxvt's when I start X (obviously these don't run the login
    init file).

    I haven't looking into this yet; it happens only on Solaris, not
    SunOS or Linux.  Not sure where the problem lies, exactly.

---

From: [email-masked] (Paul D. Smith)
Date: 09 Aug 1999 12:05:36 -0400

>> case "$-" in *i*) return ;; esac

  dv> Double-Wow! How complicated! With zsh I'd do this:

*shrug* Mine's portable to _most_ sh's, except very old ones.  Even when
writing for files like .bashrc which obviously will never be read by
anything but bash, I prefer to be portable (all things being
equal)--keeps the old reflexes sharp :).

Also, for our environment here I write a number of init setup scripts
which are sourced by everyone; with careful writing I can get the same
script to behave correctly for sh, ksh, bash, and zsh... and this is
part of that.

---

From: [email-masked] (Paul D. Smith)
Date: 09 Aug 1999 12:08:31 -0400

%% Julian Gilbey <[email-masked]> writes:

  jg> [ -z "$PS1" ] && return

Note that it's possible someone (or some app) resets the prompt to be
empty by hand, so this isn't a foolproof test.  It's the most portable,
though, and resetting your prompt to "" is unlikely enough that most
times it doesn't matter in practice.

Nevertheless, I prefer to test $- for i on principle.  Esp. given that
"return" within an init script isn't well-defined in many shells anyway:
often the ones that don't support i in $- don't DTRT with return,
either.

---

From: Julian Gilbey <[email-masked]>
Date: Mon, 9 Aug 1999 17:42:15 +0100 (BST)

> script to behave correctly for sh, ksh, bash, and zsh... and this is

I do the following, based on what Thomas Esser (of teTeX fame) uses.
I have ~/.bash_profile -> ~/Startup/Bash_profile etc.

Those files ending _sys are meant to be standard but could be modified
if necessary.  Those ending _personal are, well, personal!  Some of
the functionality divisions are arbitrary and possibly a little
excessive (for which I take the blame, not Thomas!).  For those using
zsh, this could be modified appropriately, I would guess.

~/Startup/Bash_profile:
-----------------------
sourceif() { test -r "$1" && . "$1"; }
if [ "$PRIVATE_ENVIRON" != YES ]; then
  sourceif $HOME/Startup/Bash_env_sys
  sourceif $HOME/Startup/Bash_env_personal
fi
sourceif $HOME/Startup/Bash_login_sys
sourceif $HOME/Startup/Bash_login_personal
sourceif $HOME/Startup/Bashrc

~/Startup/Bashrc:
-----------------
sourceif() { test -r "$1" && . "$1"; }
if [ "$PRIVATE_ENVIRON" != YES ]; then
        sourceif $HOME/Startup/Bash_env_sys
        sourceif $HOME/Startup/Bash_env_personal
fi
sourceif $HOME/Startup/Bashrc_sys
sourceif $HOME/Startup/Bashrc_personal

if [ ! -z "$PS1" ]; then
        sourceif $HOME/Startup/Bash_functions
        case "`basename $0`" in
            ksh | -ksh | bash | -bash)
                sourceif $HOME/Startup/Bash_aliases;;
        esac
        sourceif $HOME/Startup/Bash_interactive_sys
        sourceif $HOME/Startup/Bash_interactive_personal
fi

   Julian

---

From: Dominik Vogt <[email-masked]>
Date: Tue, 10 Aug 1999 07:51:11 +0200

> Functions, aliases, CDPATH settings (think rsh et. al.), etc. etc.

Ah, I thought .login was for *login* shells, not for *interactive* shells.
Well, juggling with the 10 (in words: ten) config files of my zsh is
complicated enough. I won't try to understand how bash does its
initialisation :-)

Bye

Dominik ^_^

---

From: Dominik Vogt <[email-masked]>
Date: Tue, 10 Aug 1999 07:52:30 +0200

>     xterm's/rxvt's when I start X (obviously these don't run the login

We had a thread about this problem a while ago. I can't remember what
exactly the solution was, but grabbing for bash in the mailing list
archive might help.

Bye

Dominik ^_^

---

From: Dominik Vogt <[email-masked]>
Date: Tue, 10 Aug 1999 07:54:54 +0200

> equal)--keeps the old reflexes sharp :).

Well, I write shell scripts usually in sh syntax, but I wouldn't care
to write my zsh init files in any other but zsh syntax. Apart from this
I consider any environment without zsh badly broken :-)

> script to behave correctly for sh, ksh, bash, and zsh... and this is

Okay. Luckily my sysadmin days are over for now.

Bye

Dominik ^_^

---

From: [email-masked] (Paul D. Smith)
Date: 10 Aug 1999 02:04:38 -0400

>> interactive shells, which _aren't_ propogated everywhere.

  dv> Ah, I thought .login was for *login* shells, not for *interactive*
  dv> shells.

???  It is.  That's my point.  You often need an interactive-only
section in your per-shell config file (.bashrc), too, not just in your
.login... IOW you can't just stick all interactive commands in .login as
a solution.

---

From: Dominik Vogt <[email-masked]>
Date: Tue, 10 Aug 1999 08:38:22 +0200

> .login... IOW you can't just stick all interactive commands in .login as

But isn't there a file that is parsed only for interactive shells in bash?

In zsh commands are read from .zprofile for every shell and from
.zshrc for interactive shells only. Okay, maybe there are people
who prefer not scattering their shell config over a dozen files.

Bye

Dominik ^_^

---

From: [email-masked] (Paul D. Smith)
Date: 10 Aug 1999 10:06:52 -0400

dv> We had a thread about this problem a while ago. I can't remember
  dv> what exactly the solution was, but grabbing for bash in the
  dv> mailing list archive might help.

Note it's not a bash issue; it happens with other shells, too.
Including zsh ;).

I think it's an X server issue, or s'thing.

But, I'll look back through messages discussing bash and see if a
solution was posted, thx.

---

From: Dominik Vogt <[email-masked]>
Date: Tue, 10 Aug 1999 16:25:43 +0200

> solution was posted, thx.

Duh, sorry, I now remember what that problem was. It was about
bash not setting the PS1 variable in xterms. I don't think that
will help you.

Bye

Dominik ^_^

---

From: [email-masked] (Paul D. Smith)
Date: 10 Aug 1999 10:50:57 -0400

dv> Duh, sorry, I now remember what that problem was. It was about
  dv> bash not setting the PS1 variable in xterms. I don't think that
  dv> will help you.

Weird.  This would only happen if bash didn't think it was running
interactively... that's SOP for non-interactive Bourne shells.  I'd be
surprised if zsh behaved differently, since it would break a lot of
shell scripts.

---

From: [email-masked] (Paul D. Smith)
Date: 10 Aug 1999 10:52:26 -0400

dv> But isn't there a file that is parsed only for interactive shells
  dv> in bash?

Nope.  Bash does it the "traditional" way; if you have sections of your
init script you want sourced for interactive shells only, you check to
see if you're interactive and don't do them if not.

---

From: Dominik Vogt <[email-masked]>
Date: Tue, 10 Aug 1999 17:06:23 +0200

> surprised if zsh behaved differently, since it would break a lot of

No, I think we identified it as a bash-only problem back then. I think
the problem was that bash overrides the PS1 prompt when started in a
non-interactive fashion, even if invoked from an interactive parent
shell with an exported PS1. So if you have this

  interactive bash 1, parent of
    non-interactive bash, parent of
      interactive bash 2

You might end up with a default promt in the interactive bash 2
if you export/set PS1 only for login shells. Doesn't happen with
any other shell I tried (zsh, csh, tcsh, ksh).

Bye

Dominik ^_^

---

From: Dominik Vogt <[email-masked]>
Date: Tue, 10 Aug 1999 17:12:49 +0200

> see if you're interactive and don't do them if not.

Hm, the bash manpage is somewhat vague about the config scripts.
It seems that bash sources different files for interactive login
shells (.bash_profile, .bash_login) than for interactive non-login
shells (.bashrc). On the other hand according to the man page it
doesn't read any files for non-interactive shells which is nonsense
in my eyes.

(bash 2.02.1(1))

Bye

Dominik ^_^

---

From: Lee Willis <[email-masked]>
Date: 10 Aug 1999 16:18:23 +0100

> doesn't read any files for non-interactive shells which is nonsense

GNU bash, version 1.14.7(1)

       Non-interactive shells:
         On startup:
               if the environment variable ENV is non-null, expand
               it and source the file it names, as if the command
                       if [ "$ENV" ]; then . $ENV; fi
               had been executed, but do not use PATH to search
               for the pathname.  When not started in Posix mode, bash
               looks for BASH_ENV before ENV.

Lee.
-- 
I was doing object-oriented assembly at 1 year old ...  
For some reason my mom insists on calling it "Playing with blocks"
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Julian Gilbey <[email-masked]>
Date: Wed, 11 Aug 1999 01:28:38 +0100 (BST)

> doesn't read any files for non-interactive shells which is nonsense

A script beginning
#! /bin/bash
would potentially behave in unpredictable ways if it read some startup
file.  This would be unacceptable.  (You can explicitly force this
behaviour by setting BASH_ENV, but beware the consequences!)  No shell
should read startup files by default when invoked non-interactively.

   Julian

---

From: Dominik Vogt <[email-masked]>
Date: Thu, 12 Aug 1999 19:34:21 +0200

> should read startup files by default when invoked non-interactively.

But if you can do it anyway you can as well give the user the
flexibility. And being able to define certain variables for
applications is useful too, e.g.

  export CVSROOT=":pserver:[email-masked]:/home/cvs/fvwm"

I call a script from a menu that does my CVS operations. With zsh
I have .zshenv for this.

Bye

Dominik ^_^

--
Dominik Vogt, [email-masked]
Reply-To: [email-masked]
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]