I am coding on a Red Hat Machine and I want to get the process id of a process in the interactive mode as well as the in a script.
In bash 'pidof' works but not in zsh.
What would be the equivalent of pidof in zsh ?
Thank you in advance.
You may wish to which pidof in bash, to determine the location of pidof and then try running zsh with the absolute path.
If the above works, you just have a $PATH issue (as I have never seen pidof as a bash builtin.)
If that doesn't work try the following:
This is probably not a simple as you want, but it works for me:
pgrep -U $USER some_program
Where 'some_program' is the name you would normally supply pidof.
On a RHEL (Red Hat Enterprise Linux) machine pidof is located at /sbin/pidof. Just add /sbin to your path.
Related
First of all, sorry for dummy question.
I would like to get distribution information from remote target by using following sample code under shell script. My local machine is Ubuntu16.04 and remote target is Ubuntu20.04(192.168.100.15). However, when I run shell script, the $distribution value is ubuntu16.04.
Why the value is not Ubuntu20.04? and How should I modify my code correctly?
ssh root#192.168.100.15 "distribution=$(. /etc/os-release;echo ) && echo $distribution"
Check the contents of /etc/os-release to find out which variables are available, then echo one of those. For example:
$ ssh root#192.168.100.15 '. /etc/os-release; echo $PRETTY_NAME'
Ubuntu 20.04.3 LTS
If you want to populate the distribution variable on your local machine, you need to use the $(...) construct locally:
$ distribution=$(ssh root#192.168.100.15 '. /etc/os-release; echo $PRETTY_NAME')
$ echo $distribution
Ubuntu 20.04.3 LTS
By the way, giving ssh access to the root user is frowned upon nowadays. And using root in this case is entirely unneccesary anyway, because /etc/os-release is world-readable to any user.
Use lsb_release:
ssh root#192.168.100.15 'lsb_release -ds'
LSB means Linux Standard Base. The command should be available on every Linux system.
I have a bash script lets say test.sh. This script contains the following:
#!/bin/bash
echo "khaled"
ads2 svcd&
This script simply prints my name (just for test purposes) and execute ads-service application in the background. When i run the script on my ubuntu, it works correctly. As a test i checked which programs run on the kernel
As you see. ads2 runs and has 12319 process-id.
Now what I'm trying to do is to run the script on the ubuntu, however remotely from a windows pc.
Therefore i opened command-line on windows and executed the following command:
ssh nvidia#ubuntu ip-address ~/test.sh
And i get the following
As you see the scripts run and prints khaled,however on windows command line and what i want is that the script is executed on the ubuntu. this justify why the lineads2 svcd& doe not do anything, neither on windows (which makes sense, since ads2 is installed on ubuntu) nor on linux.
So how can i execute the script on ubuntu ?
thanks in advance
Use the full path to start ads2. When using remote SSH your environment variables may be different than in a local shell.
#!/bin/bash
echo "khaled"
/home/nvidia/ads2 svcd&
Not sure where ads2 is located.
Try the following to locate it on your Ubuntu local shell.
command -v ads2
You may also need nohup to persist the process beyond the life of the SSH session.
If you have the script on the remote server and you want to run this, you would add back ticks,
ssh user#server './test/file.sh'
The script's output would be sent to your local machine, as if you ran the command from your local machine.
I installed debian strech yesterday. I installed fish shell . I change the default shell to fish by the following
su chsh -s 'which fish'
Then again enter the this command
su chsh -s `which fish`
Now after I restart the PC I encountered the following error while using "su"
sathish#localhost ~> su
Password:
Cannot execute which fish: No such file or directory
Did you mean to use regular single-quote chars in your first command? Doing so means your shell is now literally the string which fish rather than the path to the fish command. That explains why your second command reports that it cannot execute "which fish". Even without that mistake it is a really bad idea to change the default shell for your root account. You're just asking for trouble. And I say that as a core fish developer. Unless you are an extremely competent and confident CLI user you should not change the root shell. You can always do exec fish -l after su if you want fish as your root shell.
I am writing a portable shell script to get system process information, I need process id, command, pwdx (linux). On linux I am able to get this information as follows.. but it fails on all other unix flavours.
$ ps -awwwwwww -u <userid> -o pid,cmd|grep -i <filter_term> | egrep -v grep
$ pwdx <pid>
what I should use on AIX, HPUX and Solaris to get the similar information, or there any cross platform command
On Solaris I have tried /usr/ucb/ps but that support formatted output and lsof for pwdx equivalent but that also doesn't show what I need
On Solaris I have tried /usr/ucb/ps but that support formatted output:
What is wrong with formatted output ?
and lsof for pwdx equivalent but that also doesn't show what I need.
That doesn't make sense. pwdx is a Solaris native command and was even originally implemented on that OS.
Linux != Unix. And in the same hand, the commands are not always going to be the same, for instance GNU ps is not like Solaris ps or HP-UX ps etc. In some cases the Vendor Unix flavors offer a "compatibility binary" like those stashed in /usr/ucb on solaris. But ultimately you need to look at the man page for each version and review the output format options.
Edit. That is for in general all commands. Including grep, egrep etc.
To show the full command name, use this
ps -eo comm
This will show the command that was run. (ps is from /usr/bin on my Solaris system 5.11)
I have a script which uses killproc and procofpid commands and executes fine on a 64bit suse. But when I executed the script on 32bit redhat , I found that the above commands donot exist.
I don't have a 32bit Suse and 64bit redhat machines to test my script.
Is my guess right that on 64bit redhat the above commands should be available?
Or are the above commands specific to Suse and redhat?
Thanks
killproc is in redhat enterprise linux 5.4 as part of /etc/init.d/functions
if you need it just do
. /etc/init.d/functions
in your script to load the shell functions, its probably in other versions of redhat but thats the only one i have to hand at the moment
These commands are defined as part of the Linux Standards Base (LSB), as noted by #AndreKR.
However, on some systems like Redhat (and probably SUSE), depending on packages installed, these functions may not be defined in the location specified by the LSB, which is /lib/lsb/init-functions. Rather they are defined within /etc/init.d/functions. In addition, in some versions, the Redhat variant of /etc/init.d/functions is missing the LSB-defined function start_daemon. If you add the following snippet to the top of your script, it should be portable across most distributions/installs:
if [[ -f /lib/lsb/init-functions ]]; then
. /lib/lsb/init-functions
elif [[ -f /etc/init.d/functions ]]; then
. /etc/init.d/functions
# Pretend to be LSB-compliant
function start_daemon() {
daemon $*
}
else
echo "Linux LSB init function script or Redhat /etc/init.d/functions is required for this script."
echo "See http://refspecs.linuxfoundation.org/LSB_4.1.0/LSB-Core-generic/LSB-Core-generic/iniscrptfunc.html"
exit 1
fi
The commands are unlikely to be portable. Actually this is first time I hear about them - but I guess your problem is to work with process by the name, not pid.
Check the man pgrep or man pkill - they are slightly bit more portable. They are part of procps package (where ps and top come from) and should be available on all Linux variants. They are also available on Solaris.
The ones used in Ubuntu are part of the specification "Linux Standard Base" and are documented there.
I think those commands are distrib specifics: I have never seen them before.
killproc should be a kind of kill but what is procofpid supposed to do?
In the title you speak about pidofproc, you can find this command under the pidof on most linux boxes.
I had the same problem as you, it gave the warning:
pidof: invalid options on command line!
I changed the
"killproc -d 10 $cmd"
to
"kill -9 \`pidof $cmd\`"