This is part of The Pile, a partial archive of some open source mailing lists and newsgroups.
Subject: Re: command to keep job running after logout?
From: Bill Carlson <wcarlson@vh.org>
Date: Wed, 10 May 2000 08:24:56 -0500 (CDT)
On Tue, 9 May 2000, Barton Hodges wrote:
> I seem to have forgotten what the command
> was to keep a job running even after I log
> out of the console... can anyone help?
nohup is the command you seek...
$nohup big_job &
You have to start the job with nohup, you can't switch it later.
However, bash2 supports a command called disown which allows one to do
that on running jobs (very nice).
===
Subject: RE: command to keep job running after logout?
From: Mike McNally <m5@works.com>
Date: Tue, 9 May 2000 22:29:44 -0500
You can spin it off with
nohup yourcommand &
I personally always keep handy a little "detach" program that
effectively does the same thing, while also severing your
standard IO connections and dropping your control TTY. Here's
the source:
#include <types.h>
#include <unistd.h>
#include <fcntl.h>
#include <ioctls.h>
main(int ac, char **av) {
int i;
for (i = 0; close(i) == 0; ++i);
i = open("/dev/tty", O_RDONLY);
ioctl(i, TIOCNOTTY, (int *) 0);
close(i);
open("/dev/null", O_RDONLY);
open("/dev/null", O_WRONLY);
open("/dev/null", O_WRONLY);
if (fork() == 0)
execvp(av[1], av + 1);
}
Then you can just say
detach yourprogram
===
Subject: Re: command to keep job running after logout?
From: Hidong Kim <hkim@nwrain.com>
Date: Wed, 10 May 2000 04:36:21 -0700
'nohup'
I launch a job like this to keep it going after logging out:
nohup appname < input.file > output.file &
===
Subject: Re: bash script
From: John H Darrah <jhd@giddens.com>
Date: Mon, 15 Mar 1999 08:14:56 -0800 (PST)
On Mon, 15 Mar 1999 deedsmis@ris.net wrote:
> I'm trying to make a bash script with a condition on one line in a
> case that requires numbers beginning with 4 through 20 and an or ( | )
> in the middle ending with 24 through 29. For example: 4-20 | 24-29.
> How do I write this so it will work properly?
Try this:
N=<some_number>
if [ $N -ge 4 -a $N -le 20 -o $N -ge 24 -a $N -le 29 ]
then
echo $N
fi
In addition, the following will work also:
N=<some_number>
[ $N -ge 4 -a $N -le 20 -o $N -ge 24 -a $N -le 29 ] && {
echo $N
}
====
Subject: Re: bash script
From: Cameron Simpson <cs@zip.com.au>
Date: Tue, 16 Mar 1999 05:57:39 +0000
On 15 Mar 1999, in message <Pine.LNX.3.95.990315080924.18252A-100000@homer.giddens.com>
John H Darrah <jhd@giddens.com> wrote:
| On Mon, 15 Mar 1999 deedsmis@ris.net wrote:
| > I'm trying to make a bash script with a condition on one line in a
| > case that requires numbers beginning with 4 through 20 and an or ( | )
| > in the middle ending with 24 through 29. For example: 4-20 | 24-29.
| > How do I write this so it will work properly?
|
| Try this:
|
| N=<some_number>
|
| if [ $N -ge 4 -a $N -le 20 -o $N -ge 24 -a $N -le 29 ]
| then
| echo $N
| fi
|
|
| In addition, the following will work also:
|
| N=<some_number>
|
| [ $N -ge 4 -a $N -le 20 -o $N -ge 24 -a $N -le 29 ] && {
| echo $N
| }
You don't need the curlies there:
[ .... ] && echo blah
will work because there's just one command.
For a third alternative:
case $N in
[4-9]|1[0-9]|2[04-9]) echo blah ;;
esac
Though that's a string oriented approach rather than an arithmetically
oriented approach.
==
Subject: Re: bash programming question
From: Tim Hockin <tphocki@www.orl.ilstu.edu>
Date: Wed, 24 Mar 1999 21:42:48 -0600 (EST)
> It works okay, but the shell complains every time "$[ counter += 1 ]" is
> executed because it does the evaluation and then tried to execute the result.
try I=$((I+1))
it's buried in the bash man page.
==
Subject: Re: bash programming question
From: "Enrico Payne" <enricop@pharma.co.za>
Date: Thu, 25 Mar 1999 14:43:47 +0200
Michael George <george@mintcity.com> wrote:
>On Mar 24, Tim Hockin wrote:
>> > It works okay, but the shell complains every time "$[
>> > counter += 1 ]" is executed because it does the
>> > evaluation and then tried to execute the result.
>> try I=$((I+1))
>>
>> it's buried in the bash man page.
>Yes, that did the trick! Thanks for the advice. I thought
>I'd scoured the man page looking for any clue, but I guess
>I missed it...
You could also try the following, which is more generic...
COUNT=`expr $COUNT + 1`
======
From: "Michael H. Warfield" <mhw@wittsend.com>
Date:
Type "set" to display all of your variables or "env" for the
variables which are exported (will be copied to children processes).
=====
From: Cameron Simpson <cs@zip.com.au>
Date:
| Is there something special I need to do here ?
The command line arguments are being read correctly - they're just not
being _passed_in_ correctly.
In the shell:
$* All arguments, but like any other variable, space
interpretation is done, which breaks them up and of course
"vanishes" the empty ones.
"$*" All arguments, not space interpretation (but that of course
turns it into _one_ argument - not what you want)
$@ Just like $*
"$@" All arguments, correctly quoted. This is a special piece of
magic intended expressly for passing the argument list
to other commands intact.
So, "$@" is what you want - almost. There's a historical bug with this
of long standing. If you have no arguments at all, "$@" is the same as ""
(i.e. a single empty argument - no what you want). I imagine the reasoning
was that you've got a quoted thing there and it mustn't just vanish, but
generally it's not what you want.
So, we reach for parameter stuff and read in the manual (man sh):
Parameter Substitution
[...]
${parameter:+word}
If parameter is set and is non-null, substitute word;
otherwise substitute nothing.
[...]
If the colon (:) is omitted from the above expressions, the
shell only checks whether parameter is set or not.
So the incantation you really want is:
${1+"$@"}
This says "if $1 is defined (==> we have more than zero arguments)
insert "$@", otherwise insert nothing". And lo, the "$@" problem with
no arguments is worked around.
Learn it - love it. It is the standard robust way to pass your current
argument list to a subcommand.
You now want to say:
exec usernew ${1+"$@"}
Simple and robust.
=====
Subject: Re: List My Environment Variables
From: Ahbaid Gaffoor <ahbaidg@guyana.net.gy>
Date: Fri, 26 Mar 1999 14:24:28 -0600
Hi,
to set a variable:
VARIABLE="Hello World"
typing "export VARIABLE" makes it available to child processes
to release a variable type "unset VARIABLE"
to see the contents of the variable type "echo $VARIABLE"
you can store results of commands in variables too like:
MYPROMPT=`pwd`
===
From: Mike Cole <mike@mydot.com>
Date:
I tried it and it doesn't work here either, all though this does
$ echo "a b c" > /tmp/echotmp
$ read v1 v2 v3 < /tmp/echotmp
$ echo $v1
a
$ echo $v2
b
$ echo $v3
c
===
Subject: Re: Suppressing CR in scripts
From: brian <bunicula@mediaone.net>
Date: Fri, 21 May 1999 08:43:36 -0400 (EDT)
On Fri, 21 May 1999, Pete wrote:
> echo "testing..\c"
echo -n "testing..."
====
Subject: Re: Remapping keys under linux console
From: "Steve \"Stevers!\" Coile" <scoile@redhat.com>
Date: Mon, 24 May 1999 17:44:03 -0400 (EDT)
On Mon, 24 May 1999, Kayvan Aghaiepour Sylvan wrote:
> In a shell prompt, do:
>
> stty intr ^VDEL
>
> i.e. Type "stty intr" then Control-V then your delete key and hit
> return.
You can actually use the caret (^) to indicate control characters.
So you could instead do:
stty intr '^?'
(s t t y space i n t r space apostrophe caret question-mark apostrophe)
If you write scripts that remap keys, I recommend using this method
rather than embedding control characters.
===
Subject: Re: Bash shell guru's - why "passwd" command with redirected input
From: "Steve \"Stevers!\" Coile" <scoile@redhat.com>
Date: Sun, 6 Jun 1999 12:21:22 -0400 (EDT)
On Sun, 6 Jun 1999, Russell Salerno wrote:
> Try this:
>
> # echo user:new-password | /usr/sbin/chpasswd
>
> or
>
> # echo $1:$2 | /usr/sbin/chpasswd
>
> where $1 is the account and $2 is the password
Both of those are security risks. Better:
/usr/sbin/chpasswd <<-EOT
${1}:${2}
EOT
where "${1}" and "${2}" are the username and password, respectively.
===
Subject: Re: Bash shell guru's - why "passwd" command with redirected inputfile fails
From: "CL" <boston@brain-tree.com>
Date: Sun, 6 Jun 1999 14:34:48 -0400
: On Sun, 6 Jun 1999, Russell Salerno wrote:
: > Try this:
: >
: > # echo user:new-password | /usr/sbin/chpasswd
: >
: > or
: >
: > # echo $1:$2 | /usr/sbin/chpasswd
: >
: > where $1 is the account and $2 is the password
:
:
:
: From: Steve "Stevers!" Coile <scoile@redhat.com>
: Date: Sunday, June 06, 1999 12:21 PM
:
: Both of those are security risks. Better:
:
: /usr/sbin/chpasswd <<-EOT
: ${1}:${2}
: EOT
:
: where "${1}" and "${2}" are the username and password, respectively.
: --
: Steve Coile Red Hat, Inc.
scoile@redhat.com
: Systems Administrator www.redhat.com (919)
547-0012
Thanks so much. They both worked.
The latter form has the added benefit of fitting elegantly in a perl script
which I was trying out as an exercise, in case there are any other perl
folks on this list:
#!/usr/bin/perl
$user="dummy";
$pass="dumb";
print <<`EOS`; #execute following as shell commands
echo Starting
/usr/sbin/chpasswd <<+
${user}:${pass}
+
echo Ending
EOS
Incidentally, why is the "here document" form less of a security risk than
piping to /usr/sbin/chpasswd? Thanks again.
===
Subject: Re: Bash shell guru's - why "passwd" command with redirected inputfile
From: "Steve \"Stevers!\" Coile" <scoile@redhat.com>
Date: Sun, 6 Jun 1999 15:27:11 -0400 (EDT)
On Sun, 6 Jun 1999, CL wrote:
> The latter form has the added benefit of fitting elegantly in a perl script
> which I was trying out as an exercise, in case there are any other perl
> folks on this list:
> #!/usr/bin/perl
> $user="dummy";
> $pass="dumb";
> print <<`EOS`; #execute following as shell commands
> echo Starting
> /usr/sbin/chpasswd <<+
> ${user}:${pass}
> +
> echo Ending
> EOS
What's the point of making that a Perl script? The equivalent Bash
script:
----- begin -----
#!/bin/bash
echo Starting
/usr/bin/chpasswd <<-EOT
${1}:${2}
EOT
echo Ending
----- end -----
> Incidentally, why is the "here document" form less of a security risk than
> piping to /usr/sbin/chpasswd? Thanks again.
Because your command line is viewable by everyone else on the system
using the "ps" command.
===