Re: Execute all processes in the background from bash.

From: Chris F.A. Johnson (c.fa.johnson_at_rogers.com)
Date: 05/21/04

  • Next message: Alan Connor: "Phase 2 (is: Man Pages in Text?)"
    Date: 21 May 2004 21:49:18 GMT
    
    

    On 2004-05-21, Kevin Collins wrote:
    > In article <2h4lflF8vjh8U1@uni-berlin.de>, Chris F.A. Johnson wrote:
    >> On 2004-05-20, Kevin Collins wrote:
    >>> In article <7960d3ee.0405200757.2b49b50f@posting.google.com>, Doug Freyburger
    >>> wrote:
    >>>> Ed Morton wrote:
    >>>>> Doug Freyburger wrote:
    >>>>>
    >>>>> > When I intend to run a command very often, I write a small script
    >>>>> > and name it "x" somewhere in my path. It would be something like:
    >>>>>
    >>>>> > #! /bin/bash
    >>>>> > time ${1} &
    >>>>>
    >>>>> You might want to make the above:
    >>>>> time "$@" &
    >>>>> so you capture arguments.
    >>>>
    >>>> Good point.
    >>>>
    >>>>> > exit
    >>>>>
    >>>>> No need for the exit.
    >>>>
    >>>> True but there isn't necessarily need for the magic number in the first
    >>>> line, either. I put them into all of my scripts for cleanliness reasons.
    >>>
    >>> I assume you mean the "shebang" entry (#!/bin/bash)? If so, there is a need for
    >>> it, unless you want all your scripts to run as /bin/sh, which you probably
    >>> don't. :)
    >>
    >> Depending which shell you are running, scripts without a shebang
    >> may be run by that shell, or by /bin/sh. For example, bash itself
    >> will execute a script without a shebang, but pdksh will use
    >> /bin/sh (or is it $SHELL?).
    >
    > Per a quick glance at the pdksh manpage, its $EXECSHELL

        Which is undefined in the instance of pdksh I'm running.

    >> There are systems (probably few left now) which do not understand the
    >> shebang line at all.
    >>
    >> And I use systems with three different locations for bash, so #!/bin/bash
    >> will not work on all of them. But they usually will work on all of them
    >> if there is no shebang.
    >
    > I was not aware of that - I stand corrected. I guess I'm just thinking of ksh
    > and csh. However, what happens when someone running csh or ksh or some such
    > then runs one of your scripts with no shebang?

        That depends on what system it's running on and how it's run.

        If the person is calling the script from csh, it'll use /bin/sh;
        on most Linux and *BSD systems the chances are that it will run
        without any problems.

        If called from ksh, it will run in ksh, and again, chances are
        there will not be any problems.

        Often the script will run even under a Bourne shell; that's the
        point of writing in as portable a manner as possible, saving
        POSIX, ksh or bash extensions for when they make a significant
        difference.

        Most of my scripts will run in any POSIX shell, and many in a
        Bourne shell. Otherwise, they have to be properly installed or run
        as an argument to a shell command (bash path_to_script).

    > It won't be running under bash...

    -- 
        Chris F.A. Johnson                  http://cfaj.freeshell.org/shell
        ===================================================================
        My code (if any) in this post is copyright 2004, Chris F.A. Johnson
        and may be copied under the terms of the GNU General Public License
    

  • Next message: Alan Connor: "Phase 2 (is: Man Pages in Text?)"

    Relevant Pages

    • Re: Style and subroutines in Perl Programs
      ... The shebang has to be first if it is going to be meaningful. ... On some scripts, there are comments right after the shebang line ... I generally put the subroutines after the main code. ... I usually don't use unconditional exit statements. ...
      (comp.lang.perl.misc)
    • Re: Style and subroutines in Perl Programs
      ... The shebang has to be first if it is going to be meaningful. ... On some scripts, there are comments right after the shebang line ... I generally put the subroutines after the main code. ... I usually don't use unconditional exit statements. ...
      (comp.lang.perl.misc)
    • Re: [PATCH] Linux 2.6: shebang handling in fs/binfmt_script.c
      ... > don't split the optional shebang argument, ... > script files and their interpreters (shells, awk, perl, python, guile, ... This may be right for awk, although I still consider wrapper scripts to ... But your argument is not true for shells, perl, ...
      (Linux-Kernel)
    • Re: Shebang or Hashbang for modules or not?
      ... The shebang doesn't do you any good unless it's also in the presence of a file that has its executable bit set. ... And I also have lots of files which are not intended to be executed which are also shell scripts, but which are sucked in by the shell "." ... Lots of these shell "library" scripts can't execute as standalone. ...
      (comp.lang.python)
    • Re: Shebang or Hashbang for modules or not?
      ... The shebang doesn't do you any good unless it's also in the presence of a file that has its executable bit set. ... And I also have lots of files which are not intended to be executed which are also shell scripts, but which are sucked in by the shell "." ... Lots of these shell "library" scripts can't execute as standalone. ...
      (comp.lang.python)