KILL in 9.3 not killing process
I have a 9.3 system (fairly stock) running amsn 0.95 with the following problem. amsn crashes leaving wish running. Using ksysguard to kill the wish process (pid owner == user of ksysguard) doesn't always work, opening a terminal and using kill (pid number) doesn't work, nor does killall -e wish. Am I missing something in the kill command that would cause it to fail to kill the given pid and in killall to kill a given process by name?
Mike McMullin wrote:
I have a 9.3 system (fairly stock) running amsn 0.95 with the following problem. amsn crashes leaving wish running. Using ksysguard to kill the wish process (pid owner == user of ksysguard) doesn't always work, opening a terminal and using kill (pid number) doesn't work, nor does killall -e wish. Am I missing something in the kill command that would cause it to fail to kill the given pid and in killall to kill a given process by name?
'kill' is a poorly named program. It would be better named 'sendsignal' If you just run 'kill <pid>', what really happens is that the process with that ID receives signal number 15, which is SIGTERM. When a program receives a signal, the signal handler for that signal is invoked. For most signals (you can see a list if you run kill -l) that handler is SIG_IGN, which does nothing at all. For signal 15, the default handler will close down the program. But any program can replace that handler, to ignore the SIGTERM. So just because a program doesn't terminate on 'kill' or 'killall' (which is really the same thing, except you can use program names instead of process IDs) that doesn't necessarily mean it's a bug, the program could just be ignoring the signal. The only signal that can't be ignored, where the system default handler is the only one allowed, is SIGKILL, or signal 9. This signal will cause the program to be unconditionally shut down, removed from the process list, killed. There is, however, a kind of process which can't be killed even by signal 9, and that is a process in state 'D' (Uninterruptible sleep). This state means the process is currently executing a system call, and while that is going on, it can't be interrupted. If the process is in there for more than a fraction of a second or so, then this usually means it's hanging. There are many possible reasons for this, buggy drivers (or bad hardware), trying to read from an NFS or SMB server that has gone away etc etc etc, and they will all result in processes that are unkillable. There are also "processes" in state Z (zombie), which can't be killed, because they are already dead. These are processes that have exited, but they are still listed in the process table, because their parents haven't called the "wait" system call, to clean up after them (a parent's job is never done, eh :)
Mike McMullin wrote:
I have a 9.3 system (fairly stock) running amsn 0.95 with the following problem. amsn crashes leaving wish running. Using ksysguard to kill the wish process (pid owner == user of ksysguard) doesn't always work, opening a terminal and using kill (pid number) doesn't work, nor does killall -e wish. Am I missing something in the kill command that would cause it to fail to kill the given pid and in killall to kill a given process by name?
try ps aux | grep wish kill -9 pid both as user and after su. -- ___ _ _ _ ____ _ _ _ | | | | [__ | | | |___ |_|_| ___] | \/
On Sat, 2006-02-18 at 19:21 -0800, Carl William Spitzer IV wrote:
Mike McMullin wrote:
I have a 9.3 system (fairly stock) running amsn 0.95 with the following problem. amsn crashes leaving wish running. Using ksysguard to kill the wish process (pid owner == user of ksysguard) doesn't always work, opening a terminal and using kill (pid number) doesn't work, nor does killall -e wish. Am I missing something in the kill command that would cause it to fail to kill the given pid and in killall to kill a given process by name?
try ps aux | grep wish kill -9 pid
both as user and after su.
Thanks Carl. I'll give it a try. My wife is also having the same sort of trouble with the same app so I ought to be able to try this out sooner as opposed to later.
On Sun, 2006-02-19 at 03:47 +0100, Anders Johansson wrote:
Mike McMullin wrote:
I have a 9.3 system (fairly stock) running amsn 0.95 with the following problem. amsn crashes leaving wish running. Using ksysguard to kill the wish process (pid owner == user of ksysguard) doesn't always work, opening a terminal and using kill (pid number) doesn't work, nor does killall -e wish. Am I missing something in the kill command that would cause it to fail to kill the given pid and in killall to kill a given process by name?
'kill' is a poorly named program. It would be better named 'sendsignal'
If you just run 'kill <pid>', what really happens is that the process with that ID receives signal number 15, which is SIGTERM.
When a program receives a signal, the signal handler for that signal is invoked. For most signals (you can see a list if you run kill -l) that handler is SIG_IGN, which does nothing at all. For signal 15, the default handler will close down the program. But any program can replace that handler, to ignore the SIGTERM.
So just because a program doesn't terminate on 'kill' or 'killall' (which is really the same thing, except you can use program names instead of process IDs) that doesn't necessarily mean it's a bug, the program could just be ignoring the signal.
This must be what is happening, ignoring the signal.
The only signal that can't be ignored, where the system default handler is the only one allowed, is SIGKILL, or signal 9. This signal will cause the program to be unconditionally shut down, removed from the process list, killed.
There is, however, a kind of process which can't be killed even by signal 9, and that is a process in state 'D' (Uninterruptible sleep). This state means the process is currently executing a system call, and while that is going on, it can't be interrupted. If the process is in there for more than a fraction of a second or so, then this usually means it's hanging. There are many possible reasons for this, buggy drivers (or bad hardware), trying to read from an NFS or SMB server that has gone away etc etc etc, and they will all result in processes that are unkillable.
There are also "processes" in state Z (zombie), which can't be killed, because they are already dead. These are processes that have exited, but they are still listed in the process table, because their parents haven't called the "wait" system call, to clean up after them (a parent's job is never done, eh :)
Nice. The system, user has taken to rebooting (turn power switch off then on) the system in order to gain control when amsn crashes. I think that this is rather drastic and is a holdover from the OS that she really wants to run, but that I don't have a proper license for. So I'm cleaning up after her. ;) Thanks for the info.
On 2/18/06, Mike McMullin
Nice. The system, user has taken to rebooting (turn power switch off then on) the system in order to gain control when amsn crashes. I think that this is rather drastic and is a holdover from the OS that she really wants to run, but that I don't have a proper license for. So I'm cleaning up after her. ;) Thanks for the info.
No need to be so drastic :) The nice explanation of Anders should put you on your way for "mild" solution :) #kill -9 PID This sends SIGKILL to the program, which in most cases will shut it down. Unless one of the exceptions Anders mentioned are reached. But this usually is not the case. Cheers -- -- Svetoslav Milenov (Sunny)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Sunday 2006-02-19 at 11:12 -0600, Sunny wrote:
No need to be so drastic :)
Sometimes you have to kill the parent first, or the children. I use: ps afx|less to see. - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFD+NCqtTMYHG2NR9URAs37AJ9McHuTGfeVjp8Hg6gvzNegyArE5gCePC1g lPvYlOpMrw8ZXgxRL4OfkiY= =IMYX -----END PGP SIGNATURE-----
* Carlos E. R.
Sometimes you have to kill the parent first, or the children. I use:
ps afx|less
to see.
:^) I have a small script called psfind: ps auxf|grep -i $1|grep -iv grep -- Patrick Shanahan Registered Linux User #207535 http://wahoo.no-ip.org @ http://counter.li.org HOG # US1244711 Photo Album: http://wahoo.no-ip.org/gallery2
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Sunday 2006-02-19 at 15:30 -0500, Patrick Shanahan wrote:
ps afx|less
to see.
:^)
I have a small script called psfind: ps auxf|grep -i $1|grep -iv grep
Ah! Interesting. I'll copypaste ;-) [...] Hum! cer@nimrodel:~> psfind postfix root 8735 0.0 0.0 4384 192 ? Ss Feb11 0:20 /usr/lib/postfix/master postfix 17797 0.0 0.1 4584 556 ? S Feb17 0:02 \_ qmgr -l -t unix -u postfix 24242 0.0 0.2 4428 1480 ? S 02:38 0:00 \_ pickup -l -t unix -u cer 24392 0.0 0.2 2708 1176 pts/18 R+ 02:44 0:00 | \_ /bin/sh /usr/local/bin/psfind postfix Hah, it's finding the script as well, it needs a refinement ;-p - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFD+nJqtTMYHG2NR9URAisgAKCLSWbPAOg+qOQxJb2FCVn+aU5yUACaA0Cr eDAa09dKHyBObYJUhKimT6c= =y+DL -----END PGP SIGNATURE-----
* Carlos E. R.
cer@nimrodel:~> psfind postfix root 8735 0.0 0.0 4384 192 ? Ss Feb11 0:20 /usr/lib/postfix/master postfix 17797 0.0 0.1 4584 556 ? S Feb17 0:02 \_ qmgr -l -t unix -u postfix 24242 0.0 0.2 4428 1480 ? S 02:38 0:00 \_ pickup -l -t unix -u cer 24392 0.0 0.2 2708 1176 pts/18 R+ 02:44 0:00 | \_ /bin/sh /usr/local/bin/psfind postfix
Hah, it's finding the script as well, it needs a refinement ;-p
pat@wahoo:~> cat bin/psfind ps auxf|grep -i $1|grep -iv grep pat@wahoo:~> psfind postfix root 3423 0.0 0.0 4176 204 ? S Feb09 0:12 /usr/lib/postfix/master postfix 21894 0.0 0.0 4252 488 ? S 15:00 0:00 \_ qmgr -l -t fifo -u postfix 29150 0.0 0.1 4220 1336 ? S 20:28 0:00 \_ pickup -l -t fifo -u pat@wahoo:~> you did include the last pipe "grep -iv grep" ?? -- Patrick Shanahan Registered Linux User #207535 http://wahoo.no-ip.org @ http://counter.li.org HOG # US1244711 Photo Album: http://wahoo.no-ip.org/gallery2
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Monday 2006-02-20 at 21:45 -0500, Patrick Shanahan wrote:
you did include the last pipe "grep -iv grep" ??
Of course. Now it has: cer@nimrodel:~> cat /usr/local/bin/psfind #!/bin/sh ps auxf|grep -i $1|grep -iv grep | grep -iv /usr/local/bin/psfind and it works. cer@nimrodel:~> psfind postfix root 8735 0.0 0.0 4384 192 ? Ss Feb11 0:22 /usr/lib/postfix/master postfix 17797 0.0 0.1 4584 548 ? S Feb17 0:03 \_ qmgr -l -t unix -u postfix 9404 0.0 0.2 4416 1480 ? S 20:30 0:00 \_ proxymap -t unix -u postfix 9405 0.0 0.3 4564 1864 ? S 20:30 0:00 \_ trivial-rewrite -n rewrite -t unix -u postfix 9675 0.0 0.2 4428 1480 ? S 20:34 0:00 \_ pickup -l -t unix -u If I remove the last grep: #!/bin/sh ps auxf|grep -i $1|grep -iv grep #| grep -iv /usr/local/bin/psfind I find instead: cer@nimrodel:~> psfind postfix root 8735 0.0 0.0 4384 192 ? Ss Feb11 0:22 /usr/lib/postfix/master postfix 17797 0.0 0.1 4584 548 ? S Feb17 0:03 \_ qmgr -l -t unix -u postfix 9675 0.0 0.2 4428 1480 ? S 20:34 0:00 \_ pickup -l -t unix -u cer 9783 0.0 0.2 2708 1176 pts/0 R+ 20:38 0:00 \_ /bin/sh /usr/local/bin/psfind postfix Ie, it is finding the process where the script itself is running. - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFD+211tTMYHG2NR9URAquuAJ9CUibnFFjLqBux7uhrggprjcX3lQCfW/Wz kLTpW6k8ubf90QTXdCMzUGU= =WeOJ -----END PGP SIGNATURE-----
* Carlos E. R.
it has:
cer@nimrodel:~> cat /usr/local/bin/psfind #!/bin/sh ps auxf|grep -i $1|grep -iv grep | grep -iv /usr/local/bin/psfind
and it works.
cer@nimrodel:~> psfind postfix root 8735 0.0 0.0 4384 192 ? Ss Feb11 0:22 /usr/lib/postfix/master postfix 17797 0.0 0.1 4584 548 ? S Feb17 0:03 \_ qmgr -l -t unix -u postfix 9404 0.0 0.2 4416 1480 ? S 20:30 0:00 \_ proxymap -t unix -u postfix 9405 0.0 0.3 4564 1864 ? S 20:30 0:00 \_ trivial-rewrite -n rewrite -t unix -u postfix 9675 0.0 0.2 4428 1480 ? S 20:34 0:00 \_ pickup -l -t unix -u
If I remove the last grep:
#!/bin/sh ps auxf|grep -i $1|grep -iv grep #| grep -iv /usr/local/bin/psfind
I find instead:
cer@nimrodel:~> psfind postfix root 8735 0.0 0.0 4384 192 ? Ss Feb11 0:22 /usr/lib/postfix/master postfix 17797 0.0 0.1 4584 548 ? S Feb17 0:03 \_ qmgr -l -t unix -u postfix 9675 0.0 0.2 4428 1480 ? S 20:34 0:00 \_ pickup -l -t unix -u cer 9783 0.0 0.2 2708 1176 pts/0 R+ 20:38 0:00 \_ /bin/sh /usr/local/bin/psfind postfix
Ie, it is finding the process where the script itself is running.
The first line of your script is the problem: #!/bin/sh remove it and make the file executable and I don't believe the results will include "psfind". -- Patrick Shanahan Registered Linux User #207535 http://wahoo.no-ip.org @ http://counter.li.org HOG # US1244711 Photo Album: http://wahoo.no-ip.org/gallery2
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Tuesday 2006-02-21 at 15:56 -0500, Patrick Shanahan wrote:
The first line of your script is the problem: #!/bin/sh
remove it and make the file executable and I don't believe the results will include "psfind".
Why? All my bash scripts have that line, it is "almost" mandatory. It is used so that the shell knows what interpreter it has to tell load and execute that script, so that they are diferentiated from perl scripts, etc. It also tells editors such as joe or mcedit or vi or emacs to use the correct syntax highlighting - I tried just now all those editors to check this. I see it does have the secondary efect of loading a second bash shell, and that's why it get listed in the output. There must be a better way to tell it to reuse the same shell than removing that line. - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFD+7+otTMYHG2NR9URAmmdAJ4rMLk1vVXZUbKNUu00bpkoGk29ZQCglo6e z/uLPAxw3G4CFhuVy01CnK0= =1vXT -----END PGP SIGNATURE-----
Carlos E. R. wrote:
I see it does have the secondary efect of loading a second bash shell, and that's why it get listed in the output. There must be a better way to tell it to reuse the same shell than removing that line.
How exactly are you determining this? The only way to get the shell script to execute in the current shell is to source it. Either . <script> or source <script> Anything else will cause bash to spawn a subshell for it The #! line needs to be there if you want your script to be executed in anything other than the shell you're currently using, so to be on the safe side it's a good thing to include
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Wednesday 2006-02-22 at 02:46 +0100, Anders Johansson wrote:
Carlos E. R. wrote:
I see it does have the secondary efect of loading a second bash shell, and that's why it get listed in the output. There must be a better way to tell it to reuse the same shell than removing that line.
How exactly are you determining this?
cer@nimrodel:~> cat /usr/local/bin/psfind #!/bin/sh ps auxf and running the script, I see: cer 22262 0.0 0.1 3444 796 pts/18 Ss Feb11 0:00 \_ bash cer 29103 0.0 0.2 2968 1204 pts/18 S+ 12:03 0:00 | \_ /bin/sh /usr/local/bin/psfind postfix cer 29105 0.0 0.1 2820 968 pts/18 R+ 12:03 0:00 | | \_ ps auxf If I modify the script to # ! /bin/sh ps auxf Then I don't see any instance of the script process, nor bash running it. Therefore, the line #!/bin/sh besides telling which one is the interpreter to use, causes it to be loaded. Therefore, I have to use: #!/bin/sh ps auxf |grep -i $1|grep -iv grep | grep -iv /usr/local/bin/psfind instead of: ps auxf |grep -i $1|grep -iv grep as Patrick does.
The #! line needs to be there if you want your script to be executed in anything other than the shell you're currently using, so to be on the safe side it's a good thing to include
I know it is a good thing, that's why I use it. - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFD/EbMtTMYHG2NR9URAtodAJ92wHcMmwdt7mOc3YDgrCuATIH4PACcCcBy nVOdNmg+002Bg9OE8xIl3Uk= =/TwS -----END PGP SIGNATURE-----
On Tue, 2006-02-21 at 02:52 +0100, Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
The Sunday 2006-02-19 at 15:30 -0500, Patrick Shanahan wrote:
ps afx|less
to see.
:^)
I have a small script called psfind: ps auxf|grep -i $1|grep -iv grep
Ah! Interesting. I'll copypaste ;-)
[...]
Hum!
cer@nimrodel:~> psfind postfix root 8735 0.0 0.0 4384 192 ? Ss Feb11 0:20 /usr/lib/postfix/master postfix 17797 0.0 0.1 4584 556 ? S Feb17 0:02 \_ qmgr -l -t unix -u postfix 24242 0.0 0.2 4428 1480 ? S 02:38 0:00 \_ pickup -l -t unix -u cer 24392 0.0 0.2 2708 1176 pts/18 R+ 02:44 0:00 | \_ /bin/sh /usr/local/bin/psfind postfix
Hah, it's finding the script as well, it needs a refinement ;-p
This is one that I use... ps auxww | grep -v grep | grep $* -- Ken Schneider UNIX since 1989, linux since 1994, SuSE since 1998
Hi, On Monday 20 February 2006 20:10, Ken Schneider wrote:
...
This is one that I use...
ps auxww | grep -v grep | grep $*
Using "pidof" obviates the grep to remove the grep(s). My take on this, which I use quite frequently, is called "psp": -==--==--==--==--==--==--==--==--==--==--==--==--==--==--==- #!/bin/bash --norc while [ $# -gt 0 ]; do arg="$1" case "$arg" in -) shift break ;; -*) break ;; *) targets=( "${targets[@]}" "$arg" ) PIDs=( $(pidof "$arg") ) if [ ${#PIDs[*]} -eq 0 ]; then echo "psp: No process running named \"$arg\"" >&2 fi targetPIDs=( ${targetPIDs[*]} ${PIDs[@]} ) ;; esac shift done if [ ${#targetPIDs[*]} -eq 0 ]; then echo "psp: No target processes running" >&2 exit 1 fi ps "$@" ${targetPIDs[@]} -==--==--==--==--==--==--==--==--==--==--==--==--==--==--==- Arguments up to the first one that starts with a hyphen are program names. The rest, if any, are passed to ps as the leading arguments followed by any PIDs discovered (by pidof) for the specified program names. If the first non-program-name argument is a single hyphen, it is not passed to ps.
Ken Schneider
Randall Schulz
On Monday 20 February 2006 18:10, Ken Schneider wrote:
On Tue, 2006-02-21 at 02:52 +0100, Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE-----
I'm not able to run any of these commands as root or myself:
I have a small script called psfind: ps auxf|grep -i $1|grep -iv grep
# ps auxf|grep -i $1|grep -iv grep Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information.
Ah! Interesting. I'll copypaste ;-)
[...]
Hum!
cer@nimrodel:~> psfind postfix root 8735 0.0 0.0 4384 192 ? Ss Feb11 0:20 /usr/lib/postfix/master postfix 17797 0.0 0.1 4584 556 ? S Feb17 0:02 \_ qmgr -l -t unix -u postfix 24242 0.0 0.2 4428 1480 ? S 02:38 0:00 \_ pickup -l -t unix -u cer 24392 0.0 0.2 2708 1176 pts/18 R+ 02:44 0:00 | \_ /bin/sh /usr/local/bin/psfind postfix
# psfind postfix bash: psfind: command not found
Hah, it's finding the script as well, it needs a refinement ;-p
This is one that I use...
ps auxww | grep -v grep | grep $*
# ps auxww | grep -v grep | grep $* Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information.
-- Ken Schneider UNIX since 1989, linux since 1994, SuSE since 1998
Am I doing something wrong? Jerome
On Tue, 2006-02-21 at 09:12 -1000, Susemail wrote:
On Monday 20 February 2006 18:10, Ken Schneider wrote:
On Tue, 2006-02-21 at 02:52 +0100, Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE-----
I'm not able to run any of these commands as root or myself:
I have a small script called psfind: ps auxf|grep -i $1|grep -iv grep
# ps auxf|grep -i $1|grep -iv grep Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information.
Ah! Interesting. I'll copypaste ;-)
[...]
Hum!
cer@nimrodel:~> psfind postfix root 8735 0.0 0.0 4384 192 ? Ss Feb11 0:20 /usr/lib/postfix/master postfix 17797 0.0 0.1 4584 556 ? S Feb17 0:02 \_ qmgr -l -t unix -u postfix 24242 0.0 0.2 4428 1480 ? S 02:38 0:00 \_ pickup -l -t unix -u cer 24392 0.0 0.2 2708 1176 pts/18 R+ 02:44 0:00 | \_ /bin/sh /usr/local/bin/psfind postfix
# psfind postfix bash: psfind: command not found
Hah, it's finding the script as well, it needs a refinement ;-p
This is one that I use...
ps auxww | grep -v grep | grep $*
# ps auxww | grep -v grep | grep $* Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information.
Am I doing something wrong? Jerome
Do you know what a script is? Apparently not. psfind is a file called psfind that contains ps auxf|grep -i $1|grep -iv grep and has the execute bit set. The script I use is called psg and contains ps auxww | grep -v grep | grep $* and slao has the execute bit set (hint: chmod +x psg or psfind). -- Ken Schneider UNIX since 1989, linux since 1994, SuSE since 1998
On Tuesday 21 February 2006 09:36, Ken Schneider wrote:
On Tue, 2006-02-21 at 09:12 -1000, Susemail wrote:
On Monday 20 February 2006 18:10, Ken Schneider wrote:
On Tue, 2006-02-21 at 02:52 +0100, Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE-----
I'm not able to run any of these commands as root or myself:
I have a small script called psfind: ps auxf|grep -i $1|grep -iv grep
# ps auxf|grep -i $1|grep -iv grep Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information.
Ah! Interesting. I'll copypaste ;-)
[...]
Hum!
cer@nimrodel:~> psfind postfix root 8735 0.0 0.0 4384 192 ? Ss Feb11 0:20 /usr/lib/postfix/master postfix 17797 0.0 0.1 4584 556 ? S Feb17 0:02 \_ qmgr -l -t unix -u postfix 24242 0.0 0.2 4428 1480 ? S 02:38 0:00 \_ pickup -l -t unix -u cer 24392 0.0 0.2 2708 1176 pts/18 R+ 02:44 0:00 | \_ /bin/sh /usr/local/bin/psfind postfix
# psfind postfix bash: psfind: command not found
Hah, it's finding the script as well, it needs a refinement ;-p
This is one that I use...
ps auxww | grep -v grep | grep $*
# ps auxww | grep -v grep | grep $* Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information.
Am I doing something wrong? Jerome
Do you know what a script is?
Yes I do, I think: a script is a program run through an interpreter. Isn't any command I enter using the commandline interface a 'script'?
Apparently not. psfind is a file called psfind that contains ps auxf|grep -i $1|grep -iv grep and has the execute bit set.
Is that all it contains? No '#!'s? Is there a way to run ps auxww | grep -v grep | grep $* or ps auxf|grep -i $1|grep -iv grep from the command line?
The script I use is called psg and contains ps auxww | grep -v grep | grep $* and slao has the execute bit set (hint: chmod +x psg or psfind).
-- Ken Schneider UNIX since 1989, linux since 1994, SuSE since 1998
Thanks, for the clarification, Jerome
* Susemail
Is that all it contains? No '#!'s? Is there a way to run ps auxww | grep -v grep | grep $* or ps auxf|grep -i $1|grep -iv grep from the command line?
yes, substitute something for '$1', ie: ps auxf|grep -i mutt |grep -iv grep pat@wahoo:~> ps auxf|grep -i mutt |grep -iv grep pat 30994 0.0 0.5 7244 4264 tty2 S 19:28 0:01 xterm -title mutt -e mutt pat 30996 0.1 0.9 9752 7708 pts/14 S 19:28 0:13 \_ mutt $1 replaces itself with the first command line parameter for the calling script. -- Patrick Shanahan Registered Linux User #207535 http://wahoo.no-ip.org @ http://counter.li.org HOG # US1244711 Photo Album: http://wahoo.no-ip.org/gallery2
On Tue, 2006-02-21 at 17:10 -1000, Susemail wrote:
On Tuesday 21 February 2006 09:36, Ken Schneider wrote:
Do you know what a script is?
Yes I do, I think:
No you don't. A script is a file that contains one or more commands that may or may not have parameters passed to it. That is what the $1 and the $* are looking for.
a script is a program run through an interpreter. Isn't any command I enter using the commandline interface a 'script'?
Apparently not. psfind is a file called psfind that contains ps auxf|grep -i $1|grep -iv grep and has the execute bit set.
Is that all it contains? No '#!'s? Is there a way to run ps auxww | grep -v grep | grep $* or ps auxf|grep -i $1|grep -iv grep from the command line?
The script I use is called psg and contains ps auxww | grep -v grep | grep $* and slao has the execute bit set (hint: chmod +x psg or psfind).
In other words you would run the script like this:
psg postfix or pdfind postfix where postfix is the parameter being passed to the script and the script substitutes postfix for the $*. I use4d $* so that I could pass more then one parameter to the script. -- Ken Schneider UNIX since 1989, linux since 1994, SuSE since 1998
On Tuesday 21 February 2006 18:18, Ken Schneider wrote:
On Tue, 2006-02-21 at 17:10 -1000, Susemail wrote:
On Tuesday 21 February 2006 09:36, Ken Schneider wrote:
Do you know what a script is?
Yes I do, I think:
No you don't. A script is a file that contains one or more commands that may or may not have parameters passed to it. That is what the $1 and the $* are looking for.
A script is also a file that needs to be interpreted to be useful. Like words need a language to be meaningful.
a script is a program run through an interpreter. Isn't any command I enter using the commandline interface a 'script'?
Apparently not. psfind is a file called psfind that contains ps auxf|grep -i $1|grep -iv grep and has the execute bit set.
Is that all it contains? No '#!'s? Is there a way to run ps auxww | grep -v grep | grep $* or ps auxf|grep -i $1|grep -iv grep from the command line?
The script I use is called psg and contains ps auxww | grep -v grep | grep $* and slao has the execute bit set (hint: chmod +x psg or psfind).
In other words you would run the script like this:
psg postfix or pdfind postfix
where postfix is the parameter being passed to the script and the script substitutes postfix for the $*. I use4d $* so that I could pass more then one parameter to the script.
-- Ken Schneider UNIX since 1989, linux since 1994, SuSE since 1998
Actually it's not that easy to find definitions for a script. I managed to find two http://www.webopedia.com/TERM/S/script.html script Last modified: Thursday, February 21, 2002 Another term for macro or batch file, a script is a list of commands that can be executed without user interaction. A script language is a simple programming language with which you can write scripts. http://dictionary.reference.com/search?q=script Computer Science. A simple program in a utility language or an application's proprietary language. Thanks for the discussion, Jerome
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Tuesday 2006-02-21 at 09:12 -1000, Susemail wrote:
I'm not able to run any of these commands as root or myself:
:-)
# ps auxf|grep -i $1|grep -iv grep Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information.
Of course, because the $1 is empty... you are not using it _inside_ an script. Go create it first!
# psfind postfix bash: psfind: command not found
Go create it first! X'-) It is the script Patrick wrote, so how are you going to have it unless you write it up first? - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFD+25mtTMYHG2NR9URAgf5AJ9Ln2zwJReMCbMUAZVt8hfGG6IwMgCeN2WG vDV3WTaTwGQIAv8sAvtLL+4= =XiMs -----END PGP SIGNATURE-----
participants (9)
-
Anders Johansson
-
Carl William Spitzer IV
-
Carlos E. R.
-
Ken Schneider
-
Mike McMullin
-
Patrick Shanahan
-
Randall R Schulz
-
Sunny
-
Susemail